The Interblockchain Communication Protocol

01 Claim ledger

What the paper is allowed to say

Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.

1. Claim 01 · Paper model

   A light client, not a committee

   The destination stores enough of the source's consensus to verify a header and a Merkle proof. A packet is accepted because the source committed to it, not because a bridge multisig said so.

2. Claim 02 · Paper model

   Relayers are couriers

   Someone must submit the header and the proof. If nobody does, the packet sits. That is a liveness dependency. It is not permission to invent a packet.

3. Claim 03 · Paper model

   Escrow is the asset

   A voucher on the destination is a claim on tokens locked on the source. If the source's consensus is captured, the voucher's backing is whatever that captured chain says it is.

4. Claim 04 · Paper model

   Clients expire

   A client that is not updated can freeze. Freezing is how the design avoids trusting a stale header. It is also how a neglected channel halts. Halt and theft are different failures, and IBC tries to prefer the halt.

02 Three cuts

Observation, model, falsifier

A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.

1. 01 A light client, not a committee

   Observation

   What the study says

   The destination stores enough of the source's consensus to verify a header and a Merkle proof. A packet is accepted because the source committed to it, not because a bridge multisig said so.

   Model

   What has to hold

   Light-client code matches the real consensus. A wrong client is a forged bridge.

   Falsifier

   What would retire it

   Does the destination verify a header, or a multisig?

2. 02 Relayers are couriers

   Observation

   What the study says

   Someone must submit the header and the proof. If nobody does, the packet sits. That is a liveness dependency. It is not permission to invent a packet.

   Model

   What has to hold

   Relayers eventually submit headers and proofs, or the application tolerates a halt.

   Falsifier

   What would retire it

   Does the destination verify a header, or a multisig?

3. 03 Escrow is the asset

   Observation

   What the study says

   A voucher on the destination is a claim on tokens locked on the source. If the source's consensus is captured, the voucher's backing is whatever that captured chain says it is.

   Model

   What has to hold

   Each chain's consensus is safe at the height the light client trusts. A captured validator set can convince the counterparty of a false packet.

   Falsifier

   What would retire it

   What consensus does the light client implement, and does it match the source?

4. 04 Clients expire

   Observation

   What the study says

   A client that is not updated can freeze. Freezing is how the design avoids trusting a stale header. It is also how a neglected channel halts. Halt and theft are different failures, and IBC tries to prefer the halt.

   Model

   What has to hold

   Light-client code matches the real consensus. A wrong client is a forged bridge.

   Falsifier

   What would retire it

   Does the destination verify a header, or a multisig?

03 Sequence

One action, as an operating tape

1. 01Two chains open a connection by verifying each other's consensus state.
2. 02A module on the source commits a packet to its state.
3. 03A relayer submits the packet and a proof to the destination.
4. 04The destination's light client checks the proof against the source header it has verified.
5. 05An acknowledgement or a timeout travels back by the same method, so the source can release or refund.

04 Load-bearing

The argument, and where a pitch drops it

1. Verification does not create a third chain's honesty

   The cut

   IBC is as strong as the weaker consensus it connects, plus the correctness of the light-client code. It does not add guardians. A marketing line that IBC is trustless usually means there is no extra multisig. The source validators are still trusted.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   Light-client security collapses if the counterparty's consensus is captured. IBC does not add a third set of guardians to save you.

2. The relayer market is operational

   The cut

   Correctness without liveness is a packet that never arrives. Someone has to be paid, or otherwise motivated, to submit proofs. The specification does not print that business into existence.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   The specification is not the Cosmos Hub's current validator set, and not an assurance about every chain that speaks IBC.

05 Register

What has to be true

• Model · Not re-measured

  Each chain's consensus is safe at the height the light client trusts. A captured validator set can convince the counterparty of a false packet.

• Model · Not re-measured

  Light-client code matches the real consensus. A wrong client is a forged bridge.

• Cryptography · Not re-measured

  Relayers eventually submit headers and proofs, or the application tolerates a halt.

• Model · Not re-measured

  Escrowed assets stay escrowed. An upgrade that can drain the escrow has left the security story.

06 Divergence

What happened after the paper

The Cosmos ecosystem shipped IBC as a specification and many chains implemented clients. Light clients for new consensus algorithms are the ongoing work, and they are not automatic. Bridged assets that instead trust a committee are a different design, even if the user interface looks like a transfer. Cite the specification for the light-client packet, not for every token that moved between chains.

A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.

07 Pre-mortem

What to check before you use the idea

1. Kill test 1Does the destination verify a header, or a multisig?
2. Kill test 2What consensus does the light client implement, and does it match the source?
3. Kill test 3Who submits packets, and what happens if they stop?
4. Kill test 4Where are the real assets escrowed?
5. 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.

08 Anatomy

The paper, in the order a builder needs

09 Lexicon

Terms, opened into the record

Light client

A verifier that checks consensus headers and proofs without replaying every block.

Relayer

An untrusted courier that submits proofs. Needed for liveness, not trusted for truth.

10 Repository

Every linked record on this page

Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.

11 Related

The next papers, as theses

• Cosmos · 2016

  Cosmos: A Network of Distributed Ledgers

  The Cosmos paper: independent zones running a BFT consensus, connected by a hub, speaking a packet protocol that later became IBC. Unlike Polkadot's shared-security vision, zones here are sovereign. They choose their own validator sets.

• Atomic swaps · 2018

  Atomic Cross-Chain Swaps

  A swap across ledgers where either every transfer completes or none does, using hash locks and time locks. There is no custodian in the paper. A party can still walk away and leave the other waiting.

• Lightning · 2016

  The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments

  Poon and Dryja's 2016 design for Bitcoin payments that stay off the main chain inside penalty-backed channels, and that route across a network of those channels using hashed timelock contracts.