Union: A Zero-Knowledge Interoperability Layer Built on Consensus Verification
Union is a zero-knowledge interoperability protocol for transferring data and assets between blockchains without a trusted intermediary.
At a glance
- What is it?
- Union is a Rust-heavy, Nix-based monorepo that moves assets and messages between Cosmos and EVM chains using zero-knowledge proofs instead of trusted bridges. The trade-off is real: the protocol avoids oracles and multisigs, but only if you accept the operational burden of running a prover and relayer stack.
- Who is it for?
- Adopt Union if you need trust-minimized cross-chain transfers between Cosmos and EVM ecosystems and you have the Rust and Nix skills to run or extend the prover and relayer stack. Do not adopt it if you expect a plug-and-play bridge with minimal infrastructure overhead, because the protocol depends on operating or outsourcing a zero-knowledge prover.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 52 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Trusted Bridges and the Alternative Union Chooses
Cross-chain transfers usually rely on a trusted intermediary: a multisig, an oracle, or a committee that signs off on state. Union rejects that model. The README states that the protocol is based on consensus verification and has no dependencies on trusted third parties, oracles, multi-signatures or MPC. That is a specific claim, and it is the core of the project. Instead of asking a group to attest that a transaction happened on chain A, Union verifies the consensus of chain A directly, using zero-knowledge proofs. The intended users are developers and operators who want to move assets, NFTs, or general messages between Cosmos chains and EVM chains like Ethereum, Arbitrum, and Berachain without handing custody to a bridge. The project also targets DeFi use cases, but the README does not detail those beyond naming them.
How It Works: Consensus Verification and the CometBLS Connection
The mechanism is visible in the component list. The Union node, uniond, uses CometBLS, which is a variant of CometBFT that supports BLS signatures. That is important because BLS signatures allow aggregation, which makes it feasible to verify a large validator set in a zero-knowledge proof. The galoisd component is the zero-knowledge prover, implemented in Go with the Gnark library. In a typical flow, a light client on the destination chain receives a proof that the source chain's consensus produced a certain block. The proof is generated by galoisd and verified on-chain. The voyager relayer, written in Rust, handles the message passing between ecosystems. It is described as hyper-performant, but the README gives no benchmark numbers, so that claim is unverified. The actual data flow is not spelled out in the README, but the architecture is clear: consensus state is verified rather than trusted, and the relayer moves proofs and packets.
The Component Stack Is Large and Polyglot
The repository is not a single binary. It contains a Go node (uniond), a Go prover (galoisd), a Rust relayer (voyager), a CosmWasm smart contract stack, light clients in Rust, a Rust node supervisor (unionvisor), a Rust faucet (drip), an EVM smart contract stack in Solidity, a TypeScript SDK, and two frontends: a Svelte app and an Astro site. That is a wide surface. For an engineer evaluating the project, this means the learning curve is not just about one language. You need to understand Go for the node and prover, Rust for the relayer and light clients, Solidity for the EVM contracts, and TypeScript for the SDK. The README does not provide a high-level architecture diagram, so you have to piece together the flow from the component descriptions. The positive side is that each component has its own README with developer documentation, so the project is not a black box.
Getting It Running: Nix Is the Only Supported Path
The quickstart is explicit: install Nix. The command given is the Determinate Systems installer: curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install. After that, you can build components reproducibly with nix build .#uniond -L, nix build .#voyager -L, or nix build .#app -L. To see all packages, run nix flake show. The dev shell, nix develop, provides cargo, rustc, node, go, and other dependencies. There is a warning that some components only build on Linux. For macOS, the README recommends OrbStack to run a NixOS VM. This is a hard constraint: if you do not want to use Nix, you are on your own for building the project. The README also says to run nix run .#pre-commit -L before each PR, which suggests the project enforces formatting and spelling checks.
Supported Chains: Wide but Not Universal
The supported chains table lists mainnets and testnets for Arbitrum, Babylon, Base, Berachain, Bob, BSC, Corn, Ethereum, Osmosis, Sei, Sui, Union, and Xion. The format is chain.network-id, such as ethereum.1 for Ethereum mainnet and arbitrum.42161 for Arbitrum. The table shows that Sui is testnet-only, with no mainnet entry. The README points to the official docs for the full list, so the table may be incomplete. For an evaluator, the key point is that Union is not a universal interoperability layer. It targets specific ecosystems, primarily Cosmos and EVM. If your chain is not in the list, you would need to build a new light client and prove consensus for it, which is a substantial engineering effort.
Governance and Upgradability: A Decentralized Control Plane
The README states that upgradability of contracts on other chains, connections, token configurations, and evolution of the protocol will all be controlled by decentralized governance. That is a deliberate design choice. It means that the protocol is not static; it can change, but changes require governance approval. For an adopter, this is a double-edged sword. On one hand, it allows the protocol to adapt to new chains or fix bugs. On the other hand, it introduces uncertainty: a governance decision could alter the behavior of the system you depend on. The README does not specify the exact governance mechanism, so you cannot evaluate the quorum or voting power distribution. That is a gap in the documentation.
Maintenance and Upgrade Cost: Release Candidates and a Moving Target
The recent releases are all release candidates: bundle-union-testnet-10/v1.3.0-rc4, v1.3.0-rc3, and uniond/v1.3.0-rc2. The latest push was on 2026-06-18, so the project is actively developed. The use of release candidates suggests that the team is iterating quickly, but it also means that production stability is not guaranteed. The README does not provide a changelog or migration guide. For an operator, the upgrade cost is real: you need to track new releases, rebuild with Nix, and redeploy the node, prover, and relayer. The unionvisor component is intended for production usage, but the README does not explain how it handles upgrades. The license is Apache-2.0, which is permissive, but you should verify that all dependencies have compatible licenses.
Alternatives and the Trade-Off You Must Accept
The main alternative to Union is a traditional bridge that uses a trusted federation or an oracle network. Those systems are simpler to operate because they do not require a zero-knowledge prover. The trade-off is trust: you must rely on the honesty of the signers. Union's approach removes that trust assumption, but it introduces new operational complexity. You need to run or access a galoisd prover, which is computationally intensive. The README does not provide performance numbers for proof generation, so you cannot estimate the cost. Another alternative is a light-client-based bridge like IBC itself, which is already used in Cosmos. Union implements IBC for Cosmos compatibility, so it is not a complete departure. The difference is that Union extends IBC-style verification to EVM chains via zero-knowledge proofs, which is not trivial because EVM chains have different consensus mechanisms.
Editorial conclusion
Adopt Union if you need trust-minimized cross-chain transfers between Cosmos and EVM ecosystems and you have the Rust and Nix skills to run or extend the prover and relayer stack. Do not adopt it if you expect a plug-and-play bridge with minimal infrastructure overhead, because the protocol depends on operating or outsourcing a zero-knowledge prover. Before committing, verify that your target chains are in the supported list, review the governance mechanism for contract upgrades, and test the latest release candidate on a testnet like union-testnet-10.
Community notes