Skip to main content

Architecture Decision Records (ADR)

This is a location to record all high-level architecture decisions in the ibc-go project.

You can read more about the 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‚Äč

ADR #DescriptionStatus
001ICS-20 coin denomination formatAccepted, Implemented
002Go module versioningAccepted
003ICS27 acknowledgement formatAccepted
004ICS29 module locking upon escrow out of balanceAccepted
005UpdateClient events - ClientState consensus heightsAccepted
006ICS02 client refactorAccepted
007ICS06 Solo machine sign bytes
008Callback to IBC ACtorsAccepted
009ICS27 message server additionAccepted
010IBC light clients as SDK modulesAccepted
011ICS20 state entry for total amount of tokens in escrowAccepted
015IBC Packet RoutingAccepted
025IBC passive channelsDeprecated
026IBC client recovery mechansismsAccepted
027Wasm based light clientsAccepted