> ## Documentation Index > Fetch the complete documentation index at: /docs/llms.txt > Use this file to discover all available pages before exploring further. # What is IBC? > IBC is a protocol for sending packets between independent chains, where each chain verifies the other chain's writes with an on-chain light client. The Inter-Blockchain Communication (IBC) Protocol is the open standard for secure interoperability between independent systems. It is a battle-tested, extensible, trust-minimized interoperability protocol that connects 115+ public blockchain networks, plus private networks and consortia. In over five years of production, it has processed \$50B+ in transaction volume without an exploit of the supported version. IBC is an open standard that lets digital ledgers exchange assets and data directly with other ledgers, including Ethereum and EVM-based frameworks such as Hyperledger Besu, non-Ethereum ledgers, and other systems that meet a small set of requirements. Like TCP/IP standardized communication across the internet, IBC standardizes communication across blockchains and other distributed ledgers. It enables two systems to exchange data, assets, and arbitrary messages directly, without relying on a centralized or third-party intermediary. At its core, IBC is a collection of open specifications that define how systems establish connections, verify messages, and transfer information securely. Because IBC is an open standard, it can be implemented on virtually any system capable of generating verifiable proofs, including blockchains, permissioned ledgers, and other distributed systems. Today, IBC has implementations across major ecosystems, including Cosmos, EVM chains, and Solana, providing out-of-the-box connectivity to hundreds of networks. IBC provides a complete interoperability stack: * Protocol standards for secure cross-system interoperability * Infrastructure such as relayers that transport messages between connected systems * Reusable applications for common interoperability use cases, including token transfers and General Message Passing (GMP) for cross-chain contract calls * Flexible verification mechanisms, ranging from trust-minimized light clients to permissioned attestation-based models IBC is modular and extensible by design, allowing developers to adopt existing applications and verification systems or build custom modules tailored to their needs. ## IBC layers IBC is organized into three layers: ![The three IBC layers: application, core, and verification](https://mintcdn.com/ibc-docs/_IzGrVOELf0DsHtq/mintlify/images/ibc/ibc-layers.png?fit=max\&auto=format\&n=_IzGrVOELf0DsHtq\&q=85\&s=ab91ba978310bfee51eae4b37261006f) **The [Application Layer](/docs/ibc/02-how-ibc-works/02-packets-and-applications.md)**: the layer that defines how packet data is packaged and interpreted by sending and receiving chains. IBC applications can be thought of as the business logic layer and as a composable set of interoperability building blocks for cross-chain applications. Standard application modules include fungible token transfers ([ICS-20](/docs/ibc/spec/app/ics-020-fungible-token-transfer/README.md)), general message passing ([IBC GMP](/docs/ibc/03-applications/01-gmp.md)), and interchain fungible token ([IFT](/docs/ibc/03-applications/02-ift.md)) transfers. These modules allow developers to build reusable cross-chain functionality without needing to reimplement interoperability primitives from scratch. **The [IBC Core Layer](/docs/ibc/02-how-ibc-works/03-core-router-and-store.md)**: the routing and authentication layer. A single [router](/docs/ibc/06-ibc-solidity-contracts/02-ics26-router.md) verifies and dispatches [packets](/docs/ibc/02-how-ibc-works/02-packets-and-applications.md) to the correct application, and the [client](/docs/ibc/02-how-ibc-works/04-clients-and-counterparties.md) authenticates the data each chain receives. This layer provides the common interoperability infrastructure used to coordinate communication across independent blockchain networks with potentially distinct smart contract languages and security models. **The [Verification Layer](/docs/ibc/02-how-ibc-works/04-clients-and-counterparties.md)**: this layer handles how cross-chain state is proven. The verification layer consists of clients that verify messages across blockchains. Different client architectures are used in this layer, including [consensus light clients](/docs/ibc/04-light-clients/03-besu-light-client.md), [attestation-based](/docs/ibc/04-light-clients/01-attestation-light-client.md), and zk-proof light clients. This verification model allows IBC to operate across heterogeneous execution environments, including Cosmos, EVM-based, and Solana-based networks. Together, these layers define both the protocol standard and the production interoperability infrastructure required for secure cross-chain communication. The separation of concerns between layers allows application developers to build cross-chain applications without needing to manage low-level details such as client verification, connection setup, or proof construction. ## Why IBC? Blockchain networks have multiplied, and the ledgers behind them now need to transact with each other securely. IBC is the open standard for that, with no third party between the two networks. ### Direct communication and verification IBC enables systems to communicate directly with one another through self-hosted infrastructure. Connections are peer-to-peer and rely on no third-party intermediary or external validator network; each side verifies cross-system messages against the [counterparty's state](/docs/ibc/02-how-ibc-works/04-clients-and-counterparties.md). A ledger using IBC keeps its own security model, which simplifies the risk surface and reduces external dependencies. ### Proven in production IBC has run in production for more than five years, connecting 115+ public networks alongside private networks and consortia, and has processed \$50B+ in volume with no exploit of the supported version. Every layer has been [independently audited](/docs/ibc/07-security/01-audits.md). ### Customizable at every layer IBC makes no assumptions about what it connects. The standards can be implemented in any language, on any network able to produce the verification a counterparty requires, and each layer can be adapted independently. [Applications](/docs/ibc/02-how-ibc-works/02-packets-and-applications.md) can be anything: adopt the standard modules, [ICS-20](/docs/ibc/spec/app/ics-020-fungible-token-transfer/README.md), [GMP](/docs/ibc/03-applications/01-gmp.md), and [IFT](/docs/ibc/03-applications/02-ift.md), or write your own, which needs only to implement a minimal interface and register with the [router](/docs/ibc/02-how-ibc-works/03-core-router-and-store.md) under a port identifier. Today IBC spans EVM networks including Ethereum and [Hyperledger Besu](/docs/ibc/04-light-clients/03-besu-light-client.md), Cosmos chains, and Solana. ### Flexible verification IBC supports multiple trust models to meet different business and regulatory needs. * Consensus light client verification provides trust-minimized security by verifying messages directly against signed consensus data, as the [Hyperledger Besu QBFT and IBFT 2.0 light clients](/docs/ibc/04-light-clients/03-besu-light-client.md) do for enterprise EVM networks. * [Attestation-based verification](/docs/ibc/04-light-clients/01-attestation-light-client.md) enables organizations to leverage existing governance processes, compliance frameworks, and first-party key infrastructure. ### No vendor lock-in Because IBC is an open standard rather than a proprietary network, organizations retain control over their infrastructure, contracts, and security mechanisms while remaining interoperable with other IBC-enabled systems. Unlike other interoperability solutions, IBC requires no token, imposes no protocol-level fees, and does not tie participants to a specific service provider. To see IBC in action, [follow the tutorial to deploy IBC on two local chains and move a token](/docs/ibc/05-ibc-cli/02-tutorial/01-deploy-ibc-and-send-a-token.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.