Earlier this year, we introduced our vision for the Elastic Network — an ever-expanding ecosystem of ZK chains, secured by math. At its core is a native interoperability layer that makes the entire network feel like one unified chain.

Today’s blockchain landscape is fragmented. Users, apps, and liquidity are spread thinly across numerous chains, often resulting in:

• Limited scalability

• Fragmented liquidity

• Poor user experiences

Our industry solution has been to rely on third-party bridges, which at best force trust assumptions, and at worse get hacked. Even with additional security risks, capital is still fragmented and the UX is poor.

ZKSync’s interop changes the game by allowing ZK chains within the Elastic Network to transact and communicate directly with each other at the protocol level — no third-party bridges, no complicated UX — just a smooth, native cross-chain experience. Compared to other methods of cross-chain community, this reduces security risks, increases transparency, and is cheaper.

Native interop on ZKsync works because of the Shared Bridge and ZK Gateway. The shared bridged connects Ethereum to ZK Chains and holds all the funds in the Elastic Network. The ZK Gateway is where different ZK chains can communicate with each other effectively. By acting as a shared meeting point, the gateway provides fast and cost-efficient messages between chains while maintaining strong security measures.

There are several types of cross-chain transactions that vary in complexity. To understand how ZKsync’s native interop will work, we need to explore it at four levels.

InteropMessage is the lowest level of the interop stack — the foundational interface upon which all other interoperability layers are built. It provides the simplest form of communication between chains, enabling one L2 to send a message (payload) to another. Think of it as a way to broadcast data, like saying “Hey, something happened here!”

Here’s how it works:

When you create an interop message, the system adds important details like:

• Your L2 address

• The source chain’s ID

• A unique message number to keep it distinct

The result is a unique “message hash” that acts as an ID for this message.

A merkle proof is used to confirm that a message was sent and received. This proof comes from the Gateway. The Gateway is a piece of middleware between Ethereum and the ZK Chains that facilitates full interoperability between ZK Chains by collecting messages from all chains and organizing them into a cryptographic tree (Merkle tree), to ensure every chain stays in sync with the same data.

ZK Chains are not required to use the ZK Gateway; they can switch between using the ZK Gateway and directly settling to Ethereum at any time without affecting the security of their chains. But using ZK Gateway is more cost-efficient and performant.

Interop calls go beyond simple messaging. They allow you to call contracts on other chains and trigger actions, making cross chain actions as simple as calling a function on your own chain.

How does it work?

When a call is made, it includes replay protection. Replay protection guarantees each call is unique and can’t be executed more than once. This prevents duplicate actions and ensures the system stays secure.

On the destination chain, calls look like they came from a local account. The system maps the sender's address and source chain ID into an aliased account to simplify permissioning keep interactions secure.

Bundles group multiple calls into one atomic transaction. These instructions (calls) must execute in a specific order and all share the same fate — either all succeed, or none do. This is what makes bundles powerful and reliable for complex cross-chain tasks.

How do they work?

Each step in the bundle is tied to the others and executed in order. Actions in a bundle cannot run independently, ensuring everything happens as planned.

If the bundle fails (e.g., runs out of gas), you can retry or cancel it. Note that the failure doesn’t immediately notify the source chain. The bundle remains available on the destination chain for retry or cancellation. The caller can determine the status of their bundle by querying the Gateway. The Gateway tracks the state of all bundles, recording whether they succeeded, failed, or remain unprocessed.

Retries or cancellations can then be handled directly on the destination chain:

• Retrying: The caller or an authorized entity can re-run the bundle with updated parameters (e.g. higher gas limit or price).

• Cancelling: The cancellationAddress specified in the bundle can mark the bundle as cancelled to prevent further execution attempts.

At the top of the interop stack are Interop transactions that act as the delivery mechanism for interop bundles. They handle picking the bundle, managing gas, and running it on the destination chain, all from the source chain.

How it works

An InteropTransaction contains two pointers to bundles:

• the execution bundle (what you want to do)

• the fee bundle (how to pay for gas)

If the transaction fails, you can retry without starting over.

This simplifies complex workflows like token swaps across chains and removes the need for manual execution, gas management, or switching RPCs.

• Shared Liquidity: ZK chains within the network can access liquidity across chains without introducing additional trust assumptions.

• Composable Applications: Smart contracts on one chain can interact with those on another, unlocking new possibilities for decentralized applications.

• Unified User Experience: Users can transact across chains with a single wallet confirmation, enjoying a fast, low-cost, and streamlined process.

We’re releasing our first public native interop demo using ZKsync SSO for a friendly wallet experience. This demo showcases a cross-chain swap of $AA to $BB on Chain A that routes through Chain B. A swap might route through Chain B because Chain B has deeper liquidity, faster settlement, or cheaper costs.

You can learn more from the interop docs in the ZKsync core book.