| order | parent | |
|---|---|---|
1 |
|
This is a location to record all high-level architecture decisions in the CometBFT project.
You can read more about the ADR concept in this blog post.
An ADR should, with a strong focus on the impact on users of the system, provide:
- Context on the relevant goals and the current state
- Proposed changes to achieve the goals
- Summary of pros and cons
- References
- Changelog
To create a new ADR, please use the ADR template.
Note the distinction between an ADR and a spec. An ADR provides the context, intuition, reasoning, and justification for a change in architecture, or for the architecture of something new. A spec is more compressed and streamlined summary of everything as it stands today.
If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match.
Note the context/background should be written in the present tense.
The following ADRs are exclusively relevant to CometBFT. For historical ADRs relevant to Tendermint Core as well, please see this list. To distinguish CometBFT ADRs from historical ones from Tendermint Core, we start numbering our ADRs from 100 onwards.
- ADR-101: Data companion pull API
- ADR-102: RPC Companion
- ADR-103: Protobuf definition versioning
- ADR-104: State sync from local snapshot
- ADR-105: Refactor list of senders in mempool
- ADR-106: gRPC API
- ADR-107: Rename protobuf versions of 0.x releases to pre-v1 betas
- ADR-109: Reduce CometBFT Go API Surface Area
- ADR-111:
nopMempool - ADR-112: Proposer-Based Timestamps
- ADR-114: Partly Undo ADR 109
- ADR-115: Predictable Block Times