Inter-Blockchain Communication

IBC is a protocol for one state machine to verify facts committed by another without asking a trusted relay to attest to them. The core abstraction is not “send a token through a bridge”; it is light-client verification plus authenticated packet state. Token transfer is one application layered above that transport.

Trust is in the light client #

Chain A stores a light-client state for chain B: enough consensus information to verify B's headers and commitment roots under B's own security model. A relayer submits new headers and Merkle proofs, but the on-chain client verifies them. Relayers can delay service, reorder submissions where allowed, or censor themselves; they should not be able to forge a valid proof.

sequenceDiagram
  participant A as Chain A
  participant R as Relayer
  participant B as Chain B
  A->>A: commit packet data and sequence
  R->>B: header update + proof of commitment
  B->>B: light client verifies A's consensus and proof
  B->>B: application receives packet
  B->>B: commit acknowledgement
  R->>A: proof of acknowledgement
  A->>A: finalize send-side state

The client is therefore the critical security boundary. If it accepts a forged header, every later membership proof may be cryptographically well formed and still authenticate false state.

Clients, connections, channels, packets #

• A client tracks another chain's consensus state and validates updates and proofs.
• A connection binds compatible clients on two chains and negotiates common proof expectations.
• A channel binds application modules across a connection and chooses ordered or unordered delivery.
• A packet carries data, source/destination port and channel identifiers, a sequence, and timeout conditions.

Ordered channels require sequence order and close on certain timeout paths; unordered channels accept each sequence once in any order. Commitments and receipts prevent replay. Acknowledgements let the sending application learn the result.

Timeouts are proofs too #

A sender cannot simply declare a packet timed out. It supplies proof that the destination chain advanced beyond the timeout height or timestamp without the required receipt. This avoids the classic cross-chain failure in which the source refunds while the destination also executes, creating value twice.

Assets are escrow and accounting #

For a fungible-token transfer, the source side typically escrows or burns an asset and the destination mints or unescrows a representation according to the denomination trace. Returning along the reverse path unwinds the representation. IBC proves packet and chain state; it does not make the remote chain's validator set, application code, or governance trustworthy.

Failure modes #

The supplied Cosmos whitepaper introduced hubs, zones, Tendermint, and an early IBC vision. The maintained Interchain Standards are the source for current client, connection, channel, packet, acknowledgement, and timeout semantics.