The Inter-Blockchain Communication protocol (IBC) is joining LF Decentralized Trust, bringing an established interoperability protocol and developer community into a neutral home for open collaboration.
With the rapid expansion of blockchain networks and decentralized ledgers in recent years, secure interoperability between networks has become essential. Institutional and business adoption of blockchain technology has aimed to reduce transaction friction, but a new challenge has emerged: these ledgers need a secure, scalable, and flexible way to communicate and transact with each other.
The Inter-Blockchain Communication Protocol (IBC) addresses this challenge through an open source interoperability protocol that enables secure communication between independent digital ledgers. It allows networks to verify messages directly, peer-to-peer, without relying on a third-party intermediary or validator network. At the time of its contribution to LF Decentralized Trust (LFDT), IBC has been live in production for over five years and used by over 200 public digital ledgers.
IBC is network, application, and architecture-agnostic, making it a proven choice for connecting networks with different underlying technologies and security models. It supports EVM networks, including Besu and Ethereum, as well as Cosmos chains and integrations with other enterprise blockchain frameworks.
Similar to TCP/IP for the internet, IBC establishes common standards for secure cross-network communication. These standards can be implemented in any programming language and on any network that supports the necessary verification mechanisms, with customization at every layer. IBC enables networks to exchange assets and data while maintaining their own governance and infrastructure.
Its contribution to LFDT creates an opportunity for developers, institutions, and infrastructure providers to participate in its continued development, contribute technical expertise, and shape the future of open interoperability standards.
What is IBC and how does it work?
IBC is an interoperability protocol with open standards for exchanging and verifying messages between independent networks. Its specifications are programming language-agnostic, with implementations in Go for Cosmos networks, in Solidity for EVM networks including Besu, and in Rust. Organizations using IBC operate their own infrastructure. The protocol has no fees or costs and does not require a specific token.
IBC’s architecture can be understood through three layers, each serving a distinct function:
- The application layer: Defines the business logic behind the messages exchanged between networks, determining what information is sent and what happens when it arrives. This can include transferring an asset or executing a smart contract call.
- The IBC Core layer: Manages the communication between networks by packaging application messages into packets, routing them to the appropriate application, and recording their progress on-chain.
- The verification layer: Ensures the authenticity of messages received from other networks. This layer uses light clients to track the state of connected networks and cryptographic proofs to verify that incoming messages correspond to that state.
IBC differs from other interoperability solutions by enabling direct verification of cross-chain messages without relying on a separate group of third-party verifiers. A consensus light client is an on-chain component that maintains a small, verified view of another chain’s state. Each connected ledger maintains a light client of its counterparty: chain A has a light client of chain B, and vice versa. The light client verifies state updates from the counterparty and checks cryptographic proofs against that verified state, allowing each ledger to independently verify messages received from the other.
In IBC, each cross-chain message follows a similar path:
- An application submits a message to the IBC core on a source ledger.
- The core creates a packet and stores a fingerprint of that packet called a commitment.
- An off-chain service called a relayer carries the packet and its supporting proof to the destination chain.
- The core on the destination chain receives the packet and verifies its authenticity by checking the proof against the light client of the sending chain. The packet is then sent to the destination application.
- The destination application processes the message and returns an acknowledgement, which travels back the same way with its own proof, allowing the sending application to learn the result.
IBC's security model relies on direct verification of cross-ledger messages. Neither relayers nor any other off-chain or on-chain actors can alter the contents of packets or their associated proofs without invalidating the verification.
IBC provides implementation flexibility, allowing users to define their own applications and verification methods. It is extensible at every level of the protocol. IBC users can create custom applications or middleware to suit their business needs. This flexibility extends to light clients as well: attestation light clients can support permissioned networks, while consensus light clients or zero-knowledge (zk) clients suit more open security models. As a neutral, open standard, IBC allows implementers to customize and choose the security model and capabilities that meet their requirements, without relying on a third-party intermediary, vendor, or token.
For more information on how IBC works, visit the IBC docs.
5+ Years of Production History
Since April 2021, more than $45 billion in transaction volume has moved through IBC, which connects 200+ public networks alongside private networks and consortia. There has never been an exploit of the supported version of the protocol.
IBC’s experience provides a secure foundation for institutional interoperability. Below are a few examples of IBC in use by institutions and payment networks:
- Digital securities settlement: In collaboration with Mitsubishi UFJ Trust and Banking, Datachain demonstrated cross-chain settlement of digital securities using stablecoins, connecting Corda and GoQuorum. The demonstration uses IBC to coordinate atomic DvP(delivery-versus-payment) settlement between securities and payments.
- International stablecoin remittance: Progmat launched Project Pax, with input from Mitsubishi UFJ Financial Group, to develop cross-border stablecoin transfers using Swift’s existing messaging interfaces. IBC and Datachain’s LCP middleware facilitated these transfers between chains.
- Tokenized asset interoperability: Cosmos Labs and Peersyst Technology joined CBWeb3, an Inter-American Development Bank Lab initiative with LNET exploring interoperability between central bank digital currencies (CBDCs) and tokenized assets in Latin America and the Caribbean powered by IBC.
- Instant and Cross-border payments: Cosmos Labs and Peersyst are collaborating with the Central Bank of Honduras on cross-border movement of tokenized assets with IBC interoperability. The Bank’s 2025 annual report records the memorandum of understanding establishing the academic and technical collaboration.
These projects illustrate how institutions are using IBC across different ledger technologies while retaining control over their infrastructure and choosing verification methods that meet their needs.
The importance of neutral governance
An interoperability standard must accommodate the different needs, technologies, priorities, and commercial interests of the networks it connects. IBC’s open specifications allow organizations to implement the protocol within their existing infrastructure and adapt their implementations as their needs evolve.
For organizations considering long-term adoption, the way a standard is developed and governed is equally important. They need confidence that its development will address shared requirements without locking them into a single provider’s technology or priorities. Open source development allows participants to inspect the code and contribute improvements, while neutral governance gives organizations a framework to participate in decisions about the protocol’s future.
By joining LFDT, IBC will operate under a neutral governance framework that supports transparent development and broader industry participation. Initial maintainers from Cosmos, Datachain, and OpenZeppelin will contribute their expertise alongside developers, institutions, and infrastructure providers, creating opportunities for more enterprises to participate in IBC's continued development.
Get involved
IBC’s ongoing development draws on the experience of its developer community, network operators, and organizations implementing the protocol across different ledger technologies. Under LFDT, established maintainers, new developers, financial institutions, and infrastructure providers can all contribute.
The project’s initial maintainers include contributors from Cosmos Labs, OpenZeppelin, and Datachain. They form the initial Technical Steering Committee (TSC), which oversees the technical direction of IBC contributions and development. The governance processes are outlined on Github.
Developers can contribute by participating in discussions, proposing new solutions, improving tooling and documentation, or reviewing proposals and pull requests. Financial institutions and infrastructure providers can share technical and operational requirements, propose new standards, and contribute findings from integration and deployments.
To propose a feature or change, open an issue in the IBC repository using the feature template. For open questions, use GitHub Discussions. Contributors can also comment on existing issues and explore ideas with the community. If you think you have found a security vulnerability, do not open a public issue; follow the process in SECURITY.md.
Before participating, read the contribution guidelines for the proposal and review process, and explore the IBC technical documentation for more information.
_______________
Join us for a webinar on Unleashing New Tokenized Deposit Use Cases with IBC on November 13 at 7:00 am Pacific.
________________