Architecture Decision Records (ADRs) capture significant architectural and design decisions along with their context and consequences.
Write an ADR when making:
- Architectural decisions - Core design patterns, system boundaries, major component interactions
- Significant features - Major new capabilities, new precompile types, transaction pool changes, new APIs
If a decision affects multiple components or has lasting implications, it likely warrants an ADR.
- Copy
TEMPLATE.mdtoNNNN-title-slug.md(use the next available number) - Fill in the template sections
- Set status to
Draft - Open a pull request
- Discuss in PR comments until consensus emerges
- Update status to
Proposedwhen ready for final review - Update status to
AcceptedorRejectedbased on outcome - Merge the PR
- Update the index table below
| State | Description |
|---|---|
| Draft | Initial proposal, open for early feedback |
| Proposed | Ready for review |
| Accepted | Approved and should be followed |
| Rejected | Declined with documented reasoning |
| Superseded | Replaced by a newer ADR |
| ADR | Title | Status | Date |
|---|---|---|---|
| 0001 | ADR Process | Proposed | 2025-12-11 |
| 0002 | Block Dissemination Protocol | Draft | 2026-01-13 |
| 0003 | Dynamic Block Gas Limit Configuration Validation | Draft | 2026-02-20 |
| 0004 | Base Fee Parameter Validation | Draft | 2026-03-03 |