Blog

The Inter-Blockchain Communication Protocol (IBC) is one of the most widely adopted interoperability protocols globally. This post aims to dispel misconceptions about the protocol and educate technical and non-technical users on its development and usage.

Myth: No one uses IBC, and the protocol has no volume. 

Reality: The network is heavily used and growing. As of this writing, 2.1M monthly active users process transactions over the IBC network every 30 days. 118 chains are connected over the IBC network, and the network saw 102% growth in the number of IBC-enabled chains from 2023 - 2024. The protocol processes ~$2.1Bn USD in cross-chain volume every 30 days. These metrics make IBC one of the most widely adopted and high-volume interoperability protocols in the world.

Myth: IBC routes transactions via a third party intermediary, such as a smart contract, cross-chain liquidity pools, or a router chain.

Reality: Many interoperability protocols rely on third-party roots of trust, like router chains, permissioned relayers, or smart contracts, to facilitate token transfers. This additional layer of trust means the security of the transaction relies on not only the chains doing the transfer, but also on a third party.

The core IBC Protocol, however, is different. It facilitates direct blockchain-to-blockchain communication, meaning there is no third-party intermediary (smart contract, liquidity pool, validator set, etc.) between two communicating chains. The protocol achieves this degree of trust-minimization by leveraging light clients. 

A common question is whether IBC routes transactions through the Cosmos Hub. While the Cosmos Hub was among the first chains to adopt IBC and plays a significant role within the interchain ecosystem, IBC does not depend on any specific blockchain to function. Chains using IBC can communicate directly with each other without routing through an intermediary.

Myth: If a high-volume chain like Osmosis halts, the IBC network stops working. 

Reality: IBC is a decentralized protocol with fault-tolerant design. A halt or an issue on any participating chain, including Osmosis, does not affect the overall operation of the IBC network. The IBC connections between each set of chains operate independently of one another; for example, if Chain A, B, and C are IBC-enabled, and Chain A halts, the IBC connection between Chain B <> C will continue to function normally.

Myth: If an IBC transaction fails, the funds disappear from your wallet.

Reality: IBC uses an escrow/mint method during token transfers, where the tokens on the sending chain (chain A) are escrowed, and a matching quantity of assets is minted on the receiving chain (chain B). If a transaction cannot be completed—for instance, due to a packet timeout—the protocol ensures that the sender’s tokens are un-escrowed and returned to the sender’s wallet on A. 

The receiving chain mints a voucher represented as an IBC denomination, which tells the protocol of their originating port, channel, and denomination. Sending assets back in the reverse direction, from B to A, causes them to be burned on B and the original assets un-escrowed on A.

Myth: IBC will have a token or do an airdrop.

Reality: IBC is a protocol used by many different chains. It does not have its own blockchain, is not a decentralized application on a specific blockchain, and is not connected to any token. 

The purpose of IBC is to facilitate interoperability between sovereign chains, allowing each chain to have its own assets and tokenomics. The protocol operates independently of any specific token or asset. It does not have a value capture mechanism in-protocol, meaning there are no fees or costs for IBC users. There are no plans to ever launch an IBC token.

Myth: IBC is a bridge.

Reality: While IBC enables cross-chain token transfers like a bridge, it is a comprehensive protocol for secure and standardized cross-chain communication. IBC-enabled chains can share any type of data as long as it’s encoded in bytes, enabling the industry’s most feature-rich cross-chain interactions. Popular interactions performed over IBC include Interchain Accounts, Interchain Queries, and cross-chain callbacks. 

IBC is also unique from other protocols in that it offers asynchronous communication with native package receipts and acknowledgements, allowing teams to build complex cross-chain workflows leveraging multiple smart contracts and applications. This means you may interact with an IBC-enabled smart contract, liquidity pool, or application on a day-to-day basis; however, these elements are not inherent components of the IBC Protocol itself.

Myth: IBC relaying is permissioned. Only pre-approved companies or users can set up IBC relayers.

Reality: IBC relaying is permissionless. Anyone can run a relayer as long as they have access to a full node. This property makes IBC censorship-resistant; nobody can stop you from making an IBC transaction, as you can even relay your own transactions. The liveness of the IBC network depends on relayers. Read more about relayers on X.

Myth: IBC uses a multi-sig for fund storage.

Reality: IBC does not use multi-signature wallets for cross-chain transfers. IBC-enabled chains establish secure channels and use light clients for verification, enabling direct chain-to-chain transfer verification without requiring a multi-sig or other third-party intermediary.

Myth: IBC is a layer 0 protocol or a software development kit (SDK) developers can use to build blockchains. 

Reality: Blockchain SDKs like the Cosmos SDK and Layer 0 software provide tools for developers to use to build Layer 1 blockchains designed for specific applications or use cases. IBC is not a Layer 0 or blockchain SDK used to launch sovereign chains. It is a blockchain interoperability solution consisting of composable building blocks that existing blockchains can use to enable cross-chain communication.

Myth: IBC works only with public blockchains.

Reality: IBC is versatile and can be implemented by both public and private blockchains as long as they meet the protocol's requirements. Its design allows for a wide range of use cases across different types of networks. Check out MapofZones for a visualization of public, permissionless IBC-enabled chains. An example of private, permissioned chains is the Provenance Blockchain’s IBC-enabled connections to permissioned Zones, and the soon-to-launch Penumbra, a shielded cross-chain network. 

Myth: IBC increases centralization.

Reality: The architects of IBC wanted to build a system that empowered individual app chains to maintain their sovereignty while connecting to their peers. As such, they ensured that IBC-enabled chains never rely on a centralized entity like a bridge, a multi-signature wallet, or a router chain for transaction processing. Instead, IBC-enabled chains communicate directly with one another through light client-based interoperability without any centralization in the system.

While certain IBC-enabled chains are more well-known than others - like Osmosis, Cosmos Hub, or Celestia - the network itself is truly decentralized. By enabling direct, trust-minimized communication between chains, IBC fosters the development of a fault-tolerant and decentralized network.

Myth: There's no team behind IBC.

Reality: IBC is supported by a collaborative effort from multiple organizations and contributors. Interchain GmbH, Informal Systems, and Strangelove Labs are funded by the Interchain Foundation to focus on core protocol components. Many other organizations contribute on an ad hoc basis. Read more about the IBC development and contributor structure on the About Us page.

This wraps up our first article addressing common myths about IBC. Our goal in addressing these misconceptions is to illuminate the protocol's capabilities and explain it in easily understandable terms to users who are new to the protocol. Connect with us on Twitter/X, Discord, or Telegram for the latest news on IBC development and releases.