IBC (Cosmos) Integration for Cross-Chain Interaction

IBC (Cosmos) Integration for Cross-Chain Interaction

You're building a DEX that needs to swap ATOM for OSMO without external bridges? Or require a smart contract on Osmosis to manage staking on Cosmos Hub? Our team has 8 years in blockchain and 50+ IBC integrations under our belt. IBC (IBC Protocol) isn't just a protocol — it's fundamental infrastructure for cross-chain operations. Unlike most solutions, it doesn't require trusted third parties; verification goes through cryptographic light clients. But implementation demands deep understanding of packet lifecycle, timeout mechanisms, and relaying specifics. We help with IBC integration from protocol selection to deployment and monitoring.

What is IBC and why is it safer than multisig bridges?

IBC uses light clients that store block headers of counterparty chains. Each packet undergoes cryptographic verification: a relayer transmits data but cannot alter it. Unlike multisig bridges where 3 out of 5 validators could collude, IBC requires confirmation from the entire network's consensus. This makes it 10,000 times more reliable than traditional bridges according to hack statistics (compare: bridge hack losses >$1.5B, IBC error losses <$50M — and those are due to misconfiguration, not the protocol). According to DefiLlama, IBC processes over $100M daily with an average finality time of 6 seconds.

How does data transfer via IBC work?

Packet lifecycle is the foundation of IBC. Let's examine token transfer (ICS-20):

1. Application on Chain A calls sendPacket() with tokens and recipient address.
2. IBC Core records a commitment — the packet hash in the Merkle tree.
3. Relayer notices the new commitment, obtains a Merkle proof, and sends it to Chain B.
4. Chain B verifies the proof via Chain A's light client and calls onRecvPacket() on the receiving application.
5. On success, the relayer delivers the acknowledgement back to Chain A, which calls onAcknowledgementPacket().
6. If the packet isn't delivered before timeout (by block height or time), Chain A calls onTimeoutPacket() — funds are atomically returned to the sender.

This mechanism guarantees assets either arrive or are returned — no frozen transactions.

How to set up IBC for EVM networks via Polymer and Union?

Native IBC works only on Cosmos SDK / CosmWasm. For Ethereum and other EVM networks, we use overlays:

• Polymer — a rollup that acts as an IBC hub for EVM. Contracts on Ethereum communicate with Polymer via a dispatcher that emulates IBC semantics.
• Union — uses zk-proofs to verify Tendermint consensus on EVM. Fully trustless, without multisig.

Example integration with Polymer (Solidity):

interface IbcDispatcher {
    function sendPacket(bytes32 channelId, bytes calldata payload, uint64 timeoutTimestamp) external returns (uint64 sequence);
}

contract EVMIbcApp is IbcReceiverBase {
    IbcDispatcher immutable dispatcher;

    function sendCrossChainMessage(bytes32 channelId, bytes calldata data) external {
        uint64 timeoutTimestamp = uint64(block.timestamp + 3600) * 1e9;
        dispatcher.sendPacket(channelId, data, timeoutTimestamp);
    }

    function onRecvPacket(IbcPacket calldata packet) external override returns (AckPacket memory ack) {
        processIncomingData(packet.data);
        return AckPacket(true, bytes("ok"));
    }
}

Why is relayer selection critical for production?

A relayer is the infrastructure that physically sends packets between chains. Without it, IBC doesn't work. For production, we recommend Hermes (Rust, by Informal Systems) — it's the most mature, supports load balancing and automatic restart. Below is a comparison of popular relayers:

Configuration of Hermes for connecting Cosmos Hub and Osmosis:

[global]
log_level = "info"

[[chains]]
id = "cosmoshub-4"
rpc_addr = "https://cosmos-rpc.example.com:26657"
grpc_addr = "https://cosmos-grpc.example.com:9090"
account_prefix = "cosmos"
key_name = "relayer-key"
gas_multiplier = 1.2
max_gas = 4000000

[[chains]]
id = "osmosis-1"
rpc_addr = "https://osmosis-rpc.example.com:26657"
grpc_addr = "https://osmosis-grpc.example.com:9090"
account_prefix = "osmo"
key_name = "relayer-key-osmo"
gas_multiplier = 1.1
max_gas = 25000000

Important: the relayer spends gas on both chains. For compensation, we use ICS-29 (incentivized relaying) — a fee is embedded in the packet. Or we run a custom relayer with a sufficient token reserve.

What typical IBC scenarios have we implemented?

What does our work include?

• Requirements analysis and selection of the optimal protocol (ICS-20, ICS-27, custom).
• Architecture design: contracts, relayer, monitoring.
• Smart contract development (Solidity / Rust / CosmWasm) with gas optimization and security in mind.
• Deploying the relayer (Hermes) and configuring alerting.
• Testnet testing and security audit.
• Documentation for use and support.
• Training your team on IBC fundamentals.

How do we approach security?

IBC is a robust protocol, but errors in contracts (incorrect timeouts, invalid acknowledgement handling) have led to losses. We apply formal verification on key threats (reentrancy, data consistency) and recommend audits by teams with Cosmos specialization — Zellic, Oak Security. In our projects, we implement defense-in-depth practices: transaction amount limits, monitoring for unusual patterns, and automatic rollback on timeouts.

To discuss an IBC integration, contact us. We will analyze your project and propose an architecture within 1 day.

Cross-Chain Bridge Development: Architecture, Risks, and Implementation

We develop cross-chain bridges and cross-chain solutions end-to-end. We know how to avoid disasters. A few years ago, the Binance BNB Chain bridge lost $570M — the attacker forged a Merkle proof in BSC's native bridge. That same year, Wormhole lost $320M: guardian signature verification was bypassed through a bug in Solana's secp256k1 program. Ronin Bridge — $625M. These are not coincidences. Bridges are the most attacked infrastructure in Web3 because they aggregate liquidity and have complex cross-chain verification logic.

Why Do Bridges Break? Three Architectural Classes of Vulnerabilities

Finality and Reorg Issues. Ethereum has probabilistic finality before The Merge and economic finality after (2 epochs, ~12 minutes). Bitcoin — ~6 blocks (~60 minutes). Solana — ~400ms. If a bridge mints wrapped tokens on the destination chain immediately after 1-2 blocks on the source — a reorg of 3+ blocks allows the attacker to obtain tokens on the destination while the source transaction is reverted. Correct protection: wait for finality confirmation specific to each chain. For Ethereum — 64+ blocks (2 epochs). Not one block.

Signature Verification. Most bridges use a multisig committee or threshold signature: N out of M validators must sign the event from the source chain. Wormhole used 13 out of 19 guardians. The attack was not on the keys themselves — the attacker found a vulnerability in the signature verification code on Solana, where an outdated sysvar account was accepted as valid without verification. On-chain signature verification is harder than it seems.

Lock-and-Mint vs Burn-and-Mint. In the lock-and-mint model, original tokens are locked in a contract on the source chain, and wrapped tokens are minted on the destination. The source contract is a honeypot: all locked TVL is there. One bug in the unlock logic — and all funds are available to the attacker without needing to do anything on the destination chain. Native burn-and-mint (like Circle CCTP for USDC) is safer: no locked pool.

How to Choose a Messaging Layer for Your Project?

LayerZero — a protocol for arbitrary message passing between chains. Not a bridge itself, but infrastructure for building bridges and omnichain applications.

Architecture: Endpoint contract on each chain, Executor (delivers messages to the destination chain), DVN (Decentralized Verifier Network — verifies the transaction fact on the source chain).

Source chain:
  OApp.send() → Endpoint.send() → [emits packet event]

Destination chain:
  DVN verifies packet hash → Executor calls Endpoint.deliver() → OApp.lzReceive()

In v2, the developer chooses DVNs: official (LayerZero Labs, Google Cloud, Polyhedra), or custom. One can configure required DVN + optional DVN: a message is accepted only if all required DVNs confirm. This allows building bridges with different trade-offs between security and speed.

OApp (Omnichain Application) — the base contract for integration. Inherit OApp, implement _lzSend and _lzReceive. For token bridges — OFT (Omnichain Fungible Token) standard out of the box does burn-on-source / mint-on-destination.

Wormhole uses a network of 19 guardians (large companies like Jump Crypto, Everstake, etc.), each signing observed events. Threshold — 13 out of 19. VAA (Verified Action Approval) — a signed message that is accepted on the destination chain.

Main difference from LayerZero: Wormhole has native support for non-EVM chains: Solana, Aptos, Sui, Algorand, Near. For projects needing a bridge between Ethereum and Solana — Wormhole is often the only production-ready option.

After the exploit, Wormhole added Native Token Transfers (NTT) — an architecture without a locked pool, similar to CCTP. NTT + Hub-and-Spoke model: redundant liquidity is not accumulated on one chain.

Relay Architecture and Light Client Verification

Relay-based bridges (IBC in Cosmos ecosystem, Succinct's Telepathy) verify the source chain's state via a light client on the destination chain. For EVM→EVM: a contract on Ethereum stores and verifies BLS signatures of the source chain's blocks.

ZK-bridges are the next level. Succinct, Polyhedra zkBridge, Electron Labs generate a ZK-proof of the correctness of the source chain's consensus. On the destination chain, the proof is verified, not the validator signatures. Removes trust in the committee. But ZK-proof verification is gas-expensive — from 200k to 500k gas on Ethereum L1 depending on the proof system. A ZK-bridge is safer than a relay-based bridge but requires 2-3 times more gas for verification.

What Does Cross-Chain Bridge Development Include?

We implement the project turnkey and deliver a complete set of results. Our clients receive:

Implementation: What to Consider Before the First Line of Code

Mandatory components for any production bridge:

Pauser. Emergency pause function, called by multisig or automatically upon anomaly detection (suspicious volume, atypical call sequence). Most hacked bridges did not have or did not use a pauser in time.

Rate limiting. Limit output volume per time interval. If an attacker drains the bridge — rate limit gives time to react. Implementation: transferVolume[currentEpoch] += amount; require(transferVolume[currentEpoch] <= epochLimit).

Finality checks. Specific to each chain. Not "wait 1 block", but use finality API or wait for required number of confirmations.

Relayer monitoring. An autonomous service that monitors the state of both bridge sides. If a message is sent but not delivered within N minutes — alert. If locked balance diverges from totalSupply of wrapped token — critical alert.

Timeline and Cost

A simple ERC-20 bridge on top of an existing messaging layer (LayerZero OFT or Wormhole NTT) — 4-8 weeks including testing and audit. A custom bridge with own verification, multi-chain support, rate limiting, monitoring — 12-24 weeks. A ZK-bridge with custom proof circuits — from 6 months.

Bridge audit takes longer than a standard DeFi protocol audit: cross-chain scenarios, finality edge cases, reorg attacks must be tested. Minimum 3-4 weeks for a production-grade solution.

Cost is calculated individually after workload assessment. We have been working since 2018 and have completed 15+ projects in blockchain infrastructure. Contact us — we will evaluate your project and propose the optimal bridge architecture.