A new architectural pattern published on EthResearch on October 28, 2026 proposes carving out an intermediate execution role between Ethereum L1 and persistent rollups, framing it as an "L1.5" layer. Under the design, user state remains in wallets, shared state lives on Ethereum L1, and computation is delegated to a stateless ephemeral layer that produces a validity proof and then disappears, leaving no residual state obligations on the network. The full proposal is available on EthResearch, the public forum where Ethereum researchers publish and debate early-stage protocol ideas before any implementation begins.

Key Points

• The L1.5 label is an architectural framing, not a new canonical Ethereum protocol layer. It describes a temporary compute environment that settles back to L1 without persisting its own state between jobs.
• The model is designed for bounded execution contexts, such as application-specific sessions or high-intensity event windows, where a long-lived rollup operator would be unnecessary overhead.
• Implementation depends on two Draft-status EIPs, EIP-8141 and EIP-8288, meaning L1.5 is a research proposal contingent on future Ethereum protocol work, not a deployed feature.

Why Ephemeral Rollups Are Being Framed as Ethereum's L1.5

The October 28, 2026 EthResearch post introduces L1.5 as a design pattern, not a protocol amendment. The core claim is that not every computation needs a long-lived execution environment with a sequencer, a bridge, and persistent state commitments. Some workloads are bounded by definition, and forcing them through a permanent L2 introduces unnecessary infrastructure overhead. The framing positions itself against the rollup-centric roadmap that has guided Ethereum's scaling strategy since 2020, under which execution has largely been delegated to persistent L2 networks while L1 serves as the settlement and data-availability layer.

What Makes a Rollup Ephemeral

According to the proposal, a qualifying L1.5 job must satisfy four properties: it must be stateless between jobs, verified by L1, paid without linking the user to a persistent identity, and settled without requiring a long-lived operator. The ephemeral compute layer takes in a state snapshot, executes, and returns a new state plus a validity proof—a cryptographic attestation that lets L1 confirm a computation was performed correctly without re-executing it. It retains nothing needed by the next job.

This is a sharp departure from how persistent rollups operate. An Optimism or Arbitrum sequencer maintains a continuous state tree, manages reorgs, and coordinates with fraud or validity proof systems over an indefinite time horizon. The L1.5 model discards that continuity deliberately, treating each job as an isolated unit of work.

How L1, the Ephemeral Layer, and Users Relate

The proposed state custody model splits responsibilities precisely. Wallets hold user-owned state, while Ethereum L1 holds shared state, including commitments and nullifiers, and verifies each state transition. The ephemeral compute layer sits in between: it receives inputs, runs execution, and emits a proof that L1 can verify. Once settlement completes, the ephemeral environment is retired.

This arrangement is distinct from both pure L1 execution, which is constrained by block gas limits and sequencing throughput, and from conventional L2s, which require a persistent operator, a live bridge, and a canonical state root maintained across an indefinite chain of blocks. The L1.5 framing describes a compute role that is summoned for a specific job and then dissolved.

Ethereum trades at $2,354.52, up 2.04% in the last 24 hours, against a market capitalization of approximately $287.7 billion, according to CoinGecko, providing the economic backdrop against which proposals to improve Ethereum's execution throughput are being evaluated. The broader crypto sentiment index registers at 51, a Neutral reading that reflects neither euphoria nor fear as the research enters public review.

No verified expert social commentary has emerged on the proposal since publication, consistent with the absence of a broad public reaction window for a research post published the same day. The Neutral sentiment baseline reflects the ecosystem at large rather than any specific reception of this architectural proposal.

The Infrastructure Trade-Offs: Speed, Composability, and Settlement

Potential Use Cases: Scoped Execution Contexts

The ephemeral design fits naturally for high-intensity, time-bounded workloads: a governance vote execution window, a batch-settlement session for a derivatives clearinghouse, or an application-specific game state update. In these contexts, spawning a full L2 with a sequencer and a canonical bridge would impose more coordination cost than the execution itself warrants.

Protocols that already deal with bursty on-chain demand, such as money markets running liquidation cascades or Aave's governance-driven risk parameter updates, represent the class of workloads where isolated, high-throughput execution followed by clean settlement would reduce L1 congestion without requiring a permanent L2 deployment. The key property is that the application does not need its state to persist across unbounded time; it needs correct, verifiable execution for a defined job scope.

Latency, Sequencing, State Synchronization, and Finality

The practical questions for any builder evaluating this pattern center on how state is handed off into and out of the ephemeral environment. The proposal's state split assigns shared commitments and nullifiers to L1, but the bridge latency between a user's wallet-held state and the ephemeral layer's execution context is a sequencing problem that individual implementations will need to resolve. Proof generation time also matters: if the ephemeral layer must produce a validity proof before L1 will finalize the result, the end-to-end latency is bounded below by proof construction speed.

This is where the draft EIP dependency becomes load-bearing. EIP-8141, a Draft Core standards-track proposal created January 29, 2026, introduces frame transactions with abstract validation and gas payment logic, covering VERIFY and SENDER frame modes. Without it, the payment-without-persistent-identity property the L1.5 model requires has no native L1 hook to attach to.

EIP-8288, created June 3, 2026 and also Draft Core, extends EIP-8141 with recursive STARK-based aggregation for signatures and STARK proofs, and makes a recursive STARK a requirement for block validity. STARKs—scalable transparent arguments of knowledge—are a class of validity proofs that can be verified far more cheaply than the computation they attest to would cost to re-run. This is the proof-aggregation layer that would let the ephemeral rollup's output be verified efficiently on L1 without consuming disproportionate gas per job. Both EIPs are in Draft status, meaning neither is scheduled for a specific hard fork; under Ethereum's improvement process, proposals advance through Draft, Review, Last Call, and Final stages, and a standard takes effect only once it is included in a network upgrade.

Composability Risk and Liquidity Fragmentation

Scoped execution comes with a composability cost that persistent L2s also carry, but with a different profile. A long-lived L2 accumulates TVL and liquidity over time, building up composability depth within its own environment. An ephemeral rollup, by design, holds no persistent liquidity: every job starts from a fresh state snapshot and settles back to L1. For protocols where composability across multiple contracts within one transaction is a core user expectation, such as multi-hop DEX routing or flash-loan-backed liquidations, the ephemeral model's stateless-between-jobs constraint limits the type of interactions that can be executed within a single job scope.

The proposal does not present this as a defect but as a design boundary. The L1.5 pattern is not intended to replace general-purpose L2 execution environments. It targets the class of workloads that can be fully specified upfront, executed atomically, and settled cleanly. That is a narrower problem space than what Optimism or Arbitrum address, but it is also one where current infrastructure is arguably over-engineered.

The degree to which this framing succeeds in practice will be determined by whether EIP-8141 and EIP-8288 advance through the Ethereum improvement process, and by whether application developers find the stateless-between-jobs constraint acceptable for their specific workload patterns. Builders deploying on emerging L2 infrastructure, such as those currently migrating staking contracts across Arbitrum and Avalanche, illustrate the operational complexity that comes with managing state across persistent rollup environments. The L1.5 model offers an alternative framing for jobs where that ongoing state management is the problem being avoided, not a feature being leveraged.

Outlook

The research post frames L1.5 as an architectural vocabulary contribution rather than a deployment announcement. Its validity as a practical pattern depends on two Draft EIPs reaching finalization, on proof generation latency matching the throughput requirements of target use cases, and on application developers accepting the composability trade-offs that stateless execution imposes. The status of both proposals is publicly tracked on the Ethereum EIP site, so their progression through standardization is directly observable as the improvement process moves forward. Until EIP-8141 and EIP-8288 exit Draft status, the L1.5 design remains a proposal for what Ethereum's execution stack could support, not a description of what it currently does.