# Synchronous Composability with Real-Time Proving Source: https://x.com/0xjaehaerys/status/2120505244690120808?a=DujGWmEAuKnmzXo9fGo&s=46 Kiwi News: https://news.kiwistand.com/stories/Synchronous-Composability-with-Real-Time-Proving?index=0x6af4e842b1a558d1e8f897315b4af98508dbea9b48716802b639a3a6ae07e1ad21ce7ccb Submitted by misha on 2026-11-11 UTC, 1 upvote, 0 comments ## Summary The Ethereum Economic Zone (EEZ) is a set of contracts on Ethereum and rules for connecting chains to them, letting a connected chain run one transaction that uses Ethereum and other connected chains synchronously within the same block. The design relies on real-time proving, where a chain's proof is ready within one 12-second Ethereum slot, along with a composer that precomputes crosschain call answers and a proxy that stands in for contracts on other chains. The article's example is a rollup transaction that borrows USDC on Aave, swaps it on Uniswap, bridges the ETH back and posts it as margin on an exchange in one step. The article also lists limits, including that a chain cannot have fast blocks, synchronous Ethereum calls and a decentralized sequencer at once. ## Article Everyone is familiar with the liquidity fragmentation problem. Liquidity in the Ethereum ecosystem sits on L1 and on dozens of L2s. On a rollup you can't borrow USDC on mainnet Aave, swap it for ETH on Uniswap and post it as margin on a perp DEX in one transaction. Open a bridge, bridge over, approve here, send there, bridge again, deposit. The Ethereum Economic Zone (EEZ) makes this one transaction. A rollup in EEZ uses everything on Ethereum and on other EEZ rollups as if it were all one chain (synchronous composability). This article explains how EEZ does it. What EEZ is EEZ consists of contracts on Ethereum and the rules for connecting chains to them. It isn't a new chain or a new stack. A connected chain can use Ethereum or any other connected chain in one transaction. The idea grew out of execution sharding, an old plan for scaling Ethereum, and real-time proving made it real. EEZ starts from the idea that the number of chains around L1 is not going to shrink. Even pushed to the limit, L1 won't fit the world economy, it doesn't have the bandwidth. And living on L1 doesn't suit everyone. Nobody on L1 will fix a mistake, and a bank or an exchange needs different rules. Chains will be different, EVM and non-EVM, public, private or permissioned and the task is to make them work as one. Every chain in the zone still runs its transactions on whatever VM and in whatever order it likes. It also decides who to let in and which proofs to trust. What all chains in the zone share is the Ethereum block. Each of them can use the liquidity, contracts and keys on L1 in that same block. This is where the name economic zone comes from, a zone with a shared market where every chain has separate rules. To join EEZ, a chain has to at least prove its state within a slot and roll back together with Ethereum when it reorgs. The second condition is there so that after a reorg a chain isn't left with a trade whose other half on Ethereum is gone. The EEZ contract doesn't see what happens inside a chain. It only needs the chain's proof and state root (the hash that commits to the chain's whole state). A chain can have any VM and any admission rules, and no specific prover is required. Existing L2s can join. Technically EEZ rests on three things. Real-time proving. A chain proves its new state within one Ethereum slot. Composer. An operator that runs the transaction on every chain it touches before the block, to prepare the answers to crosschain calls. Proxy. A contract on one chain that stands in for a contract on another. What real-time proving is A validity proof shows that a chain reached its new state by following its rules. A contract on Ethereum verifies it without re-executing the chain's block. Real-time proving means the proof is ready within one Ethereum slot, in under 12 seconds. Real-time proving made a lot of noise a year ago. ZisK needed 24 RTX 5090 GPUs at the time. Four are enough today (Ethproofs). EEZ needs it because Ethereum doesn't execute a rollup's code. It accepts a rollup's answer only with a proof. While a proof took minutes or hours, the answer could not arrive in the same block as the call. A proof inside the slot makes that possible. In the EEZ design the rollup's answer to a crosschain call is prepared before the block. The composer computes it. A prover proves the result, a builder includes the proof in the Ethereum block together with the transaction that needs that answer, and they have the same 12 seconds for all of it. How a synchronous call works The easiest way to walk through it is one call from Ethereum to a rollup. A call between two rollups goes the same route. Proxy A call to another chain goes through a proxy. Every contract on the rollup has a proxy address on Ethereum that is known in advance, and vice versa. The address is computed with CREATE2 from the EEZ contract's address, the original contract's address and the chain ID from the EEZ registry. Anyone can deploy the proxy at that address. To the calling contract the proxy looks like any other local contract. A crosschain call is written in code like a normal one, without a messaging protocol. Composer and the execution table The composer runs the transaction on every chain it touches and writes every crosschain call into the execution table, a table of precomputed answers. Each entry (an execution entry) holds the answer to the call, the rollup's state root before and after it, the calls the rollup will make back into Ethereum, and a rolling hash over those calls and their results. One proof covers the whole table. The composer sends the builder a bundle, a set of transactions the builder includes all together and in order, or not at all. First in the bundle is the postAndVerifyBatch transaction with the rollup's batch, the execution table and the proof, and the user's transaction comes after it. The crosschain part on the rollup executes in a Sync block, which the rollup makes once per Ethereum block and ties to it. If the bundle misses that block, the Sync block reverts. Verifying the batch and the proxy's answer The postAndVerifyBatch transaction verifies the batch's proofs. Which proof systems to trust (ZK, TEE, a multisig or a mix of them) and how many proofs to require per batch is up to the rollup's owner, and EEZ doesn't vouch for those systems. Every proof in the batch has to pass. After that the EEZ contract stores the table's entries together with the state root transitions, which the proxy will check and apply when the call arrives. The user's transaction executes next. When it calls the proxy, the proxy finds the entry for that call in the EEZ contract and answers from it only if the call matches the one the composer simulated, the entry came with this same block's batch, and the rollup's calls back into Ethereum produced the same rolling hash. Calls back into Ethereum The rollup's calls back into Ethereum are executed by Ethereum, and the rollup takes the answers to them from the composer's simulation. Calls can nest. A contract on Ethereum that was called this way can call a contract on the rollup through a proxy, and the answer to that nested call is already in the execution table. The opening transaction This transaction goes the other way, from the rollup to Ethereum. Before the block, the composer executes it on both chains and writes into the execution table everything your wallet will get back. The builder puts the batch with the table and the proof into an Ethereum block, the EEZ contract verifies it, and the transaction executes in the rollup's Sync block. The calls to Aave and Uniswap are executed on Ethereum by the composer's transaction in the same bundle, and you pay that L1 gas through the higher tip the composer charges. The wallet calls Aave's proxy on the rollup and borrows USDC. Aave sees your wallet's proxy on Ethereum as the borrower. The collateral has to be at that address beforehand. The wallet swaps the USDC for ETH through Uniswap's proxy and reads the answer from the table. The bridge credits the ETH on the rollup. The wallet posts the ETH as margin on the exchange. The composer sees a failing step in the simulation and doesn't send the bundle. If a result on Ethereum differs from the simulation, everything reverts, on Ethereum and on the rollup. What this changes That transaction shows only one possibility. Calls go in every direction L1 → L2, L2 → L1 or L2 → L2. Ethereum's liquidity for any rollup A new chain in EEZ doesn't have to bootstrap liquidity with incentives. It can use the liquidity and apps that are already on L1. On RollupX, EEZ's test rollup on mainnet, someone bought CRV from a Uniswap pool on Ethereum. CRV didn't exist on the rollup, and the bridge minted a wrapped CRV inside the same swap (tx). When every EEZ chain does this, the volume goes into the same L1 pools and isn't fragmented across chains. Other protocols on Ethereum don't need a deployment on every chain. Gas for these calls is paid on L1, and more activity on EEZ chains means more demand for Ethereum blockspace. Apps launch a rollup to control ordering and keep the MEV, and an exchange also wants a custom matching engine. The price used to be composability with Ethereum, because L1's contracts and liquidity were available to the rollup only asynchronously. In EEZ an exchange matches orders with that engine and whatever the order book can't fill gets executed against a pool on Ethereum in the Sync block. Keys on L1 Keys and permissions can live on L1, because a contract on a rollup reads Ethereum's state within the same transaction. Safe, the multisig wallet, already works this way on RollupX. The Safe on the rollup doesn't store the list of owners and reads it from the Safe on Ethereum on every transaction. You change an owner or revoke a key once, on L1, and from the next transaction it applies on every chain where a Safe reads the owners from L1. The cost is that every transaction from that Safe makes a crosschain call and waits for the next Sync block. A Safe on Ethereum and a Safe on a rollup can run one treasury. They share one budget, and both pay on a single signature. Permissioned and private chains A chain in EEZ doesn't have to be public. A privacy chain like Aztec could join EEZ, or a permissioned chain run by a government and use L1 liquidity. The closest thing running today is Bermuda Bay, a privacy pool on RollupX. It hides who swaps, and the swap executes on Uniswap V3 on L1 in the same transaction (tx). A rollup as a coprocessor A rollup can work as a coprocessor for Ethereum. A computation that is too expensive for L1 runs on the rollup and a contract on Ethereum acts on the result in the same block. Verifying a post-quantum Falcon signature would cost 5.5M gas on Ethereum. In the EEZ demo the signature was verified on a rollup and the result authorized a payment from a Safe on L1 without a precompile or a hard fork. Ethereum can use new cryptography and new VMs if they live on chains in the zone. Limits A chain in EEZ can't have fast blocks, synchronous calls with Ethereum and a decentralized sequencer all at once. It has to pick two (Gnosis forum). For example, a fast chain with 200ms blocks needs a centralized sequencer to have synchronous calls with Ethereum. Only every 60th block is a Sync block, and an app on that chain reaches Ethereum once every 12 seconds. That chain is still usable. Only the crosschain part runs at L1 speed and depends on L1 blockspace.. Every crosschain call goes through the composer. It has to see the transaction unencrypted before the block. The composer and the builder get first shot at the MEV in it. T 7% of Ethereum blocks are built by validators themselves, without outside builders. There are no synchronous calls in those slots. In the first month every EEZ batch landed in blocks from outside MEV-Boost builders. 56% of the batches went into Titan's blocks, while it usually builds 48% of blocks. Funny that Titan now gets to MEV crosschain. With EEZ a rollup no longer has to choose between running a separate chain and being on Ethereum. It keeps control of ordering and of the rules, and it uses Ethereum's liquidity and apps in the same block.