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.

ADR #	Description	Status
001	ICS-20 coin denomination format	Accepted, Implemented
002	Go module versioning	Accepted
003	ICS27 acknowledgement format	Accepted
004	ICS29 module locking upon escrow out of balance	Accepted
005	`UpdateClient` events - `ClientState` consensus heights	Accepted
006	ICS02 client refactor	Accepted
007	ICS06 Solo machine sign bytes	Accepted
008	Callback to IBC Actors	Accepted
009	ICS27 message server addition	Accepted
010	IBC light clients as SDK modules	Accepted
011	ICS20 state entry for total amount of tokens in escrow	Accepted
015	IBC Packet Routing	Accepted
025	IBC passive channels	Deprecated
026	IBC client recovery mechanisms	Accepted
027	Wasm based light clients	Accepted

Introduction

IBC Core

IBC Migrations

IBC Light Clients

IBC Apps

IBC Middleware

Security

Architecture Decision Records

Changelog

Repositories

Architecture Decision Records (ADR)

Table of Contents

​Table of Contents

Table of Contents