Author: 0xJaehaerys, Baihua Blockchain
Everyone is familiar with the problem of liquidity fragmentation. Liquidity in the Ethereum ecosystem is spread across L1 and dozens of L2s.
On a Rollup, you cannot perform the following actions in a single transaction: borrow USDC on mainnet Aave, swap it for ETH on Uniswap, and then deposit it as margin into a perpetuals DEX. You must open a cross-chain bridge, transfer across chains, approve here, send there, bridge again, and finally deposit.
The Ethereum Economic Zone (EEZ) turns all of this into one seamless transaction. Rollups within the EEZ can access all resources on Ethereum and other EEZ rollups as if they were on the same chain (synchronous composability).
What is EEZ?
The EEZ consists of contracts on Ethereum and rules that connect various chains to these contracts. It is not a new chain or a new stack. A connected chain can use resources on Ethereum or any other connected chain within a single transaction. This concept originates from execution sharding (an old Ethereum scaling proposal), and real-time proving makes it possible.
The premise of EEZ is that the number of chains around L1 will not decrease. Even pushed to its limits, L1 cannot support the global economy—it lacks sufficient bandwidth. Moreover, not everyone belongs on L1; on L1, no one will help you correct mistakes, whereas banks and trading platforms require different rules. The various chains will differ, encompassing EVM and non-EVM, public, private, and permissioned chains, and our mission is to make them work together as one cohesive system.
Each chain within the region still runs transactions using its preferred virtual machine (VM) and ordering. It also independently decides who can join and which proofs to trust. What all chains in the region share is the Ethereum block. Each chain can utilize liquidity, contracts, and keys on L1 within the same block. The name “economic zone” derives from this: a region with a shared market, where each chain maintains its own independent rules.
To join the EEZ, a chain must satisfy at least two conditions: proving its state within a slot, and rolling back alongside Ethereum in the event of a reorg.
The second condition prevents a Rollup from remaining in a discarded historical state after a reorganization. The first condition was impossible just a few years ago.
Technically, the EEZ is built on three core components:
What is real-time proof?
A validity proof demonstrates that a chain has followed its rules to reach a new state, allowing contracts on Ethereum to verify it without re-executing the chain's blocks.
Real-time proof means that a proof can be generated within a single Ethereum slot (12 seconds). This is now a reality: RISC Zero and SP1 can generate a proof for a block within 12 seconds (using 8 to 16 GPUs at a cost of 1 to 5 cents); this process can be further accelerated if block times are shorter.
A year ago, real-time proofs caused a huge stir; back then, ZisK required 24 RTX 5090 GPUs, but today it only needs four (Ethproofs).
EEZ needs it because Ethereum does not execute Rollup code—it only accepts Rollup responses accompanied by proofs. Previously, generating proofs took minutes or even hours, making it impossible for responses to arrive within the same block as the original call; proofs completed within a single slot make this possible.
In EEZ's design, the Rollup prepares its response to cross-chain calls before block production. The combiner computes the result, the prover verifies it, and the builder packages the proof along with the transactions requiring that response into an Ethereum block—all of these steps must be completed within the same 12-second window.
How does synchronous calling work?
The simplest way to understand this process is to examine a single call from Ethereum to a Rollup—the same path applies for calls between two Rollups.
Proxy
Calls to another chain are made through proxies. Each contract on the Rollup has a pre-determinable proxy address on Ethereum, and vice versa.
This address is calculated using 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 the Rollup, it simply calls the proxy of that contract directly on Ethereum.
Composer and the Execution Table
The combinator executes the transaction on each chain involved in the transaction and writes each cross-chain call to an execution table (a table of precomputed answers). Each entry (execution entry) includes the call’s response, the Rollup’s state roots before and after the call, the list of calls the Rollup will callback to Ethereum, and a rolling hash of these calls and their results. A single proof can cover the entire table.
The bundler sends a transaction bundle to the builder, who either includes the entire set of transactions in order or excludes it entirely.
The first transaction in the batch is the postAndVerifyBatch transaction, which submits the execution table and verifies its proof. Subsequent transactions are calls to the Rollup proxy, which directly read answers from the verified execution table.
Verification batch and agent response
The postAndVerifyBatch transaction verifies the proofs for the batch. The proof system trusted (ZK, TEE, multisig, or a combination thereof) and the number of proofs required per batch are determined by the Rollup's onboarding rules.
Once the trade is executed, the execution entries in this batch will be available to agents on Ethereum.
Next, execute the user’s transaction. When it invokes the agent, the agent looks up the entry for that call in the EEZ contract and responds only if: the call exactly matches the one simulated by the combiner, the entry arrives as part of the same block’s batch, and the Rollup’s callback hash matches the Ethereum rollup hash.
Callback to Ethereum
Calls from the Rollup back to Ethereum are executed directly by Ethereum, while the Rollup obtains the responses to these calls from the simulator's execution. Calls can be nested: Ethereum contracts invoked in this manner can again call contracts on the Rollup via a proxy, and the responses to these nested calls are already present in the execution table.
The initial transaction
The direction of this transaction is opposite—it is from the Rollup to Ethereum. Before block production, the aggregator executes the transaction on both chains and records all items to be returned to the user’s wallet in the execution table.
Builders place batches containing execution tables and proofs into Ethereum blocks. The entire sequence occurs within a single block. A single transaction you initiated on the Rollup borrowed USDC, exchanged it for ETH, and deposited it into the collateral vault.
If the combiner detects any failed steps during simulation, the transaction bundle will not be sent. If the actual execution result on Ethereum differs from the simulation, all operations on both Ethereum and the Rollup will be fully rolled back.
What changes did this bring?
The transaction above shows just one possible scenario. Calls can be made in all directions: L1 → L2, L2 → L1, or L2 → L2.
Any rollup can share Ethereum's liquidity.
The new chain in the EEZ does not require token incentives to bootstrap liquidity; it can directly leverage existing liquidity and applications on L1. On RollupX, the test Rollup on mainnet, someone purchased CRV from Uniswap pools on Ethereum. At the time, CRV did not exist on the Rollup—the cross-chain bridge minted wrapped CRV directly within the same swap transaction (tx).
When each EEZ chain does this, trading volume flows into a single L1 liquidity pool rather than being fragmented across chains. Other protocols on Ethereum also don’t need to redeploy on every chain. The gas for these calls is paid on L1, so more activity on EEZ chains means greater demand for Ethereum block space.
The application of Rollups was introduced to control transaction ordering and retain MEV, and trading platforms also desire customized matching engines. The previous cost was the sacrifice of composability with Ethereum, as L1 contracts and liquidity could only be accessed asynchronously by Rollups. In EEZ, trading platforms can match orders using their own engines, while unmatched portions of the order book are executed directly against liquidity pools on Ethereum within synchronous blocks.
Key management on L1
Keys and permissions can remain on L1, as contracts on the Rollup can read Ethereum's state within the same transaction. The multisig wallet Safe is already operating on RollupX in this manner. The Safe on the Rollup is merely a proxy, with all signers and permissions retained in the Safe contract on mainnet.
Each transaction is instantly checked against the L1 state before execution to verify multisignature signatures. If the multisignature on mainnet changes, this change takes effect immediately on all Rollups without synchronization or delay. Similarly, identity contracts on Ethereum can directly prove credentials to any Rollup within the same block.
Permissioned chain and private chain
The chains within the EEZ do not have to be public. Privacy chains like Aztec, or permissioned chains operated by governments, can join the EEZ and utilize L1 liquidity. The closest existing example currently in operation is the privacy pool Bermuda Bay on RollupX, which conceals traders' identities while executing swaps on Uniswap V3 on L1 within the same transaction (tx).
Rollup as a coprocessor
Rollups can act as coprocessors for Ethereum. Tasks that are too costly to compute on L1 can be executed on a Rollup, while contracts on Ethereum can act on their results within the same block.
Verifying a quantum-resistant Falcon signature on Ethereum consumes 5.5 million gas; however, in EEZ’s demonstration, this signature was verified on a Rollup, enabling an L1 Safe payment authorization without any precompiled contracts or hard forks. As long as new cryptography and a new virtual machine exist on-chain within the Economic Zone, Ethereum can directly use them.
Limitations
In the EEZ, a chain cannot simultaneously achieve fast block times, Ethereum-compatible synchronous calls, 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 achieve synchronous calls with Ethereum. Only one out of every 60 blocks is a synchronous block, meaning applications on this chain can interact with Ethereum once every 12 seconds. Nevertheless, the chain remains fully functional, with its cross-chain operations running at L1 speed and dependent on L1 block space.
Every cross-chain call must pass through the combiner. Since it must see unencrypted transactions before block production, the combiner and builder will have priority access to the resulting MEV.
Currently, 7% of Ethereum blocks are built directly by validators without using external builders. No sync committee calls occur in these slots.
In its first month online, every EEZ batch landed in blocks built by external MEV-Boost builders. Of these, 56% ended up in blocks built by Titan (compared to Titan’s usual block share of 48%). Interestingly, Titan is now also capturing cross-chain MEV.
With EEZ, Rollups no longer need to choose between running an independent chain or staying on Ethereum. They retain control over transaction ordering and rules while seamlessly accessing Ethereum’s liquidity and applications within the same block.
