ibc-go and the Go implementation behind most IBC chains

A protocol implementation, not a client library

The Inter-Blockchain Communication protocol is a blockchain interoperability solution that allows blockchains to talk to each other. Blockchains that speak IBC can transfer any kind of data encoded in bytes, including tokens, messages and arbitrary application logic, and IBC is described as secure, permissionless, and designed to connect sovereign blockchains into a single interoperable network.

The scope of the Go implementation is stated with a claim that is worth taking seriously because it is quantified. The IBC implementation in Golang has been used in production by the majority of the 200 or more chains that have utilized IBC, and it is built as a Cosmos SDK module.

That last phrase is the whole integration story. ibc-go is not a client library you add to a service. It is a module you wire into a chain's application, with the Cosmos SDK providing the state machine, the keeper pattern and the message routing. The alternative routes into IBC, which the project points at through the IBC technical resource catalogue, include applications, middleware and tools such as relayers, and those are the routes for a team whose chain is not Cosmos SDK based.

The Go module path carries the major version, and the manifest states it plainly:

module github.com/cosmos/ibc-go/v11

go 1.26.5

So the current line is v11, and the toolchain requirement is Go 1.26.5. The dependency set is a Cosmos SDK application stack rather than a small library. The SDK itself is pinned at v0.55.0, with the store package at v2.0.0, CometBFT at v0.40.0, and the collections, errors, log and math modules from the cosmossdk.io namespace. There is also an explicit replace directive for goleveldb, pinned to a specific commit.

Release lines are the unit of compatibility, and v9 is gone

The Releases section is short and it contains the single most important operational fact for anyone depending on this library.

The release lines currently supported are v10 and v11. v9 has been retracted and has been replaced by v10. The project points to a versioning guide in the RELEASES.md file for how to read the versioning scheme.

This is a real constraint rather than a technical footnote. Because ibc-go tracks protocol specifications rather than only an API, the version number tells you which specification revisions your chain implements. A retraction means v9 is not merely old, it is withdrawn, and a chain that is still on it is in a category the maintainers have explicitly moved away from.

The recent release history shows why the lines move. v10.7.0 and v11.1.0 were both tagged on 2026-05-20, and v11.2.0 followed on 2026-07-15. Two lines, tagged on the same day, is the signature of a project that maintains a stable branch and an active one in parallel.

The repository is not archived and the last push was on 2026-10-22, so maintenance continues on the branch that follows the 2026-07-15 release. The presence of RELEASES.md and a releases-decision-tree.png at the repository root says the project has thought carefully about how it decides which line to cut, which is a good sign for a dependency that other chains depend on for consensus critical code.

Audits cover named specifications, not the whole protocol

The Audits section lists the work that has been done on the ibc-go source code, and reading it carefully tells you more than a generic claim of being audited would.

There is an audit of ICS20 Fungible Token Transfer by Informal Systems, and a second of ICS20 Fungible Token Transfer V2 by Atredis Partners. ICS27 Interchain Accounts was audited by Trail of Bits together with Informal Systems. ICS08 Wasm Clients was reviewed by Ethan Frey of Confio and by Halborn. ICS04 Channel upgradability was assessed by Atredis Partners. And IBC v2 has a collaborative audit report from April 2025.

The pattern is instructive. Every entry names a specific ICS specification, and between them they cover the token transfer, interchain accounts, Wasm clients and channel upgradability. That is a useful set to have audited, and it is not the same as the whole protocol.

So a chain that is only doing fungible token transfers over IBC has had its path audited, twice. A chain that depends on a specification not in this list is relying on code whose review history you would have to find elsewhere. The audit reports are in the repository under docs/audits, which is a real advantage over a vendor statement.

The security reporting path is separate from the audits. To report a security vulnerability, the README points to a Coordinated Vulnerability Disclosure Policy in the SECURITY.md file, and the repository also carries an OpenSSF Scorecard badge, a Go report card badge, a Codecov badge and a badge for the tests and code coverage workflow, plus a separate E2E status badge. For a library that other chains put in the consensus path, that set of signals is what a due diligence process actually reads.

Cosmos Labs maintains it, the Interchain Foundation owns it

The Maintainers section describes an unusual governance arrangement that is worth understanding before you depend on the code.

Cosmos Labs maintains the core components of the stack, namely the Cosmos SDK, CometBFT, IBC, Cosmos EVM and various developer tools and frameworks. The detailed maintenance policy lives in a separate policy document, and Cosmos Labs also provides advisory and engineering services for blockchain solutions.

Then the second paragraph changes the ownership question. Cosmos Labs is a wholly-owned subsidiary of the Interchain Foundation, the Swiss nonprofit responsible for treasury management, funding public goods and supporting governance for Cosmos.

So the entity writing the code is a for-profit company, and the entity that owns it is a Swiss nonprofit. For a project that other sovereign chains depend on, that structure means the code has a single commercial maintainer with a clear incentive to keep it current, and a governance owner whose mandate is the wider ecosystem rather than any one chain's roadmap.

The README also states that the Cosmos Stack is supported by a community of open-source contributors, which is the normal claim, and the practical structure for a contributor is the contributing guidelines in the CONTRIBUTING.md file. Issues in the repository are described as exclusively for bug reports and feature requests, with the help routed to Discord, Telegram and Slack, and the two issue labels for newcomers are good first issue, for well defined tasks suited to developers new to ibc-go, and help wanted, for work that is a bit more involved and usually requires some familiarity with the codebase already.

The repository also contains an AGENTS.md file and a.gitvote.yml file.

The container image builds a relayer binary, not a node

The Dockerfile in the repository is worth reading because it shows what the project considers a distributable artefact, and it is not what you might guess.

The build stage starts from golang:1.26-alpine, installs the C toolchain and headers, and takes the IBC_GO_VERSION as a build argument. There is a guard that the version must actually be specified, so an image cannot be built without knowing which release it is. The comment explains why the internal, simapp, testing and modules directories are copied before go mod download, and it is a specific Go gotcha: replace directives to local paths break if the local files are not copied before the download step.

The runtime stage is alpine:3.21, and it copies a single binary, the simd executable, out of the builder and out of the go/build/simd path, with the entrypoint set to simd.

So the container is a simapp binary, which is the reference chain binary that the project uses for development and testing, and not a relayer, not a full node and not the chain you would run in production. The naming is a little confusing at first because simd is also the conventional name for a Cosmos SDK chain binary, and here it is the example application rather than a generic one.

The Makefile shows the same emphasis. It has separate package sets for the simulation and non-simulation code, computes the version from git describe and the commit from the git log, and it handles the ledger hardware wallet build tag conditionally, erroring out with a message to install gcc or set LEDGER_ENABLED=false if the compiler is missing. There is a cleveldb branch that adds a gcc build tag when COSMOS_BUILD_OPTIONS contains it, and a warning for OpenBSD that disables ledger support entirely.

The repository layout separates protocol code from test infrastructure

The top level of the repository describes where the interesting boundaries are.

The modules directory holds the on-chain code, and the Quick Navigation section in the README begins with the Core IBC Implementation under modules/core, and then lists the client specifications including ICS 02 Client. The proto directory holds the protobuf definitions, with a buf.work.yaml at the root for the protobuf toolchain, and there is a .golangci.yml for linting and a .clang-format file.

Then there is the test infrastructure, which is substantial. There is an e2e directory, a testing directory, a simapp directory, a contrib directory, and an internal directory. The internal directory is what the Dockerfile copies before the module download, which tells you it holds things the build needs and that are not part of the public package surface.

The tooling files are also telling. There is a requirements.txt with pinned Python dependencies, which is not a Python project, so those pins exist for a script in the scripts directory that talks to GitHub or the release tooling. There is a package-lock.json, which is likewise not a JavaScript project, and a go.work.example, which is a template for a Go workspace file for developers working on several modules at once.

A CHANGELOG.md and a docs directory sit alongside, and the docs are where the per-specification detail lives, including the audit reports referenced earlier. The overall shape is a mature, long-lived library whose build and test tooling has grown to match a large multi-year codebase, and the presence of an AGENTS.md file is a newer addition aimed at coding agents working inside the repository.

Where ibc-go is the wrong tool

The first wrong case is a chain that is not built on the Cosmos SDK. ibc-go is a Cosmos SDK module, and the SDK provides the keeper pattern, the message routing, the store and the ABCI plumbing that the module assumes. A chain on another framework that wants to speak IBC is looking at a different implementation, and the technical resource catalogue is where the alternatives are listed.

The second wrong case is a chain that needs a protocol line the project has dropped. v9 is retracted and replaced by v10, and the supported lines are v10 and v11. Staying on a retracted line means staying on code the maintainers consider withdrawn, and the upgrade path to a supported line is a migration rather than a dependency bump.

The third is a use case that is not IBC at all. If the requirement is to move a token between two chains you control with a trusted relayer and no light client verification, the full protocol machinery, its state and its light clients are more than the problem needs. IBC is built for connecting sovereign chains, which means the verification model has to assume the other side is not yours and that you may need to track its state.

The alternative worth naming is writing your own light client and packet protocol, or using another implementation in another language. The difference in approach is the security model. ibc-go gives you a protocol whose verification is a light client and a merkle proof, audited for specific specifications, with the trade that the whole stack is coupled to the Cosmos SDK and to the maintainers' release discipline, and that adopting it means adopting a version line and its upgrade cadence along with the code. A hand written implementation gives you exactly the features you need with no upgrade path at all, at the cost of reimplementing the parts an audit has already covered. For a chain whose whole reason to exist is interop with other IBC chains, the audited implementation is usually the right answer, because the counterparty on the other side will be running ibc-go anyway and the protocol needs to line up on both sides.

Editorial conclusion

ibc-go fits a Cosmos SDK chain that needs to send packets, tokens or application logic across a light client verified connection to another sovereign chain, and that wants a protocol implementation with published audits behind it. It is the wrong choice outside the Cosmos SDK, since it is a module rather than a standalone library, and the wrong choice for a chain that needs a protocol line the maintainers have already dropped. Before you adopt it, read the RELEASES.md versioning guide, confirm your SDK version matches the release line you pick, and check the ICS specifications for the specific features you intend to use, because the audit list covers ICS20, ICS27, ICS08 and ICS04 rather than the whole protocol.

Frequently asked questions

Official sources

1. cosmos/ibc-go on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases