Ethereum Economic Zone: Making Rollups Compose in One Operation

The Ethereum Economic Zone (EEZ) starts from a familiar rollup tension: execution is spread across networks even when an application needs one answer from all of them before it can act. EEZ's proposed response is synchronous composability, where a contract calls across execution environments, receives a result, and continues within the same transaction. That changes the engineering problem from coordinating separate messages to coordinating state transitions, proofs, and inclusion. The framework is under active implementation, while Gnosis Chain's proposed transition is a specific early instance rather than evidence that the larger design is complete. EEZ will matter if its shared execution model becomes dependable enough for applications to treat liquidity and contracts across participating rollups as one operation.

Contributors are building shared infrastructure

EEZ presents itself as a framework for Ethereum rollups, not as a proprietary chain product. That framing matters because cross-rollup calls become more useful as independent networks and applications can use common coordination rules. Each instance can still make its own choices about fees, upgrades, and operations; shared infrastructure does not make those choices disappear.

The March 2026 launch announcement names Gnosis and ZisK as founding contributors, describes the Swiss EEZ Association, and says the Ethereum Foundation funds development.

The open-infrastructure ambition depends on useful specifications and code beyond the founding teams. Funding supports development; it does not guarantee delivery, an audit, or a settled operating model.

w00tcake

Oct 5, 2026

View article →

First atomic cross-chain L1-to-L2 transaction executed on mainnet

𝕏/@eduadiez • Oct 5, 2026

One call changes the application boundary

In an asynchronous cross-domain flow, one action sends a message or asset and another consumes its result later. That model can be sufficient when delay is acceptable, but it complicates operations whose next step depends on a result held elsewhere. An application must account for intermediate states and the possibility that only part of its intended sequence has completed.

The Ethereum Economic Zone is a framework intended to let contracts on participating rollups call Ethereum mainnet or another EEZ rollup and use the response within one transaction.

This puts the cross-domain boundary inside the transaction: a contract can use a response immediately instead of scheduling a later action. The protocol still must define failure behavior, call order, and what evidence is enough to accept a result. “Atomic” names the intended unit; it does not explain what happens when a call fails or is excluded.

Gnosis's rationale is that a rollup should be able to reach mainnet liquidity and return a result within the same operation, rather than require an application to coordinate separate transactions.

This case is strongest where a result elsewhere is essential to one decision, such as a trade or payment. Where asynchronous settlement already works, the added coordination may not justify itself. Synchronous composability is another way to organize dependencies; builders still have to weigh its value against the proof, sequencing, and inclusion assumptions it introduces.

Shared sequencing makes coordination part of execution

EEZ's central challenge is to make related actions use a coherent settlement point. If each rollup finalized its part independently, an application could still face a partial-result problem. The design instead centers coordinated execution on an Ethereum L1 block: state transitions are prepared ahead of settlement and checked on-chain so related calls can be considered together.

The core implementation describes rollups sharing an L1 sequencer, precomputed state transitions checked on-chain by configurable proof systems, and atomic cross-rollup calls within a single L1 block.

For applications, the intended benefit is one unit of work: dependent calls can use results across participating environments without waiting for another transaction. Protocol rules must bind each transition to the right state, order calls, check proofs, and handle incomplete sequences.

A shared L1 sequencing point creates a settlement window, not a guarantee of inclusion. Provers still must provide required evidence and transactions must land in that window. Proof and inclusion rules decide how dependable coordination remains when part of the operation is late.

0xpmm.eth

Oct 8, 2026

View article →

Ethereum card-speed payments: stacking FCR fast confirmation with EEZ lets rollup users pay base-layer shops in ~25 seconds, with no bridge to trust, and about 5 seconds as slots shrink.

ethresear.ch • Oct 8, 2026

The test path exposes the proof boundary

Public code makes the design inspectable, and a test deployment shows that it has moved beyond diagrams. It also makes visible the difference between a working call path and the stronger security model the project aims to support. Those are related milestones, but they are not the same evidence.

The core repository labels its implementation early stage and unaudited, warns that interfaces and storage layouts may change, and treats its periphery bridge and token examples as test infrastructure outside the protocol audit scope.

A test bridge or token can exercise protocol behavior without becoming a supported production integration. Nor would a core-contract audit automatically establish every prover, sequencer, composer, or deployment configuration. The repository labels this inspectable implementation work, not a settled security contract.

The Rollup Zero repository describes a Chiado test deployment whose current ECDSA proof system verifies a hash-bound attestation rather than a succinct validity proof.

A hash-bound attestation is a signed statement tied to a recomputed result; a succinct validity proof would provide different evidence that a transition follows protocol rules. The current verifier is not the latter. Chiado can exercise coordination while the stronger proof design remains future work.

EEZ's July update reported both-direction composition implemented end to end in code, partial functionality on Chiado Rollup Zero, and a placeholder single-prover setup while multi-prover work continued.

The update distinguishes an end-to-end code milestone from a mature deployment: testnet functionality was partial and the prover was a placeholder. The ZisK Ethereum client is an experimental execution client that validates blocks from execution witnesses and is designed to prove that validation inside the ZisK zkVM.

ZisK's client is relevant to the broader proving direction, but its existence does not change what the Rollup Zero verifier currently checks. Builders should follow the verifier used by the deployment they intend to rely on, then ask what it proves and who is trusted to produce or attest to the result. A general proving capability is not a guarantee already present in a particular test system.

Gnosis Chain is one proposed instance

The framework and Gnosis Chain's transition sit at different levels. EEZ aims to provide shared cross-layer behavior for participating rollups; Gnosis's proposal concerns one chain adopting an instance, with its own choices about fees, governance, and sequencing. A DAO decision can set a direction for that chain without establishing that the transition has happened or that all parts of EEZ have shipped.

The August EEZ update reports GnosisDAO's approval of GIP-153, putting Gnosis Chain on a proposed path toward becoming an EEZ rollup settling on Ethereum.

The proposal is directional. GIP-153 asks for strategic alignment rather than funds for a Gnosis-operated EEZ instance, targets a first iteration for December 2026 or January 2027, and places a fuller specification in 2027.

Those are targets, not completed milestones, and the first iteration and fuller specification are separate stages. Users need a clear account of which features are live at each stage; a roadmap is not evidence that dependencies will land on schedule.

The Gnosis proposal says forced inclusion is required but absent from the first version, leaves its delay undecided, and postpones the detailed GNO revenue-sharing design.

Forced inclusion defines how a transaction can reach the system if the sequencer omits it. The proposal identifies the need but leaves the delay open and puts the feature beyond version one. Separately, the transition does not settle how future fees relate to GNO; that economic design is deferred.

Danicjade

Mar 29, 2026

View article →

Gnosis and Zisk unveil Ethereum Economic Zone (EEZ), a rollup framework enabling synchronous composability across L1 and L2s without bridges, backed by Ethereum Foundation

The Block • Mar 29, 2026

Payments have two different clocks

A payment example separates execution from confidence. A payer could hold an asset on a rollup while a merchant watches Ethereum. Atomic execution asks whether linked actions happen together; confirmation asks when the recipient should trust the result. Solving the first does not settle the second.

In an October payments illustration, CPerezz combines EEZ's atomic execution with the Fast Confirmation Rule to estimate roughly two slots, or 25 seconds, under the confirmation rule's conditions; the five-second example assumes speculative shorter slots.

The estimate combines two mechanisms; it is not a general service promise. EEZ addresses cross-layer execution, while FCR changes the example's wait for confidence. Timing depends on FCR's conditions, and the shorter-slot scenario is speculative. A payment designer must decide whether that assurance fits the purchase.

The same research example distinguishes a conditionally safe block from slashing-backed finality and notes that the demonstration used a stand-in signer for the proof.

A conditionally safe block and slashing-backed finality offer different assurances; a stand-in signer is not a completed proving deployment. The example sketches a user experience, but product teams must state their confirmation policy instead of implying a stronger guarantee.

Outlook

The next test is whether a controlled cross-layer call becomes dependable enough for applications. That requires proof matching the promised assurance, an inclusion path for omitted transactions, and a clear list of live features. Code, deployments, and governance milestones can answer those questions.

EEZ's thesis is that rollups can compose within one operation rather than connect only through delayed messages. Public code and Chiado testing make the idea concrete, while also exposing unfinished work. Gnosis Chain could be a proving ground if its first iteration has clear limits and later milestones follow. If proof assumptions and forced inclusion remain unresolved, applications needing dependable settlement will have reason to keep asynchronous flows. Stronger proofs, defined inclusion, and working instance milestones would change that judgment.