IBC and Eureka: How Cosmos Talks to Everyone Else

The bridge hack decade, and the outlier

On 2 February 2022, an attacker drained about $325 million — 120,000 wETH — from Wormhole, the bridge linking Solana and Ethereum. A deprecated Solana function failed to properly check a system account, and that gap let the attacker forge a signature that looked like guardian approval for a mint of wrapped ETH backed by nothing.

Seven weeks later, around 23 March 2022 (discovered 29 March), Ronin — the sidechain behind Axie Infinity — lost about $624 million: 173,600 ETH and 25.5 million USDC. No cryptography was broken. The attacker used a transaction-signing allowlist Sky Mavis had granted itself months earlier and never revoked, collecting signatures from 5 of the 9 validators required to approve a withdrawal. Sky Mavis controlled four of those five directly.

On 1 August 2022, Nomad lost about $186 million in what barely counts as an exploit. A flawed trusted-root initialization had set the "proven" value to 0x00 — the same value used for messages that hadn't been proven at all. Once that was noticed, more than 300 separate addresses copy-pasted the same transaction with their own numbers.

Three different surface causes, one underlying pattern: a small trusted set — guardians, validators, a root hash — that, once broken or bypassed, could authorize a withdrawal with no further check. If you want a general method for reading a hack post-mortem, that pattern is the thing to look for first.

Cosmos's Inter-Blockchain Communication protocol has moved comparable volume — the wider network handles on the order of $3 billion a month across 115+ connected chains — without an equivalent protocol-level loss of funds. That's the result of a different architecture, not luck. This is Part 2 of a series on that architecture; Part 1 explained why Cosmos chose sovereign appchains over a single shared virtual machine. This part covers how IBC actually secures a transfer, its one real near-miss, and what changes now that it reaches outside Cosmos into Ethereum.

How IBC classic actually works

A light client is code running on Chain A that tracks Chain B's block headers and validator-set changes, and can cryptographically verify a claim about Chain B's state — without downloading Chain B's full history. Chain A runs a light client of Chain B, and Chain B runs one of Chain A.

A connection is a verified pairing between two chains' light clients, set up once via a handshake and then reused by many applications. A channel is an application-specific pipe on top of a connection — ordered or unordered depending on whether sequence matters — with ICS-20 as the standard for token transfers. A packet is the actual unit that moves: data committed on the sending chain, delivered with a Merkle proof, and checked against the receiving chain's light client of the sender before it's accepted.

None of this is cheap to set up in classic IBC. Creating the client is a step of its own; opening a connection is a four-step handshake; opening a channel on top of it is another four steps — roughly ten steps before the first transfer can happen. That overhead is exactly what IBC v2, the layer Eureka builds on, collapses down to about three steps.

The trust model: chains, not bridges

IBC's own framing is precise: you trust the chains themselves, not the bridge. There's no separate validator committee or oracle network checking signatures between the two chains — security reduces to the two chains' own consensus mechanisms, the same ones already securing everything else on those chains.

Relayers are the processes that carry packets and proofs between chains. Anyone can run one — no permissioning or bonding required in classic IBC — but a relayer cannot alter or forge what it carries; every packet is checked against the receiving chain's light client of the sender. That limits a relayer's role to liveness: how fast a packet moves, or whether it moves at all. A malicious or offline relayer can delay a transfer. It cannot fabricate one — that would require actually breaking the counterparty chain's consensus, a harder problem than compromising 5 of 9 signers or 13 of 19 guardians.

That's the real difference from Wormhole, Ronin, and Nomad: none of those asked an attacker to break a chain's consensus. Each asked them to get past a small, fixed set of signatures or an initialization check.

This isn't "zero trust," though. You're still trusting that the connected chain's own validators behave honestly — if they collude to finalize a fraudulent block, IBC will faithfully relay the fraud, because the light client has no way to know a header was dishonestly produced. There's also a real, tunable assumption in every light client: the trusting period, the window during which it accepts a validator set's signatures without rechecking. Too long, and a light client can be fooled by a validator set that's since changed hands; too short, and connections need constant, costly updates. IBC swaps a trusted signer set for trust in a chain's own security — usually a better bet, but a bet, not a certainty. Working out who has to behave honestly for your funds to stay safe is the same exercise as the multi-chain custody problem, just applied to a protocol instead of a wallet.

The closest call: Dragonberry

IBC's record has one real asterisk. ICS-23 is the Merkle-proof specification IBC uses to prove a piece of data does or doesn't exist in a chain's state. In October 2022, a bug in its implementation was found that would have let an attacker forge a non-existence proof — a fake proof that something, like a prior withdrawal, had never happened. Depending on which connected chains and channels were involved, exploiting it could have enabled double-spends worth, per the Cosmos SDK team's own retrospective, hundreds of millions of dollars across the network.

It was never exploited. Osmosis engineer Dev Ojha found it internally on 9 October 2022, during a security review prompted by an unrelated BSC bridge incident — not because anyone was attacking Cosmos chains. A patch shipped five days later, on 14 October 2022. No funds were lost.

Dragonberry is worth naming precisely because of what it argues, and doesn't. It isn't evidence that light clients share the failure mode behind Wormhole, Ronin, or Nomad — those were signer-set or initialization failures; this was a bug in a proof library. But it does mean a light-client architecture is only as good as the code implementing the proofs, and a bug there fails just as badly as a trusted-bridge failure would, because the entire safety guarantee lives in that code. IBC's record isn't "a design that can't fail." It's a design that, so far, has failed safely once, and needed a fast patch to stay that way.

Enter IBC Eureka

IBC v2 shipped in ibc-go v10 at the end of Q1 2025, replacing the separate connection-then-channel handshake with a direct client-pair model — the roughly ten classic steps down to about three, same safety guarantees.

Eureka is the productized extension of that upgrade beyond Cosmos entirely. On 10 April 2025, Interchain Labs announced Ethereum as the first non-Cosmos chain to join IBC, combining IBC v2, Skip:Go (cross-chain routing and intents tooling) and the Cosmos Hub, launching with dYdX, MANTRA, Lombard and Babylon as initial partners and a target of under $1 in combined gas and relay fees per transfer.

The architecture deserves precision, because "bridges Cosmos and Ethereum in one connection" oversimplifies it. Eureka is hub-and-spoke, not a mesh. The Cosmos Hub acts as an interchain router: chains reach Ethereum by routing through the Hub rather than each standing up its own direct Ethereum light client. That means most of the 115+ chains IBC connects can reach Ethereum without running Ethereum-consensus-verification infrastructure themselves — at the cost of the Hub being a load-bearing link in that path.

Solving the gas problem: ZK light clients

Extending IBC's light-client model to Ethereum ran into an economic problem before a cryptographic one. Cosmos chains use CometBFT consensus, secured by validators signing with Ed25519. Verifying a single such signature inside an EVM smart contract could cost up to roughly 500,000 gas. A real light client needs to check enough signatures to mean something — doing that directly on Ethereum ran an estimated $10 to $100 per transaction just to verify consensus, before the transfer itself did anything.

Succinct's fix moves the expensive part off-chain and proves it happened. Their SP1 zkVM runs the actual tendermint-rs consensus-verification code — the production Rust library Cosmos chains already use, not a reimplementation — inside a zero-knowledge proof, so the receiving chain verifies one succinct proof instead of rechecking every signature. Proof generation takes about 25 seconds on the Succinct Prover Network; onchain verification costs roughly 200,000 gas, about a 25x reduction. It's the same move validity-proof rollups make on Ethereum itself: do the expensive computation off-chain, verify a small proof of it on-chain.

The Solidity IBC v2 implementation's own Groth16 benchmarks: about 165,000 gas to send a packet, about 524,474 gas to receive a transfer of an already-registered token (about 1,072,445 the first time a token is registered), about 399,576 to acknowledge, about 473,505 to process a timeout. Batching 25 packets into one proof brings average receive cost down to about 179,471 gas each. Both Groth16 and Plonk proving are supported; the same repo also ships a non-ZK CosmWasm Ethereum light client and a simpler multisig "attestation" light client, both explicitly less trust-minimized fallbacks.

What's live, and what's still promised

As of mid-2026, the Ethereum–Cosmos Hub leg of Eureka is live in production and routes onward to the 115+ Cosmos chains IBC connects. Early integrators beyond the four launch partners include Injective, PumpBTC, SatLayer, Tower DEX, SEDA and Elys Network.

Two things aren't live yet and shouldn't be described as if they were: direct Solana connectivity, and direct connections to Ethereum layer-2s like Base, Arbitrum and Optimism. Both are described by the teams building them as being in final development and security-audit stages, not shipped.

Worth not conflating, too: the ~$3 billion/month figure is IBC's whole-network volume, across all 115+ chains and years of Cosmos-to-Cosmos traffic — not an Eureka-specific number. Eureka's Ethereum leg is new enough that no comparably sized figure exists yet for it alone.

The permissioned relayer asterisk

Worth stating plainly: at launch, relaying on the new Hub–Ethereum leg of Eureka was permissioned — a curated set of operators — unlike classic IBC, where anyone has been able to relay since its earliest days.

That matters in a limited way. The light-client and ZK-proof verification layer — the part deciding whether a packet is safe to accept — was fully live and trust-minimized from day one, independent of who was relaying. A permissioned relayer set affects liveness only: it could delay or decline to carry a transfer. It could not forge one, because forging still requires a proof the light client would accept, and a curated relayer set has no more ability to produce a fake proof than an open one would.

The stated plan is to open Eureka relaying to anyone, matching classic IBC. Until that happens, it's a real, if minor, trust-model difference — worth flagging rather than assuming Eureka relaying worked just like classic IBC from day one. It didn't.

IBC against the oracle bridges

Where IBC wins is the strongest protocol-level security record of this group: no light-client-level loss of funds to date, against Wormhole's $325 million alone and more than $1 billion in cumulative bridge-hack losses industry-wide.

Where it loses is reach and flexibility, and it's worth being just as direct about that. IBC only works between chains that implement the protocol — historically, Cosmos-SDK and CometBFT chains. LayerZero (30+ chains), Axelar (60+ chains) and Wormhole connect far more heterogeneous ecosystems, faster, precisely because they don't require deep consensus-level integration on both ends. Cost is a real tradeoff too: light-client verification doesn't get the batching economies an oracle network can achieve, so under congestion IBC can be pricier than an oracle bridge for the same transfer — which is why Eureka's ZK compression exists at all.

The honest bottom line: IBC and Eureka make sense when trust-minimization matters more than reach or speed. Oracle and guardian-network bridges remain more universal and will likely stay ahead on chain count — but they reintroduce, in some form, the trusted-intermediary risk behind every major bridge hack so far.

Part 3 turns from IBC's mechanics to what actually pays for all this Hub traffic: ATOM's tokenomics and the Cosmos Hub's security budget.