Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryInteroperability2020Design paperCorpus record

The Interblockchain Communication Protocol

IBC. Christopher Goes and the Cosmos IBC specification.

Two chains verify each other with light clients. A relayer carries packets and proofs. The relayer is not trusted to tell the truth. It is trusted to bother showing up. Security is the security of both chains.

IBC carries a packet from one chain to another. The destination checks it with a light client of the source. The relayer who carries the packet does not have a key that can forge it. Security is the two chains' own consensus.

The five-minute read

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.

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.

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.

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.

One action, walked through

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

The argument, unpacked

Verification does not create a third chain's honesty

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.

The relayer market is operational

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.

What has to be true

  • 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.
  • Light-client code matches the real consensus. A wrong client is a forged bridge.
  • Relayers eventually submit headers and proofs, or the application tolerates a halt.
  • Escrowed assets stay escrowed. An upgrade that can drain the escrow has left the security story.

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.

What to check before you use the idea

  • Does the destination verify a header, or a multisig?
  • What consensus does the light client implement, and does it match the source?
  • Who submits packets, and what happens if they stop?
  • Where are the real assets escrowed?

Terms

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.

The problem the paper names

A bridge committee that signs for another chain is a new custodian. IBC asks whether each chain can check the other's consensus directly, the way a light client would.

What the design proposes

  • A client tracks a counterparty's consensus state.
  • A packet is committed on the source, then proved on the destination.
  • Timeouts and acknowledgements so a packet cannot be left in doubt forever.

How the mechanism is specified

  • Verification uses the counterparty's header and a membership proof. Forging a packet means forging that chain's consensus, or breaking the proof.
  • Relayers can censor by silence. They should not be able to invent a packet the source did not commit.
  • A client that is not updated expires. Expiry is a halt risk, which is different from a theft risk.

What this page does not treat as proven

  • The specification is not the Cosmos Hub's current validator set, and not an assurance about every chain that speaks IBC.
  • Light-client security collapses if the counterparty's consensus is captured. IBC does not add a third set of guardians to save you.
  • Token vouchers on the destination are claims on escrow on the source. The escrow is the asset.

Why a venture studio still reads it

Ask who verifies the header. If the answer is a multisig you have never seen in the paper, you are not looking at IBC. You are looking at custody.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.