Inter-Blockchain Communication (IBC)

Inter-Blockchain Communication (IBC) is a protocol that allows separate blockchains to exchange tokens and messages without relying on a central intermediary. Each chain keeps a light client of the other, a compact record that lets it verify the other chain's block headers and proofs. Independent operators called relayers carry packets of data between the chains, but they cannot forge messages, because every packet is checked against the light client on arrival.

IBC was developed for the Cosmos ecosystem, a network of application-specific blockchains, and went live on the Cosmos Hub in early 2021. It has since connected dozens of chains, including decentralized exchanges such as Osmosis, and work has continued to link it with networks outside Cosmos. It is one of the main approaches to blockchain interoperability and is often contrasted with bridges secured by a small group of signers.

Imagine two banks in different countries that want to send money to each other without a correspondent bank in the middle. Each bank keeps an up-to-date, verified copy of the other's official ledger summary. Couriers carry payment messages between them, but each message comes with proof drawn from the sender's ledger, and the receiving bank checks that proof itself. A dishonest courier can delay a message but cannot invent one.

IBC works the same way for blockchains. The chains check each other directly. The couriers, called relayers, are just delivery services that anyone can run.

• Light clients. Each chain runs a light client of its counterpart, tracking its headers and validator set so it can verify proofs of what happened there.
• Connections and channels. Two chains establish a connection between their light clients, then open channels on top of it for specific applications, such as token transfers.
• Packets. An application on one chain sends a packet, which is committed in that chain's state. A relayer submits the packet and a proof to the other chain, which verifies and processes it, then sends back an acknowledgement.
• Timeouts. If a packet is not delivered in time, it can be timed out and the action reversed on the sending chain, for example refunding escrowed tokens.

The most common IBC application is fungible token transfer. When tokens move from chain A to chain B, they are locked in escrow on chain A and an equivalent voucher is minted on chain B, carrying a record of the path it took. Sending the voucher back burns it and releases the original tokens. Because the record includes the route, the same token arriving by different paths is treated as different assets, which prevents confusion but can fragment liquidity. Beyond transfers, IBC supports interchain accounts, which let one chain control an account on another, and general message passing between smart contracts.

IBC's security depends on the chains it connects rather than on a separate group of signers. If both chains are secure and their light clients are correctly implemented, messages can be trusted. This differs from many crypto bridges, where a committee or multi-sig wallet confirms transfers and, if compromised, can approve fraudulent ones. The trade-off is that a weak chain can still harm the chains that accept its tokens, for example if its validators are corrupted. Bugs in IBC implementations have also been found and patched over the years.

IBC is built into the Cosmos software development kit, so new chains built with it can connect from launch, a model sometimes described as a network of appchains. Volumes and the number of connected chains are tracked by public dashboards and change over time. Efforts to extend IBC to chains with different consensus systems, which are harder to verify with light clients, have relied on new client types and on proof techniques such as zero-knowledge proofs. These would let IBC verify chains such as Ethereum efficiently.

• Light client requirements. Chains must be able to run light clients of each other, which is easier between chains with fast finality, such as those using Tendermint-style consensus, than with probabilistic finality.
• Relayer incentives. Relayers pay fees to submit packets, and without good rewards, delivery can become unreliable.
• User experience. Path-dependent tokens and channel choices can confuse users and split liquidity.
• Shared risk. Accepting another chain's tokens means trusting its security, so a weak chain can spread losses across connected networks.

IBC is often cited as one of the more trust-minimized ways to connect blockchains, a key idea in the wider study of cross-chain communication.

• IBC Protocol