Across vs IBC: Ops Complexity

No on-chain light clients: Relies on a decentralized network of off-chain relayers and a single on-chain Spoke Pool contract per chain. This drastically reduces the smart contract footprint and gas costs for the destination chain. Ideal for teams wanting to add a new chain with minimal deployment overhead.

Fraud proofs with economic slashing: Uses a 30-minute optimistic window where relayers can dispute incorrect fills. The system is secured by bonded relayers (e.g., UMA's Data Verification Mechanism) rather than live consensus. This simplifies real-time operations but introduces a finality delay, best for non-instantaneous value transfers.

Formally verified light clients: Each chain must run a light client of its counterparties, providing cryptographic security without trusted intermediaries. This creates a robust, permissionless mesh network. Essential for protocols like Osmosis and Stride that require instant, guaranteed-finality cross-chain composability.

Significant consensus-layer integration: Requires implementing the IBC protocol stack (ICS standards), light client logic, and relay infrastructure. This is a complex, one-time engineering effort but results in a standardized, low-fee communication layer. The cost is justified for chains building a long-term presence in the Cosmos ecosystem.

Optimistic verification model: Relies on a single, bonded relayer and fraud proofs, enabling fast finality (often <2 minutes) and low, predictable fees. This matters for high-frequency arbitrage and user-facing dApps where cost and speed are primary UX drivers.

Light client verification: Each chain validates the state of the other using its own consensus, requiring no external trust assumptions. This matters for sovereign chains (e.g., Cosmos, Osmosis) and high-value institutional transfers where security is non-negotiable.

No chain-specific client maintenance: Uses a single, unified smart contract on each chain (e.g., SpokePool). This drastically reduces the engineering burden compared to managing IBC light clients and relayers for each new connection. Ideal for teams wanting to connect to 10+ chains without proportional ops growth.

Relayer costs are abstracted: Users pay a fee that covers the relay network's gas costs and profitability. Protocol teams don't manage or subsidize relayers. This simplifies budgeting and eliminates the operational risk of relayers going offline due to funding issues, a common concern in permissionless IBC networks.

End-to-end cryptographic security: Messages are verified by light clients on-chain, eliminating trust in external relayers. This provides stronger security guarantees for high-value, interchain transactions (e.g., cross-chain governance, asset transfers) where minimizing trust assumptions is critical.

Universal application layer (ICA/ICQ): Enables cross-chain smart contract calls (Interchain Accounts) and queries (Interchain Queries). This allows for complex, composable applications (e.g., Osmosis pools using assets from multiple zones) that are natively interoperable, rather than bridge-mediated.