Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.cosmos.network/llms.txt

Use this file to discover all available pages before exploring further.

IBC (Inter-Blockchain Communication) is a protocol that lets independent blockchains exchange messages with cryptographic verification. A chain running IBC can send tokens, trigger contract calls, or pass arbitrary data to any other chain that also runs IBC, without relying on a centralized bridge operator.

​
The Interoperability Solution

Blockchains are isolated by design. Chain A has no access to Chain B’s state, and they cannot call each other the way web services can. Connecting them traditionally meant trusting a third party to relay information honestly, which introduces a single point of failure and requires ongoing trust in an external operator. IBC is the solution to this problem: it replaces trusted operators with cryptographic proofs. Each chain runs a light client that tracks the counterparty chain’s state. When a message arrives on Chain B, Chain B’s light client verifies that it was actually committed on Chain A. IBC is also permissionless. Anyone can submit proofs to either chain, and each chain verifies them independently. IBC is flexible in how that verification works. A consensus light client tracks block headers and validates them against the counterparty’s consensus rules. An attestation light client relies on a committee, oracle network, or existing signing infrastructure instead. Chains choose the verification approach that fits their security model.

​
IBC Layers

IBC is organized into three layers that can be swapped independently: IBC layers
  • The application layer is where users and cross-chain actions interact. IBC applications can be anything: token transfers, contract calls, arbitrary messaging, or custom logic built for a specific use case.
  • The core layer manages the packet lifecycle: sequencing, replay prevention, timeout enforcement, and proof verification. Applications never deal with this directly.
  • The verification layer handles how cross-chain state is proven. This is where light clients live, and different client types can be swapped in without affecting the layers above.
IBC was designed for flexibility and extensibility. Because the layers have defined interfaces, a new light client type or application can be added without changing the others.

​
What you can do with IBC

Any cross-chain action is wrapped in a packet and sent through the protocol. IBC is agnostic to the content: the same infrastructure that moves tokens can also trigger contract calls or pass arbitrary messages. A single packet can carry multiple payloads from different applications, and they all execute atomically. For a detailed look at how the components work, see How IBC Works. For the full packet flow from send to acknowledgement, see IBC Lifecycle.