Wormhole: a monorepo where one bridge spans nine chains

One protocol, many chains, one monorepo

This monorepo contains the reference implementation of the Wormhole protocol, and the repository layout is the clearest statement of what that means in practice.

The chain directories are the point. There is `ethereum/`, `solana/`, `sui/`, `near/`, `aptos/`, `algorand/`, `cosmwasm/` and `svm/`, which is the Solana Virtual Machine, and a `third_party/` directory. Alongside them sit `node/` for the guardian node, `sdk/` for the client libraries, `clients/` for the various language clients, `proto/` for the protocol buffer definitions, `guardianset/` for the guardian set material, `devnet/` for the local network, `deployments/`, `docs/`, `audits/`, `whitepapers/`, `dashboards/`, `lp_ui/` for the liquidity provider interface, `testing/`, `tools/`, `scripts/` and `linters/`.

And the topic tags are blockchain, golang, rust and solidity, which names the three implementation languages in play. The Go is the guardian node, the Rust is in the Solana and other high performance pieces, and the Solidity is the smart contract side on Ethereum compatible chains.

The `svm/` directory deserves a note. Putting the Solana Virtual Machine in the same shape as the chain directories means a chain that is a virtual machine rather than a single chain gets the same treatment in the build system, which is how a protocol that supports a growing list of execution environments stays tractable.

The build system is a multi-language one, and the top level shows it. There are `Dockerfile.cli`, `Dockerfile.const` and `Dockerfile.proto` for the different build targets, a `Tiltfile` for the local development environment, a `Makefile` with a `Makefile.help` include, a `buf.yaml` with two generation templates and a `buf.lock` for the protocol buffers, a `.nvmrc` for the Node version, a `.golangci.yml` for the Go linter, and a `codeql/` directory.

The whole thing is a reference implementation, and the reference implementations of interoperability protocols are large by definition, because the protocol is only as good as its widest supported chain.

The guardian node, and how it is built

The guardian node is the piece that has to work, so it is worth looking at how the build treats it.

The Makefile header states the intent plainly. It is for production builds, it is not meant or optimized for incremental or debug builds, and the devnet should be used for development. Then the reason for the approach, which is a design decision rather than a preference: for the sake of decentralization, we specifically avoid the use of prebuilt containers wherever possible to increase diversity, and operators sourcing their compiler binaries from different sources is a good thing.

That is an unusual and deliberate choice. Building from source on each operator's machine, with their own toolchain and their own compiler binaries, means the deployed guardian nodes are not all running an identical artefact. A fleet of identical binaries is a single point of failure, because a bug or a supply chain compromise in one image affects every node at once.

The build itself follows from that. The `generate` target goes into `tools` and runs `./build.sh`, removes the `bridge` and `node/pkg/proto` directories, and then runs `tools/bin/buf generate` to regenerate the protocol buffer code. The `node` target builds the `guardiand` binary with `CGO_ENABLED=1` and a version stamp:

cd node && go build -ldflags "-X github.com/certusone/wormhole/node/pkg/version.version=${VERSION}" \
  -mod=readonly -o ../$(BIN)/guardiand \
  github.com/certusone/wormhole/node

The version string comes from `git describe --tags --dirty`, falling back to `dev-` plus the short commit hash. So a build from a dirty tree is marked as such, which is a small thing that matters when you are trying to work out what a running node is running.

And the install target does something that is easy to miss. After installing the binaries, it runs `setcap cap_ipc_lock=+ep $(PREFIX)/bin/guardiand`. The guardian node needs the ability to lock memory, and the capability is granted to the binary rather than to the process running as root, which is the right way to do it and a detail worth copying.

The testing targets follow the same structure. `test-coverage` runs the Go tests for the node and the SDK with `-count=1 -v -timeout 5m -race -cover`, and there are separate lint targets, one running `scripts/lint.sh lint` for spelling and Go, and one running `scripts/clippy.sh` for clippy on most of the Rust crates.

The risk notice, and the deployment documentation

The README's warning is unusually blunt, and it is the part a reader should not skip.

The software is distributed on an as is basis, without warranties of any kind, either express or implied, and the plain version of the same statement is that this is a very complex piece of software which targets a bleeding-edge, experimental smart contract runtime. Mistakes happen, and no matter how hard you try and whether you pay someone to audit it, it may eat your tokens, set your printer on fire or startle your cat. And cryptocurrencies are a high-risk investment, no matter how fancy.

The register is deliberately comic, but the content is not. Three things are being said at once. The legal disclaimer is a normal one for this class of software. The technical warning is that the target runtime is experimental, which is a statement about the substrate rather than about the bridge code. And the risk statement is that the asset class is volatile regardless of how good the interoperability layer is.

The documentation set around the warning is what a production operator needs. `DEVELOP.md` has instructions for setting up a local devnet, `CONTRIBUTING.md` covers contributing, `SECURITY.md` has information about the security audits and the bug bounty program, and `docs/operations.md` is the node operator instructions. The Live Contracts page is linked for the current testnet and mainnet deployments of the smart contracts, which is the document to check before assuming a chain is enabled.

There is also a `SAFETY_CRITICAL_CODE.md` and a `SECURITY_CONTEXT.md` at the top level, plus an `audits/` directory. The presence of a file named for safety critical code is a signal about how the maintainers themselves think about the risk surface, and the audits directory is the record of the external reviews.

The `docs/operations.md` pointer is the one to read first if you are evaluating this for a production guardian, because the difference between a reference implementation and an operated deployment is exactly what that document covers.

The version number tracks chain onboarding

The release history is the most informative thing about the project, and the pattern in it is specific.

v2.66.0 is labelled the Tron mainnet, v2.67.0 is labelled the Robinhood chain mainnet, and v2.68.0 carries no chain name. Earlier in the list, v2.65.0 and v2.64.0 have no labels either.

So the release notes are partly a changelog and partly a deployment log. When a new chain goes live, there is a release, and the release is named after the chain. That is a useful convention, because it means the list of versions in the repository doubles as the list of chains that have been onboarded, in order, and you can tell at a glance when support for a given chain landed.

It also tells you the shape of the maintenance work. Onboarding a chain means writing a new module under the chain directory, wiring its messages into the protocol buffers, and deploying contracts, and the version bump is the marker for that having happened. A patch that fixes something in the node does not need a new chain to be named, so the absence of a name in a release number is a signal that the change was in the shared code rather than in a new integration.

The release cadence itself is visible too. v2.66.0 on 2026-07-27, v2.67.0 on 2026-08-04, v2.68.0 on 2026-09-04, with the last push on 2026-10-16, so there is work happening between releases and the repository is being touched.

For an engineer choosing whether to build on this, the practical questions are whether your chain is already in the list of onboarded chains, whether the SDK for your language is present, and whether you intend to run a guardian node yourself or depend on the public one. Those three questions are answerable from the live contracts page, the `clients/` directory and the operations documentation respectively, and they matter more than the version number itself.

Editorial conclusion

Wormhole fits a developer whose application has to accept assets or messages from several chains, because the chain specific work is already written and the protocol's semantics are documented, and because the guardian node is a single Go binary you can run yourself. Skip it if you only need one chain, since the operational surface is large, and read the safety notice before you rely on it, because the project distributes the software as is and says plainly that it is a complex piece of software targeting a bleeding-edge experimental smart contract runtime. Before you deploy a guardian, read the operations documentation and the security policy, and note the release pattern, where v2.66.0 was the Tron mainnet, v2.67.0 the Robinhood chain mainnet and v2.68.0 a further release, so the version number tracks chain onboarding as much as code changes. The last push was on 2026-10-16.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wormhole-foundation/wormhole on GitHub