IBC (Inter-Blockchain Communication) is an open protocol that lets two independent blockchains send each other verified messages, most often token transfers. It does not use a multisig or an outside validator committee. Each chain runs a light client of the other, checks cryptographic proofs of what happened on the far side, and only then mints, burns or releases tokens. Relayers carry the data between chains, but they cannot fake it. IBC began in the Cosmos ecosystem. Through IBC v2, branded IBC Eureka, it now connects Cosmos chains to Ethereum mainnet as well.
- IBC security comes from on-chain light clients and proofs, not a bridge operator. A relayer can delay a transfer, but it cannot steal one.
- Tokens arriving over IBC show up as
ibc/plus a long hash. The hash encodes the exact route the token took, so the same coin can have several different denoms. - Send tokens back the way they came (path unwinding). Multi-hop routes create tokens that DEXs and wallets may treat as a separate asset.
- Every IBC transfer has a timeout. If it is not delivered in time, the funds are refunded on the source chain once a timeout proof is relayed.
- IBC Eureka links Ethereum to the Cosmos Hub and, through it, to IBC-connected chains.
What is IBC in crypto?
IBC is a set of standards, called ICS specifications, that defines how two chains authenticate each other, open a communication path, and pass ordered data packets with guaranteed delivery or refund. Token transfers (the ICS-20 standard) are the best-known application. The same transport also carries interchain accounts and cross-chain queries.
“IBC crypto” usually comes up when someone moves ATOM, OSMO, USDC or another asset between chains like the Cosmos Hub, Osmosis, Neutron, dYdX Chain or Noble. New to the ecosystem? Our Cosmos explainer covers the Hub, ATOM and the app-chain thesis. This page focuses on the protocol layer that profile skips.
IBC is not limited to chains built with the Cosmos SDK. Any chain can implement it if it can run a light client of its counterparty and produce provable state. Namada and Penumbra, both privacy-focused chains, use IBC without being standard Cosmos SDK chains. The Interchain Foundation’s subsidiary, Cosmos Labs (renamed from Interchain Labs in September 2025), maintains the main implementation, ibc-go. It calls IBC the largest non-incentivized bridge in the industry: the protocol itself does not pay relayers.
How Cosmos IBC works: clients, connections, channels and packets
IBC classic, the version most Cosmos chains still use for chain-to-chain transfers, is built from four layers.
1. Light clients
Chain A stores a light client of Chain B: a compact record of B’s validator set and block headers. When someone submits a proof that “packet #42 was committed on B,” A checks it against B’s headers. This is why IBC trust reduces to the honesty of the two chains’ own validator sets, not to an extra committee.
2. Connections
A connection pairs one light client on each side through a four-step handshake. Once open, it confirms that both chains really are talking to each other and not to an impostor.
3. Channels and ports
Applications communicate over channels opened on top of a connection. Token transfers use the transfer port. Each channel gets an ID such as channel-0 or channel-141, and IDs are local to each chain. The Hub’s channel to Osmosis has a different number from Osmosis’s channel back to the Hub. Two chains can have several transfer channels between them, and that matters for denoms, as explained below.
4. Packets, acknowledgements and timeouts
A transfer is a packet: sender, receiver, amount, denom and a timeout (a destination block height or timestamp). The source chain commits the packet to its state. An off-chain relayer reads it, builds a proof and submits it to the destination chain. The destination verifies the proof, executes the transfer and writes an acknowledgement. The relayer then carries that acknowledgement back. If the destination never receives the packet before the timeout, the relayer instead proves the non-receipt to the source chain, which refunds the sender.
IBC relayer: what it does and what it cannot do
An IBC relayer is ordinary software, such as Hermes or the Go relayer, that watches both chains and pays gas to submit pending packets. A relayer cannot forge a transfer, because the receiving chain rejects anything without a valid proof. What a relayer can do is fail to show up. If nobody relays a channel, packets sit pending until someone does. That is a liveness risk, not a theft risk.
ICS-20 IBC transfers and the ibc denom
ICS-20 uses escrow on the way out and mint on the way in. When you send ATOM from the Cosmos Hub to Osmosis, the Hub locks your ATOM in an escrow account tied to that channel. Osmosis mints a voucher that is fully redeemable for the escrowed ATOM. When the voucher comes back over the same channel, Osmosis burns it and the Hub releases the original ATOM.
The voucher’s on-chain name is its ibc denom. It is built from a trace: the port and channel of every hop plus the base denom, for example transfer/channel-0/uatom. The chain hashes that string with SHA-256 and stores it as ibc/ plus the hash. ATOM that arrived on Osmosis over channel-0 is ibc/27394FB092D2ECCD56123C74F36E4C1F926001CEADA9CA97EA622B25F41E5EB2. Wallets map this to “ATOM” using a public chain registry, but explorers show the raw hash.
How to trace an ibc denom
To check what an unknown ibc/... token really is:
- Use a block explorer. Most Cosmos explorers show the full trace path and base denom when you click an IBC asset.
- Query the chain. Every chain running ibc-go answers a denom-trace query by hash through its CLI or REST endpoint. The result is the path, for example
transfer/channel-0, plus the base, for exampleuatom. - Compare against the chain registry. If the path does not match the canonical channel for that asset, you are holding a non-standard version, even if the ticker looks right.
Path unwinding: why you should send a token back the way it came
Because the denom encodes the route, the same base asset can exist as several incompatible tokens. ATOM sent Hub → Osmosis → Neutron has the trace transfer/channel-X/transfer/channel-Y/uatom on Neutron. That gives it a different hash from ATOM sent straight from the Hub to Neutron. Neutron DEX pools and lending markets usually list only the direct version. Your two-hop ATOM may not be accepted, or it may trade in a thin pool.
Path unwinding means retracing the route in reverse until the token is back on its origin chain, then sending it out again directly. Routers such as Skip:Go, now part of the Cosmos Stack under Cosmos Labs, unwind automatically and use Packet Forward Middleware to chain several hops into one signature. That is the main reason most users never handle channels by hand. The same logic applies if a wallet’s “advanced IBC transfer” sends a token over a non-canonical channel. The result is a second, orphaned denom that you will need to route back.
IBC Eureka and IBC v2: connecting Ethereum
IBC v2 streamlines the protocol so it is cheaper to implement on non-Cosmos chains. It drops the separate connection and channel handshakes, and packets are addressed by client IDs instead. IBC Eureka is Cosmos Labs’ implementation of IBC v2. It went live on mainnet in April 2025 with Ethereum as its first non-Cosmos chain.
The setup, according to Cosmos Labs’ Eureka documentation:
- The Cosmos Hub runs an Ethereum light client. On Ethereum, a Hub light client is verified with SP1 zero-knowledge proofs to keep gas costs down.
- Assets travel Ethereum → Cosmos Hub → destination chain. Any chain with a regular IBC connection to the Hub can receive them.
- The docs cite user-paid fees of roughly $5 (fast) and under $1 (standard) for Ethereum-to-Cosmos transfers, varying with gas prices.
- Relaying started with a permissioned relayer set for safety. That affects liveness, not custody, and the docs say permissioning is meant to be removed.
Launch partners included Lombard’s LBTC, and the docs describe a route for any ERC-20 issuer to integrate. Ethereum layer 2s (Base, Arbitrum) and Solana have been on the roadmap, but direct IBC connections to them were not confirmed live as of November 2026. Routes like bridging Cosmos to Solana still rely on other bridge protocols behind the router. For the end-to-end ETH-to-Cosmos walkthrough, see how to bridge to Cosmos.
IBC vs lock-and-mint bridges
IBC also uses escrow and mint, but what it trusts is very different from a typical external bridge. For the wider landscape, see our crypto bridging hub.
| Factor | IBC (classic and Eureka) | Typical lock-and-mint bridge |
|---|---|---|
| Who confirms the transfer | Light clients on each chain check proofs of the other chain’s consensus | An external committee, multisig or oracle network attests to the deposit |
| Trust assumption | The validator sets of the two chains involved | The bridge’s own signers or validators, plus its contract code |
| Relayer or operator power | Can delay or censor, cannot forge | A compromised key set can mint unbacked tokens |
| Speed | Seconds between fast-finality Cosmos chains. Eureka says assets arrive in seconds. | Ranges from minutes to hours depending on source-chain finality and design |
| Cost | Gas on the source chain (tiny on most Cosmos chains), plus Eureka’s fee for Ethereum routes | Gas plus a bridge fee or spread |
| Failure mode | Timeout refund to sender once proven | Depends on the bridge. Some funds may need manual recovery. |
No bridge is risk-free. IBC has had implementation bugs that were patched before exploitation, and a chain whose validators collude can still lie to its counterparties. Our guide on whether bridging crypto is safe explains how to weigh those risks.
How to use Cosmos IBC bridging: a practical IBC transfer
Here is the generic flow in any wallet with IBC send support. Keplr is the most common; our Keplr wallet review covers its safety and Ledger setup.
- Hold gas on the source chain. You pay the IBC transfer fee in the source chain’s gas token, such as ATOM on the Hub or OSMO on Osmosis, not in the token you are sending. A zero balance blocks the transaction.
- Use the wallet’s cross-chain or IBC send screen. In Keplr, the default cross-chain send picks a recommended channel. Its manual IBC option, which must be enabled in settings, lets you type a channel. Only use it if an official project doc names that channel.
- Paste the destination address. Cosmos addresses carry a chain prefix (
cosmos1,osmo1,neutron1). The wallet derives them from the same seed, so copy the address for the destination chain from your own wallet. - Check the route if the token is not native to the source chain. If you hold a voucher, a router that unwinds it first is safer than a direct send.
- Sign and wait. Between Cosmos chains, delivery normally takes seconds to a minute. Check the destination balance, not just the source transaction.
What to do if an IBC transfer times out
If funds leave the source chain but never arrive, look up the source transaction hash on an explorer. A pending packet means no relayer has delivered it yet. Once the timeout passes and a relayer submits the timeout proof, the tokens are refunded to your source address automatically. If the refund does not appear after a few hours, contact the support channel of the app or router you used. Stuck packets on quiet channels sometimes need a relayer operator to act. Never share your seed phrase with “recovery” offers.
FAQ
What is an ibc denom?
An ibc denom is the on-chain name of a token that arrived over IBC: ibc/ followed by a SHA-256 hash of its route (ports, channels and base denom). The hash makes each route distinct. ATOM that took two hops therefore has a different denom from ATOM sent directly. Explorers or a denom-trace query decode the hash back into the readable path.
Is IBC a bridge?
Functionally yes, it moves assets between chains. Its trust model differs from most bridges, though. There is no separate multisig or committee holding funds. Each chain verifies the other with a light client, so you rely on the two chains’ validator sets. Relayers only carry messages and cannot forge transfers, although they can delay them.
What is IBC Eureka?
IBC Eureka is the implementation of IBC v2 that connects Ethereum mainnet to the Cosmos Hub, and through it to chains with an IBC connection to the Hub. It launched in April 2025. It uses an Ethereum light client on the Hub and SP1 zero-knowledge proofs on Ethereum. Fees are paid by users, and relaying began with a permissioned relayer set.
Do I need an IBC relayer to send tokens?
No, not as an end user. Relayers are run by validators, infrastructure companies and app teams, who pay the gas to deliver packets. You only sign the transfer on the source chain and pay its normal fee. Running your own relayer matters only if you operate a chain or an app that needs a guaranteed delivery path.
Crypto is volatile and risky; this is education, not financial advice. Do your own research.
