A New Solution for Ethereum Cross-Chain: How Is EEZ Breaking Down L2 Liquidity Silos?
Author: 0xJaehaerys, Whitehat Blockchain
Everyone is well acquainted with the problem of liquidity fragmentation. Liquidity in the Ethereum ecosystem is scattered across L1s and dozens of L2s.
On a Rollup, you cannot complete the following operations in a single transaction: borrow USDC on mainnet Aave, swap it for ETH on Uniswap, and then deposit it as collateral into a perpetual contract DEX. You would have to open a cross-chain bridge, perform a cross-chain transfer, authorize here, send there, cross-chain again, and finally make the deposit.
The Ethereum Economic Zone (EEZ) turns all of this into a single transaction. Rollups within the EEZ can use all resources on Ethereum and other EEZ Rollups as if they were on the same chain (synchronous composability).
What is EEZ
EEZ consists of contracts on Ethereum and rules that connect various chains to these contracts. It is not a new chain, nor a new stack. A connected chain can use resources on Ethereum or any other connected chain within a single transaction. This idea originates from execution sharding (an old Ethereum scaling plan), and real-time proving makes it possible.
EEZ starts from the premise that the number of chains around L1 will not decrease. Even pushed to its limits, L1 cannot support the global economy due to insufficient bandwidth. Moreover, not everyone belongs on L1; no one on L1 will help correct your errors, while banks or trading platforms require different rules. Chains will vary, covering EVM and non-EVM, public, private, or permissioned chains, and our task is to make them work together as a cohesive unit.
Each chain within the zone still executes transactions according to its preferred Virtual Machine (VM) and order. It independently decides who can join and which proofs to trust. What all chains in the zone share are Ethereum blocks. Each of them can use L1 liquidity, contracts, and keys within the same block. The name "Economic Zone" stems precisely from this: a region with a shared market, yet each chain operates under its own independent rules.
To join the EEZ, a chain must meet at least two conditions: prove its state within a single slot, and roll back along with Ethereum in the event of a reorg.
The second condition prevents a scenario where a Rollup remains stuck in a discarded historical state after a reorg occurs. The first condition was simply unimaginable just a few years ago.
Technically, EEZ relies on three core components:
What is Real-Time Proving
A validity proof indicates that a chain has reached a new state while adhering to its rules, allowing contracts on Ethereum to verify it without re-executing the chain's blocks.
Real-time proving means that a proof can be generated within a single Ethereum slot (12 seconds). This has now become reality: RISC Zero and SP1 can generate a proof for a block in 12 seconds (using 8 to 16 GPUs at a cost of $1 to $5); this process can be accelerated further if block times are shorter.
A year ago, real-time proving made huge headlines. At that time, ZiSK required 24 RTX 5090 GPUs, whereas today only 4 are needed (per Ethproofs).
EEZ requires it because Ethereum does not execute Rollup code; it only accepts Rollup responses when accompanied by a proof. In the past, generating a proof took minutes or even hours, so responses couldn't arrive within the same block as the initiating call; a proof completed within a single slot makes this possible.
In the EEZ design, a Rollup's response to a cross-chain call is prepared before block production. The composer calculates the result, the prover generates a proof for it, and the builder packs the proof along with the transaction requiring that response into an Ethereum block. All these operations must be completed within the same 12-second window.
How Synchronous Calls Work
The simplest way to understand this process is to look at a single call from Ethereum to a Rollup (the call path between two Rollups is identical).
Proxy
Calls to another chain are routed through proxies. Every contract on a Rollup has a predetermined proxy address on Ethereum, and vice versa.
This address is calculated via CREATE2 based on the EEZ contract address, the original contract address, and the chain ID. When a contract on Ethereum needs to call a contract on a Rollup, it simply calls the proxy address of that contract on Ethereum directly.
Composer and the Execution Table
The composer runs the transaction on each involved chain and writes every cross-chain call to an execution table (a table of pre-calculated answers). Each entry (execution entry) contains the answer to the call, the state root of the Rollup before and after the call, a list of calls the Rollup will make to Ethereum, and the rolling hash of those calls and their results. A single proof can cover the entire table.
The composer sends a transaction bundle to the builder, who either includes the entire set of transactions in sequence or omits them entirely.
The first transaction in the bundle is the `postAndVerifyBatch` transaction, which submits the execution table and verifies its proof. Subsequent transactions are calls to Rollup proxies, which read answers directly from the verified execution table.
Verifying Batches and Proxy Responses
The `postAndVerifyBatch` transaction verifies the batch's proof. Which proof system to trust (ZK, TEE, multisig, or a combination thereof) and how many proofs are required per batch are determined by the Rollup's onboarding rules.
Once the transaction executes, the execution entries from that batch become available on Ethereum for proxies to use.
Next, the user's transaction executes. When it calls a proxy, the proxy searches the EEZ contract for the corresponding entry and only returns a response if the following conditions are met: the call exactly matches what the composer simulated, the entry arrived as part of the same block's batch, and the rolling hash generated by the Rollup's callback to Ethereum matches.
Callbacks to Ethereum
Calls back to Ethereum from the Rollup are executed directly by Ethereum, while the Rollup obtains the answers to these calls from the composer's simulation. Calls can be nested: an Ethereum contract called this way can again call a contract on the Rollup via a proxy, with the answer to this nested call already existing in the execution table.
The Opening Transaction
This transaction works in reverse, moving from the Rollup to Ethereum. Before block production, the composer executes the transaction on both chains and writes everything the user's wallet will reclaim into the execution table.
The builder packs the batch, containing the execution table and proof, into an Ethereum block. The entire sequence occurs within a single block. The single transaction you initiated on the Rollup borrows USDC, swaps it for ETH, and deposits it into the collateral vault.
If the composer detects any failed steps during simulation, the transaction bundle will not be sent. If the actual execution result on Ethereum deviates from the simulation, all operations on both Ethereum and the Rollup will be rolled back.
What Changes Does This Bring?
The transaction above merely demonstrates one possibility. Calls can occur in all directions: L1 → L2, L2 → L1, or L2 → L2.
Any Rollup Can Share Ethereum's Liquidity
New chains in the EEZ do not need to cold-start liquidity through token incentives; they can directly utilize existing L1 liquidity and applications. On RollupX, a test Rollup for the EEZ on mainnet, someone purchased CRV from Ethereum's Uniswap pool. CRV did not exist on the Rollup at all, and the cross-chain bridge minted wrapped CRV directly within the same swap transaction (tx).
When every EEZ chain does this, trading volume flows into the same L1 liquidity pool rather than fragmenting across different chains. Other protocols on Ethereum also do not need to be redeployed on every chain. The gas for these calls is paid on L1, meaning more activity on EEZ chains translates to greater demand for Ethereum block space.
Applications launch Rollups to control transaction ordering and capture MEV, while trading platforms also desire custom matching engines. The traditional tradeoff was sacrificing composability with Ethereum, since L1 contracts and liquidity could only be used asynchronously by Rollups. In the EEZ, trading platforms can match orders using their own engines, while unmatched portions of the order book execute directly against Ethereum pools within synchronized blocks.
Key Management on L1
Keys and permissions can remain on L1 because contracts on the Rollup can read Ethereum's state within the same transaction. The multisig wallet Safe is already operating this way on RollupX. Safe on the Rollup acts merely as a proxy, with all signers and permissions retained in the mainnet Safe contract.
Every transaction checks the L1 status in real time before execution to verify multisig signatures. If changes are made to the multisig on mainnet, they take immediate effect across all RollUps without requiring synchronization or introducing latency. Similarly, identity contracts on Ethereum can directly attest credentials to any Rollup within the same block.
Permissioned and Private Chains
Chains in the EEZ do not need to be public. Privacy chains like Aztec, or permissioned chains run by governments, can all join the EEZ and tap into L1 liquidity. The closest live example currently is the privacy pool Bermuda Bay on RollupX, which hides trader identities while executing swap operations on L1's Uniswap V3 within the same transaction (tx).
Rollup as a Coprocessor
Rollups can serve as coprocessors for Ethereum. Tasks that are too computationally expensive for L1 can run on a Rollup, while contracts on Ethereum act upon the results within the same block.
Verifying a quantum-resistant Falcon signature on Ethereum costs 5.5 million Gas; in an EEZ demo, this signature was validated on a Rollup, and its result directly authorized a payment on the L1 Safe without any precompile contracts or hard forks. As long as new cryptography and VMs exist on chains within the economic zone, Ethereum can utilize them directly.
Limitations
Chains in the EEZ cannot simultaneously achieve fast block times, synchronous calls with Ethereum, and a decentralized sequencer: it must choose two out of three (see Gnosis Forum discussion).
For example, a fast chain with a 200-millisecond block time requires a centralized sequencer to enable synchronous calls with Ethereum. Only 1 out of every 60 blocks is a synchronized block, meaning applications on this chain can reach Ethereum once every 12 seconds. Nevertheless, the chain remains fully functional, with the cross-chain component running at L1 speed and relying on L1 block space.
Every cross-chain call must pass through the composer. It must see unencrypted transactions before block production, giving the composer and builder priority access to the embedded MEV.
Currently, 7% of Ethereum blocks are built by validators themselves without external builders. Synchronous calls do not occur in these slots.
In its first month online, every EEZ batch fell into blocks built by external MEV-Boost builders. Of these, 56% ended up in blocks built by Titan (compared to Titan's usual block production rate of 48%). Interestingly, Titan can now also capture cross-chain MEV.
With EEZ, Rollups no longer face a binary choice between "running an independent chain" and "staying on Ethereum." They retain control over transaction ordering and rules, while seamlessly utilizing Ethereum's liquidity and applications within the same block.