Skip to content

Latest commit

 

History

History
38 lines (27 loc) · 2.21 KB

README.md

File metadata and controls

38 lines (27 loc) · 2.21 KB

Architecture Decision Records (ADRs)

This directory captures significant architectural decisions made in Fund-My-Cause — what was decided, why, and what alternatives were considered.

What is an ADR?

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.

When to write an ADR

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.).

How to add a new ADR

  1. Copy template.md to a new file: ADR-NNN-short-title.md (zero-padded, e.g. ADR-004-fee-model.md).
  2. Fill in every section. Leave Status: Proposed until the decision is merged.
  3. Open a pull request. Discussion happens on the PR.
  4. Once merged, status becomes Accepted.
  5. If a later ADR supersedes this one, update the Status line to Superseded by ADR-NNN and add the forward link in the new ADR's Context section.

Index

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