unionlabs/union: a zero-knowledge interoperability protocol built around Consensus Verification and IBC

What Union replaces, and for whom

Most cross-chain bridges ask you to trust a set of signers. Union's README states the protocol is "based on Consensus Verification and has no dependencies on trusted third parties, oracles, multi-signatures or MPC." That sentence is the whole pitch. Instead of a committee attesting that something happened on chain A, the destination chain verifies the consensus of chain A directly, using light clients. The repository backs this up structurally: the Cargo workspace lists a long series of verifier crates such as lib/ethereum-sync-protocol, lib/arbitrum-verifier, lib/cometbls-groth16-verifier, lib/parlia-verifier and lib/tendermint-verifier, and a parallel set of light client type crates. That is the shape of a system where each connected chain needs its own verification logic, not a generic message relay.

The audience follows from that. This is infrastructure for teams building cross-chain applications, not an end-user product. If you are writing a contract that needs to move an asset from Ethereum to a Cosmos chain, Union wants to be the layer under you. The README also points at IBC for Cosmos compatibility, which means the mental model is closer to a Cosmos IBC relayer setup than to a typical bridge SDK. Teams already comfortable with IBC will recognise the vocabulary; teams coming from an EVM-only background will find a lot of new nouns.

The four moving parts: uniond, galoisd, voyager and the light clients

The README's component table is the clearest map of the architecture. uniond is the node implementation, written in Go and built on CometBLS. galoisd is the zero-knowledge prover, written in Go using Gnark. voyager is the relayer, written in Rust and described as modular. The cosmwasm directory holds the CosmWasm smart contract stack and the light clients, and evm holds the Solidity side.

The data flow implied by that layout runs roughly like this. A source chain produces blocks and consensus proofs. A light client contract on the destination chain verifies those proofs. galoisd generates the zero-knowledge proofs that make the verification cheap enough to run on chain. voyager watches both sides and submits the transactions that carry state across. uniond is the chain that anchors Union's own state, and unionvisor is the supervisor intended for production node operation.

Two details are worth noting because they constrain everything else. First, the prover is a separate process with its own RPC surface: the workspace contains lib/galois-rpc, so galoisd is not a library you link, it is a service you run. Second, the relayer is written in Rust while the node is written in Go, which is why the quickstart insists on Nix rather than a language-specific toolchain. You are not building one project, you are building a workspace that spans Go, Rust, Solidity, Cairo and TypeScript.

Building uniond and voyager from source with Nix

The README's quickstart does not offer binaries. It asks you to install Nix first, with the Determinate Systems installer:

curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install

After that, the README states you can reproducibly build any component from source. The example builds uniond, voyager and the app:

nix build .#uniond -L
nix build .#voyager -L
nix build .#app -L

# to see all packages, run:
nix flake show

The README says the result of whatever you build will be in `result/`. That is the standard Nix output symlink, so after `nix build .#uniond -L` you should find the node binary under `result/`.

For development rather than a one-off build, the README provides a dev shell containing cargo, rustc, node and go:

nix develop

It notes this does not affect your system outside the repository. Before opening a pull request, the README asks you to format the whole repo and check spelling:

nix run .#pre-commit -L

One practical caveat the README states directly: some components can only be built on Linux. On macOS it recommends OrbStack to set up a NixOS VM, and notes that most Union developers use macOS with OrbStack and that there is no need to install Nix inside the NixOS VM. If you are on macOS and skip that step, expect build failures rather than a warning.

Where the supported-chain list becomes a hard boundary

Union's README includes a supported chains table with mainnet and testnet identifiers. On mainnet the list covers Arbitrum, Babylon, Base, Berachain, Bob, BSC, Corn, Ethereum, Osmosis, Sei, Union and Xion. Sui appears only as a testnet entry, `sui.4c78adac`, with a dash in the mainnet column. The README points to https://docs.union.build/ucs/04/ for the full list.

That table is the single most important document for evaluating fit. Adding a chain is not configuration; it requires a light client and a verifier, which is why the Cargo workspace carries separate crates per ecosystem. If your destination chain is not there, Union is the wrong tool today, and no amount of relayer configuration will change that. The Sui row is a useful illustration: testnet only means you can experiment but not deploy.

The second boundary is governance. The README states that upgradability of contracts on other chains, connections, token configurations and protocol evolution will all be controlled by decentralized governance. That is a real dependency, not a footnote. Your integration's behaviour can change through a governance process you do not control, and the README does not describe the mechanics of that process, the voting thresholds, or the upgrade delay. Anyone integrating should treat that as an open question to resolve against the docs before committing funds.

Release cadence, versioning and what it costs to keep up

The most recent releases are all release candidates: bundle-union-testnet-10/v1.3.0-rc4, bundle-union-testnet-10/v1.3.0-rc3, and uniond/v1.3.0-rc2. The naming is informative. Bundles are versioned against a specific testnet, so a bundle release is not a promise about mainnet. If you are running infrastructure, you should expect to track a moving target and to read each release's notes rather than assume compatibility.

The repository does contain VERSIONING.md at the top level, which suggests the maintainers have written down a versioning policy. The README itself does not summarise it, and the README does not document rollback. That absence matters for operators: if an upgrade to a bundle goes wrong, the README does not tell you how to revert. Verify that against VERSIONING.md and the node's own README before you run anything in production.

On the licence side, the repository root carries both LICENSE-APACHE and LICENSE-MIT, and the project metadata lists Apache-2.0. That dual-licence layout is common in Rust workspaces and is permissive in both directions, but the components are not uniform: the repository also contains Solidity, Cairo and TypeScript code, and the top-level LICENSE files may not cover every subdirectory. Check the licence of the specific crate or contract you intend to reuse rather than assuming the root files apply. This is a description of what the repository contains, not legal advice.

Union against a Cosmos IBC relayer setup

The obvious alternative is running a conventional IBC relayer between Cosmos chains, or between a Cosmos chain and an EVM chain via an existing bridge. The difference is where trust sits. A classic relayer setup still depends on light clients, but the ecosystem around it assumes you are connecting chains that already speak IBC natively. Union's README describes it as implementing IBC for Cosmos compatibility while also connecting to EVM chains like Ethereum, Berachain, Arbitrum and others, and the workspace contains an entire evm directory plus lib/ibc-solidity. So Union's bet is that it can bring non-IBC chains into the same verification model rather than routing them through a separate bridge contract with its own trust assumptions.

That bet has a cost. A plain Cosmos-to-Cosmos relayer is a well-trodden path with years of operational experience and a large pool of operators who know how to run one. Union asks you to run galoisd as well, because the zero-knowledge proofs are what make verification affordable on chains that cannot cheaply verify a foreign consensus. You are trading operational simplicity for a different security argument. Whether that trade is worth it depends entirely on whether your counterparty chain is in the supported list; if both ends are Cosmos chains that already speak IBC, the extra prover is hard to justify.

Who should take this on, and what to check first

Union fits teams that need cross-chain message passing where the security model cannot include an external signer set, and that are prepared to build from source. The Nix flake is the intended entry point, and the README is explicit that reproducibility is the reason for it. If your team already runs Cosmos infrastructure, the IBC framing will be familiar. If your team is EVM-only and wants a drop-in bridge SDK, the component table alone should tell you this is a larger commitment than that.

Before adopting anything, do three concrete things. Run `nix flake show` to see which packages the flake actually exposes, because the README's examples cover uniond, voyager and app but not everything in the component table. Read VERSIONING.md, since the README does not document rollback and the current releases are release candidates. And confirm that a light client exists in cosmwasm/lightclient for each chain you intend to connect, because the supported chains table is the boundary that no configuration can move.

Editorial conclusion

Adopt Union if you need cross-chain message passing whose security argument rests on consensus verification rather than an external validator set, and you are willing to build from a Nix flake and follow release candidates such as bundle-union-testnet-10/v1.3.0-rc4. Do not adopt it if you need a stable tagged release with documented rollback, or if your target chain is not in the supported list. Before committing, run nix flake show and confirm the package you need is exposed, then check the light client module for your destination chain exists in cosmwasm/lightclient.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes