ZKsync’s Elastic Network is one of the most ambitious attempts to scale Ethereum without sacrificing its foundational guarantees. As of Q2 2025, this network has expanded into an ecosystem of over 19 live ZK Chains—modular chains built using the ZK Stack that include rollups, validiums, and volitions. But scaling execution wasn’t the hard part. The problem that started looming as chains launched wasn’t how to make more of them. It was how to make them work together. Because even with the same SDK and the same base layer beneath them, Elastic Chains were still isolated environments by default. ZKsync was not alone in this. The same pattern was playing out across every major L2 ecosystem.
The industry had entered a phase where “many chains” had become a reality, but “many chains working as one” was still a myth. That’s when they brought out the missing piece: ZKsync ZK Gateway.
And once you understand how it works, what it enables, and what it could eventually replace, you’ll understand why ZKsync ZK Gateway is the part of the stack the rest of the L2 ecosystem might soon be copying.
What Makes ZK Gateway Different — And Why the Market Needs It?
Deployed as ChainID 9075 and activated through governance with ZIP-10, the ZKsync ZK Gateway is the core middleware that allows Elastic Chains to speak to each other trustlessly, coordinate their state updates, and batch their proofs for low-cost, high-speed finality on Ethereum.
ZK Gateway isn’t trying to be everything. At its core, ZK Gateway is a shared settlement and interoperability layer—a chain built not to execute user logic, but to help other ZK Chains settle proofs cheaply, coordinate securely, and communicate natively. It was formally activated in May 2025 via ZIP-10.
But it wasn’t born there. The foundations were laid months earlier through ZIP-6, which upgraded the ZKsync protocol to support features that would become essential for Gateway’s existence: custom data availability, flexible bridge contracts, and the ability to register chains against a shared settlement hub.
But the real distinction lies in how it answers the hardest question in multichain architecture: how do you make chains talk to each other without creating new trust assumptions or user friction?
Until now, the answers from other ecosystems have been partial at best. Arbitrum had Orbit chains, each isolated. Optimism’s Superchain talked of cohesion but relied on centralized bridging layers. Polygon’s AggLayer promised unification, but its performance remained limited, often clocking in around 5 TPS in live tests. Everyone was scaling blockspace. No one was solving coordination.
ZKsync took a different path. From the outset, it designed its Elastic Network around native trustless interoperability, not as an add-on, but as a base-layer principle. And ZK Gateway is the key to that principle.
Over $2 billion has been lost in cross-chain bridge hacks since 2020. Most of that loss has come from centralized relayers or weak multisig setups used to pass messages or move tokens between chains. Even the most battle-tested protocols have struggled to secure their bridges. Meanwhile, users deal with endless wallet confirmations, unpredictable fees, and fragmented identities as they try to navigate what’s supposed to be a unified experience.
ZKsync ZK Gateway solves that by removing the bridge altogether. It turns messages into the unit of cross-chain interoperability. And it backs every message with zk-SNARK verification, permissioned aliasing, and protocol-enforced finality.
Inside ZKsync ZK Gateway — Architecture and Core Components
The ZK Gateway operates as a carefully designed middleware protocol with built-in logic to reduce costs, eliminate trust assumptions, and scale communication across dozens (eventually thousands) of chains.
At a high level, the ZKsync ZK Gateway sits between the Elastic Chains and Ethereum, acting as both a message router and a proof aggregator. ZK Chains run their own execution environments and produce zk-SNARK proofs. The Gateway batches these proofs, compresses them recursively, and submits a single proof to the ZK Router contracts on Ethereum, which maintain the global state of the Elastic Network. Alongside this, it handles inter-chain message passing—receiving, validating, and coordinating payloads through a cryptographic Merkle tree.
Beneath this high-level design, the Gateway is made up of tightly coordinated components, each with a distinct role in ensuring the system operates securely and at scale.
- At its core is the Proof Aggregator, the component responsible for batching zk-SNARK proofs from all participating ZK Chains.
Every Elastic Chain runs its own proving system—many of them using Boojum, ZKsync’s native STARK-based prover optimized for performance. When these chains finalize blocks, they generate proofs of correctness and submit them to the Gateway. Instead of sending each proof to Ethereum directly (which would spike gas costs and congestion), the Gateway bundles them recursively. The result is a single compact proof that can be verified on Ethereum L1, no matter how many chains were involved.
- The Merkle Tree Manager inside the Gateway plays a parallel role, acting as the ledger of interop messages.
Whenever a ZK Chain wants to send data, trigger a smart contract on another chain, or pass state updates, it generates a payload called an InteropMessage. These are collected by the Gateway, hashed, and organized into a Merkle tree. It ensures that every message passed between chains is tamper-proof and globally recognized. Other chains can verify these messages cryptographically by referencing the tree root, removing the need for any off-chain or permissioned relayers.
- Then there’s the Validator Network—the economic and operational layer that keeps the Gateway running. As described by Zksync,
“…The ZK Gateway will be operated by a decentralized, trustless set of validators, to ensure resilience and reliability of the network. The participation in this decentralized validation process requires a ERC20 token, designated by ZKsync network governance.
The validators will charge a fee to facilitate bridging, as well as a fee for every byte of state diff data posted to the ZK Gateway. This means that the revenue of the ZK Gateway validators can grow exponentially over time, as more and more of the value transactions move onchain.”
- ZKsync has gone even further by introducing the Interop Call Processor, a critical module that ensures messages don’t just travel between chains, but do so safely.
Every time one chain calls a contract on another, the system maps the sender’s address and chain ID into an aliased account. This protects the destination chain from spoofed identities or unauthorized contract execution. On top of that, the processor introduces replay protection, ensuring each message or call can be executed exactly once. No race conditions. No duplicates. Just mathematically guaranteed integrity.
- Of course, all of this is anchored to Ethereum through the ZK Router—a set of L1 contracts that maintain the Elastic Network’s global state.
When the Gateway finalizes a recursive proof, it submits it to the Router. The Router verifies the proof, updates the shared transaction root, and reflects that state to the broader Ethereum network. This is where the Elastic Network inherits Ethereum’s security directly. Nothing is finalized without Ethereum’s signature. And thanks to recursive SNARKs, the Router only needs to verify a single lightweight proof, no matter how many chains are active underneath.
- One of the key features introduced in ZIP-6 was support for custom Data Availability (DA) layers.
That means ZK Chains can now choose whether to post data to Ethereum (rollup), use external DA networks like EigenDA or Celestia (validium), or switch between the two. Gateway fully supports this variability.
How the ZKsync ZK Gateway Will Work?
Here’s how all of these components play out in practice.
A ZK Chain processes a batch of transactions—DeFi swaps, AI agent interactions, SocialFi activity, anything—and generates a zk-SNARK proof for that batch. Alongside the batch, it may include one or more interop messages: perhaps a signal to a lending protocol on another chain, a contract call to initiate a swap, or even a state update to bridge an asset.
All of this—the proof and the messages—gets submitted to ZK Gateway. Once the Gateway receives these inputs, it does two things in parallel.
First, it feeds the zk-SNARK into the Proof Aggregator, which collects similar proofs from other Elastic Chains. These are compressed into a single recursive SNARK using Boojum.
Second, it organizes all the interop messages—InteropMessages and InteropCalls—into a Merkle tree. Then comes settlement.
The Gateway sends its aggregated proof, along with the Merkle root of messages, to the ZK Router smart contracts on Ethereum. The Router verifies the proof and updates the Elastic Network’s transaction root. Once this happens, any receiving chain can verify that a message intended for it exists in the global state, using a Merkle proof tied to that batch. The destination chain can then execute that message without relying on any relayer, external oracle, or third-party bridge.
This is where ZKsync ZK Gateway shines. It doesn’t pass assets. It passes intent. These instructions are structured into four levels of interop, each building on the last.
- At the base level, you have the InteropMessage—a simple message payload that one chain sends to another. The Gateway includes it in the Merkle tree, and the receiver can consume it once the proof is finalized on Ethereum.
- Then there’s the InteropCall—a more advanced form where one chain can actually call a smart contract on another. The Gateway ensures this call is cryptographically authorized, maps the sender to a unique aliased identity, and enforces replay protection, so no attacker can reuse it.
- On top of that is the InteropBundle—a group of interop calls packaged as a single atomic transaction. If any part of the bundle fails, the whole thing reverts. This is crucial for complex DeFi logic or multi-step workflows like cross-chain arbitrage or yield farming.
- And finally, the InteropTransaction—the UX abstraction layer. It manages both the execution logic and the fee payment logic in one operation. The user signs once. The transaction can include pointers to a fee-paying bundle and an execution bundle, letting users route through whichever chains offer cheaper gas or better liquidity.
Even better, this whole stack integrates with ZKsync’s Single Sign-On (SSO) and the Ethereum Multi-Chain Address (EMCA) standard. That means users don’t even need to manage separate accounts or addresses across Elastic Chains. One identity. One wallet. One experience.
What ZK Gateway Unlocks: The Benefits of Comosability, Cost, UX, and more
For all its architectural elegance, the true value of ZKsync ZK Gateway shows up at the edges—where developers build, where users transact, and where institutions demand guarantees before they deploy.
- The most immediate unlock is cost.
With ZKsync ZK Gateway recursive SNARK mechanism, a thousand transactions from a dozen chains can settle with the cost footprint of a single verification. For example, settling 1,000 transactions directly on Ethereum might cost $100 at 20 gwei, while the Gateway could reduce this to $10 or less by Q3 2025, as projected in ZIP-10.
For validiums, the Gateway minimizes on-chain data by integrating with external DA layers like EigenDA, achieving fees as low as $0.0001 per transaction a floor that makes use cases like gaming, microtransactions, and AI agents finally viable without compromising security.
- Then comes throughput.
The Gateway uses recursive zk-SNARKs for unlimited parallelism in proof generation and constant-time verification. This enables it to handle thousands of transactions without performance degradation.
The Q3 2025 target of 10,000 TPS positions the Gateway as one of the most scalable settlement layers. In testnet conditions, ZKsync has already clocked over 180 TPS on a single chain—orders of magnitude beyond the ~5 TPS Polygon AggLayer has shown in public benchmarks.
Faster batch settlement (sub-minute finality) will also reduce latency for cross-chain transactions.
- It also drastically improves the developer experience.
Builders launching Elastic Chains with the ZK Stack don’t have to build their own bridging contracts or worry about custom message formats. Gateway support is native. The interop layers—InteropMessages, Calls, Bundles—are built into the SDK.
And because every chain plugged into Gateway shares the same settlement and messaging standard, any app built on one chain is interoperable with others by default. That’s not just convenient—it’s how ecosystems reach critical mass.
- Institutions, too, get a valuable choice
The combination of validium support, custom data availability, and predictable fee ceilings makes Gateway an enterprise-ready interop solution. No bridges, no wrap logic, no unpredictable costs.
In projects like Deutsche Bank’s Project Dama 2, ZKsync’s modular architecture (powered in part by Gateway’s settlement layer) has already proven capable of meeting compliance, security, and latency demands that would break most L2s.
Launch Your Own ZKsync Elastic Chain at Just $50 with Zeeve RaaS
Thinking of launching your own Elastic Chain? Zeeve’s Rollups-as-a-Service makes it insanely easy to go live on ZKsync. Spin up your testnet for just $50, or move straight to mainnet at $995—with everything from infra, ops, and dozens of 3rd party integrations handled for you.
You bring the idea. Zeeve handles the execution—from day-zero setup to full Gateway-ready deployment. Want to see how it works?
Book a call with our experts and get your chain up and running in no time.
