Overview
This is a location to record all high-level architecture decisions in the Interchain Security project.
You can read more about the Architecture Decision Record (ADR) concept in this blog post.
An ADR should provide:
- Context on the relevant goals and the current state
- Proposed changes to achieve the goals
- Summary of pros and cons
- References
- Changelog
Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and justification for a change in architecture, or for the architecture of something new. The spec is much more compressed and streamlined summary of everything as it is or should be.
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.
To suggest an ADR, please make use of the ADR template provided.
Table of Contents
Accepted
- ADR 001: Key Assignment
- ADR 002: Jail Throttling
- ADR 004: Denom DOS fixes
- ADR 005: Cryptographic verification of equivocation evidence
- ADR 008: Throttle with retries
- ADR 010: Standalone to Consumer Changeover
- ADR 013: Slashing on the provider for consumer equivocation
- ADR 014: Epochs
- ADR 015: Partial Set Security
Proposed
- ADR 011: Improving testing and increasing confidence
- ADR 016: Security aggregation
- ADR 017: ICS with Inactive Provider Validators