Terp Network Docs

ADR

Architectural Decision Records for Terp Network

ADR Index

Status Definitions

  • DRAFT — Under initial authorship, not yet open for review
  • Proposed — Open for community and core-team review (minimum one week)
  • Accepted — Approved and binding on all future work
  • Rejected — Not adopted; preserved for historical reference
  • Deprecated — Superseded by a later ADR; the replacement is linked in the document
  • Superseded — Replaced by a specific later ADR

Three-Layer ADR Hierarchy

Terp Network inherits architectural decisions from three upstream layers. Before proposing any change, traverse all three:

  1. Cosmos SDK ADRs — 63 ADRs covering store management, module wiring, testing, and core SDK mechanics. Start with ADR-041, ADR-059, ADR-063, ADR-065.
  2. IBC-go ADRs — 15 ADRs governing inter-chain communication, relayers, and middleware. Critical: ADR-027 (IBC wasm client).
  3. Terp-core module specs — Local specs under x/<module>/spec/ covering feeshare, drip, and custom module behavior.

When layers conflict, the most specific layer wins — but the conflict must be documented as a Terp-specific ADR.

Proposing a New ADR

  1. Open a PR with the ADR in DRAFT status using the template from ADR-1
  2. Allow at least one week for community and core-team review
  3. Security reviewers must sign off on crypto-related ADRs
  4. Only maintainers may change status to Accepted/Rejected
  5. Link the ADR from code, specs, and upgrade documentation

Upstream ADR Discovery

All three layers are indexed in QMD's abstract collection. Use semantic search to find relevant decisions:

  • oline-qmd search 'store migrations' -c abstract — keyword search
  • oline-qmd query 'how does the SDK handle module state upgrades' -c abstract — hybrid semantic search

See ADR-9 for the full LM-augmented development pipeline.

On this page