Ephemeral Rollup: The New "L1.5" of Ethereum

Ephemeral Rollup: The New “L1.5” of Ethereum

Ethereum’s core responsibility has always been to verify state transitions. Rollups made verification succinct but introduced a new problem: they hold users’ state, which forces every rollup to provide an exit mechanism. Recent advances—native account abstraction (EIP‑8141 and related proposals) and proof aggregation—make it practical to keep compute and state separate. The resulting architectural pattern, which we call L1.5, sits between the user’s wallet and the base layer (L1). It is less a new protocol layer than a design paradigm.

---

1. The L1.5 Pattern Explained

| Component | Responsibility | |-----------|-----------------| | Wallet | Holds the user’s private state (balances, notes, secrets) in clear text. | | L1 | Maintains shared, global state and verifies every transition via a single proof. | | L1.5 | Executes stateless computation, produces a proof, and submits the result to L1. |

In this model the wallet supplies inputs, L1.5 performs the work, and L1 checks the proof and updates its commitment. The key properties that distinguish L1.5 from a traditional rollup operator are:

1. Stateless – after a job finishes, no data needed for the next job remains on the compute node.
2. Checked – L1 validates the proof before any funds move.
3. Paid without linking – the transaction fee can be paid by the contract itself, keeping the user’s identity private.
4. Landed without an operator – any node can relay the proof‑bearing transaction; no long‑lived account is required.

These properties become feasible thanks to three emerging EIPs:

• EIP‑8141 (frame transactions) lets a contract embed a VERIFY frame that both checks a proof and pays the fee from its own balance.
• EIP‑8250 (keyed nonces) provides nonce uniqueness derived from privacy nullifiers, preventing double‑spends.
• EIP‑8288 (recursive STARK aggregation) enables a single aggregated proof in the block, so each individual proof is checked only once by the network.

Together, they allow an application to keep its state on L1, hand off computation to any willing worker, and settle the result directly on L1.

---

2. How L1.5 Differs from Traditional Rollups

| Aspect | Traditional Rollup | L1.5 (Ephemeral Rollup) | |--------|-------------------|------------------------| | State location | Stored in a dedicated rollup contract; users must exit to retrieve it. | User‑owned (wallet) + shared L1 commitments; no exit needed. | | Compute ownership | Sequencer or operator runs the VM and holds intermediate state. | Stateless worker runs a single job, discarding all intermediate data. | | Settlement | Batch submitted to L1 with a fraud/validity proof; gas paid by sequencer. | Single proof submitted in a VERIFY frame; fee paid by the contract itself. | | Trust model | Users trust the rollup operator to publish correct state. | Trust is minimized; any node can relay the proof, and L1 enforces correctness. |

Existing roles on Ethereum already perform fragments of this pattern—relayers for privacy mixers, batch inserters for Merkle trees, MEV‑Boost relays, and key‑share providers for encrypted mempools. L1.5 unifies these fragments into a coherent, reusable architecture.

---

3. Emerging Applications Enabled by L1.5

a) Gas‑less, privacy‑preserving payments

A committee can issue blind gas tickets using threshold signatures. Users redeem tickets on L1 through a contract’s VERIFY frame, paying fees without ever holding ETH at the spending address. The ticket issuance and redemption are unlinkable, preserving privacy while eliminating the need for a funded address.

b) Fair exchange for off‑chain services

Consider a private RPC that charges per query. The requester submits a blinded payment ticket; the service provider returns an encrypted answer together with a zero‑knowledge proof that the answer satisfies the request. L1.5 verifies the proof before releasing the payment, ensuring the provider is paid only for correct responses.

c) Decentralized order‑book matching

An on‑chain order book can remain a simple contract that accepts match proofs. Independent matchers compute batches, generate a proof, and submit it via a VERIFY frame. If a matcher disappears, another can pick up the next batch without any state hand‑off, because the order book’s state lives on L1 and the matcher holds no persistent data.

---

4. Why Now?

The primary barrier to this pattern was efficiency. Early account‑abstraction proposals (EIP‑2938) existed for years, but they lacked the necessary transaction‑level primitives. Recent upgrades—frame transactions (Jan 2026), keyed nonces (Apr 2026), and recursive STARK aggregation (post‑Hegota fork)—collapse the overhead of proof verification and fee payment into a single, cheap on‑chain operation. With these tools in place, developers can build applications that keep state on L1, outsource compute, and settle instantly.

---

Closing Thoughts

L1.5 is not a new “layer” in the traditional sense; it is an architectural pattern that leverages native account abstraction and proof aggregation to separate state from compute. By allowing wallets to own their data, letting L1 verify succinct proofs, and enabling stateless workers to perform arbitrary computation, Ethereum can support a new class of applications that are more private, more composable, and free from the exit‑mechanism constraints of current rollups. As the relevant EIPs mature and tooling improves, we expect developers to experiment with ephemeral rollups across DeFi, privacy, and decentralized infrastructure, gradually turning the L1.5 concept from theory into everyday practice.