This directory captures significant architectural decisions made in Fund-My-Cause — what was decided, why, and what alternatives were considered.
An ADR is a short document that records a single architectural decision. It is immutable once accepted: if a decision is reversed, a new ADR supersedes the old one rather than editing it.
Write an ADR when you are making a decision that:
- Is hard or expensive to reverse (on-chain data models, token flows, cross-service contracts)
- Will surprise a future contributor without context
- Involves a trade-off between two or more reasonable alternatives
- Affects more than one layer of the stack (contract + frontend, indexer + API, etc.)
You do not need an ADR for routine implementation choices (which library to use for formatting, file naming conventions, etc.).
- Copy
template.mdto a new file:ADR-NNN-short-title.md(zero-padded, e.g.ADR-004-fee-model.md). - Fill in every section. Leave
Status: Proposeduntil the decision is merged. - Open a pull request. Discussion happens on the PR.
- Once merged, status becomes
Accepted. - If a later ADR supersedes this one, update the
Statusline toSuperseded by ADR-NNNand add the forward link in the new ADR'sContextsection.
| ADR | Title | Status |
|---|---|---|
| ADR-001 | Pull-based refund model | Accepted |
| ADR-002 | Off-chain indexer architecture | Accepted |
| ADR-003 | GraphQL API for frontend queries | Accepted |
| ADR-004 | Soroban contract module boundaries (contracts/common) |
Proposed |
| ADR-005 | Keeping fraud_detection and recommendations as separate services |
Proposed |
| ADR-006 | Unify Frontend Chain Read Paths via GraphQL API | Proposed |
| ADR-007 | Stellar contract upgrade strategy & state migration | Accepted |