The canonical IBC repository distinguishes transport, authentication and ordering from application packet processing. Its current index separates IBC v1 from v2, rather than presenting one undifferentiated list. Many classic specifications are indexed as Candidate, while newer v2 entries are Draft. Some individual classic files still carry older draft metadata, so the index, file version and implementation must be read together. These are ecosystem engineering specifications, not ISO certifications.

Their numbers identify technical documents and applications; they do not identify a tradable asset. A chain using one part of the stack has not necessarily enabled every application listed in the repository.

The protocol team's history records an initial production asset transfer between Cosmos Hub and IRISnet on April 2, 2021. Later development extended the scope beyond its original concentration in Cosmos SDK networks. The current overview describes support for additional execution environments and new application capabilities, including general message passing. That historical progression explains the ambition to make independent ledgers communicate without forcing them into one execution system. It should not be read as a route directory.

A particular transfer still depends on the implementations, clients and applications actually configured between its endpoints, rather than the broadest ecosystem listed on an overview page.

ICS-2 defines a client as verification logic paired with a trusted state of a remote system. It checks updates and provides a way to detect relevant consensus misbehavior. IBC does not prescribe one underlying consensus design: the specification explicitly accommodates a single signing process, a quorum or a Byzantine-fault-tolerant network. A client generally does not re-execute every remote transaction. This makes the installed client an essential part of the security description. Two routes can both use IBC while relying on different verification assumptions.

Inspecting the client type and its trusted state is more informative than calling every connection equally trustless.

ICS-23 describes commitments and proofs of existence or nonexistence at particular positions in state. A relayer can supply a proof, while the receiving handler checks it against the relevant commitment. That distinction lets a receiver verify a state claim without accepting the relayer's word for it. The document specifies required properties rather than one universal concrete tree implementation. Correct paths, values and proof interpretation matter alongside the client that establishes the trusted root. A cryptographic proof answers a bounded question about committed state.

It does not independently establish the economic value of a token or the correctness of every application that produced that state.

In classic IBC, ICS-3 describes a connection as two corresponding pieces of state, each associated with a client of the other chain. The handshake establishes counterpart identifiers and the context used for later verification. Channels can then associate application traffic with that connection. The protocol is designed to allow untrusted actors to submit the required messages, with verification enforced by the chains. This is why a connection is more than two websites agreeing to display a bridge button. It creates inspectable protocol state.

The initial trusted states and correct client configuration remain consequential even when the handshake itself follows the specification exactly.

ICS-4 gives classic channels their ordering, execution and application-association rules. Packets may travel between chains that produce blocks independently, and an external carrier can delay or reorder them. Ordered and unordered channels handle those conditions differently while protecting against repeated execution. The packet payload is interpreted by its application rather than by the transport layer. An acknowledgement reports the receiving side's result, while timeout processing handles a packet that can no longer be received under its deadline.

These mechanisms are designed for asynchronous systems. A transaction appearing on the sending chain is therefore a stage in a cross-chain operation, not automatic evidence that the intended destination action has completed.

ICS-18 describes relayers as off-chain processes that inspect chain state, construct messages and submit them to the other side. Safety is intended not to depend on an honest relayer; verification takes place on-chain. Liveness still needs a correct, functioning relayer and functioning endpoints. A missing carrier can leave a legitimate operation waiting even when no forged proof would be accepted. Relayers also carry acknowledgements and timeout evidence, so their work continues after the initial send.

This separates two questions users often combine: whether the protocol can reject an invalid message and whether infrastructure is available to complete a valid one. Incentives and reliable operation address the second question.

ICS-20 defines fungible-token transfer as an application of IBC. Depending on the token's path, a send escrows source tokens or burns returning vouchers; receipt mints a representation or releases escrow. Failed acknowledgements and timeouts invoke refund handling. The denomination carries path information, so representations reached through different routes cannot simply be assumed identical because a wallet shows the same ticker. Returning through the appropriate path is part of redeeming the original representation. These rules aim to preserve supply across the transfer.

They do not remove the underlying token issuer's risks or make every asset representation equally desirable in a market.

ICS-26's classic routing module connects incoming protocol messages with the application callbacks that must handle them. It maintains a mapping to the relevant modules and invokes their handshake or packet logic. This keeps the relayer from needing a bespoke delivery interface for each application. It also shows where application behavior begins: a transport proof can establish that a message was committed, while the receiving module must correctly interpret it and decide what state changes to make.

Token accounting, account execution and application-specific checks cannot be replaced by the routing layer. Auditing a cross-chain application therefore means examining both its use of the transport and the callbacks that act on received data.

Classic ICS-27 distinguishes a controller chain, a host chain and an owner on the controller. The host account executes instructions carried in authenticated IBC packets rather than ordinary transactions signed by a private key belonging to that account. A host can restrict permitted functionality, and supporting the controller role does not require a chain to host accounts in return. The design also addresses ordering and recovery of access after a channel closes.

These details matter for applications that promise remote staking or account management: the relevant host must enable the role and allowed messages, while the controller must enforce who can send instructions for each owner.

The newer ICS27-GMP specification, created in January 2026, is a separate v2 design for general message passing. It derives a destination caller account from the client identifier, sender and salt, instead of requiring a per-account channel handshake. Calls use a shared port and return an acknowledgement containing the execution result. The destination runtime interprets the payload and must support its encoding. This draft targets heterogeneous execution environments rather than making their contract languages identical.

The similar ICS number should not conceal the different protocol version: classic Interchain Accounts and ICS27-2 general message passing describe related ambitions through distinct account and lifecycle machinery.

The February 2025 IBC v2 announcement explains a redesign around clients, a router and applications. Removing classic connection and channel handshakes reduces integration work and makes application upgrades less dependent on coordinating a new channel lifecycle. The router handles replay and timeout checks before dispatching verified traffic. The same announcement explicitly allows different client security models, including multisignature and single-signature verification. That flexibility can make integration easier, but it also makes a precise client description indispensable.

The announcement's planned launch dates belong to its historical context. They should be separated from later evidence showing when a product or particular route actually became available.

Interchain Labs' launch release dated April 10, 2025 described Eureka as a product combining IBC v2, the Cosmos Hub as a routing layer and Skip's application and API infrastructure. Its first iteration connected Ethereum with the Cosmos ecosystem. The release separately described other integrations as forthcoming, so its entire partner list cannot be treated as a list of completed deployments on that date. The distinction between a protocol and a product is useful here: IBC specifies communication rules, while Eureka packages implementations, routing and user access around them.

The publisher's speed, price and growth language remains promotional rather than a permanent guarantee for every transfer.

The earlier Gaia v23 proposal shows the chain-level coordination behind that product launch. Interchain Labs requested a governance-approved software upgrade and documented dependency versions, testing and contingency handling. It also proposed a narrowly described authorization to upload the Ethereum Wasm client because that component was not ready before the vote submission. This is a more concrete account of deployment than a claim that interoperability appears automatically once software exists. The proposal is evidence of the requested upgrade and its disclosed permission boundary.

It does not, by itself, establish the exact later activation of every contract, route or future network mentioned in the discussion.

IBC-Go's release policy distinguishes software versions from protocol versions. It also distinguishes API changes from state-machine changes that require coordinated upgrades. A minor software version can therefore have operational significance beyond what someone expects from ordinary application versioning. Pre-release labels carry separate warnings, and stable support has defined lifecycles. Maintaining a connection involves following the implementation actually installed, its dependencies and the releases still supported by its maintainers.

The existence of a published specification does not keep an obsolete binary repaired. Protocol compatibility and continuing security maintenance must be evaluated together when operators decide how and when to upgrade.

An April 28, 2025 Cosmos Hub proposal illustrates that maintenance burden. Lexa requested an Ethereum light-client migration ahead of Pectra, explaining that the client had been instantiated before the fork height was known and could freeze without the update. The issue was continuity of verification across a remote consensus change. It demonstrates why a bridge can require action even when its own token-transfer application has not changed. This source records a migration proposal, not a claim that Pectra caused an exploit or that the text alone proves the migration executed.

Operational status needs the subsequent chain record as well as the rationale for the work.

A later proposal sought scoped authority for the Eureka Security Council to store and migrate 08-wasm light-client code. Its rationale was faster response than successive governance cycles, with named message permissions rather than an unspecified administrative power. The reviewed thread also includes a request for strict auditing and transparent review. This is an important governance tradeoff: repair speed and scrutiny have to coexist when code determines which remote state is accepted.

The article treats the document as a proposal and does not infer an executed grant from supportive comments. Current authority on a particular deployment requires checking its enacted permissions and subsequent changes.