+
+| Priority |
+User story |
+Status |
+Notes |
+
+
+| P0 |
+As a blockchain operations engineer, I deploy the IBC contracts (clients, IFT token, GMP) on each EVM chain and open the connection, so that two EVM chains can exchange packets without a hand-built deploy sequence |
+Not started |
+Replaces 9+ manual deploy txs for EVM. The broader CLI surface (query, config validate, db migrate) is eng's call, potential scope cut |
+
+
+| P0 |
+As a blockchain operations engineer, I run the relayer, attestor, and signer from one binary and one config, so that I operate the whole stack as one service |
+Not started |
+Consolidation mechanism (storage, etc.) is eng's to hash out |
+
+
+| P0 |
+As a token developer, I issue an IBC-enabled token (IFT) and move it between the two chains, so that I have a working cross-chain token |
+Not started |
+IFT = our interchain fungible token, IBC-native (not Axelar's ITS) |
+
+
+| P0 |
+As a blockchain operations engineer, the binary auto-relays packets and handles proofs, submission, retries, and failure recovery with a status API, so that nothing gets stuck and I don't build an event loop |
+Not started |
+ |
+
+
+| P1 |
+As an application developer, I use GMP to make cross-chain contract calls between the two chains, so that I can build IBC apps beyond token transfer |
+Not started |
+GMP ships in the release; per Barry, not the priority story yet |
+
+
+| P0 |
+As a blockchain operations engineer, I can run it in production and in tests because it's Apache 2.0 |
+Not started |
+Today's stack is source-available, which blocks production and third-party testing |
+
+
+### Decisions adopted
+- One core relaying solution: a single Go binary, one YAML, SQLite default, Postgres optional.
+- Port the Rust components (ProofAPI, attestor) to Go. This is a rewrite and needs an internal security audit; the rationale is that team expertise is Go.
+- Consolidate relayer and ProofAPI; built-in auto-relay; move the remote signer in-repo.
+- Components as libraries wrapped in processes, so local and remote attestors and signers can mix.
+- Attestor-based connections, not a zk light client (SP1 is out of V1).
+- Apache 2.0.
+- "IBC" means the current version; no legacy.
+- Product name: IBC Link.
+### Architecture
+**Current state.** Relayer in `cosmos/platform` (Postgres state, gRPC-triggered relay, no auto-relay, no CLI). ProofAPI in Rust in `cosmos/ibc-contracts` (renamed from `solidity-ibc-eureka`; Tendermint sig+merkle, SP1 ZK, attestor signatures; uses Succinct SP1). Attestor in Rust in `cosmos/ibc-attestor` (queries a chain, signs packets; the relayer publishes aggregated signatures verified on-chain). Three config formats, 9+ deploy txs for EVM, manual wiring. Not self-serviceable.
+**Target state.** One Go binary, one YAML config. The relayer absorbs ProofAPI aggregation in-process. SQLite default, Postgres optional. The platform's remote signer moves in-repo. The release centers on three repos: `cosmos/ibc` for the Go relayer, attestor, and signer, `cosmos/ibc-go` for the IBC modules, and `cosmos/ibc-contracts` for the Solidity contracts. Relayer, attestor, and signer are libraries wrapped in processes, which enables a combined mode (sandbox/PoC), an in-process attestor (a consortium member runs the relayer plus its own attestor in one binary), or a distributed consortium (remote attestors and signers). Detailed design lives in Dmitry's IBC Infra Revamp Proposal.
+### CLI (`ibc-link`)
+One binary drives the whole lifecycle. The config names every connection; connection-scoped commands take the connection explicitly, with no implicit "all," and you run one connection per process for failure isolation.
+**Commands**
+- `ibc-link init`: scaffold the YAML config.
+- `ibc-link deploy