Skip to main content
This page covers enough of the protocol to reason about a deployment. For the full specification and developer material, see the Inter-Blockchain Communication documentation.

Light clients

A light client is an on-chain component that tracks a counterparty chain’s consensus state. Each chain runs a light client of the other. The tracked state lets each chain verify that something occurred on the other chain without trusting anyone to report it. Light clients form the foundation of the trust model: the chains verify cryptographic proofs themselves, with no external attestor.

Connections and channels

A connection is a link between two light clients that establishes mutual verification between their chains. A channel is an application traffic path established on top of a connection. A single connection can support many channels.

Why the separation exists

The separation matters operationally: the expensive trust-establishing step happens once per counterparty. Individual applications then receive their own channels on top of that connection.

Packets and relayers

A packet is the data an application sends over a channel. The sending chain commits the packet, the receiving chain accepts it, and an acknowledgment returns. A relayer is a permissionless transport role that carries packets between chains. It cannot forge, alter, or censor a packet because the receiving chain verifies every packet against its light client before acting. A misbehaving relayer can cause only a delay, not an invalid state change.

Timeouts

A timeout is a deadline carried by every packet. If the packet is not delivered in time, the sending chain can prove the timeout and revert its side. The timeout prevents assets from becoming stranded when a counterparty chain stalls or a relayer stops.