Everyone is familiar with the problem of liquidity fragmentation. Liquidity in the Ethereum ecosystem is scattered across L1 and dozens of L2s.

On a Rollup, you cannot complete the following in a single transaction: borrow USDC on Aave on mainnet, swap it for ETH on Uniswap, then deposit it as collateral into a perpetual DEX. You must open a cross-chain bridge, perform a cross-chain transfer, authorize here, send there, cross again, and finally 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 smart contracts on Ethereum and the rules that connect chains to these contracts. It is neither a new chain nor a new stack. A connected chain can utilize resources on Ethereum or any other connected chain in a single transaction. The concept originates from execution sharding (an old Ethereum scaling proposal), made real by real-time proving.

The premise of EEZ is that the number of chains around L1 will not decrease. Even at its limits, L1 cannot carry the global economy—it lacks sufficient bandwidth. Not everyone should be on L1; no one will help you correct mistakes on L1, whereas banks or exchanges require different rules. Chains will remain diverse—spanning EVM and non-EVM, public, private, or permissioned chains—and our task is to make them work together as a unified whole.

Each chain within the zone still runs transactions according to its preferred virtual machine (VM) and ordering logic. Each chain independently decides who may join and which proofs to trust. What all chains in the zone share is Ethereum’s block. Each can access L1 liquidity, contracts, and keys within the same block. The term “economic zone” derives from this: a region with shared markets but independent rules per chain.

To join EEZ, a chain must satisfy at least two conditions: prove its state within a single slot, and rollback alongside Ethereum in case of a reorg.

The second condition prevents a Rollup from remaining in discarded historical state after a reorg. The first condition was once impossible—but now it's feasible.

Technically, EEZ relies on three core components:

What is Real-Time Proving

Validity proofs demonstrate that a chain has reached a new state while adhering to its rules, allowing Ethereum-based contracts to verify without re-executing the chain’s blocks.

Real-time proving means the proof is generated within a single Ethereum slot (12 seconds). This is now achievable: RISC Zero and SP1 can prove a block in under 12 seconds (using 8 to 16 GPUs, costing $0.01 to $0.05); performance improves further with shorter block times.

A year ago, real-time proving caused a stir—ZisK required 24 RTX 5090 GPUs, whereas today only 4 are needed (Ethproofs).

EEZ requires it because Ethereum does not execute Rollup code—it only accepts Rollup responses when accompanied by valid proofs. Previously, proof generation took minutes or even hours, making responses unable to arrive within the same block as the initiating call. Now, proofs completed within a slot enable this possibility.

In EEZ’s design, Rollup responses to cross-chain calls are prepared before block production. The composer computes the result, the prover validates it, and the builder packages the proof along with the transactions requiring the response into an Ethereum block—all within the same 12-second slot.

How Synchronous Calls Work

The easiest way to understand this process is to examine a single call from Ethereum to a Rollup (the path between two Rollups is identical).

Proxy

Calls to another chain go through a proxy. Every contract on a Rollup has a pre-known proxy address on Ethereum, and vice versa.

This address is computed via CREATE2 using the EEZ contract address, original contract address, and chain ID. When an Ethereum contract needs to call a contract on a Rollup, it simply calls the proxy on Ethereum.

Composer and the Execution Table

The composer executes the transaction on every involved chain and writes each cross-chain call into the execution table—a precomputed answer ledger. Each entry (execution entry) includes the call’s result, the Rollup’s state root before and after the call, the list of Rollup-to-Ethereum calls, and a rolling hash of those calls and their results. One proof covers the entire table.

The composer sends a transaction bundle to the builder, who either includes the full set of transactions in order or excludes them entirely.

The first transaction in the bundle is postAndVerifyBatch, which submits the execution table and verifies its proof. Subsequent transactions are calls to Rollup proxies, which directly read answers from the verified execution table.

Verifying the Batch and Proxy Responses

postAndVerifyBatch verifies the batch’s proof. Which proof system (ZK, TEE, multisig, or combinations) and how many proofs per batch are trusted are determined by the Rollup’s onboarding rules.

Once executed, the entries in the batch become available to proxies on Ethereum.

Next, user transactions are executed. When calling a proxy, the proxy checks the EEZ contract for the corresponding entry—and only responds if: the call exactly matches the composer’s simulation, the entry arrives in the same block as the batch, and the rolling hash of the Rollup’s callback to Ethereum matches.

Callbacks to Ethereum

Rollup-to-Ethereum calls are executed directly by Ethereum, while the Rollup obtains answers from the composer’s simulation. Calls can be nested: Ethereum contracts invoked this way can, via proxies, call Rollup contracts again, with the nested call’s answers already present in the execution table.

The Initial Transaction

This transaction goes in reverse—from Rollup to Ethereum. Before block production, the composer executes the transaction on both chains and writes all assets the user wallet will receive into the execution table.

The builder includes the batch with the execution table and proof into an Ethereum block. The entire sequence happens within a single block. Your single transaction on the Rollup borrows USDC, swaps it for ETH, and deposits it into a collateral vault.

If the composer detects any failed step during simulation, it won’t send the transaction bundle. If actual execution on Ethereum differs from the simulation, all operations on both Ethereum and the Rollup roll back completely.

What This Changes

The above transaction demonstrates just one possibility. Calls can occur in any direction: L1 → L2, L2 → L1, or L2 → L2.

Any Rollup Can Access Ethereum’s Liquidity

New chains in EEZ don’t need token incentives to bootstrap liquidity—they can immediately use existing liquidity and applications on L1. On the test Rollup RollupX hosted on mainnet, someone bought CRV from Ethereum’s Uniswap pool. At that time, CRV didn’t exist on the Rollup—yet the cross-chain bridge minted wrapped CRV directly within the same swap transaction (tx).

When every EEZ chain operates this way, trading volume flows into a single L1 liquidity pool instead of being fragmented across chains. Other protocols on Ethereum don’t need to redeploy on every chain. Gas for these calls is paid on L1, so the more activity on EEZ chains, the greater demand for Ethereum block space.

Launching a Rollup traditionally meant controlling transaction ordering and retaining MEV, but at the cost of sacrificing composability with Ethereum—L1 contracts and liquidity could only be used asynchronously. In EEZ, exchanges can use their own matching engine, while unmatched orders are executed synchronously against Ethereum’s liquidity pools within the same block.

L1 Key Management

Keys and permissions can remain on L1 because contracts on Rollups can read Ethereum’s state in the same transaction. Multisig wallets like Safe are already running this way on RollupX. The Safe on the Rollup is merely a proxy—the signers and permissions stay in the mainnet Safe contract.

Every transaction is validated against the L1 state before execution. If the multisig changes on mainnet, the change propagates instantly across all Rollups without synchronization or delay. Similarly, identity contracts on Ethereum can directly prove credentials to any Rollup within the same block.

Permissioned and Private Chains

Chains in EEZ need not be public. Privacy chains like Aztec or permissioned chains run by governments can join EEZ and use L1 liquidity. The closest current example is Bermuda Bay, a privacy pool on RollupX, which hides users’ identities while executing swap operations directly on L1’s Uniswap V3 in the same transaction (tx).

Rollups as Co-processors

Rollups can act as co-processors for Ethereum. Computationally expensive tasks too costly for L1 can be offloaded to Rollups, enabling Ethereum contracts to act on their results within the same block.

Verifying a quantum-resistant Falcon signature on Ethereum consumes 5.5 million gas; in EEZ’s demo, the signature was validated on a Rollup, and the result directly authorized a Safe payment on L1—no precompiles or hard forks required. As long as new cryptography and new VMs exist within the economic zone, Ethereum can directly leverage them.

Limitations

Chains in EEZ cannot simultaneously achieve fast block times, synchronous calls to Ethereum, and decentralized sequencers—they must choose two out of three (referencing discussions on Gnosis Forum).

For example, a fast chain with 200ms block times needs a centralized sequencer to enable synchronous calls to Ethereum. Only one out of every 60 blocks is synchronized; apps on such a chain can interact with Ethereum only once every 12 seconds. Nevertheless, the chain remains usable—its cross-chain component runs at L1 speed and depends on L1 block space.

Every cross-chain call must pass through the composer. Since the composer must see unencrypted transactions before block production, it and the builder gain priority access to the associated MEV.

Currently, 7% of Ethereum blocks are built directly by validators without external builders. No synchronous calls occur in these slots.

During the first month of launch, every EEZ batch landed in a block built by an external MEV-Boost builder. 56% of batches entered Titan-built blocks (Titan’s usual block share is 48%). Interestingly, Titan now also captures cross-chain MEV.

With EEZ, Rollups no longer face the binary choice 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.

Author: 0xJaehaerys, Plain Language Blockchain