In 2025, crypto users have access to more opportunities than ever before. Hundreds of blockchains now host thriving financial and cultural communities, each offering unique ways to participate and create. As interest grows across ecosystems, we encounter new wallets, explorers, and tokens along the way. This abundance, while exciting, can also make navigation complex. To address this, many ecosystems are turning to blockchain interoperability and abstraction. Cosmos has indisputably led the way with the development of the Inter-Blockchain Communication Protocol (IBC). But despite its success in connecting over 100 different blockchains, it has struggled to expand into non-Cosmos based ecosystems, leaving space for innovation. And, empowered by zero-knowledge (ZK) technology, Union has risen to the call. In this article, we will:

(1) Teach you a bit about zero-knowledge proofs
(2) Show you how they fit into Union’s interoperability technology
(3) Look at some major ecosystem developments and milestones for the project

Let’s dive in.

WTF Are ZKPs?

In order to understand the inner-workings of Union, we need a basic understanding of zero-knowledge proofs (ZKPs). You can check out this overview for more detail, but let’s start simple. A zero-knowledge proof allows any party to prove that a statement is true without revealing any information except for whether it is indeed true or not. ZKPs have two major features: privacy (‘zero knowledge’) and efficiency (computationally cheap to verify many statements at once). For Union, the efficiency aspect is the most important, so let’s look at an analogy for this.

Imagine that you work for the tax authorities and that each year, large funds must submit individual tax filings for the hundreds of companies that they own. Unfortunately, you are on the team that must manually check the filings of each company of each fund to ensure they have complied correctly. Since all the validation has to occur twice – once by the fund and once by you – you find yourself wishing for a more efficient way to accomplish this.

Now, imagine that an engineer at the tax authority is ZK-savvy and makes a suggestion. Instead of checking each company from each fund manually, the government will issue specialized ZK software. This software will allow the funds to batch the individual filings together and generate a single ZK proof. This single proof would demonstrate that all compliance related computations for all subsidiary companies have been met correctly. Now, rather than painstakingly verifying hundreds of companies individually, you need only check one ZK proof for each fund, and can be certain that no individual company has cheated, thus saving a tremendous amount of time and money.

Admittedly, this example is a little far fetched, but it contains all of the ingredients we need to understand a ZKP:

(1) Mathematical conditions: In this case, every single filing is really a set of conditions like “Revenue was between X and Y thresholds”. Our ZKP will compile all of these for each company and efficiently batch them together.

(2) Proof Generation: The program used to generate the ZKP will require access to all the company filing data, but the ZKP will contain none of these details (hence ‘zero-knowledge’) – only the proof that every condition has been met (a property called ‘completeness’).

(3) Proof Verification: Any party should be able to verify using ONLY the generated ZKP that the batched statements for each fund are true, and should harbour no further doubt once it has been verified (this property is called ‘soundness’).

++ Note: This example is actually just one type of ZKP, called a non-interactive proof. This is the most applicable to Union and blockchains generally, but consult this overview for more details.

This ZKP is extremely useful! At any point in the future, the fund would be able to prove to anyone running the verifier program that their tax filings were performed correctly for that year in a fraction of the time that it would take to re-verify each case from the original filing documents. Now that we understand a bit about ZKPs, let’s see how they are used in Union.

Union & IBC: Interoperability Standards

Union is a Layer 1 blockchain designed to coordinate connections between other blockchains. It uses a specialized consensus algorithm called CometBLS, which is tailor-made for verification of ZKPs. But why? Remember, the goal of a validator set is to ensure (or ‘prove’) that nobody cheated.

Consider a simple situation: A user on Chain A wants to send a crosschain transaction to Chain B – maybe send some assets or control a Chain B account by signing on Chain A. Whatever it is, lets revisit our ZKP example scenario in this context.

In order for the validators on Chain B to accept that the transaction was valid, they will first check that it was valid on Chain A. This is like the authorities checking a single company’s tax filing.

The cumbersome path: The validators of Chain B could each run an entire full node for Chain A – the entire state. This is like handing over the original filing documents – it is WAY more information than they actually need, and will be very slow to process.

The IBC path: A light client of each chain is included in the other’s chain state, so that each can independently use light client proofs to verify that transactions are valid. This works well with chains with fast finality and CometBFT, but has been impractical for other consensus mechanisms.

The Union path: A ZK proof will be generated proving that all conditions for the transaction have been met. This proof will be sent from Chain A to Union, and incorporated into the Union blockchain. Once the Union light client on Chain B updates, Chain B validators will automatically be able to verify the state of Chain A and see the transaction’s validity. What’s critical is that this proof will generally contain a large batch of crosschain transactions – just like our ZKP example proved the compliance of many companies – which can all be confirmed simultaneously rather than independently like in IBC.

How does this actually happen? Let’s break it down step by step.

Union Transaction Lifecycle

The Union interoperability protocol we described above is an extension of IBC, so let’s quickly review the basics. IBC allows any two blockchains to connect directly to each with communication facilitated by a relayer. In IBC, the message originating at Chain A and destined for Chain B would be observed by a relayer, and forwarded as a transaction to Chain B.

By contrast, Union functions as a router between Chain A and Chain B. We have 5 sets of players in this protocol:

• Chain A validators running Chain A (which contains the Union light client)
• Chain B validators running Chain B (which contains the Union light client)
• Union chain validators running Union (which contains light clients for Chains A and B)
• Voyager relayers submitting proofs between chains
• Galois ZK-proving network for proof generation

Important: Upon connecting to Union, the Union light client will become part of the state of Chains A and B, and will be regularly updated by relayers (after being confirmed by the validators). We discussed light clients in the IBC context more here.

First, the Chain A validators will confirm that the transaction is valid, and include it in a block along with a crosschain event.

A relayer (running the Voyager software) connecting Chain A and Union is listening for these types of events. Once detected, they forward the transaction information (possibly in a batch of other crosschain transactions) to the Provers.

The Provers are a permissionless network running the Galois software, specially designed for converting transaction data into ZKPs. Once a Prover has constructed the proof, they submit it directly to the Union blockchain for verification by the validator set.

When Union validators reach consensus that the ZKP is valid (using CometBLS), the Union blockchain is updated with this new information. A second relayer detects this update and forwards the ZKP of Union’s consensus to the Union light client on Chain B.

This light client verifies the proof in a single, deterministic transaction, finalizing the crosschain process and confirming the entire batch of crosschain transactions from A to B. All crosschain instructions will be executed and funds will be visible on the destination chain.

That seems like a long and complicated process, but Union developers have spent a lot of energy ensuring that the process will be fast and smooth just like IBC – perhaps even more so.

Union interoperability can allow for a variety of different use-cases in a permissionless and trust-minimized environment. One of the most common examples is the transfer of assets between different chains, opening up multichain trading and defi without the need for centralized intermediaries. But as a generalized message passing protocol, Union can facilitate far more than secure bridging. For example, users and applications are able to control accounts on Blockchain B through signatures on Blockchain A (a concept that is currently being utilized for a Union liquid staking token through Escher Finance). This allows users to access other blockchains directly without needing to install new wallets, and manage multiple private keys. Interoperability of this sort can immediately improve both the functionality and the user experience of the blockchains it supports.

Conclusion

Using ZK proofs, Union is paving the way to enable trust-minimized interoperability between almost any blockchain. The protocol is already live and in use, having routed 98% of Bitcoin liquid staked token volume into the Babylon ecosystem. Other important integration partnerships they have already established include:

• Polygon and Arbitrum – the first of the Ethereum Layer 2s
• Rome protocol for Solana interoperability
• Stargaze for interchain NFTs
• Movement and Noble
• Secret Network, Xion, Agoric, and other Cosmos-native networks

At CryptoCrew, we are thrilled to be a Union validator and investor, and we cannot wait to see the Interchain expand through their protocol.

zkgm.