The Target State

Chapter 5, the study turns its gaze and describes what Ethereum would look like if the Roadmap were fully implemented over a horizon of ten or more years. The protocol is henceforth presented and treated as a system conceived as complete, whose properties emerge from the interplay of the planned overhauls, with the target state remaining the consistent subject of discussion rather than the development status of individual components.

The transition shifts not only the point in time of the analysis but also the logic by which the system is read. Chapter 4 tested each criterion against mea-sured states — validator distributions, client shares, fee trajectories, and so on — while Chapter 5 reads a system design whose components exist as specifications, prototypes, and lines of research, which are here assembled into a coherent picture. The presentation takes the components in the final state described by their specifications and research designs, and keeps the question of the probability and sequence of their implementation outside the system description. The following sections show an Ethereum whose base layer would carry its own execution at the scales today reserved for Rollups, whose consensus would finalize in seconds rather than minutes, and whose guarantees extend across connected layers. Before sections 5.2 through 5.6 unfold this system layer by layer, however, the target state requires its frame — because the multiplicity of overhauls only becomes readable as a coherent program once the strategic premise from which they derive is named.

The premise set out here takes its starting point in 2025. Over that year, the Layer 1 substantially expanded its execution capacity, while the Rollups, to which the scaling of the platform had been assigned in the previous architecture, continued to be ordered by a single centralized Sequencer each, which alone determines the acceptance and ordering of transactions. From the tension between these two observations arose the strategic reorientation whose result the present chapter shows. The target state described here rests on a fundamentally altered system architecture. Layer 1 expands its own execution capacity again going forward. Rollups serve as integrated, specialized execution environments (e.g., for privacy) that process complex applications and whose data are ultimately secured on Layer 1.

What the reorientation has displaced is the rollup-centric Roadmap that Ethereum had followed since 2020. In it, the Layer 1 remained a deliberately lean layer for consensus, settlement, and data availability, with deliberately limited execution capacity, while the processing of transactions was outsourced to the Rollups. The division of labor rested on a dual assumption: that the Rollups inherit the security guarantees of Layer 1 because they anchor their data and proofs there, and that they would simultaneously free themselves over time from the control of their operators. How far the real system matched that assumption in the first quarter of 2026 was examined in detail in Chapter 4.

5.1 Strategic Pivot

The Strategic Pivot

Two Findings Force the Revision

Two empirical findings, each of its own weight, forced the revision. The first concerns the outsourcing promise itself: the decentralization of the leading Rollups proceeded considerably more slowly than the Roadmap had assumed. This is evident in that the large networks continue to be ordered by centralized Sequencers belonging to their respective operators, that substantial value lies behind the multi-signature keys of Security Councils, and that the organizational ties of the operators to Ethereum are looser than the technical connection of their systems. The second finding bears the weight in the opposite direction, because the Layer 1 demonstrated that it can expand its own execution. Over the course of 2025, the Gas Limit doubled from 30 to 60 million without the protocol needing to change, since the adjustment ran through the block-by-block voting of the validators and was coordinated by social consensus alone.¹ The effect reached into individual application projects, as with the Ethereum Name Service, which abandoned its planned rollup of its own in favor of the now cheaper Layer 1.² What is demonstrated is a path, not yet a state. At 60 million Gas, the Layer 1 processes 15 to 30 transactions per second. The claim that the base layer scales on its own is not yet realized as a full property in the current system. The finding establishes the direction of expansion, not its scale.

Vitalik Buterin brought both findings together on 3 February 2026 in a post on X in which he announced the departure from the previous strategy.³ He identified two facts. The decentralization of the second layer had proceeded far more slowly and laboriously than originally anticipated, and Layer 1 was by then scaling on its own. From this he drew the conclusion that the original vision of Rollups as an outsourced scaling layer no longer made sense and demanded a new path. The post articulates the reorientation and grounds it in the two findings, but leaves open what form the relationship between the layers will take in the future. This openness is what the new model closes.

The New Model: Two Directions

The new model has two directions, the first of which concerns the Layer 1 itself. It resumes the scaling of its own execution. It rests on a graduated path of further Gas Limit increases and on an enshrined zkEVM, under which validators verify blocks solely through validity proofs. The load of verification would be decoupled from the system’s capacity, so that capacity could grow without making the requirements for participation in consensus grow with it. The validator voting that carried the doubling of 2025 would be merely the beginning in this scheme, because the later expansions would remain bound to the proof architecture. Which stages the path passes through and on which architecture the proofs rest is developed in section 5.2.

The second direction redefines the relationship to the Rollups. In place of a homogeneous scaling layer, a spectrum emerges that is ordered along two dimensions. The degree of binding ranges from full convergence with Layer 1 to the sovereign chain with minimal binding. The differentiation describes what a Rollup grounds its existence on — privacy-focused execution environments, application-specific efficiency, low latency rather than mere throughput, or extreme scaling beyond the capacity of the Layer 1. The idea of a uniform role for Rollups disappears in the spectrum. Each network positions itself along both dimensions and bears the consequences of its position. At the outer end stands the sovereign chain, which gains full design freedom with its own data availability and its own consensus while simultaneously operating outside Ethereum’s guarantees. Within the spectrum, the choice of trust level lies with users and applications themselves. The redline for connection to Ethereum’s guarantees is Stage 1, that level of maturity from which a functioning proof system limits the operator’s rights of intervention to emergencies. The mechanism of full convergence is to be provided by the native-rollup precompile, through which a converged Rollup would directly use the execution logic of the Layer 1 and automatically adopt every protocol upgrade — a construction whose substance section 5.6 develops. The privacy direction gains its own shape in the closing section of 5.1.

The new strategy takes dimensional shape in five target pictures that the research community leads as North Stars and that Justin Drake bundled in the Strawmap in February 2026. The Strawmap is a coordination document without formal governance status that documents the direction of work without setting a binding target horizon. Buterin publicly categorized it as important orientation.⁴ The five target pictures span the dimensions of the target state, from execution through data to consensus, cryptography, and privacy. Fast L1 designates the concentration of finality, which would fall from today’s roughly 13 minutes into the seconds range and in the realized target state would lie at three-slot finality of roughly 36 seconds, whose consensus-side substance the later course of the chapter develops. Gigagas L1 names the target of roughly 10,000 transactions per second on Layer 1, which would become achievable over the long term via the graduated expansion path of execution, and whose stages likewise appear in section 5.2. Teragas L2 designates the decoupling of second-layer throughput from Layer 1 via Data Availability Sampling, whose mechanics the data section of 5.2 develops. Post-Quantum L1 describes the target state of fully hash-based cryptography, whose substance the following section and section 5.3 develop, and Private L1 names native shielded ETH transfers at the protocol level as a long-term direction, whose substance that very closing section of 5.1 addresses.

In sum, the target state of the chapter describes a division of labor in which Layer 1 again carries execution on its own and Rollups choose their place through degree of binding and differentiation. The guarantees of the base layer extend through convergence to where the connected networks wish to draw on them. That the ambition of the reorientation reaches beyond the protocol is documented by the Ethereum Foundation’s reconnection to Cypherpunk principles under the heading DeFipunk, the establishment of the dAI Department for the economy of autonomous AI agents together with the standard ERC-8004 for Trustless Agents, and Buterin’s New Year framing of Ethereum as civilizational infrastructure.⁵ Whether a program of such reach can be realized depends on a design philosophy that makes the complexity of the protocol itself its subject, which the following section develops.

Lean Ethereum as Design Philosophy

With each year of its development, the protocol has become harder to survey. What began as a manageable set of rules has grown into an entanglement of specifications, client implementations, and cryptographic procedures whose maintenance demands specialized knowledge and whose auditing becomes more expensive with the volume of the code. The circle of those who can still survey the system in its entirety has grown smaller over the years, and every new capability the protocol acquires adds to it another layer of code and attack surface. The new strategy outlined in section 5.1-A enlarges the entanglement further, and the Roadmap ties its manageability to a design philosophy that makes the complexity of the protocol itself its subject.

Lean Ethereum is the program of simplification, and it rests on the assumption that the security and durability of a protocol decrease with every avoidable component that an attacker can study and a developer can misunderstand. The Ethereum Foundation has identified accumulated complexity as its own burden since around 2024, visible in the code complexity of the clients as well as in the exhaustion of the EIP consensus process.⁶ The consensus process can resolve only a small selection of competing proposals per hard fork and plays each additional function against the next. The elements of the program range from the reduction of client code through the transition to SSZ as a unified serialization format to a formally verified consensus client and hash-based primitives. Added to these are a new execution environment in the form of leanVM and the RISC-V line as its foundation.⁷

Post-quantum resistance would emerge from the principles of this simplification as an integral property. The migration from the currently deployed components would then constitute only the transitional problem. The actual construction effort lies elsewhere. Hash-based primitives stand by default in place of number-theoretic procedures, from Poseidon through leanXMSS to the STARKs, whose security rests solely on the collision resistance of hash functions. The ECDLP-dependent components — from BLS aggregation through Pedersen Commitments and IPA to KZG — yield to hash-based alternatives, whereby the attack surface for a sufficiently large quantum computer disappears. Formal verifiability at all levels would be added, making correctness provable rather than merely empirically familiar. Lean Ethereum thus appears as cryptographic simplification with emergent post-quantum resistance. It follows structurally from the architecture beyond 2029.

At the consensus layer, the Lean Ethereum target state would take the form of the Beam Chain, now called Lean Consensus — a complete redesign of the existing Beacon Chain that would absorb five years of operational experience and take over its task without inheriting its cryptographic foundation. Hash-based validator signatures from the leanXMSS line would replace the BLS signatures, constructively post-quantum-resistant. In place of algebraic BLS aggregation would come hash-based aggregation that condenses many valid signatures through hashnative proof procedures such as STARKs and hash-based SNARKs into a single verifiable proof.⁸ Post-quantum security would rest solely on the hardness of the hash function. The Beam Chain would be formally verified and its correctness mathematically proven. Where finality is concerned, a three-slot finality of roughly 36 seconds stands as the target state, which would replace today’s finality after several minutes, with reference to section 5.5 for the mechanics. Methodologically, the Beam Chain remains a research subject without a fork date. It depends on already deployed prerequisites, among which the higher maximum Effective Balance (MaxEB) introduced with Pectra facilitates hash-based aggregation.⁹ leanVM on the execution environment and Beam Chain on the consensus layer would share the same three properties — hash-based primitives, formal verifiability, and constructive post-quantum resistance. The Lean Ethereum design philosophy would take the same shape on both layers as an integral consequence, whose execution substance section 5.2-E unfolds and whose operational consensus migration section 5.5 describes. The target state shown here is a design state and applies under the same conditions to both layers.

The design philosophy names the direction of the Roadmap and sets no deadlines for it. leanVM and Beam Chain lie beyond the horizon of 2029 without being specified in final form. Concrete research work and an EF-internal consensus carry them, naming the components without yet determining their final interlocking. The interlocking with the RISC-V line remains open in the primary sources and will occupy the coming rounds of specification. Whether the design philosophy holds will be decided beyond the protocol architecture at the operational conditions of its implementation — at governance, client diversity, and privacy, which the following section develops.

The Operative Expectation

The operational level is the place where a technically coherent protocol design can still fail, because an ecosystem must carry, maintain, and defend it against erosion over years. A correctly specified protocol would disintegrate if the client base became monocultural, if further development depended on the engagement of specific individuals, or if an announced property never found its way into the protocol. All three conditions, which the present section develops, share the feature that the design presupposes them without being able to guarantee them itself. The first is plannable governance, the second an actively maintained client diversity, the third a privacy that moves from the exceptional case to the default. The last of these conditions simultaneously shows where the evaluation framework encounters its own limit.

Plannable Governance

The governance target picture is a plannable, institutionalized protocol development that would run as a sustained process independently of any given leadership. Its most visible anchor is the envisaged six-month fork cadence — two hard forks per year at a rhythm that the ecosystem can plan for years in advance and that reaches to 2029.¹⁰ For an infrastructure system, what counts is less the speed of change than its predictability, because dependent systems fix their own development to the known fork windows. The rhythm establishes the dates without fixing the content, which is why the cadence can be maintained even when individual features move to a later fork. Only the perpetuation over several years transforms a release plan into an institutional expectation that no longer depends on the disposition of individual actors.

What makes development robust against the turnover of individual persons is its anchoring in a documented process that guides every proposal through the same stages regardless of its author. A named technical contact accompanies a proposal from submission to possible inclusion in a fork. Per upgrade and layer, the process selects a headliner feature, while the remaining proposals are gathered until a deadline and evaluated as a batch.¹¹

The status of every proposal is publicly traceable in graduated stages from initial consideration to firm scheduling, which detaches coordination from the internal knowledge of specific participants. For a system on which others build, a readable pipeline is itself a service, because dependent teams can assess the maturity of a planned change without participating in internal conversations. The process thus makes the progress of a proposal depend on its documented status rather than on the attention of a particular leadership. A change at the top therefore does not interrupt the cadence. The reorganization of protocol work into three tracks in February 2026 aligned the process with a few clear priorities rather than orienting it around a growing feature list. As a second indicator of plannable long-term coordination, the Strawmap is added, reaching beyond the individual fork-by-fork coordination.¹²

Maintained Client Diversity

Client diversity remains an actively maintained property of the ecosystem rather than a self-sustaining one, because market dynamics press toward a standard implementation whose prevalence ties the network to a single codebase. Maintenance requires ongoing incentives for minority clients, because the convenient choice of the most widely deployed implementation would otherwise reinforce concentration on its own. The target picture would be a distribution of execution and consensus layer clients in which no single implementation exceeds the 33 percent threshold. Above the threshold, a bug in a single client could threaten network finality. Below the threshold, the diversity of the remaining clients catches the error of any single one, so that an implementation bug remains local and does not escalate to a consensus failure across the entire network.¹³ As a long-term simplification, the leanVM harmonization would be added, deriving client consistency from a formal specification, whose three dimensions section 5.2-E unfolds.¹⁴

Privacy as Limit and Target Picture

The twelve-criteria framework of the study does not capture privacy, thereby marking a limit of the evaluation instrument itself, whose reflection section 6.3 carries. The limit arises from the fact that the twelve criteria were deductively derived from an infrastructure concept that did not carry confidentiality as constitutive, and that verification on systems without their own confidentiality claim provided no occasion for correction. The instrument can describe the transparency of the current state, but holds no criterion that would register a movement toward confidentiality as progress or regression. Even a protocolnative shielded pool would not resolve end-to-end privacy on its own, because the encryption of the mempool, anonymity at the network layer, and the design of wallet UX lie outside the protocol.¹⁵ Protocol privacy would be a necessary foundation without on its own securing the confidentiality of the entire interaction.

As a target picture on the horizon beyond a decade, privacy-by-default would reverse today’s ordering. Currently all transfers are public, and confidentiality is the concern of individual applications and Rollups. The protocol does not provide it. Anyone seeking confidentiality today must actively establish it and becomes visible simply by moving into a protected path, while a default would shift this burden onto disclosure. As long as confidentiality remains distributed across individual applications, it fragments into small and weak anonymity sets in which participants can barely conceal themselves. The Strawmap North Star Private L1 would embed native shielded ETH transfers in the protocol and would understand confidentiality as the protocol’s default.¹⁶ The horizon extends beyond the 2028 North Star mark, until privacy would count as an architectural property of the infrastructure and would outgrow today’s binding to individual applications. Confidentiality is then a reliable foundational property on which every application rests, rather than remaining an add-on service of individual providers.

EIP-8182 concretizes the direction with a protocol-managed shielded pool and ZK verification as a protocol feature, so that private transfers to any ordinary address would be possible without requiring a dedicated privacy address format.¹⁷ The pool would sit as a system contract at a fixed address, without a privileged key and without a pause mechanism, so that no party could subsequently lift the confidentiality or interrupt the traffic. The core lies in the unified anonymity set, because every integrating wallet would feed the same shared pool and anonymity would thereby arise from a single pool. With every wallet that uses the shared pool, the anonymity set grows, so that confidentiality increases with the spread of integration. The proposal has been submitted for Hegotá and is at the status of a draft in PFI-review — the Proposedfor-Inclusion stage of the ACD process — whose inclusion is not secured. Buterin’s 2025 call for a native shielded balance from which sending happens by default carries the logic of such a default.¹⁸ Both rest on curve-based ZK cryptography and therefore belong to a different horizon than the hash-based post-quantum target state outlined in the previous section.

The following sections examine the individual directions of the target state in sequence. Section 5.2 addresses the scaling of execution, 5.3 verification and access, 5.4 state management, 5.5 neutrality, and 5.6 the architecture of Layer 2. Each section takes up one of the directions that the framework has named and examines how far the design carries it in the target state.

5.2 Execution Scaling

The Dependency Chain: Parallelization, Decoupling, Convergence

Every capacity increase beyond 100 million Gas forces a decision that the current protocol does not offer: higher throughput or a broader verification base. At 60 million Gas, Ethereum processes between 15 and 30 transactions per second, depending on transaction complexity.¹⁹ For infrastructure intended to carry financial systems, supply chains, and institutional settlements, this is a structural limitation: Visa processes on average more than 8,000 transactions per second, at a tested peak capacity of 65,000 TPS.²⁰

The comparison in terms of transaction counts understates, however, the performance class in which Ethereum already operates. A single Ethereum transaction can settle value of several hundred million US dollars with programmable finality while consuming the same 21,000 Gas as a transfer of 0.01 ETH. In the dimension relevant for institutional settlement — value throughput per unit of time — Ethereum L1 already moves in the range of global payment infrastructure.²¹ The structural limitation thus concerns the number of simultaneous operations that L1 can carry and the breadth of use cases beyond high-volume individual transactions.

The exponential scaling path that EIP-9698 formulates as a target would dissolve this limitation by increasing L1 capacity by a factor of 100 over four years (tenfold increase every two years over two cycles).²² Such an increase would bring Ethereum from the niche of specialized crypto applications into the reach of global infrastructure loads, provided that the decentralization of verification is maintained. Exactly here lies the tension: three features must architecturally break the trade-off between capacity and decentralization before the expansion can proceed safely. They address different bottlenecks but form a directed dependency chain whose shared infrastructural prerequisite is Enshrined Proposer-Builder Separation.

the tested VisaNet network capacity, not the actual peak value. The comparison serves as an order-of-magnitude reference. Visa and Ethereum are not directly architecturally comparable.

Parallelization as Gatekeeper

The sequential verification of all transactions by every node becomes a temporal bottleneck with increasing Gas Limit. In the current model, a validator checks every transaction in sequence, the ordering being mandatory as long as the node cannot determine which transactions compete for the same storage slots. At a Gas Limit below 100 million, the verification time remains manageable within the 12-second slot.²³ At higher values it grows linearly, until the slot no longer suffices. Block Access Lists (EIP-7928, SFI Glamsterdam, i.e. Scheduled for Inclusion) solve this time problem through a new field in the block header: the Builder declares at block construction all State accesses of every transaction, including the post-execution values.²⁴ Receiving nodes can then parallelize disk accesses and transaction validation, because the dependencies between transactions are known in advance.²⁵ The additional data overhead remains at an average of 70 KiB per block at a Gas Limit of 60 million — below the maximum calldata size — and does not burden the protocol with a new data problem.²⁶

BALs are therefore not an optimization but the gatekeeper of the entire L1 execution scaling. Without them, the Gas Limit cannot safely be raised above 100 to 150 million, because the sequential verification time would burst the slot. The governance status underpins feasibility: SFI for Glamsterdam, three client teams (Besu, Geth, Nethermind) with ongoing prototype implementations.²⁴ Parallelization solves, however, exclusively the time problem on the verification side. The cost problem remains: despite parallel processing, every node continues to fully re-execute every transaction. Hardware requirements for validators grow linearly with the Gas Limit, and this linear coupling has no upper bound. Beyond a certain threshold, the requirements become so high that only professionally operated nodes can keep pace, which erodes the verification base. Exactly this erosion must a second mechanism prevent. BALs also unfold a second effect that reaches beyond the validator side: the dependency graph they provide is simultaneously the prerequisite for parallel witness generation in the zkEVM proving pipeline.²⁷ Since 60 to 80 percent of transactions in a block use disjoint storage slots, provers can parallelize execution across independent transaction clusters and distribute proof generation across multiple machines.²⁵ Without the dependency graph known in advance, serial witness generation would remain the bottleneck limiting zkEVM scaling at high Gas Limits.

Decoupling through Cryptographic Verification

The linear coupling between capacity and hardware requirements can be quantified. At a Gas Limit of 60 million, full verification of a block requires one to two seconds.²⁸ At 600 million, it would be ten to twenty seconds with sequential processing. Even with the parallelization enabled by BALs, the verification time in this range reaches the boundary of the 12-second slot. At 5,000 million — the projected endpoint of the EIP-9698 path — verification within a 12-second slot would be impossible.²⁹ The consequence is clear: every increase in network capacity simultaneously raises the minimum hardware requirements for validators. This stands in direct conflict with the decentralization goal, because participation in verification becomes more expensive with every capacity level. The zkEVM (EIP-8025, active EF Roadmap since January 2026) breaks this coupling by fundamentally changing the mode of verification.³⁰

The paradigm shift consists in replacing universal re-execution with cryptographic proof verification. Instead of every validator recalculating every transaction, a specialized prover generates a zero-knowledge proof that mathematically proves the correct execution of all transactions.³⁰ The prover is thereby a standalone role that the EIP-8025 design separates from Proposer and Builder: the Proposer proposes the block, the Builder constructs it, and the Prover delivers the cryptographic proof of correct execution. Validators verify the proof in milliseconds, regardless of how many transactions the block contains. A block with

60 million Gas and a block with 5,000 million Gas create the same effort for the verifier. The decisive design principle is optionality: nodes can fall back to full re-execution at any time if they do not trust the proof.³¹ Proving latency fell between July and December 2025 from 16 minutes to 16 seconds, with a 45-fold cost reduction.³² This threshold has architectural significance: for the first time it becomes realistic to prove a block within a single slot, so that a validator on commodity hardware verifies a block without executing it. This changes the verification architecture of the network.

The Security Question as Open Point of Friction

The proving speed is resolved. The mathematical underpinning is outstanding. Fast proving times rest on STARK-based proof procedures that rely on unproven cryptographic assumptions, primarily regarding the collision resistance of certain hash functions and the security of the Fiat-Shamir transformation that converts interactive proof systems into non-interactive ones.³³ Work from the EF research group and independent cryptographers began during 2025 to formally question individual such assumptions.³³ Should they fall, the affected proof systems would be mathematically unsecured, and the 128-bit security that the protocol sets as its target would not be achievable with current procedures. The Ethereum Foundation responds with graduated milestones: provable 100-bit security by Glamsterdam, 128 bits by end of 2026.³⁴

For the scaling path, two things follow from this. Should proving times increase by a factor of three to five under mathematically secured security, the decoupling shifts temporally backward. Single-slot proving would then first be achievable with the next generation of proving hardware or optimized proof systems, which could delay the complete scaling path by one to two years. Network security is not affected by this, because optionality acts as a fallback: as long as the cryptographic underpinning is outstanding, nodes verify through full re-execution. The question of unproven assumptions is thus a timeline risk for decoupling.

A second security layer reduces the remaining risk further. The proposed 3-of-5 threshold model foresees that five independent client implementations each generate their own proofs. A block is considered valid if three of them are verified.³⁵ A cryptographic flaw in a single proof system does not compromise the network as long as the other implementations remain intact. Client diversity, which in the current state represents best practice without protocol enforcement, becomes through this model a cryptographic security guarantee.

Why Building Remains Specialized

The zkEVM decouples verification from the Gas Limit. State remains tied to capacity. Block builders must continue to hold the full State, which grows with increasing capacity.³⁶ The architecture thus deliberately separates three roles. Verification is democratized, because proof verification is independent of block size and functions on resource-constrained hardware. Building remains the role of specialized operators, because a block builder must hold the full State (as of Q1 2026, roughly 430 GiB) in fast access, and this load grows with every Gas Limit increase. Proving establishes itself as a third role on its own hardware basis: specialized GPU clusters with high energy load, without State retention, with its own market conditions and concentration risks.³⁷ Section 5.3 elaborates both dimensions: Stateless Clients show the democratization of verification. The cryptographic infrastructure layer addresses there the hardware and market conditions of the Prover role.

ePBS as Convergence Point

The zkEVM solves the cost problem of verification but creates a new requirement in doing so: proof generation requires time that the current slot design does not provide. Without structural change, the prover is left after block propagation and attestation with a window of only one to two seconds, which is insufficient for real-time proving at practically relevant Gas Limits.³⁸ Enshrined Proposer-Builder Separation (EIP-7732) resolves this bottleneck through a reorganization of the slot sequence.³⁹ ePBS separates block verification into two phases: consensus verification in slot N and execution verification in slot N+1. This creates a proving window of six to nine seconds in which the prover can complete the cryptographic proof before the attestation of the following slot begins.

The same separation of Proposer and Builder is simultaneously the prerequisite for BALs. The Builder creates the Block Access List in parallel with Proposer selection. Without the protocol-level formalization of this role separation, the procedure cannot be safely implemented.⁴⁰ Two features with fundamentally different functions — parallelization in BALs and decoupling in the zkEVM — converge in the same infrastructural mechanism. This convergence is a consequence of the architectural change: as soon as the protocol formally separates block construction and block verification, both scaling paths become possible simultaneously.

The bottleneck is resolved on the governance side. ePBS has SFI status for Glamsterdam, all five consensus layer clients are in active development, and the first generalized devnet was started in April 2026.⁴¹ ePBS unfolds beyond the capacity function described here a second effect: the elimination of the Relay chokepoint and its consequences for censorship resistance. Section 5.5 addresses these.

BALs parallelize execution for provers and validators ePBS zkEVM creates the time window in which the prover completes the proof decouples the validator load from the Gas Limit from around 100M Gas

6 to 9 seconds fully from around 500M Gas accelerate the prover gives the prover time frees the validator

The chain is directed. An undirected relationship would be incorrect.

The Interplay of the Three Features

The three features form a directed dependency chain in which each link enables the next. BALs provide the dependency graph that first enables parallel witness generation and distributed proving. ePBS reorganizes the slot sequence so that the prover can use the resulting time window of six to nine seconds. The zkEVM translates the output of this chain into a constant verification time for validators, independent of the Gas Limit. If any of the three links is absent, scaling breaks at a different point: without BALs, proof generation becomes the bottleneck; without ePBS, the prover lacks the time window; without the zkEVM, validator load grows linearly with capacity.⁴²

The governance status staggers implementation along this chain. BALs and ePBS are confirmed as SFI headliners for Glamsterdam and create the infrastructural foundation on which the zkEVM can build. The zkEVM itself follows an active EF Roadmap with graduated security milestones, whose complete implementation depends on cryptographic underpinning. The complete hundredfold scaling depends on prerequisites beyond execution scaling, which are addressed in sections 5.3 and 5.4. What the chain achieves as a whole, none of the features could achieve alone: a capacity expansion that architecturally safeguards the decentralization of verification by formally separating the roles of Builder, Prover, and Validator and assigning to each role the scaling prerequisites suited to its function.

The Graduated Scaling Path

For Ethereum to fulfill the criteria of Functional Irreplaceability and Coordination Function operationalized in Chapter 3 at the level of global infrastructure, its L1 capacity must substantially exceed today’s level of 15 to 30 transactions per second at 60 million Gas. The role separation described in 5.2-A is the architectural answer to this requirement. The graduated scaling path along this role separation begins, however, before its formalization. The Gas Limit doubled from 30 to 60 million between February and November 2025 — in roughly ten months — without the protocol needing to change.⁴³ This doubling shows that Ethereum can expand its L1 capacity without sacrificing the decentralization of verification. The question for infrastructure assessment is how reliably the prerequisites of each further stage are secured⁴⁴ and what new bottlenecks each stage creates. The scaling path divides into five thresholds, with each threshold revealing a specific technical limit that must first be addressed before the next stage becomes achievable.

The Operative Proof

The doubling of the Gas Limit from 30 to 60 million (cf. section 5.1-A) expanded L1 transaction capacity by a factor of two.⁴³ In validator voting, validators converged on the new target value within a few months, with each block proposer able to adjust the limit by approximately 0.1 percent per block. The Fusaka hard fork in December 2025 anchored two accompanying protective measures. The Gas Limit Default Target (EIP-7935, DEPL) formalizes the preset target value for client software. The Transaction Gas Cap (EIP-7825, DEPL) limits the maximum Gas consumption of an individual transaction to 16.78 million.⁴⁵ Blob parameter optimizations progressively raised the Blob Target to 14 and the maximum to 21.⁴⁶

The same mechanism that carried the doubling to 60 million can push the limit to approximately 100 million, because the sequential verification time in this range remains manageable within the 12-second slot.²³ Only above this threshold does the growing verification time compel new protocol prerequisites. In practice, three mechanisms act as sequential thresholds that couple the Gas Limit to actual protocol maturity. When blocks exceed the processing capacity of validators, missed attestations and associated reward losses increase — a self-correcting economic incentive that ties the limit to operational reality. Client teams and the Ethereum Foundation take public positions on the prerequisites of each increase level, as evidenced by Buterin’s endorsement of the doubling in November 2024.⁴³ Large staking operators only raise their targets once their own infrastructure can carry the new requirements. The doubling from 30 to 60 million was accordingly not an emergent process: the EF had communicated the prerequisites, client teams had optimized execution, the hardware was ready. The actual dynamic is sequential: features are deployed, their operational stability is confirmed, and only then does validator voting enable the next capacity level.

From Validator Voting to Hard Fork

From 100 million Gas, sequential verification runs into a temporal limit that the current protocol cannot resolve: verification time grows linearly with the Gas Limit and exceeds the 12-second slot once the node can no longer determine which transactions are independently processable. BALs and ePBS, whose mechanisms section 5.2-A presented, address exactly this bottleneck. BALs reduce verification time through parallel processing, ePBS creates the extended propagation window for larger blocks. Both require protocol changes that only a coordinated hard fork can deliver.⁴⁷ The transition from autonomous voting to coordinated fork development follows from the complexity of the next stage: BALs change the block header, ePBS reorganizes the slot into two phases, and both require that all clients adopt the new structures simultaneously. Ethereum’s fork cadence demonstrates the viability of this coordination: Dencun (March 2024), Pectra (May 2025), Fusaka (December 2025), and Glamsterdam (expected 2026) follow in an increasingly shorter rhythm, which has accelerated from annual to twice yearly and continuously structures the scaling path. Both features have SFI status. Implementations are running in three execution layer clients for BALs and five consensus layer clients for ePBS. The next step is thus specification-ready and in advanced implementation work, with ePBS development proving more complex than originally anticipated according to EF Checkpoint 9 (April 2026).⁴⁸ Tomasz K. Stańczak, then EF Co-Executive Director, specified the graduated thresholds in December 2025: first 100 million Gas after Glamsterdam, 200 million Gas after fully operational ePBS, and long-term an L1 target of approximately 10,000 transactions per second.⁴⁹ The Soldøgn developer consensus of 2 May 2026 affirmed these stage values as operational orientation.⁵⁰

The threshold at 150 to 500 million Gas creates a second bottleneck: the Gas costs of individual EVM operations no longer reflect actual hardware costs, so that an attacker can use low Gas expenditure to force disproportionately expensive operations. The Gas Repricings (EIP-7904 and EIP-8038, Meta-EIP 8007, CFI Glamsterdam, i.e. Considered for Inclusion) recalibrate costs to current hardware realities.⁵¹ This type of recalibration is established governance practice: EIP-1884 (Istanbul, 2019) and EIP-2929 (Berlin, 2021) had already adjusted Gas costs to changed hardware and altered attack profiles in earlier forks.⁵² The details and DoS risks that the current recalibration must address are treated in section 5.2-C.

Up to that threshold, the scaling path is governance-anchored and operationally prepared: each prerequisite has an SFI or CFI status and a named fork. The first near-tenfold increase in L1 capacity, from 60 to approximately 500 million Gas, moves within the range of proven governance mechanisms. In parallel with the execution bottleneck, however, the scaling path generates a correlated State growth from that threshold, whose sustainability section 5.4 quantifies and which places the assessment of the first tenfold increase under a qualification not resolved here.

The Second Tenfold: Active Research, Open Specification

From approximately 500 million Gas, the scaling path enters a stage in which prerequisites are actively being researched but not yet specification-ready. The specific bottleneck lies in full re-execution: from approximately 600 million Gas, verification time exceeds the slot even with parallel processing, so that the zkEVM described in 5.2-A becomes a mandatory prerequisite for decoupling verification and capacity. The zkEVM has a draft EIP (EIP-8025), a published EF Roadmap, and a dedicated research team, but no fork date.⁵³ A feature without a fork date is the expected state at this development stage: BALs and ePBS likewise had none before becoming specification-ready and receiving SFI status. The remaining uncertainty lies in the precise timing of protocol integration. The Conjectures problem described in 5.2-A acts as a timeline risk that can delay the path. Should the cryptographic assumptions of STARK-based procedures prove untenable, the delay would be more substantial than the one to two years estimated in 5.2-A. The sequential logic of the path bounds this risk: the Gas Limit will not reach 500 million before BALs, ePBS, and Gas Repricings are deployed, and the zkEVM will have had several years of development time by then.

At 600 to 800 million Gas, distributed proving becomes a prerequisite because a single prover can no longer maintain the ePBS window.⁵⁴ The economic coordination of such a proving network has neither an EIP nor a Roadmap. The comparison with Builder economics provides a countermodel. MEV auctions, Builder APIs, and the entire PBS infrastructure emerged organically when economic incentives were present, without an EIP specifying them in advance.⁵⁵ The analogy has a structural limit, however: MEV extraction is a value extraction game with endogenous profit sources, while proving is primarily an infrastructure service whose compensation must be fed from protocol subsidies or priority fees. The analogy assumes that proving economics generates comparable incentives, which depends on the protocol-level anchoring of the zkEVM and the transaction volume at this capacity level. Execution Tickets (RES), discussed for Building, could prospectively move the coordination of Building and Proving into the protocol. Proving economics is a future coordination problem whose difficulty can be measured against a real analogy but not predicted.

1,000 Million Gas as Projection

Above 1,000 million Gas lies the range for which the Roadmap holds no concrete answers. The soundness of the zkEVM is cryptographically guaranteed through ZK proof verification. The 1-of-N model ensures liveness as long as at least one honest prover is active. The economic safeguarding of this minimum operation — that is, the incentives for a sustainable number of active provers — remains open as a coordination task.⁵⁴ The State problem, which already acts as a growing bottleneck from approximately 500 million Gas and at this threshold becomes the binary limiting factor, is the subject of section 5.4.⁵⁶

Decisive for the infrastructure assessment is the classification of thresholds in operational orders of magnitude. At 60 million Gas per block and 12-second slots, Ethereum processes approximately 5 million Gas per second. At 500 million Gas per block, this would be approximately 42 million Gas per second — sufficient for roughly 2,000 simple ETH transfers or roughly 200 Uniswap swaps per second. The actual capacity depends on the transaction mix. The order of magnitude illustrates the leap from a niche of specialized crypto applications into a performance class in which institutional settlement loads could operate on L1. At 1,000 million Gas, the values double again. The first near-tenfold increase, which this study assesses as governance-anchored and operationally prepared, addresses the infrastructure requirements formulated in Chapter 2. The second moves on a research timeline, whose maturity corresponds to its position in the pipeline. Beyond that begins open terrain that does not concern the infrastructural capacity needs of the relevant planning horizon.

500–1,000M over 1,000M

150–500M

100–150M below 100M

DEPL

SFI

CFI

Draft EIP validator voting and social coordination

Gas Repricings, established precedent active research: zkEVM

Research Horizon proving economics and State

Hard Fork: BALs and ePBS

The increasing distance is the point. Scaling does not become uniformly harder, but advances in leaps.

The Path as Governance Achievement

Each threshold of the scaling path creates a specific bottleneck that the next protocol change addresses: the sequential verification time to 100 million, the slot congestion to 150 million, the DoS vulnerability of miscalibrated Gas costs to 500 million, the linear coupling between capacity and verification effort to 1,000 million. The sequential dynamic of the path — in which features are deployed before the Gas Limit reaches the next stage — is the actual governance achievement. The practical mechanisms that secure this rhythm are effective even without protocol formalization: economic incentives via missed attestations, public EF positioning on each increase level, and the infrastructure readiness of staking operators. Should a stage be delayed, the path blocks at that point, because validator voting only releases the next threshold once operational reality sustains it. The threshold at 150 to 500 million Gas depends on a recalibration of Gas costs that has so far only been mentioned as a prerequisite. What exactly this recalibration encompasses and which DoS risks it must address the following section clarifies.

The Recalibration of the Pricing System

The recalibration that carries the scaling path to 500 million Gas corrects a divergence between Gas prices and real hardware costs. Gas is the pricing system by which the protocol accounts for every operation against the load on validator hardware. The calibration must be chosen so that even the most expensive constructible block can be fully verified within the 12-second slot. If this fails, the honest validator misses its vote on which block is added to the chain and loses part of the reward associated with the slot. Today’s Gas prices date from Ethereum’s early period. Computation has since become considerably cheaper to execute because processor performance has grown strongly. Storage access, by contrast, has become more expensive. The blockchain’s State storage has grown to roughly 430 GiB, so that locating individual entries takes correspondingly longer.⁵⁷ The Gas prices for both categories of operations remained unchanged, so that a portion of computation is today overpriced relative to grown processor performance, while other computation and storage accesses remain underpriced relative to their actual hardware load.

At 60 million Gas per block, this divergence is too small to noticeably strain validator capacity. From 150 to 500 million Gas it becomes a practical problem. At this stage an attacker can with a low Gas budget construct blocks that generate considerably higher hardware load for validators than they pay for. At greater block size, more underpriced operations fit simultaneously into a block, so that hardware load can cumulatively exceed the slot boundary. A graduated capacity path thus places a requirement on the pricing system. Relative prices must approach the real hardware load closely enough that an attacker with little Gas can no longer generate oversized validator load.

The Glamsterdam repricings raise the Gas costs of three systematically under-priced categories of operations: computation, State access, and State creation. The Compute Gas Cost Increase (EIP-7904, CFI Glamsterdam) raises the costs of 13 underpriced computation operations and precompiles whose actual execution is slower than their current pricing reflects. Cryptographic precompiles such as POINT_EVALUATION rise from 50,000 to 89,363 Gas, basic arithmetic operations such as DIV from 5 to 15 Gas.⁵⁸ The State Access Gas Cost Increase (EIP-8038, CFI Glamsterdam) raises the costs of underpriced State accesses. A read operation such as EXTCODESIZE, which triggers two database reads on the current State, is recalibrated in this direction.⁵⁹ As a third correction, the State Creation Gas Cost Increase (EIP-8037, SFI Glamsterdam) raises the costs for creating new storage slots and accounts. The long-term effects of new State entries on the overall size of State were not priced into the original calibration.⁶⁰ The question of why State growth remains an unresolved structural problem despite the adjustment is addressed in section 5.4. The three corrections affect application classes with differing intensity: protocols with a high density of cryptographic operations or State-creating deployments bear stronger cost increases than protocols with lightweight transaction profiles. Section 5.5 addresses the neutrality implications of the differential effect.

Reduce Intrinsic Transaction Gas (EIP-2780, CFI Glamsterdam) lowers as a flanking component the fixed 21,000 Gas intrinsic costs that every standard transaction carries regardless of its content.⁶¹ Meta-EIP 8007 centrally consolidates all EIPs belonging to the repricing package and thereby gives the ecosystem an overview of which corrections belong together. The substantive coordination between the individual EIPs is the work of the Glamsterdam repricings calls of the Ethereum core developers.⁶²

Two mechanisms already active in Fusaka limit the room that an attacker can exploit per transaction and per fork. The Transaction Gas Cap (cf. section 5.2-B) acts in the recalibration as a boundary condition. At a block size of 500 million Gas, even the most expensive permissible transaction can thus occupy only 3.4 percent of the block. An attacker would consequently need to combine many transactions to push a block beyond the slot, which substantially increases the cost of attack. The Gas Limit Default Target formalizes the target value by which validators orient their Gas Limit voting. Validators can increase or decrease the Gas Limit slightly per block. The Default Target gives them the common reference value at which individual decisions coordinate. The corrections and the flanking mechanisms address the price–hardware divergence on three levels: the repricings calibrate the price per operation, the Transaction Gas Cap limits the effect per transaction, and the Gas Limit Default Target coordinates the adjustment per fork.

The Friction of Every Recalibration

The recalibration of the pricing system follows in Ethereum an established practice whose friction point structurally belongs to the mode. The Istanbul recalibration of December 2019 adjusted the Gas costs of a triad of State-access opcodes to changed State access times.⁶³ The effect can be read from SLOAD, whose costs were raised from 200 to 800 Gas to carry the increased I/O load. Roughly 680 deployed Aragon contracts became non-functional after this adjustment because their internal transfer logic implicitly rested on the old Gas costs. ETH deposits from other smart contracts to Aragon organizations before version 0.8 could no longer be retrieved after the fork. The affected range extended beyond Aragon to Kyber, Gods Unchained, and various Open-Zeppelin proxies. This is a structural cost category of recalibration: every price increase for underpriced operations hits contracts that carry the same assumption. For the current Glamsterdam package it follows that the price increases there will likewise hit such contracts. This friction is the price of every recalibration of the pricing system. The Berlin hard fork confirmed the logic 16 months later with another calibration of State accesses, which followed as the second major adjustment within that period.⁶⁴ The fork cadence has since become shorter: 14 months between Dencun and Pectra, 7 months between Pectra and Fusaka, roughly six months aimed at between Fusaka and Glamsterdam.⁶⁵ The semi-annual cadence is the stated goal. Governance responds iteratively; the ecosystem absorbs the costs of adjustment in those contracts built on the old calibration.

On several levels simultaneously, the components of the correction address the pricing side of the threshold between 150 and 500 million Gas. In the interplay of elements, the compute increase corrects the relationship between opcode costs and hardware load. The State access increase removes an attacker’s ability to generate disproportionate I/O load with little Gas, while the State creation increase binds the creation of new State entries to their long-term costs. The Transaction Gas Cap holds the effect of an individual transaction at the 3.4 percent of the block cited above. The Default Target anchors the path on the governance side by formalizing the target value around which the coordination of all subsequent adjustments orients. A further Glamsterdam component shifts the structural boundary of contract size: EIP-7954 (Max Contract Size Increase, CFI Glamsterdam) raises the current 24 KB limit per contract to 64 KB, thereby relieving larger zkVM verifiers and more complex DeFi architectures.⁶⁶ The price safeguard thus stands alongside the parallelization and verification mechanisms described in 5.2-A. These elements jointly address the first near-tenfold capacity increase envisioned in the Roadmap.

What the Recalibration Does Not Solve

The safeguard remains within a structural boundary that Glamsterdam shifts but does not remove. The PLAN corrections operate within a pricing system that combines computation time, storage access, and bandwidth in a common Gas budget. A price shift on one side thus continues to feed back onto the other sides. Two features at RES status aim at a structural redesign of this system. EIP-8011 (Multidimensional Gas Metering, RES/DFI Glamsterdam, i.e. Declined for Inclusion) proposes replacing the one-dimensional Gas budget with separate counters for multiple resource categories, which the EIP’s author bundles as block execution time, block network time, short-term memory, and long-term storage. Each resource category thereby receives its own Gas budget, so that a price shift on one side no longer distorts the other sides.⁶⁷ EIP-8057 (Inter-Block Temporal Locality Gas Discounts, RES/DFI Glamsterdam) pursues a different direction and discounts Gas costs for accesses to State entries that have been touched within a window of the last 32 blocks. The idea draws on empirical cache observations: recently touched entries are likely still in the client cache and incur lower actual costs on re-access than cold entries.⁶⁸ Both options carry EIP numbers but are assigned to no fork and have no fork date. They mark research directions intended to structurally advance the pricing side beyond the point corrections of the PLAN components.

The reach of the overall price safeguard remains limited in two respects. First, the Glamsterdam package calibrates prices for the threshold between 150 and 500 million Gas. Higher thresholds will generate further recalibrations that the established governance mode can carry, but which are not delivered in this fork. Second, the correction addresses the pricing side, not State growth itself. The structural asymmetry between the processing, data, and storage resource thus persists. The data resource is addressed in section 5.2-D, State growth in section 5.4.

The Roadmap thus aims to develop the pricing system into an adaptive layer of the protocol that aligns with the hardware reality of network resources. The corrections at PLAN status are intended to address the divergence between price and hardware load within the existing one-dimensional Gas budget. The research directions at RES status — namely multidimensional Gas metering and the temporally local discounting of recently touched State entries — aim at a structural redesign of the pricing system itself, whose concrete implementation remains open. The goal is for the network to price its resources as the hardware actually loads them, and to readjust this pricing along the graduated capacity levels.

The pricing side of the execution resource is addressed in the Roadmap through PLAN corrections and RES research directions. The protocol scales not only processing, however. L2 Rollups publish their transaction data on L1, so that the capacity of the second direction becomes a standalone scaling task.

The Scaling of Data Availability

The recalibration of the pricing system from section 5.2-C calibrates the execution resource. The second resource that the scaling path addresses follows its own logic. The data that L2 Rollups publish on L1 is not subject to the same bottlenecks as execution itself. Before Proto-Danksharding (EIP-4844, DEPL since March 2024)⁶⁹ these data competed for the same block space as regular transactions and thereby directly determined L2 cost overhead. Proto-Danksharding resolved this competition by introducing Blobs as a separate data type with its own fee market.⁷⁰ Blob Gas follows its own EIP-1559-analogous price dynamic, decoupled from execution Gas. The data availability load of L2 Rollups is thereby separated in price from the L1 execution load.

Before Dencun, the large L2 Sequencers together paid more than 15,000 ETH per month for calldata on L1 — an order of magnitude of roughly 34 million US dollars.⁷¹ After Dencun, Blob costs at normal utilization move near the minimum. Transaction costs on the major Optimistic Rollups fell from an average of roughly 0.35 US dollars before Dencun to below 0.01 US dollars after Dencun.⁷² This corresponds to a reduction of 95 to 99 percent, with deviations depending on the Rollup and utilization. For an L2 operator this means a change in the cost model: data availability was one of the largest line items before Dencun. After Dencun it is no longer a structural operating load.

This decoupling harbors a vulnerability at the lower end of the price corridor. At below-target utilization — when fewer Blobs are submitted per block than the target value specifies — the Blob price converges rapidly toward zero, because the EIP-4844 fee formula reduces the price exponentially in each block. The data availability resource is thus factually cost-free at low utilization, even though it consumes L1 block space and validator bandwidth. The protocol carries the resource economically without drawing any counter-revenue from it. The Blob fee share of validator revenues approaches zero, and the L1 security budget weakens accordingly. Blob Fee Stabilization (EIP-7918, DEPL with Fusaka)⁷³ couples the minimum Blob base fee to execution Gas costs, so that the price assumes a floor that reflects the block space costs of Blob submission. The Blob fee share of the L1 security budget is thereby maintained even at below-target utilization. The complete security budget argument is developed in section 5.5. At this point it suffices to note that EIP-7918 economically stabilizes the data resource.

PeerDAS: Verification via Sampling

The price layer is economically calibrated. The second architectural layer of the data resource addresses the verification side. Until Fusaka, every full node down-loaded every Blob in full, so that validator bandwidth scaled linearly with Blob capacity. PeerDAS (EIP-7594, DEPL with Fusaka in December 2025)⁷⁴ replaces this effort with Data Availability Sampling — a probabilistic procedure. Each node checks only a small portion of the Blob data. An attacker withholding data becomes statistically detectable. Technically, the Blobs are extended horizontally via Reed-Solomon coding, and the extended matrix is divided into 128 column subnets. Each node deterministically downloads only the roughly 12.5 percent of data assigned to it.⁷⁵ The architecture follows the same principle as the zkEVM on the execution side: where the zkEVM replaces re-execution with proof verification, PeerDAS replaces full data retention with sampling verification. Both mechanisms decouple the resource requirement per node from the total load of the network.

The capacity effect of this decoupling can be read from the Blob parameter path of the recent hard forks. Since Dencun, Blob capacity has been increased in several steps. The current status after BPO2 is Target 14 and Maximum 21 Blobs per block.⁷⁶ The theoretical 1D maximum of the PeerDAS architecture is

64 to 128 Blobs, and thus a multiple of the current level.⁷⁷ At a Rollup-specific compression of a few hundred to a few thousand L2 transactions per Blob, the current level reaches the order of magnitude of a few thousand L2 TPS, while the 1D maximum reaches several tens of thousands.⁷⁸ The mechanism that enables these increases is Blob-Parameter-Only Forks: isolated parameter changes that exclusively affect Blob capacity parameters without requiring a coordinated hard fork. The previous BPO rounds demonstrate the implementation maturity of the PeerDAS mechanics under production load. Blob capacity can thus be expanded independently of the general fork calendar as long as network stability sustains the next step. The execution resource with its hard fork dependencies knows no such governance mode. Operational validation under adversarial conditions will be demonstrated in the coming Blob increases — specifically in network stability at higher Blob counts and in sync behavior at column subnet unbalance.

theoretical 1D-PeerDAS ceiling 64 to 128 Blobs maximum target

Dencun 3/6

Pectra 6/9

BPO1 10/15

BPO2 14/21

The gap between the achieved value and the ceiling conveys the point.

Beyond the 1D maximum, the long-term path of the data resource lies in a two-dimensional extension of the same architecture. Full Danksharding (RES, no fork assignment) extends PeerDAS from one-dimensional to two-dimensional sampling by adding a vertical Reed-Solomon extension to the horizontal one. The reconstructibility of data scales quadratically rather than linearly, and a node grasps Blob completeness from a considerably smaller sample fraction. In this matrix, nodes download individual cells (matrix cells) rather than entire columns, so that the data volume per node remains constant as Blob count grows. Validator requirements are structurally decoupled from the scaling objective.⁷⁹ The capacity projection is 64 Blobs Target and 256 Maximum, corresponding to roughly 32 MB of data throughput per slot.⁸⁰ The technical prerequisite is efficient bivariate polynomial interpolation that reconstructs the complete matrix from a partial subset of samples. This reconstruction has been mathematically defined for some time. What remains open is the production-ready implementation, because the computational load per reconstruction currently exceeds the hardware budgets of prover and validator infrastructure.⁸¹ Full Danksharding thus depends on an engineering bottleneck whose solution is expected but not scheduled. Under the L1-first pivot, the path is not critical as long as PeerDAS carries the foreseeable L2 development. Accelerated adoption through institutional Rollups, ENS Namechain, or Based Sequencing can overtake the baseline assumption.

Alongside the engineering dimension, the target state harbors a cryptographic migration question. The KZG commitments that today guarantee Blob correctness without full download rest on elliptic curve pairings, which a sufficiently large quantum computer would break via Shor’s algorithm. The Roadmap therefore foresees the transition to STARKor lattice-based commitments. The problem is that STARKs do not possess the mathematical linearity property (homomorphism) of KZG. Since linearity constitutes the mathematical foundation for two-dimensional Data Availability Sampling — the efficient verification of data structures via partial samples — the switch leaves an as yet unresolved down-stream problem in the scaling architecture.⁸²

State: The Direction without Breakthrough

While the data resource permits a graduated expansion, the two breakthrough mechanisms on the execution and data sides raise a question that reaches beyond the data resource. The three scaling resources of the protocol — Execution, Data, and State — stand at three different maturity levels that follow from the architecture. The execution resource has with the zkEVM an identified breakthrough mechanism whose governance path and Gas threshold assignments sections 5.2-A and 5.2-B unfolded. For the data resource, PeerDAS provides a deployed break-through mechanism and Full Danksharding a long-term option. The storage resource, by contrast, has no comparable breakthrough mechanism standing at the same maturity level as these two.

The breakthroughs in the first two directions drive the growth of the third. Every additional execution capacity can generate State, and every additional data capacity enables L2 activity whose settlement on L1 again produces State. With every scaling stage, the asymmetry sharpens: what in earlier Roadmap formulations appeared as a long-term risk becomes, under the L1 Gas Limit path, a medium-term bottleneck.

The role separation from 5.2-A solves verification and proving, but not Building itself. The zkEVM decouples the validator from Gas capacity, PeerDAS additionally from Blob bandwidth. Distributed proving decouples the prover from block volume. ePBS separates the Proposer from Building and simultaneously eliminates the Relay chokepoint (cf. section 5.5). The role of Block Builder remains tied to State. A Builder must hold the full State to construct a valid block. With every capacity level, its State synchronization load grows. The entry barrier for Block Building thus rises with each capacity level, even as the verification and proving barriers fall. The decentralization of verification is thereby architecturally sustained. The decentralization of Building remains tied to the unresolved State resource. Section 5.4 examines this State dependency as the deepest unresolved bottleneck of the Roadmap.

The execution resource thus stands with an architectural chain, a graduated path, and the prospective decoupling through the zkEVM. The data resource stands with a deployed sampling mechanism and a two-dimensional long-term path. State remains the open dimension and is the subject of section 5.4. The Blob capacity of the data resource simultaneously unfolds an effect beyond the L2 cost model. It is the L1 prerequisite for Rollups to shift their security guarantees from an institutional to a cryptographic basis. Section 5.6 addresses this shift as a separate architectural question. Up to this point, the design state and the interplay of features that the Roadmap provides for capacity expansion in the two scaling directions have been established. Beyond the design state, a development emerges that redesigns not the capacity of the execution layer but its execution environment itself.

Post-Design State: RISC-V, leanVM, and the EIP-Invariant Role Separation

The execution environment whose further development the preceding section marked is the Ethereum Virtual Machine: the runtime environment in which all the scaling mechanisms described above run. The zkEVM, which 5.2-A introduced, proves the correct execution of this existing machine with its historically grown opcodes and State transitions. A deeper further development replaces not individual mechanisms but the instruction set architecture itself: the foundational catalog of instructions that the runtime environment interprets and executes. Every smart contract code is ultimately translated into these instructions. Buterin’s proposal of May 2025 sketches this direction: to supplement or replace the EVM in the long term with a RISC-V-based or similarly ZKnative execution environment.⁸³

RISC-V and the Proving Advantage

RISC-V (RES, exploratory, no governance anchoring) stands for Reduced Instruction Set Computing, fifth generation. The philosophy behind the Reduced Instruction Set is a minimalist foundational decision in computer architecture: few, simple instructions that each execute only one computation step, while complex macro-instructions decompose internally into many sub-steps. RISC-V is the open standardization of the architecture, developed at UC Berkeley in 2010 and since available under a license-free specification. For Ethereum, neither the academic origin nor the license-freedom is the decisive point. What is decisive is what the simplicity of the instructions means for ZK proving: every

RISC-V instruction executes only a single computation step, without hidden internal complexity, and can therefore be mapped with few mathematical equations. A ZK circuit constraint is such an equation that enforces the correct execution of an instruction: it specifies which values must hold before and after the instruction for the computation to be provably valid. Each instruction is represented by a set of such equations. A RISC-V instruction operates on a small number of registers — the fast internal storage cells of a CPU — and performs on them a single arithmetic operation: addition, multiplication, comparison, shift. Side effects — a simultaneously modified stack state, a growing memory area, an accounting of resource consumption — are absent. An EVM opcode, by contrast, typically combines several such basic operations internally and additionally carries a Gas accounting, a growing memory area, and stack operations with it. All of this must be mapped in ZK verification. This is the source of the order-of-magnitude difference: a RISC-V instruction is typically associated with single-digit to low double-digit equations, an EVM opcode execution with several hundred to thousands. The performance improvement for smart contract execution in ZK provers derived from this lies, according to Buterin’s proposal, at a factor of 100 or more. The practical consequence: the proving effort, which today sets significant latency and cost barriers, would fall to levels sufficient for realtime proving within a slot window.⁸⁴ The figure is a projection from the proposal. It has been measured on no running system.

The Roadmap expects three consequences from this architectural change that increase accessibility and provability at different levels. The first level is proving economics. As a direct consequence of the constraint counts in the preceding paragraph, specialized proving infrastructure is needed today: an EVM block contains millions of opcode executions, which together generate several billion constraints. A proof system that must process this quantity in acceptable time requires massively parallel hardware — typically GPU clusters or specialized ASICs. With a RISC-V-based execution environment, the infrastructure loses its structural necessity: the constraints per instruction fall by one to two orders of magnitude, the total effort becomes manageable on commodity hardware, the prover market opens to a broader actor base. The second level is developer generativity. Worldwide there are between 70,000 and 80,000 developers with Solidity experience. Rust, C, and Go together are the system languages from which Linux kernels, browser engines, cloud infrastructure, databases, and operating systems emerge. Smart contracts would be writable for the same developer pool from which the infrastructure itself comes. The special community around Solidity would persist but be expanded by an order of magnitude. Smart contract development would no longer be a specialized discipline with its own language and own community — it would become a domain of general software development. The third level is formal verification. The RISC-V Sail specification is a complete, academically reviewed formal description of the execution environment, while the EVM has only partially formalized semantics for individual components: Run-time Verification models for individual opcodes, K-Framework formalizations of selected subsets, but no unified formal foundation. Simpler execution environments with more clearly specified instruction sets allow faster formal verification of their implementations: the mathematical proof that concrete software does exactly what the specification prescribes. This proof is operationally relevant for Ethereum because the EVM specification is carried by several independent client implementations — software in different programming languages, such as Geth in Go, Nethermind in C#, Besu in Java, Reth in Rust. Each of the implementations must behave exactly the same way for the network to achieve consensus. Today, extensive testing and mainnet operation ensure the correspondence. A formally verifiable execution environment would allow the correspondence to be mathematically proven. Consensus bugs through divergent client interpretations would thereby be structurally excludable, whereas tests and operation today only make them unlikely.⁸⁵

The horizon of the potentials lies in the post-Strawmap period after 2029. RISC-V stands without governance anchoring, without an EIP, and without a fork date. Temporally the proposal lies behind the zkEVM: only when the latter is deployed and stabilized does the question of a RISC-V-based further development become operative.

leanVM as Target State of Execution

The EVM stands within a larger protocol framework whose accumulated complexity the Ethereum Foundation has identified as its own burden since around 2024. This burden directly affects the EVM.⁸⁶ Buterin and others have repeatedly identified the greatest structural task of the coming years as not further expansion but systematic simplification: less code, clearer semantics, formally specified components whose implementations provably comply.⁸⁷ Lean Ethereum is the program that carries this simplification, and section 5.1-B develops it as the overall framework. Within this program, leanVM (RES, horizon beyond 2029) marks the postulated target state of the execution environment with three defined properties. The precise interlocking with the RISC-V line remains open in the primary sources.

leanVM defines itself through three dimensions that in their interplay change the trust model of the protocol. The first dimension is harmonized client implementations. Client diversity in today’s Ethereum is an active ecosystem effort, won through separate teams, different programming languages, and years of specification coordination. Bugs in individual clients must therefore be caught by the diversity of other clients. The leanVM architecture would derive client diversity from a formal specification. A formal specification is a document that precisely defines every instruction in a mathematical language without room for interpretation by implementers. Different teams continue to build different implementations, in different languages, with different optimizations, but their semantics — their input-output behavior — would be mathematically provably identical to the specification. The risk of a consensus split through divergent interpretation disappears. The second dimension is formal verifiability. Today’s EVM is empirically stable. Its correctness is evidenced by years of operation, extensive testing, and bug bounties, not by mathematical proof. A formally verified target state would derive implementation correctness from specification proofs. Whole classes of bugs would consequently be architecturally excluded. The third dimension is ZK nativity. The EVM uses primitives efficient on classical CPU hardware: KECCAK256 hashing for State tree accesses, 256-bit integer arithmetic for most computations, Gas accounting for resource control. All of this is optimally chosen for CPU execution but expensive in ZK circuits: KECCAK256 alone generates thousands of constraints per hash operation. Gas accounting is carried along with every instruction. The leanVM would from the outset choose primitives that represent favorably in ZK circuits. Hash-based functions such as Poseidon generate orders of magnitude fewer constraints in ZK circuits than KECCAK256. Field arithmetic works in the algebraic structure of the proof system rather than in 256-bit integer operations. Data structures dispense with running accounting. The costs of subsequent ZK adaptation, which today make up a large portion of total proving costs, thereby disappear. Together, these three dimensions shift the trust model: away from empirically established stability, toward mathematically secured correctness of the runtime environment. The Roadmap postulates the target state without presenting a concrete specification. What leanVM is for the EVM, Beam Chain is for the Beacon Chain. Justin Drake sketched the consensus layer target state at Devcon SEA 2024, which has since been further developed on ethresear.ch and in Buterin’s Roadmap of February 2026: hash-based cryptography instead of grown complexity, post-quantum security as design principle, and formal verifiability at all levels.⁸⁸ The substantive elaboration is carried by section 5.1-B. Both target states lie beyond 2029 and stand for the same design philosophy of simplification to a formally manageable minimum.

While leanVM and Beam Chain are still outstanding, the direction of development already shows in the current governance process. Two EVM extensions that on first glance appear as technical improvements stand under the caveat that a long-term RISC-V replacement would make them redundant. EOF (EVM Object Format, RES, status open) would have reformed EVM bytecode structure through code validation, static jumps, and function boundaries. In April 2025 the proposal was removed from Fusaka for several reasons, including the increasingly questionable long-term benefit under the RISC-V perspective.⁸⁹ EVM-MAX (RES) would make certain cryptographic basic operations such as elliptic curve multiplication and modular exponentiation considerably more efficient in the EVM, making smart contracts with signature verification or ZK proof verification cheaper to execute. This approach too, however, stands under the same RISC-V redundancy caveat. The post-design state already shapes the prioritization of current EIPs.

Ethereum’s Answer: Role Separation

Other blockchain architectures have chosen different answers to the scaling question. One direction raises the hardware requirements for the validator role and thereby accepts a higher access threshold to network participation. Another reduces the number of validators and concentrates consensus formation on few actors. Solana and Monad are prominent representatives of the first direction, BNB Chain of the second.⁹⁰ Ethereum’s answer is a third: role separation. The scaling by a factor of 100 that section 5.2 has unfolded only becomes possible because no single role must accomplish it alone. The core of this role separation, as 5.2-A anchored it in the protocol, can be captured in three parallel statements. The Validator verifies without recalculating. The Builder constructs without validating. The Prover proves without proposing blocks — thereby establishing itself as a standalone infrastructure layer whose elaboration section 5.3-A′ undertakes. None of these roles could carry the scaling alone. Only their interplay generates capacity growth without the decentralization of any single role falling below the hardware threshold. Decisive here is the load distribution: Builder and Prover may become capital-intensive because their outputs are verified by every Validator with minimal hardware. Validator and Proposer remain on consumer hardware because they alone verify proofs. This role separation is the EIP-invariant principle that holds section 5.2 as a whole together.⁹¹

The limit of the principle was already marked by 5.2-D, and the role separation reaches as far as it carries, to proposing (cf. section 5.2-D). This has a structural consequence that points beyond the capacity question. While verification and proving become architecturally democratizable through the architectures of 5.2-A through 5.2-D, Block Building remains tied to State retention — and thereby to hardware requirements that grow with every scaling level. The participation architecture of the system becomes asymmetric: those who verify need less. Those who build need more.

Scaling raises a question that goes beyond capacity: two questions remain open — the one concerning the verifiability of the scaled system, and the one concerning participation in it. The answer lies in the architecture of verification, in the cryptographic basis that carries it, and in the access threshold it sets.

5.3 Verification and Access

Validating means: actually recalculating computations. A validator validating a block executes the block’s transactions itself, with the same EVM logic, the same Gas costs, the same State transitions that the block builder followed in construction. Verifying means something more general: checking whether a block is correct without necessarily calculating oneself. In Ethereum’s historical architecture, both concepts coincided, because the protocol knew no other form of verification than re-execution by each individual verifier. Anyone wishing to check a block therefore needed the hardware that re-execution required, and that hardware grew with the Gas Limit.

The zkEVM breaks this identity. It replaces re-execution with the verification of a cryptographic proof whose effort remains independent of block size. Verification becomes possible even where the verifier neither wishes nor can follow the computations. A second coupling remains in place, however. Even zk-based verification needs State as input. The proof confirms: if the initial State was X and transactions Y were applied, the final State is Z. But one who does not know that the initial State was X cannot embed the proof’s statement in the world. The verifier needs access to the State values that the block reads and writes. As long as they must hold the full State locally to access these values, their participation depends on the storage capacity that State occupies. This second coupling is the subject of section 5.3.

The section develops the answer in three steps. First, a new State data structure reduces the volume of data a verifier needs at all. Then, post-quantum-resilient procedures secure the cryptographic basis on which this reduction rests. Finally, a more flexible account layer lowers the access threshold from which an ordinary actor can actually use the system. The sequence is mandatory. The cryptographic basis first protects a reduced data volume. The reduction first becomes reliable through a long-term stable cryptographic basis. The access threshold decides whether anyone outside professional infrastructure actually uses the verification. The first step begins with the data structure in which Ethereum holds its State.

The New State Data Structure

Ethereum’s State encompasses all account balances, contract storage values, and bytecodes of the network. The protocol stores these values as a tree with several hundred million leaves. Each leaf contains a concrete value — for example, the token balance of an account or an individual storage slot of a smart contract. The root of this tree is the State Root, a cryptographic summary of all leaves. The block header carries this State Root. Anyone wishing to check an individual value — for example, the token balance of a specific account — does not need the whole tree. They need a witness: a proof path from the corresponding leaf to the State Root. A verifier checking the witness against the State Root can establish the correctness of the value without knowing the other leaves.

The size of a witness depends on two properties of the tree structure. First, the branching factor — the number of children each node in the tree has. With a tree of branching factor 16, each node has 16 children, and the path from root to leaf must carry all 15 sibling nodes at each branch, otherwise the node computation cannot be reproduced during verification. Second, the commitment scheme: the procedure that forms from the values of a node the cryptographic anchor of that node. The commitment scheme determines the form in which the sibling nodes must be carried at all.

Ethereum’s current data structure, the Merkle Patricia Trie (MPT), has a branching factor of 16 and uses Keccak-256 hashes as its commitment scheme. The average witness size per account access is roughly three kilobytes, in the worst case roughly nine.⁹² Verkle Trees (EIP-6800, RES, Stagnant) change both properties. They increase the branching factor to 256 and replace the Keccak hashes with Pedersen Commitments with Inner Product Arguments. Pedersen Commitments combine many State values into a single short anchor. Anyone wishing to check an individual value can do so against the anchor without needing to know or provide the other values. Concretely the commitments operate on the Bandersnatch curve, an elliptic curve over the BLS12-381 scalar field. Inner Product Arguments generate a single compact proof for the path to the State Root instead of listing all sibling nodes individually. The witness size no longer depends on the depth or breadth of the tree. The average witness size per account access falls to roughly 200 bytes, the block witness in the worst case from roughly 18 megabytes to roughly 1.2 megabytes. This corresponds to a reduction by a factor of fifteen to forty-five.⁹³

The witness reduction decouples verification effort from State volume. What a verifier must check no longer depends on the size of the State tree but remains bounded for each individual value to the compact path to the State Root. What hardware consequences a Stateless Client draws from this, the next section addresses. Verkle Trees play a dual role beyond the verification function. They are the State data structure on which later architectural refinements build, and they are the witness form that Native Rollups need for their EXECUTE precompile, because MPT witnesses would be prohibitively large for the purpose.

Verkle is deployment-ready. Kaustinen-7 has been running since late 2024 as a dedicated Verkle testnet in multiclient configuration, with Geth, Nethermind, Besu, and EthJS on the execution side and Lighthouse, Lodestar, and Teku on the consensus side.⁹⁴ Reth and Prysm are absent — these are gaps in the multiclient picture, but not blockers of the path. EIP-7612 and EIP-7748 provide named migration strategies with measured benchmarks. When governance assigns the headliner slot, Verkle can be activated in one of the next forks. This path is stalled, however: Verkle carries the designation Stagnant because the Ethereum Foundation has prioritized the long-term direction toward Binary Trees and deployment readiness has not yet translated into a fork assignment.

Verkle or Binary: The Quantum Question

This implementation readiness conceals, however, a cryptographic weakness that carries no weight under classical hardware. Pedersen Commitments and Inner Product Arguments rest on the ECDLP over the Bandersnatch curve. The ECDLP states: given a point P and a point Q on the curve, find the number k such that Q equals k times P. Classical computers cannot find this number for the curve sizes used in any practicable time. A sufficiently powerful quantum computer can compute it directly using Shor’s algorithm, in a runtime that grows polynomially with key length rather than exponentially. The ECDLP falls, and with it fall Pedersen Commitments and IPA. A research paper from the Dagstuhl context records that Verkle Trees are not secure against quantum computers, and the design of dynamic vector commitments that would be simultaneously asymptotically optimal, practically efficient, and post-quantum-resilient remains an open research question.⁹⁵ Buterin characterizes Verkle against this background as an interim solution that buys time until STARK-based and related procedures are mature.⁹⁶

Binary Trees (EIP-9257, RES) replace Bandersnatch and IPA with STARK-compatible hash functions. Hash functions cannot be accelerated by Shor’s algorithm. Effective security halves at most under Grover’s algorithm, which can be compensated for by sufficiently long hashes. The implementation status lies considerably further behind, however. There is no multiclient testnet at the level of Kaustinen-7 and no migration EIPs at comparable maturity. Estimates from the research community calculate that a switch to Binary Trees would shift the verification and L2 guarantee strand by twelve to eighteen months.⁹⁷

The EF Protocol Priorities Update of 18 February 2026 names for the first time ”a move to binary trees and statelessness” as long-term direction. The Ethereum Foundation thereby marks a strategic prioritization toward Verkle. Guillaume Ballet, one of the EIP-6800 authors, subsequently characterizes Binary Trees as ”a serious alternative.”⁹⁸ Two scenarios are open. In one scenario, Verkle is deployed as a bridging solution, with long-term architecture on Binary Trees basis. In the other, the Roadmap revises the Verkle deployment decision in favor of a direct Binary path. The tension of this decision can be concretely named. Verkle is today deployment-ready but does not carry long-term stability because its cryptographic basis falls before quantum computers. Binary Trees carry long-term stability but are today not deployment-ready, because their implementation lags the Verkle path by twelve to eighteen months. The Roadmap thus decides on the relationship between short-term availability and long-term robustness. This decision fits into the Lean Ethereum program, which understands post-quantum security as a design principle.

The Migration without Downtime

The migration path to the new State data structure is conceived as a bundle of three EIPs that remains largely invariant with respect to the Verklevs.-Binary choice. EIP-7612 (Overlay Tree, RES, without fork assignment) solves the problem of the State switch without mainnet downtime. Upon fork activation, the protocol activates the new Tree as an overlay parallel to the existing MPT, and the MPT is frozen as read-only. All State writes run from this point into the new Tree. Reads search there first, fall back to the MPT if needed, and migrate the found value on the next write. The big-bang switch, which would have required an offline period of roughly one month, was discarded.⁹⁹

EIP-7748 (State Conversion, RES, without fork assignment) governs the background migration. Per block, the protocol converts a fixed number of key-values from the MPT into the new Tree. Benchmarks on an AMD Ryzen 7 5800U measure roughly 300 milliseconds for 10,000 keys per block, from which a total conversion of approximately fifteen days follows. The migration is temporary but plannable.¹⁰⁰ EIP-4762 (Statelessness Gas Cost Changes, RES, without fork assignment) maps the new access costs in the Gas schedule. Per code chunk and per storage slot, an access costs 200 Gas, with adjacent storage optimization for consecutive slots in the same 256-group. The average Gas increase is six to twelve percent.¹⁰¹

The three EIPs solve migration as a separate problem. Which commitment scheme is used is decided by the Tree choice, while the migration bundle determines how the switch remains manageable. Both questions are separately solvable. The complexity of this switching procedure is considerable. Guillaume Ballet has called the Verkle migration ”on the scale of the Merge if not worse in terms of complexity.”¹⁰² This complexity lies in the implementation of the migration.

The State data structure is the first step of the verification architecture that section 5.3 develops. It reduces the data volume a verifier needs from the full State to individual witnesses. Which data structure Ethereum concretely deploys — Verkle or Binary — decides the long-term cryptographic robustness. The architectural logic of the reduction remains unaffected by this. Pedersen Commitments, Inner Product Arguments, and the Bandersnatch curve are not special equipment of the State migration. They belong to a broader layer of specialized cryptographic components that the protocol provides above the EVM. This layer the next section unfolds.

The Extension Layer above the EVM

In the Ethereum protocol there are operations that are cryptographically expensive: generating proofs, verifying signatures, checking Blob data against commitments, and soon also aggregating quantum-resistant signatures. They cannot run efficiently in the EVM, because the EVM knows no instruction for a 256-bit modular multiplication or an elliptic curve point addition. It would have to build such operations from thousands of basic components whose Gas costs add up. A native implementation in the client software of the same operation, by contrast, completes in microseconds, since the CPU knows a direct instruction for multiplication of wide numbers. Exactly this bottleneck between EVM speed and native speed the extension layer addresses. Precompiles and provers execute expensive operations outside the EVM and bind their correctness back to the EVM via cryptographic proofs or consensus guarantees. Four functions of the target picture rest on it: zkEVM verification, the post-quantum migration of signatures, Native L1 Privacy, and the verification of the reduced State from 5.3-A. Where 5.3-A discusses two alternative Tree options, 5.3-A′ unfolds two cooperating components of the extension layer for the computational work on the reduced data volume. The term extension layer is an analytical designation of this study and not an established term in the sources. The primary sources discuss the on-chain precompiles and the off-chain prover pipeline predominantly separately. Here they are consolidated because they fulfill a common architectural function.

The extension layer consists of two parts: the on-chain precompiles and the off-chain prover pipeline. Off-chain here means: outside the consensus protocol, so that the prover is not incorporated into the slot cycle and its proofs flow into the protocol only after their generation. The on-chain precompiles extend the EVM with operations it cannot itself efficiently perform — for example, the verification of a BLS signature or a KZG commitment. The off-chain prover pipeline generates for each block a cryptographic proof of its correct execution. A verifier can check this proof on-chain without having to repeat the entire block execution. Both pursue the same goal: to extract expensive operations from EVM bytecode execution. Precompiles do this for individual cryptographic operations, the prover pipeline for the entire block execution. The verification of a prover proof on the on-chain side itself uses precompiles as cryptographic building blocks. The two components have matured to different degrees. Today the precompiles are active on mainnet, while the prover pipeline in the design state of the Roadmap is not yet anchored by hard fork. The Prover as actor follows from the role separation of 5.2: who should prove the blocks is someone other than who builds, proposes, or validates them.

The precompiles are established today in a first stage and grow through future hard forks. Three operations are currently active and cover the cryptographic classes needed by the EVM in the current state. BLS signatures carry the validator aggregation of the Beacon Chain (EIP-2537, IMPL Pectra). KZG commitment verification checks the Blob data of the Rollups (EIP-4844, IMPL Cancun). secp256r1 verification opens passkey authentication for accounts (EIP-7951, IMPL Pectra). Two further components are planned in the Roadmap. EVMMAX (EIP-6690, RES) accelerates modular arithmetic, with the RISC-V caveat from 5.2-E. A planned family of post-quantum precompiles (RES, ETH2030 line) encompasses the lattice-based operations and STARK verification components.

The accumulation of the layer proceeds asymmetrically between protocol and application. Hard forks activate new precompiles discretely, in sharp jumps every six to nine months. Application in smart contracts diffuses by contrast continuously over years. A precompile can exist in the protocol for years before reaching the most widely used contracts. This is the normal speed at which smart contract adoption develops. The extension layer thus emerges as a slow concentration over several hard fork cycles.

The Prover as New Actor

The prover pipeline introduces a new economic actor into the protocol whose hardware requirements lie above the validator level and below the data center level. The EF profile for realtime proving fixes the threshold through two values: capital outlay of at most 100,000 US dollars and power consumption of at most 10 kilowatts, each for an on-premises setup.¹⁰³ The range lies above the validator setup, whose investment costs are in the low four-digit range. It lies below a hyperscaler data center, whose investments reach into the seven-digit range. The Prover thus belongs neither to the validator class nor to the data center class, but forms its own economic layer between the two. The threshold is not static, since the zkVM teams have reduced their GPU requirements by roughly three quarters in recent months. Investment costs shift into the range of actual home prover setups.¹⁰⁴ Two points still separate the prover pipeline today from the design state: the realtime proving threshold and the economic architecture of prover compensation. 99 percent of mainnet blocks should be proven in ten seconds, but mainnet reality today still lies above the target range. For compensation, the Roadmap specifies neither a reward in the protocol nor a complete solution out-side the protocol. Section 5.5-B picks up the deficit under the aspect of MEV and Builder economics.

To avoid the chokepoint of a single zkVM implementation, EIP-8025 (zkEVM Optional Execution Proofs, active EF Roadmap) anchors an acceptance threshold. Three proofs from five different zkVM implementations must be present for a block before it counts in the full security level.¹⁰⁵ The threshold targets software diversity in zkVM implementation, while the actor diversity of the provers remains unaffected. A single prover can generate its proofs with three different implementations and thereby satisfy the threshold. What matters is not the market concentration of provers but the diversity of the software — such as SP1, RISC Zero, Pico Prism, or Zisk. The logic of today’s client diversity thereby transfers to the prover pipeline without intervening in the market structure of provers. A bug in a single zkVM does not distort consensus, provided the majority of independent proofs do not reproduce it. Liveness remains unaffected, since in the 1-of-N model a single honest prover suffices for proof generation. Here too two points remain open: the maturity level of the zkVM implementations and the hard fork activation of EIP-8025 itself. The EF security milestones for 2026 provide three stages in which security and performance requirements are progressively tightened. Full 3-of-5 viability depends on the last stage.¹⁰⁶ EIP-8025 remains an architecture statement until hard fork activation and does not take effect in today’s consensus rules.

Many Proofs, One Master Proof

The extension layer contains an aggregation mechanic that consolidates many individual proofs into a master proof. STARK proofs have a recursive property for this purpose: a superior proof packages the verifier logic of several subordinate proofs within itself. The verification effort of the master proof thereby remains approximately independent of their number. At the mempool level, a second aggregation stage is added, where the protocol collects the signatures of multiple transactions in a 500-millisecond cycle and consolidates them into a single aggregation proof.¹⁰⁷ The post-quantum migration of signatures first rests on this mechanic, since its unaggregated verification costs would otherwise exceed the transaction budget. The Roadmap quantification names the range from ECDSA to STARK: 3,000 Gas for a classical ECDSA signature, 200,000 Gas for an unaggregated hash-based individual signature, 10 million Gas for a STARK without aggregation. In the aggregation batch, the amortized persig-nature costs return into the transaction budget.¹⁰⁸ Validation Frames (EIP-8141, PLAN, CFI Hegotá Non-Headliner) bring the aggregation vehicle into the transaction format and make it available to all application classes needing such ZK wrappers. Beyond the PQ migration, three further application classes rest on the same mechanic: Native Privacy wrappers, Data Availability Sampling proofs, and application-layer ZK proofs of external protocols. The architecture is fully described in the design state but depends for the on-chain verification of the aggregated quantum-resistant proofs on the notyet-activated PQ precompile family.

The extension layer follows a glue-and-coprocessor architecture in which the EVM coordinates data and calls while precompiles and provers handle the expensive operations. The picture from the hardware level is the relationship between CPU and GPU. The EVM behaves like a universal CPU: it can execute any operation but is not optimal for expensive specialized tasks. Precompiles and provers behave like specialized chips that execute quickly those operations that would be slow in the EVM. Buterin empirically substantiated the scheme in 2024 using an EVM trace. Of the 46,924 Gas of a simple ENS hash update, roughly 73 percent fell on a small number of structured expensive operations such as storage reads, writes, logging, and cryptography.¹⁰⁹ From the pattern, the direction of Roadmap development can be read. Efficiency work shifts outward: to precompile extensions for expensive cryptography and to the prover pipeline for expensive verification. A deeper opcode restructuring of the EVM itself is omitted. The withdrawal of EOF from Fusaka follows the shift, since an EVM-internal bytecode-format refactoring can be expected to yield less effect than the parallel development of the coprocessors.

The extension layer is thereby described as the architectural foundation on which the post-quantum migration from 5.3-D and the Native L1 Privacy statement from 5.1-C rest. The PQ migration itself is a crosscutting phenomenon with four vulnerability classes that section 5.3-D individually unfolds. For the immediately following section 5.3-B it provides a central prerequisite. 5.3-A showed how the protocol reduces the data volume of a block: witnesses on Verkle or Binary basis replace the State tree path with a compact proof path. 5.3-A′ showed how the protocol reduces the computation volume of a block: STARK proofs replace re-execution of the block with constant verification. Both reductions work together, and their common consequence is an architectural shift. Anyone wishing to validate a block need neither download the complete State nor repeat the complete block execution. They verify a compact witness and check a short proof. This is exactly the prerequisite for Stateless Verification, whose hardware consequence section 5.3-B unfolds. The extension layer carries not only the cryptographic substance of the late Roadmap functions but also the computational prerequisite for the Stateless Clients of 5.3-B.

The Hardware Consequence of Stateless Verification

A Stateless Client verifies blocks without holding State locally or repeating block execution — and thereby verification moves from a server task to a function running on consumer hardware. The prerequisite is provided by the two reductions of the preceding sections: witness reduction decouples verification from local State storage, proof verification decouples it from re-execution. The factor that hardware-side dominates full verification today thereby disappears — the obligation of local State storage created the hardware load of execution in the first place, over and above light consensus verification. The Stateless Client knows this hardware load no longer, because it receives State per block as a witness and checks correctness against the State Root without locally tracing the computation path. The resulting hardware profile shifts the requirements of a verification node by three to four orders of magnitude. Each of the four hardware factors derives from one of the two reductions whose technical mechanics were presented in the preceding sections. Storage requirements fall from 2 to 4 terabytes to below 100 megabytes — a reduction by a factor of 20,000 to 40,000.¹¹⁰ RAM falls from 16 to 64 gigabytes to below 1 gigabyte, by a factor of 16 to 64. The compute requirement falls from 4 to 8 CPU cores to a single core, because proof verification with constant cost magnitude replaces linear re-execution. Hours to days consume the initial synchronization today — the build-up of the local State database from the network — constituting the largest entry barrier for new node operators. It collapses to seconds, provided the client no longer builds historical State. The hardware class shifts thereby from professional server configuration to the spectrum of consumer devices: smartphone, browser tab, Raspberry Pi, and home server.

Only One of Three Roles

The reduction concerns, however, only one of the three roles that the protocol carries on the hardware side. The verifier in the strict sense follows the profile of the preceding paragraph and operates their node on consumer hardware, since they neither produce blocks nor order transactions. The Validator, who in the design state as zkAttester verifies proofs, falls in their compute requirement to the same profile. They retain, however, a hardware dimension that escapes the reduction: bandwidth — the network connection for block propagation. It scales linearly with the Gas Limit, since the block size itself scales. At a hypothetical limit of 5,000M Gas, blocks grow to an order of magnitude of 100 to 500 megabytes per slot.¹¹¹ Such a scale requires a network connection that exceeds current home connections beyond the top tier. The current validator recommendation is roughly 25 megabits per second — a connection that the scaling path shifts into the range of several gigabits. The compute requirement is thus decoupled from the Gas Limit, the bandwidth scaling with the Gas Limit persists, and it defines the hardware boundary of the design state for the attestation role. The Block Builder finally remains in the data center class. They hold the full State to extract MEV and compose block candidates in parallel, competing with other builders in a millisecond latency race. The competitive infrastructure of the role is today estimated at roughly 200,000 US dollars per month.¹¹² The naive reading that Stateless Clients lower hardware requirements across the board thereby overlooks the structural differentiation. The reduction applies to the verification side fully, to the attestation side with an open bandwidth question, to the builder side not at all.

Today the hardware layering of the three roles rests on an out-of-protocol construction that ePBS moves into the design state. MEV-Boost assumes the separation between Proposer and Builder hardware as an out-of-protocol sidecar and as of Q1 2026 routes roughly 96 percent of all mainnet blocks.¹¹³ ePBS relocates the same separation into the protocol and makes it a binding element of the slot sequence.¹¹⁴ The hardware consequence of the relocation is the institutional safeguarding of what the architecture requires regardless. The Proposer function remains supportable on the consumer hardware profile, the Builder function remains in the data center class. The protocol step sequence thereby anchors the separation structurally, where today it depends on social pressure and market coordination. The institutional relocation shifts the decentralization requirement to the Proposer layer, while the Builder layer operates as a specialized market whose neutrality is secured elsewhere.

The Cloud Concentration Remains

With the reduced verification profile, the possibility of participation shifts from the data center to home hardware, without the current hyperscaler concentration thereby being resolved. In the current state, roughly 59 percent of hosted execution layer nodes run their service on the infrastructure of AWS, Hetzner, and OVHcloud.¹¹⁵ The M2 threshold value of at most 50 percent applies to a single provider. The 59 percent are distributed across three providers and thereby do not violate it. The Roadmap contains no mechanism that directly addresses the concentration. Neither do protocol penalties for cloud deployment exist, nor does the system have an incentive layer that economically rewards geographically distributed home nodes. The concentration rests on operational advantages that the protocol cannot eliminate because they lie outside its reach. These include the guaranteed uptime of hyperscaler SLAs, the automated monitoring of validator infrastructure, the low latency to large builder nodes, and the convenience of a click setup compared to the manual operation of a home node. Stateless Clients lower the hardware threshold for home staking to a level that is technically achievable. They do not automatically translate, however, into a changed distribution of operations, since the operational frictions of home operation persist independently of the hardware profile. The architecture provides the prerequisite. The operational consequence is decided outside the protocol, in the choices of operators. The hardware consequence belongs to the diagnosis with the same clarity as the reduction factors of the verification profile, because otherwise the architecture statement would be confused with an operations statement that it does not carry.

For the Hardware Agnosticism of the design state, an asymmetric improvement results. On the verification side, the spectrum of hardware classes that can cryptographically verify an Ethereum block is radically expanded. Smartphone, browser tab, and embedded systems take their place alongside the professional server class, and the spectrum of acceptable verification hardware is in the design state no longer bounded by the Gas Limit. On the operations side, the concentration of node infrastructure on a few hyperscalers persists, since no protocol measure outweighs the operational convenience of the cloud against the friction of home operation. The reach of the protocol ends at the boundary of its mechanism, and the choice of operating environment remains a decision of actors that the protocol at most facilitates but does not prescribe. The hardware prerequisite for broader participation is thereby clarified. The question of where a Stateless Client obtains its witness and proof without the gained trustlessness being lost again through a new central data channel is carried by the next section.

The Trustless RPC Architecture

The Stateless Client from 5.3-B can cryptographically verify blocks on a smart-phone because it neither holds State nor repeats execution. What it does not itself produce, however, are witness and proof per block — so it must receive the data from the network, and the receive side is where the viability of the entire hardware democratization depends. The access channel today is the RPC endpoint, a server that operates an Ethereum full node and accepts requests via the JSON-RPC protocol. As of February 2026, roughly ninety percent of Ethereum RPC traffic runs through three providers: Infura from the ConsenSys environment, the independent Alchemy, and QuickNode.¹¹⁶ When a wallet receives an RPC response, it relies on the truthfulness of the provider without its own cryptographic verification. This trust relationship cannot be dissolved by the cryptographic verification of the Stateless Client. The client verifies the data against proofs, but both — data and proofs — come from the same provider, so that a manipulated provider could internally forge both consistently. With the viability of verification on consumer hardware, the question of trustlessness thus shifts to data provisioning.

The Trustless RPC Architecture replaces the central provider relationship with three cooperating out-of-protocol components whose combination fulfills the function of an RPC endpoint with cryptographic verification. The Ethereum Foundation has listed the combination in its Protocol Priorities 2026 under exactly the name Trustless RPC Architecture.¹¹⁷ Helios carries verification on the end device through cryptographic checking of Beacon Chain headers. The Portal Network handles the decentralized distribution of historical and State data that the client needs for verification. The witness availability from the State tree architecture, whose mechanics 5.3-A fully covers, finally provides the cryptographic attestations against which checking takes place. The three components each carry their function only on the presupposition of the others. Helios verifies only the block header and needs the attestations that the Portal Network supplies. The Portal Network transports only the data that become transmissible through the witness structure of 5.3-A at all. The witnesses carry only insofar as Helios has cryptographically verified the header status. The architecture thereby resolves the question of where the client obtains its data without the trust load being newly centralized.

Helios: Verification on the Device

Helios resolves the trust problem by making the authenticity of data locally verifiable so that the data server itself need not be trustworthy. The client downloads light client updates from any Beacon Chain endpoint, and each update contains the signed block header together with the aggregated signature of the sync committee. The signature is checked locally against the known committee membership, so that authenticity is established independently of the supplying server and the trust relationship shifts from the data server to verification in the end device. The implementation written in Rust and compiled to WebAssembly requires approximately two seconds for initial synchronization and has a binary size of thirteen megabytes, making Helios operable on a smartphone, in a browser tab, and on Raspberry Pi class hardware without requiring any blockchain storage of its own.¹¹⁸ The trust model rests on the assumption that at least two thirds of the sync committee act honestly, with the committee consisting of 512 validators drawn randomly from the total pool every 27 hours who sign Beacon block headers via BLS aggregation.¹¹⁹ The reach of verification ends at the consensus layer. Helios checks that the block header is signed by the sync committee. What Helios does not check is whether the transactions within the block were actually correctly executed — that is, whether the State transition follows from the inputs according to protocol rules. This execution correctness rests in current Helios on the assumption that validators fulfill their duty and have not signed a manipulated result — that is, on a social assumption about validator honesty without its own cryptographic guarantee. In the design state it is closed by a combination of two layers: the proof pipeline from 5.3-A′ supplies the correctness proof of the State transition, the Stateless Client architecture from 5.3-B verifies it on the end device. The implementation has been productively in use since 2024.

The Portal Network complements the verification layer through decentralized distribution of historical and State data, whose necessity arises from the history reduction introduced with EIP-4444. EIP-4444 (DEPL since July 2025) allows Execution Clients to discard historical data older than one year, enabling full node operation on a two-terabyte hard drive.¹²⁰ The structural consequence of the reduction is an availability gap, because no individual node need hold the complete history any longer and the network shifts data responsibility from the individual to the collective. The Portal Network distributes historical and State data over a decentralized peer network in which each node holds part of the data. A discovery system routes requests to the respectively responsible nodes. Four sub-protocols cover different data classes. The History Network carries block bodies and receipts, the State Network account data and bytecode. The Beacon Network supplies the sync committee data on which Helios verifies, while a Transaction Gossip subnet ensures mempool access without local State. Four productive implementations (Trin, Fluffy, Ultralight, Shisui) are operationally active as of February 2026, with crossclient interoperability, without the Portal Network being anchored as a binding part of the consensus protocol.¹²¹ Data responsibility thus lies with a distributed network outside the protocol core.

So that fully decentralized data distribution also holds up as the Gas Limit rises, EIP-7975 (PLAN/CFI Glamsterdam) upgrades the eth wire protocol to eth/70 and introduces pagination of block receipt lists, thereby lifting the ten-mebibyte transmission limit per devp2p message for architecture scaling. The devp2p protocol on which peer-to-peer communication of Execution Clients rests today permits messages up to ten mebibytes. The limit is not sustainable as the Gas Limit rises, since block receipts grow with transaction count. The computational threshold for exceeding the ten mebibytes according to the EIP text is 83 million Gas; the practical threshold documented in Erigon tests of January 2026 already at roughly 75 million Gas.¹²² Anyone re-synchronizing historical blocks from the network can no longer transfer the associated receipts in a single message, causing synchronization to fail at a pure transmission boundary. EIP-7975 resolves the risk by allowing a node to retrieve the receipt list of a block in multiple sub-requests — for example, the first hundred receipts in one request and the next hundred in a separate one — at which point the wire protocol reassembles the sub-transmissions into a complete receipt list. With this hardening, the scaling capacity from 5.2 becomes genuinely enforceable in the RPC path — meaning Gas thresholds above today’s 60 million. Otherwise it would collapse at a transmission bottleneck long before the hardware reduction from 5.3-B takes effect.

Available, but not Integrated

The Trustless RPC Architecture is technically available today. Its effect on the real trust load depends on adoption by wallets and frontends, actors the protocol cannot compel. As of February 2026, none of the three market-dominant wallet solutions — neither MetaMask, Trust Wallet, nor Ledger — integrates Helios as the default for trustless verification.¹²³ The infrastructure is available. Integration into end-user software is outstanding. The diagnosis follows a pattern already seen in the Hyperscaler concentration in 5.3-B. Both phenomena affect operational layers above the protocol. The protocol can facilitate them but cannot dictate how they are populated. They differ in their subject matter. The Hyperscaler concentration concerns the choice of operator infrastructure by validator operators; the RPC provider diagnosis concerns the choice of frontend integration by wallet and dApp developers.

With the distribution of the trust question across three out-of-protocol components, and the resolution of the scaling question through wire protocol hardening, the verification architecture of the scaled network rests entirely on cryptography at the endpoint device. The cryptographic loadbearing layer of Helios in turn relies on the BLS signatures of the Sync Committee, whose security rests on the same ECDLP that was identified in 5.3-A as non-quantum-resistant for threshold for exceeding the ten-mebibyte limit per devp2p message lies, per EIP text, at 83 million Gas; the practical threshold documented in Erigon implementation tests from January 2026 is already approximately 75 million Gas. eth/69 was deployed as a networking update for Fusaka (December 2025). Eth/70 is linked to Glamsterdam (H2 2026 probable). Sources: ethereum/EIPs repository, EIP-7975 specification; erigontech/erigon issue January 2026 on receipt sizes above 75 million Gas.

the IPA commitments of Verkle Trees.¹²⁴ The verification architecture of Stateless Clients and the cryptographic foundation from 5.3-A thus share the same assumption and face the same migration requirement. 5.3-D unfolds the post-quantum roadmap as a migration that concerns both pillars of the architecture built so far.

The Post-Quantum Migration of Verification

The preceding sections have shown how a block can be verified on ordinary consumer hardware — on a phone or laptop — without local state and without one’s own re-execution. This verification is carried by the signatures and commitments the block contains, whose authenticity the verifier recomputes. Today’s signatures rely on elliptic curve cryptography, whose security rests on the discrete logarithm problem. The private key allows the corresponding public value to be computed in fractions of a second, while the reverse computation becomes exponentially more expensive for classical computers with each additional digit of the key. The security of every signature protecting a block today rests on the asymmetry between easy computation and practically impossible inversion.

A sufficiently large quantum computer shifts the boundary at which inversion becomes impossible. Shor’s algorithm breaks the ECDLP in polynomial time (cf. Section 5.3-A). Against growing classical computing power, a longer key has so far sufficed, but against a polynomial runtime this measure fails, because doubling the key length only moderately increases the attacker’s effort. The quantum computer thereby invalidates the very assumption on which the security of these procedures rests, and the break reaches beyond any single one of them.

Not every form of cryptography rests on such an algebraic structure. A hash function conceals no solvable problem. Its security lies solely in that an attacker would have to try all possible inputs. Grover’s algorithm makes this search faster for a quantum computer, but it remains a search — the computer continues searching rather than computing the answer. A faster search can be countered by enlarging the search space and extending the output of the hash function. This is precisely the difference from Shor’s attack on elliptic curves, which computes the answer directly and therefore cannot be countered by any larger search space.¹²⁵ The target state of verification therefore replaces the vulnerable procedures with hash-based cryptography. The late roadmap treats resistance as a design principle and introduces it under the name Lean Ethereum (Section 5.1). For the verification layer that Section 5.3 has built upon the restructured data structure and the Trustless RPC Architecture, the transition poses a twofold question. What remains to be examined is whether the architecture remains cryptographically loadbearing under it, and what a delayed migration would entail.

Four Vulnerability Classes

The threat extends beyond verification, and the roadmap divides it into four vulnerability classes, each affecting a different primitive at a different location in the protocol. The BLS signatures of consensus are replaced by hash-based signatures with STARK aggregation, the substance of which Section 5.5 develops. Equally affected are the KZG commitments of data availability, which follow a separate migration path with an unresolved downstream problem addressed in Section 5.2-D. The ECDSA signatures with which every account signs its transactions today transition to hash-based procedures via an opt-in vehicle. Section 5.3-E unfolds the mechanics. The fourth class, the proofs of the application layer, rests on the aggregation mechanics that recurs below as a hinge. The map shows a crosscutting phenomenon, whose sections each bear one class.¹²⁶

Of the four classes, verification is most heavily exposed, because it has purchased its trustlessness at the cost of two efficiency gains, both of which rest on the vulnerable class. The first is the compact Witness from 5.3-A, which compresses the proof path to the State Root into a short proof and makes the Stateless Client viable on consumer hardware. The second is the aggregated Sync Committee signature from 5.3-C, which allows Helios a single check against the entire committee rather than verifying each signature individually. Both rest on the same discrete logarithm — the Witness via the Inner Product Arguments of the Bandersnatch curve, the signature via the pairing property of BLS12-381. Precisely what makes the smartphone a verifier is thus the most quantum-vulnerable part of the architecture.¹²⁷

The hash-based alternative is robust against the quantum attack, but expensive for signatures. In place of BLS come the hash-based signatures of the leanXMSS line (RES), whose substance Section 5.5 unfolds. A single such signature unaggregated consumes more than sixty times the Gas of an ECDSA signature, and its storage requirement is orders of magnitude higher. If the protocol had to verify each signature individually once hash-based procedures move from the exception to the rule, these costs would burst the budget of a block.¹²⁸ This is where the aggregation mechanics from 5.3-A′ intervene as a hinge and render the expensive path affordable again. Aggregation combines the proofs (cf. Section 5.3-A′), so that the per-signature prohibitive costs in aggregate fall to a manageable share per block. The same mechanics that carries the proofs of the application layer thereby also makes the hash-based consensus signatures viable. The hash-based State Tree achieves its quantum resistance by its own route — the switch to Binary Trees — whose cost lies in the larger Witness and which no signature aggregation reduces. The mechanics are fully described in the design state but, for the verification of aggregated proofs, depend on a family of precompiles not yet activated by a hard fork.¹²⁹

Exposure Is Not Risk

Maximum exposure is not maximum risk, because what carries Ethereum through a delayed migration is the willingness of consensus to keep running without finality — not a cryptographic procedure. The Inactivity Leak, which enforces this willingness, is a mechanism proven on Mainnet for years: if the network can no longer reach finality, the non-participating validators gradually lose their stake until the remaining ones again constitute two thirds. The mechanism was designed for the case of validators going offline, and it accommodates the quantum case as well, without ever having been designed for it. If a procedure breaks before migration is complete, the chain continues producing blocks, and finality returns as soon as two thirds of the stake have migrated to the new scheme — an economic process without new cryptographic preconditions. The network thus loses the finality guarantee while the chain keeps running, in Buterin’s formulation ”keeps chugging along.”¹³⁰

The design state drastically compresses finality without abandoning the mechanism that secures the transition. Single-Slot Finality finalizes a block in the same slot in which it is proposed, but explicitly retains the Inactivity Leak.¹³¹ The consensus layer finds its end state in the Beam Chain, whose substance Section 5.5 develops and which lies beyond the current decade.¹³² The reform of the Leak for the migrated procedure belongs to this horizon, while the mechanism that secures the transition already stands on Mainnet in its current form.

The verification architecture of Section 5.3 thus rests on a cryptographic base that is exposed but not undefended. Witness and Sync Committee signature share the quantum fragility of their discretelog foundations, but their hash-based replacement becomes affordable through aggregation, and the loadbearing capacity of the transition lies in the end less in cryptography than in a consensus that keeps running without timely migration. What the account layer contributes to this picture — the programmable validation logic through which a user switches their authentication from ECDSA to a quantum-resistant procedure — is unfolded in the concluding section of 5.3.

Account Abstraction and the Migration of the User Signature

The preceding sections of this chapter have shown how the network verifies an entire block on cheap hardware, without central services, and even when a quantum computer breaks today’s cryptography. Each of these checks begins, however, one layer below, with the individual transaction, whose validity the protocol measures against the signature of the sending account. The final section of 5.3 turns to the lowest-level check — and thus to the user themselves, who maintains their account and signs their transactions. An account is today bound to a single secret, a private key that its owner must safeguard. Anyone sending a transaction proves ownership by signing it with the key, and the signing procedure, ECDSA, is the same for every account and firmly anchored in the protocol.

This rigidity carries a price borne by every user. If they lose the key, they lose the account and everything in it, with no possibility of recovery, since no one else can prove ownership. They cannot change their signing method, even if a more secure procedure were available, and they can only pay a transaction’s fee in the network’s own currency. The account is bound to a single key and a single procedure, and the fixed binding is the real barrier to broad use.

Account Abstraction dissolves the binding. It removes from the protocol the prescription of how an account validates a transaction, and gives it to the account itself, making the validation rule freely programmable. Everything else rests on this single shift in the protocol: the wallets and applications built on top can unlock an account with a fingerprint, recover it after loss, or migrate its signature to a quantum-secure procedure. How far programmability changes participation in Ethereum for the ordinary user, and where the gained ease carries its own price, is the question this section addresses.

The Device Becomes the Wallet

For the ordinary user, participation in the target state begins with a gesture they have long known from their phone. They unlock their account and confirm a transaction via fingerprint or passkey — the same procedure their device already uses to secure logins without a password, and whose key never leaves the device’s secure element. In place of the character string the account holder previously had to write down and safeguard for years — and whose loss was irreversible — comes an authentication the user already commands from everyday interaction with their device. The account demands no new knowledge about keys and custody, and fits into a handling that requires no further explanation. The device they carry anyway thus becomes the wallet, and the separate installation of specialized software that currently stands between the user and the network is eliminated. The first contact with Ethereum no longer presupposes that the user has understood the logic of private keys and practiced their safekeeping.

If the user loses the device on which their key rests, their account remains accessible. They have previously bound it to multiple trusted parties of their choice — other individuals, their own secondary devices, or a specialized service — of which a predetermined majority suffices to jointly restore access, without any single one of them having sole control over the balance. They pay the fee for a transaction in any currency in their account, or not at all themselves, because the application they are using covers it on their behalf, so that acquiring the network’s currency as a prerequisite for first use is eliminated. Multiple actions that the protocol today treats as individually confirmed transactions — such as approving an amount and then using it — are batched by their account into a single, atomic confirmation whose parts either all succeed or all fail. Once they have granted an application a narrowly defined authorization — for instance for recurring payments within a limit they set — their account acts within those bounds thenceforth, without each individual action requiring renewed confirmation. The sum of these conveniences yields a participation that, in its handling, approaches familiar services of the open internet, without adopting their centralized custody.

Each of the conveniences rests on the single shift the protocol makes, yet emerges only on the layer above it. The protocol relinquishes the fixed prescription that an account validates its transaction solely via an ECDSA signature, and treats the account instead as a Smart Contract whose logic for checking validity lies in its own code. Before executing a transaction from this account, the protocol hands it to the account’s validation function, which decides according to freely chosen logic whether the accompanying data authorize the transaction. This data no longer needs to be an ECDSA signature. The account’s code can verify a signature generated via fingerprint, require the collaboration of multiple keys for recovery, or charge the fee to a third party — and which rules apply is determined solely by the account, not the protocol. What the user perceives as the experience is therefore shaped by the wallets and applications that write and maintain the code for them, while the protocol alone guarantees the freedom within which they do so. The boundary between what Ethereum itself delivers and what the layer above makes of it runs exactly at that point: the protocol provides programmable validation, and the wallet turns that into the account operable by the user.¹³³

The Price of Ease

The gained ease carries its price at the same seam at which it arises. Binding recovery to trusted parties provides security against loss and simultaneously creates a dependency on their availability and integrity, whose collaboration is precisely what carries access in a critical situation. The assumption of fees by a third party requires their continued willingness. Managing the account through a particular application relies on its validation code having been written correctly and kept maintained. The convenience thus shifts part of what the user is solely responsible for in the current state onto providers whose selection the user makes themselves but whose behavior they subsequently have only limited ability to control. How far the low entry barrier ultimately holds depends on whether this layer reliably conceals the complexity it introduces — and that part of the answer lies outside what the protocol itself can guarantee.¹³⁴

The Voluntary Migration of the Signature

The same programmable validation that makes the account easier to manage permits it a further and more significant step: the switch of the procedure by which it forms its signature. The ECDSA signature to which every account is today bound rests on that elliptic curve cryptography whose security a sufficiently large quantum computer would break, making it the single largest quantum vulnerability directly affecting the user’s own assets. Via a dedicated transaction format, the Validation Frames, an existing account can migrate its signature to a quantum-secure procedure — for example a hashor lattice-based signature, whose only materially relevant property here is its significantly larger key.¹³⁵ The protocol does not prohibit the old signature. It places the new one alongside it as a voluntary option, so that each account chooses the timing of its migration itself. The per-signature initially prohibitive costs of the quantum-secure procedure remain affordable solely through the aggregation mechanics from 5.3-A′, which combines many such signatures into a single proof and reduces their verification overhead in aggregate to a small share per block.¹³⁶ The voluntary nature of this migration is the same one that keeps access low-threshold from the outset, because the account here too determines for itself which validation logic it carries.

Section 5.3 closes the arc from the verification of an entire block on ordinary hardware to the lowest-level check at which the protocol measures the signature of an individual account, and it shows the same movement at every level. The restructured data structure reduced the proof required for verification, and the unburdened hardware brought this verification onto the device of the ordinary user. The Trustless RPC Architecture freed it from centralized data services; the post-quantum migration secured its cryptographic foundation against the quantum transition. The lowest of the checks, that of the user signature, the programmable validation finally placed in the hands of the user themselves. At every level the protocol guarantees a loadbearing and quantum-safely migratable foundation, while usefulness for the user only arises on the layer above, which makes the foundation usable for people.

The voluntary migration of the user signature with which the section has closed carries, however, a consequence that reaches beyond verification. A quantum-secure key such as that of an ML-DSA signature is orders of magnitude larger than today’s ECDSA key, and every account that adopts it deposits the larger key permanently in the network’s state.¹³⁷ If many accounts migrate, the larger keys aggregate into a perceptible expansion of the State that no signature aggregation reduces — because aggregation reduces the verification overhead of signatures, not the permanently stored volume of data. This very expansion of state, which the migration of verification generates as its side effect, is the subject of the following section.

5.4 State and Storage Persistence

Why State Is Different

The expansion of state to which the migration of the user signature pointed at the end of the preceding section is only the most recent pressure on a resource whose difficulty runs deeper than any individual load upon it. The structural finding formulated in 5.2-D — Execution has a breakthrough mechanism, Data has one, State has none — reveals a second level of asymmetry: the nature of the resource itself.¹³⁸ Execution and Data can be delegated: the zkEVM shifts the verification load onto a proof, PeerDAS shifts data availability onto a sampling procedure (cf. Sections 5.2 and 5.2-D). Both mechanisms allow individual nodes to perform only a fraction of the total work while still verifying completely. State does not permit this delegation. A Builder seeking to produce a valid block must hold the complete state — every account balance, every storage slot, every contract bytecode. A lower Gas Limit reduces individual blocks. The accumulated State is unaffected by this. Buterin puts this asymmetry in a formula: for Execution there is the zkEVM, for Data there is PeerDAS, for State there is no comparable instrument.¹³⁹

Two bottlenecks limit State scaling, and only one is in principle solvable. The short-term bottleneck lies in database efficiency: today’s client databases are not designed for multi-terabyte states, and every State write operation requires logarithmically growing tree updates.¹⁴⁰ New database designs and Block Access Lists can alleviate this bottleneck. The long-term bottleneck eludes this kind of technical solution. Synchronizing a State of several terabytes requires, even at perfect bandwidth efficiency, significant time, because the entire State Tree must be traversed and verified. With every doubling of State size, the number of actors willing and technically able to hold the complete State falls approximately to half. No database design can dissolve this relationship as long as a single Builder must hold the entire State locally.

This synchronization limit has direct consequences for the decentralization of block building. If only operators with server hardware can synchronize the

State, the circle of Block Builders narrows. This narrowing strikes exactly the role of the Block Builder that the target state anchors in the protocol through the separation of Proposer and Builder. The scaling hierarchy thereby reveals an asymmetry that places the decentralization assumptions of the scaling path above 500 million Gas under qualification.

What the State Consists Of

Ethereum’s State comprises as of Q1 2026 approximately 430 GiB, but what is decisive for the building question is the composition of this volume.¹⁴¹ 81.7 percent falls on Contract Storage, with ERC-20 token balances at 27.2 percent and ERC-721 data at 21.6 percent forming the largest individual categories.¹⁴² The overwhelming part of this State is not actively used: approximately 80 percent has been untouched for more than a year. 63 percent of all storage slots were written only once.¹⁴³ More than half of all contracts have no storage slots at all yet still occupy space in the State Tree. The protocol makes no distinction between active and inactive State: both occupy the same storage, require the same synchronization, and generate the same holding costs for every Builder. A Builder seeking to produce a valid block synchronizes the entire State, including the 80 percent that no one has accessed in years. At a constant Gas Limit of 60 million, the State grows by approximately 100 to 125 GiB per year, yielding a volume of approximately 830 to 930 GiB by 2030.¹⁴⁴ This remains within the range of commercially available 2 TB SSDs. The critical threshold, however, comes earlier: empirical stress tests by the Bloatnet initiative identify a performance cliff at approximately 650 GiB, at which State access times increase by 40 percent and sync times extend exponentially.¹⁴⁵ According to the scaling model of Maria Silva, this threshold is exceeded at a constant Gas Limit already in mid-2027; according to a linear extrapolation of the actual growth rate, around the turn of 2027/28. The roadmap does not foresee constancy.

The Gas Limit path presented in 5.2 transforms the calculation fundamentally. The exponential Gas Limit path under EIP-9698 would, with continuous validator voting, drive the limit to 500 million by mid-2027. By mid-2029 it would rise to five billion. Operationally, the actual thresholds depend on feature maturity and client benchmarks, so the timeline can shift by one to two years.¹⁴⁶ The correlation between Gas Limit and State growth is not linear: a historically observed correction factor of approximately 1.5 dampens the effect, because not every additional unit of Gas flows into State write operations.¹⁴⁷ Even with this dampening, the cumulative State reaches approximately 2.7 to 7.0 TB by 2030 without countermeasures. Already in 2028, in the conservative estimate, it exceeds one terabyte — in the aggressive estimate, nearly two.¹⁴⁸ 2 TB SSDs are no longer sufficient for Block Builders from that point on. Block Builders would need server infrastructure with 8 to 16 TB, of the kind common in data centers today and absent from the home offices of independent Block Builders.

A differentiated State model introducing new, more restrictive State types while leaving existing State untouched could limit permanent State to 1.2 to 1.5 TB.¹⁴⁹ Before the path there lies a dead end that must first be understood.

Silva’s scaling model (ethresear.ch/t/23476, November 2025) projects that this threshold will be exceeded by mid-2027 in all three Gas limit scenarios (conservative 686 GiB, base 859 GiB, aggressive 1,080 GiB).

History as a Resolved Contrast

History shows, in contrast to State, what a resolved storage problem looks like in practice. History Expiry under EIP-4444 (cf. Section 5.3-C) enables all five Execution Clients to delete historical blocks, transactions, and receipts after a defined period.¹⁵⁰ The savings amount to 300 to 500 GB per node, giving Full Nodes on 2 TB disks room to spare again.¹⁵¹ Before pruning they required over a terabyte. Archive Nodes in the Geth implementation reached 15 to 20 TB.¹⁵² The Portal Network archives the deleted data in a decentralized manner across three independent clients, an architecture described in 5.3-C as a building block of the trustless verification infrastructure.¹⁵³ Those who need historical data retrieve it from the network. Rolling Window Expiry as the next phase extends this model to ongoing pruning and is anchored in the governance process.¹⁵⁴

The contrast between History and State sharpens the finding for the overall architecture. History could be delegated: historical data can be pruned and retrieved from the network when needed, because no running process needs to hold it permanently. State is the exact opposite — it is needed at every block, by every Builder, in its entirety. The only storage problem Ethereum has so far structurally resolved was not a State problem. A direct attempt at solving State did exist: State Expiry was intended to let unused State lapse after a defined period. The attempt failed at a fundamental technical obstacle.

State Expiry and Tiered State

The fundamental obstacle lies in the requirement for non-existence proofs.¹⁵⁵ When a user creates new State — at an address or a storage slot — the protocol must verify that nothing ever existed at that location in Ethereum’s entire history, not only in the current period. Without State Expiry, this check is trivial: what is not in the current State Tree does not exist. As soon as the protocol allows State to expire, this check loses its foundation. A slot that appears empty could contain expired State that would be reactivatable at any time. Distinguishing between ”never occupied” and ”once occupied, then expired” requires a historical proof that the protocol cannot produce efficiently.

For accounts, a partial solution approach exists: CREATE3 would bind addresses to creation periods, so that an address can demonstrably only exist from year N onwards.¹⁵⁶ For storage slots, there is no comparable safeguard: an ERC-20 balance for Account X is stored under keccak256(…, X), a hash that is opaque to the protocol.¹⁵⁷ The protocol sees a slot. It does not see that the slot represents a token balance belonging to a concrete user. State Expiry for storage slots is therefore not implementable in a backward-compatible manner without completely rewriting ERC-20 logic. All existing token contracts — whose balances together account for 27.2 percent of the State — must be migrated.¹⁵⁸

In September 2025, Buterin drew the consequence: State Expiry should be abandoned in favor of Partial State Nodes, which would be functionally similar, require no Consensus Layer changes, and be considerably more flexible.¹⁵⁹ The Ethereum Foundation kept the conceptual option open in December 2025, but a workstream, team, and discussion point in the All Core Developers Calls are missing.¹⁶⁰ State Expiry is de facto abandoned.

Tiered State: The Reversed Lever

The failure of State Expiry explains why the only remaining approach takes a fundamentally different path. State Expiry was meant to automatically remove unused State from the active dataset. This proved impossible precisely as long as the protocol cannot distinguish between active and expirable State. Tiered State (RES, ethresear.ch post February 2026) starts at the opposite point: existing State remains entirely untouched. Instead, new, cheaper but more restrictive State types are introduced to channel future growth.¹⁴⁹

The architecture opts for two extremes rather than a middle path and places three State types side by side. Permanent State encompasses accounts, core contracts, and all data that must be available completely and without additional retrieval costs at every block. Temporary Storage is reset to zero at the beginning of each period, intended for short-lived data with a monthly reset cycle. UTXOs drive this principle to the extreme: their expiry period is zero — they expire immediately upon consumption.¹⁶¹ Existing contract code, existing balances, existing DeFi positions remain in the permanent tier. The growth limitation arises through the incentive structure: new applications choose the more restrictive types once permanent persistence is not required. No deletion of existing data takes place.

Server Hardware 8–16 TB SSD

Consumer Hardware 2–4 TB SSD

16 TB

8

4

2

1 TB

500 GB

430 GiB, Q1 2026

Consumer Threshold Crossed

B Pivot without State Solution EIP-9698 Path 2.7–7.0 TB

C Pivot with Tiered State 1.2–1.5 TB permanent

A Without Pivot Gas Limit 60M 0.6–0.8 TB

2026

2027

2028

2029

2030

The largest State consumers would be the first candidates for the more restrictive tiers. ERC-20 token balances claim 27.2 percent of the current State, ERC-721 data a further 21.6 percent.¹⁶² Both could be assigned to the UTXO or Temporary tier, as could individual DeFi positions.

The question ”in which tier do I store this data?” does not exist in today’s Ethereum. It would become the central design decision for every new contract, comparable to the choice between calldata and Blob storage that Proto-Danksharding introduced for L2 operators. The calldata-Blob decision concerned a handful of Rollup teams. The tier decision would concern every Smart Contract developer in the ecosystem. No protocol upgrade can compel this migration: it requires the voluntary adoption of new token standards, the adaptation of existing toolchains, and the coordination of an ecosystem that has settled on permanent State as its default assumption.

A Pricing Model That Does Not Exist

Even if the ecosystem could manage this coordination, Tiered State would face unresolved technical dependencies. The multi-tier system presupposes an efficient State Tree structure, such as provided by Verkle Trees (EIP-6800, RES, Stagnant) or Binary Trees (EIP-9257, RES).¹⁶³ This State separation alone is insufficient: the system requires separate Gas dimensions for different tiers so that the economic incentives produce the desired allocation. Multidimensional Gas (EIP-8011, RES/DFI Glamsterdam) and Inter-Block Temporal Locality Gas Discounts (EIP-8057, RES/DFI Glamsterdam) are the technical prerequisites for this price differentiation, analogous to the Blob pricing template established by EIP-4844 for data blobs.¹⁶⁴ Blob pricing builds on a functioning EIP and a deployed mechanism. For State tiers, the pricing model exists so far only conceptually. EIP draft, reference implementation, and simulation of the market dynamics between tiers are missing. Tiered State presupposes Multidimensional Gas. Multidimensional Gas presupposes a specified pricing model. The pricing model does not exist.

A smaller precursor to this pyramid underscores the distance between concept and implementation. EIP-8032 (Size-Based Storage Pricing, RES/DFI Glamsterdam) would have coupled storage costs to actual storage size, delivering a first building block of the storage repricing architecture that Tiered State presupposes.¹⁶⁵ The EIP was scheduled for the Glamsterdam inclusion list and was downgraded via EIP-7773. The argumentative position is thus clear: the Tiered State architecture requires multiple repricings, and even the smallest intended building block did not reach the first fork cycle.

The ethresear.ch discussion from February 2026 shows that no consensus exists even within the research community.¹⁶⁶ The most conservative objection concerns sequencing: user MicahZoltu in the Ethereum Magicians forum demands that State expansion be allowed only once at least one user-operated RPC node can serve the complete State.¹⁶⁷ This condition is not met today, and State expansion itself would additionally hinder its fulfillment. Even if the sequencing were clarified, an architectural trade-off would remain: different tiers generate different access patterns, from which inferences about the use of a contract can be drawn. User igor53627 identifies therein a privacy risk that does not exist in current Ethereum.¹⁶⁸ The most radical counterargument questions the premise itself: user kladkogex argues that parallelization over node clusters would trivialize the State problem and that a multi-tier system therefore introduces unnecessary complexity.¹⁶⁹

These objections meet a proposal at the earliest conceivable stage of development. Tiered State is an ethresear.ch post and is neither listed as an EIP draft nor on the agenda of the All Core Developers Calls. Research team, advocates in the client ecosystem, and a fork timeline are missing. Of the features addressing a core resource, none is at a comparably early stage. Tiered State is simultaneously the only feature that offers any prospect of a long-term answer to the scaling-hierarchy asymmetry described in 5.4-A.

The Timing Contradiction

Solution and problem thus move on fundamentally different timescales. The Gas Limit path under EIP-9698 drives the State from 2027 into territory where a management solution becomes structurally necessary. The only proposed solution has neither a specification nor a timeline. The Gas Limit, however, has both. The Gas Limit is governed by validator voting, a decentralized voting process that can converge faster than the coordinated development of complex protocol changes. The most recent increase illustrates this speed differential: the Gas Limit doubled within a year (cf. Section 5.1-A), while Fusaka with PeerDAS as its core feature required the same period for specification, implementation, and deployment.¹⁷⁰ The EIP-9698 path provides for an exponential increase that would push the limit past 500 million by 2028. Validator voting for that requires no new specification, no client implementation, and no coordinated hard-fork deployment. Tiered State requires all of this and has not begun any of these steps.

The consequence is a twelve-to-twenty-four-month window in which L1 capacity overtakes the infrastructure for sustainable use.¹⁷¹ Within the window, fragility increases: higher capacity is used, the State grows accordingly, but the mechanisms for differentiating and limiting this growth are absent. ML-DSA, the leading post-quantum signature candidate (RES), increases the pressure further: its signatures and public keys are several times larger than those of ECDSA.¹⁷² Where the data is stored in State — for instance in Smart Contract wallets under Native Account Abstraction — this increases the State pressure, which the post-quantum migration described in 5.3-D and 5.3-E additionally intensifies. The window closes only once the prerequisites are delivered. The pre-requisite chain from 5.4-B remains unchanged, alongside the voluntary adoption of new token standards by the entire ecosystem.

The temporary centralization within the window affects precisely the role that the target state anchors in the protocol through the separation of Proposer and Builder. When the State grows to two to three terabytes before a management solution takes effect, only operators with server infrastructure can synchronize the complete State.¹⁷³ The circle of Block Builders narrows at the very moment the protocol intends to open it through ePBS. The verification layer, decoupled from State growth through Stateless Clients and zkEVM, is unaffected. ePBS accepts professional building as a deliberate trade-off and protects decentralization via the Proposer set and FOCIL (EIP-7805, SFI Hegotá Head-liner). The timing contradiction thus concerns censorship resistance: a Builder market with two to three dominant actors raises the question of whether the inclusion lists that FOCIL secures on the Proposer side can structurally with-stand the building bottleneck.

SSZ as Incremental Contrast

The SSZ migration (EIP-6404, EIP-6466, EIP-6493, EIP-7807, all DRAFT) shows, by contrast, that protocol simplification at the State representation layer is achievable when the change proceeds incrementally.¹⁷⁴ SSZ replaces the informally specified RLP serialization with a typed, Merkle-provable format, thereby improving interoperability between the Consensus Layer and the Execution Layer. The Consensus Layer has used SSZ since December 2020. The EL migration is a multi-stage project with a time horizon of 2025 to 2026 and beyond.¹⁷⁵ SSZ does not resolve State growth. It reduces the complexity of State representation, eliminates RLP parsing as a source of error, and enables direct state proofs. The simplification is making progress because it is backward-compatible and does not alter any existing developer experience.

The contrast with Tiered State sharpens the finding. Tiered State is neither incremental nor backward-compatible in the same sense. It introduces a new design decision that every Smart Contract developer would have to make for every new contract. Added to this is the open prerequisite chain from 5.4-B. Ethereum can simplify State. Scaling State is a qualitatively different challenge that goes beyond serialization formats and intervenes in the core logic of the ecosystem.

The interplay of Tiered State, Multidimensional Gas, and differentiated persistence levels would for the first time make it possible to couple State costs to actual usage patterns: permanent data at higher cost, temporary at lower, consumable at the cheapest rate. The economic logic would correspond to the Blob pricing template (cf. Section 5.4-B), extended to the resource the protocol has until now treated without differentiation. This interplay is the most fragile of all system combinations in Chapter 5, because its central component stands at the beginning of its specification. The fragility lies in the distance between design and implementation.

The prospect of Tiered State thus lies in giving State the architectural answer that makes the growth of a core resource sustainably loadbearing in the long term — an answer already delivered for History through pruning. As long as this answer is absent, State remains the dimension in which the roadmap cannot demonstrate a reliable solution.

Capacity scales, verification is democratized. The neutrality of the system under this expanded capability — in particular censorship resistance in concentrated block building — is not secured: whether the protocol guarantees against censorship and discrimination hold when economic incentives shift is answered by Section 5.5. The open flank of State enters that analysis. A system that expands its capacity faster than its protection mechanisms must actively secure neutrality.

5.5 Neutrality and Fairness

The Three-Pillar Censorship Resistance System

Up to this point the chapter has examined the base layer from three sides, each of which has exposed a part of the target state. Scaling has shown that the layer can deliver far more than it does today, because it transforms the load of execution into a proof and replaces the holding of all data with a sampling procedure, so that a single block carries a multiple of its current volume (Section 5.2). Verification has shown that this expanded layer remains verifiable by everyone — on ordinary hardware, without central services, down to the signature of the individual account (Section 5.3). And State management has exposed the flip side: State is the one resource without a breakthrough mechanism, the bottleneck at which block production narrows to a few professional Builders, while verification distributes across thousands of ordinary devices (Section 5.4). So what remains at the end is a system that is more capable and at the same time generally verifiable, but whose production bundles in few hands. Up to this point the question was what the layer can do. Now the question is what it permits its most powerful actors. This section examines the neutrality and the fairness of the concentrated layer: its neutrality by the standard of whether a single powerful producer can still exclude a valid transaction or displace an already confirmed block retroactively from the chain. Its fairness by the standard of whether they can extract the value of block building exclusively for themselves. The answer of the target state shifts neutrality from the integrity of the operators to the rules of the protocol, which demands from them what it previously entrusted to them. The most fundamental of the three dangers against which the protocol enforces neutrality in this way is the exclusion of a valid transaction.

The exclusion meets a boundary that begins where verification ends, because it shifts the question of neutrality from the correctness of a block to its completeness. The cheap verification that the preceding part of the chapter brought to the device of the ordinary user reliably catches the invalid block, because thousands of validators recompute it and immediately reject any error in the state transition. It does not catch, however, the valid block that simply omits a particular address — because a fully correct block can bypass a disfavored transaction without ever violating a rule the protocol could verify. Verification ensures that a block contains nothing false, and it says nothing about whether it includes everything valid. What forces the inclusion of a valid transaction against the producer’s discretion is the layer this section describes. It stands alongside verified correctness as its necessary complement, because a concentrated producer could exploit the gap between the two that the protocol currently leaves open.

Three Points of Censorship

A valid transaction can be excluded from a block at three points, and the target state closes each of them through its own mechanism. The first point lies before the chain, at the off-chain relay through which the overwhelming majority of blocks run today, and at which transactions can be filtered according to external directives such as OFAC lists, even though the chain itself knows no such filtering. Eliminating the relay is accomplished by the Enshrined Proposer-Builder Separation, which lets the Builder direct its bids immediately and without a trusted intermediary to the chain, thereby removing the single point at which filtering outside the protocol can apply at all. Were the relay to remain, every protocol-anchored inclusion rule would be rendered ineffective, because its effect could be circumvented at the intermediary — so the separation of Proposer and Builder, scheduled for the earlier of the two upcoming forks, is less a building block of neutrality than its precondition.¹⁷⁶ The two remaining points lie within the protocol, at the Proposer’s choice of block content and at the visibility of transaction content, and each demands its own natively anchored mechanism, which the following paragraphs develop.

The second point concerns the choice the Proposer makes over the content of their block, and it is closed by a forced inclusion list that prescribes which transactions they must include. This coercion is provided by the Fork-choice Enforced Inclusion Lists (FOCIL, EIP-7805), in which a committee of 16 randomly chosen validator-Includers, together with the Block Proposer, compiles in every slot — based on their own mempool view — a list of transactions to be included, with each list capped at 8 KiB. The guarantee rests on a 1-of-N assumption: a single honest Includer among the 16 suffices for an unjustly omitted transaction to make it onto the list and for the Proposer to be required to include it. Enforcement of the list is carried out by the Attesters, who withhold their vote from a block that excludes valid list transactions without the reason of insufficient space, so that disregarding the list costs the block its confirmation. The maximum delay with which an initially bypassed transaction nevertheless enters the chain falls from an empirical average of approximately 29 to 12 to 24 seconds. The strength of the 1-of-N construction is evident under regulatory pressure: even if that pressure compelled the majority of Builders to conform to a blocklist, a single non-conforming Includer forces the inclusion of the affected transaction. Among the three mechanisms, forced inclusion is the most mature, scheduled as the sole set Consensus Headliner for the upcoming Hegotá fork.¹⁷⁷ A formal safeguard of this forced inclusion against retroactive reorgs is still outstanding, so its protection for now rests on the general finality guarantees of the protocol and not on a rule specifically set for it.¹⁷⁸ How far a confirmed block can be displaced by such a reorg at all depends on Single-Slot Finality, to which this section turns later.

The third point is the visibility of the transaction content itself, because what the Builder can read before inclusion it can also deliberately bypass — and this information remains open once the first two mechanisms have taken effect. Visibility is addressed by a procedure that keeps the content of every transaction encrypted until its inclusion in the block. The Builder thus decides on inclusion without knowing the content, and cannot censor what it cannot see. It is carried forward under the name Universal Enshrined Encrypted Mempool (EIP-8105). Only after the order of transactions is fixed is their content decrypted, so that neither the Builder can make a content-based selection nor an observer can anticipate an order. The encryption closes a second gap, because with the concealed content, frontrunning and sandwich attacks also disappear — both of which are made possible today by reading the public mempool in advance. The draft from the Shutter environment and the approach developed under the name LUCID by EF research converge technically on the same Threshold Encryption. Among the three mechanisms, the encrypted mempool is the least mature, proposed for the Hegotá fork but without a fixed place in it, having failed to prevail against forced inclusion as the Headliner proposal.¹⁷⁹

The guarantee of forced inclusion rests on precisely the decentrality that Section 5.5-C marks as unsecured, because the 1-of-N assumption and the enforcing Attesters hold only as long as the Validator set remains sufficiently diverse. With the largest staker holding approximately 23 percent, the assumption holds comfortably — and how durably the precondition holds in the long run is examined in that section.¹⁸⁰ How far forced inclusion goes beyond earlier attempts is shown by the contrast with the Original Inclusion Lists (EIP-7547), the first and now discarded attempt at forced inclusion, whose rigid model lacked precisely the flexibility that the later 1-of-N committee provides.¹⁸¹

What the target state places alongside verified correctness is, with the three mechanisms, a forced completeness that the protocol demands from the producer where today it depends on their good conduct. It answers the first of the three dangers arising from concentrated production, while the extraction of value and the retroactive displacement of already confirmed blocks are reserved for two later sections.

Value Extraction and the Decoupling of Validator Economics

The same concentrated producer whose censorship power the three mechanisms of the preceding section have curtailed continues to earn from the blocks it must now include a profit that none of these mechanisms captures. Forced inclusion prescribes which transactions enter the block, and leaves open the order in which the producer arranges them, even though the largest part of its profit comes precisely from the ordering. This section answers the question that begins at the open point: whether the producer can use the profit so gained to couple the economics of the validators to its concentration.

The profit in question arises solely from the selection and ordering of transactions, and the ecosystem refers to it as MEV (cf. Chapter 4).¹⁸² As long as the profit accrues to the producer alone and grows with the volume of production, it proposal against FOCIL; the Shutter design (EIP-8105) and the LUCID approach of EF research have technically converged (threshold encryption, including BLS threshold).

connects the concentration of building with an economic incentive that acts on the validators. The preceding section touched on the profit at one point, because the Encrypted Mempool deprived the Builder of the view of transaction content, and with the content-based selection, frontrunning was also eliminated. This section asks about its distribution: where it ends up after the build and whether its distribution binds the economics of the validators to the concentration of production.

The first answer of the target state is that building blocks does not become fair, because the incentives that bring a few professional Builders to the top of production persist and the protocol resolves none of them. A single Builder provides in the baseline state approximately half of all blocks, and the production market, by conventional concentration measures, is among the most highly concentrated of all.¹⁸³ Three structural causes keep this concentration stable, and none lies within reach of any single protocol rule, because they follow from the professional, vertically integrated, and multi-domain character of the market.

The Source of Builder Concentration

The first cause is the latency with which a Builder submits its bid in the auction. Builder competition runs as an auction within the fixed time window of a slot, in which bids are sharpened until the last moment, and the largest part of MEV comes from CEX-DEX arbitrage, whose price differential moves until the final instant. A Builder closer to the auction and trading infrastructure bids later and with more current prices and still arrives in time, while a distant Builder must bid earlier with stale valuations. The advantage is secured by lowlatency infrastructure colocated at the trading venue, whose costs lie in the six-figure US dollar range per month.

The second cause is cross-domain arbitrage between the base layer and Layer 2 networks. The same assets trade at different prices across these domains, and a Builder or sequencer active on multiple simultaneously can atomically extract both sides of the differential, while a Builder confined to one domain sees only one side. This coordination requires operator rights or privileged access on multiple networks and advantages the already vertically integrated actors who already dominate the base layer. Their returns grow superlinearly with the number of domains controlled, because an entire class of atomic opportunities only opens once an actor controls multiple domains simultaneously.

The third cause is exclusive order flow, the privately routed stream of transactions. Approximately 54 percent of block value stems from transactions that bypass the public mempool and go directly to a single Builder via private RPCs, available only to them. Their source — a wallet, a trading bot, or an aggregator — entrusts this flow exclusively to one Builder against a paid arrangement and simultaneously protects its users from frontrunning, because the transaction never becomes public. Access is self-reinforcing, because a larger private inflow generates higher block valuations, more frequent auction wins, and greater profit margins, which in turn attract further flow.¹⁸⁴

That production remains concentrated is not a goal the target state fails to achieve. The protocol treats concentrated block building as an accepted fact, because none of its measures attacks the three causes: ePBS eliminates trust in the relay and leaves the concentration incentives intact. Even the most prominent attempt to decentralize building nevertheless documents only its limit. The Builder network BuilderNet from the Flashbots environment lets multiple operators work together on a block without any of them seeing the others’ contributions, and has thereby achieved a market share of approximately 27 percent — but operates outside the protocol and eliminates none of the three causes.¹⁸⁵ The concentration becomes a problem only where the value extracted from building enters the economics of the validators and binds the broad mass of stakers to the advantage of the concentrated Builder. The target state interrupts this transition at precisely two points, at which it separates the Builder’s profit from the reward of the validators and returns its base amount to the commons.

Decoupling and Socialization

The first point is the decoupling, which separates the extracted value from the reward of the validator. In the baseline state, the randomly selected validator proposing a slot decides on the content of their block and simultaneously receives the value extracted from it, so that the value reaches the staker economy through them. The decoupling now separates the right to determine and propose the content of a block from the validator’s remaining duties and auctions it off to a dedicated market of buyers. The ecosystem refers to this separation as Attester-Proposer Separation (APS). It takes two forms, discussed as Execution Ticket and Execution Auction, which are alike in awarding the right to the highest bidder rather than allocating it to the randomly selected validator. Their goal is to protect the broadly distributed mass of validators against the centralizing effect of the extracted value, without intervening in the build itself. Because the extracted value thereafter remains with the buyer of the right and no longer flows through the validator, the validator receives after the build solely the regular consensus reward — and the advantage of the concentrated Builder no longer reaches the staker economy in either form. APS builds on the protocol-level separation of Proposer and Builder that ePBS (EIP-7732) anchors in consensus.¹⁸⁶

The second point is socialization, which returns the base amount of extracted value to the commons. The protocol burns the proceeds of the auction, thereby passing them on to no individual actor. It thus extends the fee burning in effect since 2021 under EIP-1559 to the extracted value.¹⁸⁷ Because the burned amount reduces the supply of ETH, it mathematically benefits every holder, while being withheld from the Proposer and the Builder. APS and MEV Burn interlock and do not compete: APS auctions the right to determine the block, and MEV Burn burns the proceeds of the auction.

The decoupling simultaneously eliminates an incentive that previously additionally favored concentration. In the baseline state, the Proposer’s reward grows with the extracted value, and this value grows with every additional second during which trading takes place. A Proposer therefore has reason to delay publishing their block in order to extract greater value. Such delay strategies — known in the ecosystem as Timing Games — shift the temporal dynamics of consensus in favor of actors with the greatest latency advantage.¹⁸⁸ Once the extracted value no longer flows through the Proposer, the reason for delay disappears and the economic cause is eliminated. The structural cause — the time window of the slot itself — is not eliminated until Single-Slot Finality, which a later section of 5.5 addresses.

What the target state achieves lies in the distribution of value and in the economics of the stakers, while production itself remains concentrated. The Builder continues to extract value, but can use it neither to harm the commons — whose share is burned — nor to make the validators dependent on its concentration — whose reward is separated from its advantage. The concentration of production remains a fact of the baseline state, but its effect on neutrality is interrupted at both transitions.

Both mechanisms stand differently than forced inclusion, which the preceding section carried. APS and MEV Burn are research projects without a fixed place in a named fork, supported by the EF Robust Incentives Group and the research around Justin Drake. They are thus the most immature of the responses the section assembles. They belong to the roadmap phase addressing systemic centralization risks, which the ecosystem refers to as ”The Scourge.” Their effect is therefore a direction with established mechanics and an open timeline.

The decoupling prevents production from passing its profit on to the staker economy, and does not reverse the concentration that already exists in the baseline state. The largest single staking provider holds approximately 23 percent of staked ETH, and whether this threshold holds durably is examined in the following section.¹⁸⁹ What MEV Burn touches beyond fairness is the security budget of the chain, because the burned value benefits the protocol rather than increasing individual actors’ rewards, which intervenes in the economic sustainability whose synthesis the same section provides. The target state thus answers the second of the three dangers arising from concentrated production, by separating its profit from the economics of the stakers and directing its base amount to the commons. The retroactive displacement of an already confirmed block, the last danger, remains reserved for the concluding section.

Staking Economics and the Limit of Distribution

The guarantees of the two preceding sections depend on an assumption neither has examined: the Validator set remains sufficiently diverse. Forced inclusion needs only a single honest Includer in the committee for this (Section 5.5-A), and the decoupling of rewards protects an existing distribution of stakers without creating it (Section 5.5-B). The preceding sections examined the concentration of production — the question of who builds the block. Now the question is the concentration of stake — who validates at all and how many providers hold the staked capital.

Two questions follow, which diverge in their assessment. The first is economic and concerns the lasting sustainability of staking, on which the affordable security of the network depends. The second concerns distribution and asks whether the protocol prevents control over consensus from concentrating in few hands. To the first question the protocol answers with a stable yes. To the second, it does not. The first part shows how the economics holds. The second, why distribution remains open.

Economically, the protocol above all must sustain the security budget — the reward to stakers that keeps the cost of acquiring an attack share higher than the gain from it. Its level is composed of three quantities: issuance, transaction fees, and burn. Issuance pays for security, fees supplement it, and burn maintains the value of the paid-out ETH through scarcity.

Of the three quantities, the protocol sets only issuance itself, and only for it is the future level open. Every newly created ETH distributes the existing supply across more units, devaluing those already held — which is why the protocol should create only as much as security requires. Under the current rule, however, the distributed quantity grows the more ETH is staked in total, so that emission can grow without limit. The reform discussed under the heading Minimum Viable Issuance changes the rule: once the staked share exceeds a target, the annual return per validator falls, and further stake loses its incentive.¹⁹⁰ The reform seeks the share that is high enough for security and low enough to keep emission small. Its status remains open, since research is still debating the right target. Added to this is the fact that the narrative of scarce, deflationary ETH — which the ecosystem calls Ultrasound Money — no longer held in 2024 (and sub-sequently 2025) when the declining burn rate allowed supply to grow again.¹⁹¹ The other two quantities — fees and burn — stand on firmer ground than issuance. On the fee side, Blob Fee Stabilization (EIP-7918) secures a minimum price for the data that Layer 2s deposit on Layer 1.¹⁹² It prevents Blob fees from falling toward zero and preserves the fee component for validators. On the burn side, the protocol already burns the base price of every transaction today, and in the target state additionally the MEV. MEV fluctuates heavily, since rare blocks with large liquidations or arbitrages yield several times that of an ordinary block. MEV Burn destroys it via the auction for block determination, so that no single block provides a Proposer with exceptional returns and validator rewards remain steady.¹⁹³ It counts here on the burn side of the budget. In Section 5.5-B it appears under fairness.

Returns exceed operating costs only with efficient validation, and here MaxEB (EIP-7251) takes effect, delivered since the Pectra upgrade in spring 2025. The upgrade raised the maximum Effective Balance of a validator from 32 to 2,048 ETH.¹⁹⁴ Large operators can since then consolidate thousands of smaller nodes into fewer larger ones, reducing their costs and steadying their returns. For the economics of staking, node consolidation counts as a stabilizing factor. What consequences the consolidation has for distribution is clarified in the second part.

rium issuance with a target stake ratio as a stationary state in which the security budget balances among stake, fees, and burn. The dispute over the correct target size is open; the ”Ultrasound Money” narrative around the deflationary ETH burned through burn no longer held in 2025, after the burn decreased as activity shifted to Layer 2 networks and supply grew again.

From the interplay of the three quantities follows a self-stabilizing state. The staking rate settles at a value at which issuance just covers security. Burn offsets issuance to the extent that the network need not buy its security at ever-higher expense. This is the basis for the high economic loadbearing capacity of the network. An attack on a third of the stake requires acquiring approximately 11.5 million ETH. The buying pressure of such a quantity would drive the price high enough to make the attack uneconomical.¹⁹⁵ The threshold holds even if the reform modestly reduces the staked share, because the price driven by acquisition counts more than the quantity to be purchased. Security is thus load-bear-ing, but its dollar value depends on the ETH price and usage volume and is not guaranteed by the protocol alone.

The Unresolved Concentration

Everything described so far stabilizes the economics of staking and does not touch its distribution. No mechanism in the roadmap reduces the share that a single provider holds of the staked capital. Every existing mechanism operates on the economics or the operation of validation, and none shifts the market shares of providers. The limit of the section becomes visible as soon as the mechanisms are individually examined for what they address.

A technological approach to risk mitigation is provided by Distributed Validator Technology (DVT). This decentralizes the operation of an individual validator by distributing its tasks across multiple physical machines and different operators. The Single Point of Failure is thereby eliminated: neither the failure of individual servers nor the loss of cryptographic keys endangers validation or leads to Slashing. Implementations of the technology are already deployed via protocols such as Obol and SSV Network, including within the market leader Lido. DVT does not, however, affect market-structural centralization. Since the technology merely distributes the technical infrastructure behind the validation keys, the percentage market share of the staking providers in total capital remains unaffected.

For network distribution, MaxEB unfolds a dynamic contrary to its economic benefit. While raising the maximum validation balance optimizes operational efficiency, it simultaneously promotes consolidation of nodes by large operators, which has a structurally centralizing effect. A shift in market shares is not to be expected from the modified emission rate either, as this only marginally reduces the incentive for dominant actors. Furthermore, the minimum threshold of 32 ETH remains untouched, as MaxEB solely reforms the upper limit of the effective balance. This economic entry barrier continues to block the growth of solo staking, which still shows a market share of under one percent of aggregated stake.

A direct limitation of market shares could be realized through a protocol-level upper limit (Staking Cap) that anchors the maximum share of a single provider at the protocol level. Although such a cap is discussed within the community, it constitutes neither a planned nor a decided measure in the current target state and is consequently not in the official roadmap.¹⁹⁶ Such a cap would directly intervene in free-market competition, which corresponds to a regulation with which the Ethereum protocol has deliberately left the market to itself for reasons of neutrality. Herein lies the actual deficit of network distribution, since the problem of centralization is one of regulatory policy. Since the only structurally effective countermeasure — in the form of a protocol-level maximum share — is not anchored in the governance rules of the protocol, Ethereum currently lacks the protocol-level tool to prevent a monopoly-like concentration of staking power. Furthermore, the approach of Rainbow Staking is still in the conceptual phase. The model aims to reactivate solo staking by dividing the validation system into two classes: capital-strong actors take on complex network security, while private small participants are involved as a control instance without expensive hardware requirements, which significantly lowers the financial and technical entry barrier.

This advancing market concentration pushes the protocol-side guiding principle of protocol neutrality to its conceptual limit. While the protocol can technically enforce certain behaviors — such as guaranteed inclusion of a transaction (Section 5.5-A) or the economic decoupling of rewards (Section 5.5-B) — it cannot stop the accumulation of market power by a shrinking number of staking providers. The technical measures thus protect the network from the acute misuse of existing power structures, but do not effect a structural redistribution of power. Beyond the internal capital allocation, there is also an external, geographical limit of neutrality, since approximately 39 percent of all nodes are located in the United States.¹⁹⁷ The causes of geographical clustering lie outside the protocol’s influence.

Precisely that decentralization which the protocol itself cannot actively bring about forms, however, the foundation for the security guarantees of the preceding sections. The mathematical assumption of forced transaction inclusion thus presupposes a sufficiently diverse participant network, while the decoupling mechanism protects an existing distribution but cannot artificially reproduce it. The conceptual neutrality of the entire protocol is thus based on a structural diversity of actors that is indispensably presupposed in the target state, but not guaranteed by the system itself.

The Price of Finality

Between the vote of the Attesters and the definitive confirmation by the protocol, approximately 13 minutes currently elapse — a period during which a block is considered confirmed but not yet irreversible. During this period there are two problems, which the preceding section resolved economically and referred to this section for technical resolution. The first problem is the retroactive displacement of an already confirmed block through a chain reorganization (Reorg). This is the third and final main danger arising from concentrated production. The second problem is the artificial delay of block publication (Timing Games). The economic incentive for this has been removed from the Proposer by the separation of Proposer and Builder, but the temporal possibility still exists. Both problems exploit the same tolerant temporal structure of the network, which makes delays and retroactive changes technically possible at all. The following section brings the topics together through Single-Slot Finality, since immediate, secondgrained block finalization removes the operational basis from both chain reorganizations and artificial publication delays.

The full mechanics of the delay — which Section 5.5-B merely named — belongs here. The value a Proposer extracts from the ordering of transactions grows with every second in the slot, as temporal shifts in market prices create additional arbitrage opportunities and enable further liquidations. A Proposer who publishes their block later extracts more MEV (these delay strategies, cf. Section 5.5-B). They reward actors with the greatest latency advantage, who bid late enough yet still arrive in time, and shift the temporal dynamics of consensus in favor of fewer operators.¹⁹⁸ The decoupling introduced with APS deprived the delay of its direct reward by separating the extracted value from the Proposer. It left, however, the slot’s discretionary window intact — within which the delay takes place — so that Timing Games merely shifted to the level of Builders. As long as the protocol permits a temporal tolerance within a slot, the structural cause for the emergence of Timing Games formally remains.

The risk of a chain reorganization (Reorg) exploits the same time window but operates at a different point. A block is considered confirmed as soon as the Attesters have voted for it. It becomes irreversible, however, only once the protocol finalizes it after two consecutive epochs (checkpoints). In the interim, a reorganization of the chain could theoretically displace the block and replace it with another. A market-dominant actor with a sufficiently large share of validation votes could thereby exchange an already confirmed block. In this way, a transaction could be retroactively removed from the chain even after it had just been included through the inclusion list (from Section 5.5-A). With the replacement of the block, the transaction it contained would also disappear. The complete inclusion of transactions that the first protection mechanism of this chapter was meant to enforce would remain unsecured against such retroactive displacement. The underlying separation of Proposer and Builder (ePBS) already binds the Builder to a firm commitment. Mechanisms such as Builder Staking and dedicated validator confirmations from the Payload Timeliness Committee (PTC) further deprive it of the ability to simply withhold a completed block. As a result, retroactive modification of the blockchain is limited to at most a single slot. This risk nevertheless persists as long as the first confirmation of a block and its irreversible finalization remain temporally separate in the protocol.

Single-Slot Finality as the Answer

Single-Slot Finality is the roadmap’s goal for fully closing the temporal gap between the first confirmation and the irreversible finality of a block. The concept promises, however, more than the currently favored design actually delivers. The research around Justin Drake, Buterin, and others currently places the practically achievable finalization at three slots, which is why the concept must be understood in substance as three-slot finality. Finalization within a single slot would require spreading and combining the attestations of the entire Validator set into a proof within a single interval — which exceeds the available time for propagation and aggregation. Three slots give the network this time and remain short enough to deny reorganizations and delays their room to maneuver. At the current tempo of twelve seconds per slot, the period between confirmation and finality falls from approximately 13–15 minutes to approximately 36 seconds. The accelerated finalization merely shortens the time until the security threshold is reached. It does not lower that threshold. Once finality is reached after 36 seconds, reversing the chain is economically just as expensive — and thus practically just as impossible — as in the current system. Independently, the time to first confirmation falls to a few seconds via so-called Fork-Choice Confirmations. Section 5.6-C develops the mechanics. Finalization on the short timescale of slots thus eliminates at a single point both the risk of retroactive chain reorganizations and the remaining technical cause of Timing Games.

At the level of the entire Validator set, finality requires one of the most profound architectural adaptations of the blockchain altogether. Currently, only a subgroup (Committee) of validators attests per slot. Single-Slot Finality (SSF) requires instead that the attestations of the entire Validator set be condensed into a verifiable proof within a few seconds. No current consensus layer is designed for this enormous load of signature aggregation. The roadmap provides for the redesign under the concept of Lean Consensus and locates the end state in the Beam Chain — corresponding to a complete redesign of the consensus layer whose implementation is a research state beyond 2029 without a fork deadline.¹⁹⁹ The raising of the maximum Effective Balance (MaxEB), which has been driving the consolidation of validator nodes since the Pectra upgrade, reduces the absolute number of validators and is thereby a direct functional prerequisite for aggregation. The efficient compression of the signatures of the entire set further depends on the market maturity of advanced ZK proofs. The endpoint of rapid finality thus coincides technologically with the most demanding building blocks of scaling. The requirements for Single-Slot Finality thus reach from the fine temporal structure of the slot deep into the fundamental architecture of the consensus layer.

The cryptographic basis of the challenge is the signature procedure on which aggregation relies today. The BLS signature procedure natively combines the signatures of many validators into a single one, and this property makes fast aggregation computationally and capacitywise highly efficient. The hash-based procedure of the leanXMSS line, intended to replace BLS in consensus, produces signatures that are orders of magnitude larger. In addition, it carries no native aggregation capability, so the switch massively complicates aggregation technically.²⁰⁰ The new procedure is chosen as a post-quantum cryptography measure, whereby the consensus layer anticipates the same transition to hash-based procedures that Section 5.3-D derived for verification. The technological requirements of Single-Slot Finality overlap here with the necessities of quantum security, without either challenge inherently resolving the other.

The larger signatures of the new procedure are handled by an integrated zkVM that creates a compact validity proof for them. Via a recursive SNARK, the instance referred to in the roadmap as leanVM folds them into a single proof. This reduces the data load by approximately 250-fold, so that finality remains within the time window despite the larger individual signatures.²⁰¹ The same aggregation mechanics that 5.3-A′ invoked for the quantum-resistant proofs of the application layer thereby also makes the consensus signatures scalable again. Closing the last time window in consensus thus means rebuilding it down to its signature procedure — and the new procedure is chosen quantum-secure from the outset.

With this, the third and final danger is answered: the retroactive displacement of an already confirmed block — after the exclusion of a transaction and the extraction of its value. These three answers protect the neutrality of the consensus layer against its most powerful actors, without dissolving the concentration of block production itself. They also all rest on a diversity of the Validator set that Section 5.5-C has marked as unsecured. What weight the unsecured diversity carries against the achieved guarantees is analyzed in the target-state assessment in 5.7, from which the chapter derives its overall verdict in 5.8.

5.6 L2 Architecture and Settlement

The Second Security Class and Its Convergence Point

The preceding section addressed the neutrality of Layer 1 against its most powerful producers at the protocol level, while one layer higher the two-class problem of Layer 2 persists. Whoever sends a transaction on Layer 1 trusts solely the protocol, whose consensus and cryptography rejects every rule violation. Whoever sends the same transaction on a Rollup trusts additionally the company that operates the Rollup. The operator controls two services themselves today: the correct execution of transactions (Execution) and the order in which they are processed (Sequencing). From Layer 1, a Rollup so far takes only data availability, whose guarantee Section 5.2 developed. The target state reverses the verification relationship of Execution: today the operator proves to Layer 1 the correctness of their system; in the future Layer 1 checks it with its own State Transition Function. This section addresses Execution, the following one Sequencing. From the convergence of both follows the basis of the Settlement role: Ethereum as the layer on which other networks and applications definitively record their state changes.

Behind the second security class stand identifiable actors, since the operator of a major Rollup is in each case a single company — Offchain Labs for Arbitrum, Coinbase for Base, Matter Labs for zkSync Era. The state follows structurally from the rollup-centric scaling that shifted execution onto Rollups and left its security to the operators. The concrete problem lies in a verification gap in the protocol: a Rollup publishes its transaction data and the resulting State Root on Layer 1, yet Layer 1’s consensus possesses no rule of its own connecting the two. Whether the claimed State Root actually follows from the execution of the published transactions is verified solely by a Verifier Contract — a Smart Contract that the operator develops, deploys, and can modify via its own governance. Layer 1 executes the contract according to its rules but does not vouch for the correctness of its verification logic, and a bug in the proving circuits can allow an invalid state transition to pass as cryptographically correct. The operator thereby replicates a function that Layer 1 has long performed natively for its own blocks: the verification of EVM state transitions.

From the gap follow the three self-provided services on which the correctness of a Rollup today rests. A standalone proof system attests that the operator correctly advances the state of its users, and a Security Council — a body with privileged intervention rights — can halt or modify the system in an emergency. Added to this is a rollup-specific governance that decides on upgrades to which users are subject. Optimism relies on the fraud-proof system Cannon, Arbitrum on BOLD, zkSync Era on the ZK system Boojum.²⁰² Each of the three systems requires its own codebase and its own audit, and every line of proprietary proof logic increases the probability of failure against which the Security Council must stand ready. For the user, the security of their funds thus depends on the competence and integrity of identifiable companies and bodies — a dependency that Layer 1 has eliminated at the protocol level.

The counter-concept to operator-based security is Trustlessness — the state in which the validity of every operation follows solely from protocol rules and cryptographic verification and requires no trust in identifiable actors. How much power an operator still holds over its users can be categorized in three development stages, which the analytics platform L2BEAT — a continuous documentation of the degree of decentralization of Rollups — runs as a Stage schema. At Stage 0, the operator can modify the system or freeze user funds at any time. At Stage 1, a functioning proof system is present and the Security Council is limited to emergencies. At Stage 2, every privileged intervention is excluded and mathematical verification alone applies.

No Rollup at Stage 2

As of early 2026, no major Rollup has reached Stage 2: Arbitrum, Base, Optimism, Starknet, and Scroll stand at Stage 1, zkSync Era and Linea at Stage 0.²⁰³

Several operators have left the relinquishment of the last intervention rights publicly unanswered for regulatory reasons. In the second direction a comparable concentration exists, because every major operator deploys the Sequencer — the instance determining the order of transactions — as a single, self-controlled component. The leading attempt at a shared Sequencer, Astria, was discontinued in 2025, and the expectation that operators would incrementally relinquish their position of their own accord has not been fulfilled in either direction. Buterin drew the consequence publicly in February 2026: progress toward Stage 2 had been far slower and more difficult than originally expected.²⁰⁴ The strategic reorientation that follows from this is carried by Section 5.1.

The Stage classification describes the existing state; the trajectory of the target picture leads both Rollup classes to the same end state. The distinction between Optimistic Rollups with a downstream challenge period and zkRollups with an upfront Validity Proof dissolves to the extent that Validity Proofs become cheaper and more general in their reach. At the end, zkRollups achieve proof of complete EVM execution, and Optimistic Rollups abandon the sevenday challenge period once a cheap Validity Proof replaces it. At the end of both movements stands the same cryptographic Settlement security, at which no user needs to trust the operator for correctness. It is fully achievable for neither class as long as the operator maintains the proof system itself — and here the target state intervenes: the verification of state transitions is relocated into the protocol of Layer 1.

Verification Relocates into the Protocol

Native Rollups (EIP-8079, RES) relocate verification via a single protocol-level call onto Layer 1.²⁰⁵ The core is the EXECUTE precompile, which extends progress toward Stage 2 as far slower and more difficult than originally expected — a finding among the empirical triggers of the strategic pivot.

the precompile layer introduced in Section 5.3-A′ with an entry point into Ethereum’s own State Transition Function. The operator submits a pre_state_ root, a post_state_root, and a Witness Trace, and the precompile checks whether Layer 1 computes the same end state from the initial state as the operator claims. The Witness Trace — a compact collection of precisely those State values that the Rollup block reads and writes — enables verification without Layer 1 needing to hold the complete Rollup State. The operator’s claim is thus checked by the same thousands of validators that verify every Layer 1 transaction, and the correctness of a Rollup block moves from a contract rule of the operator to a rule of the protocol. In the proof-of-concept, verification proceeds by re-execution; prospectively by a SNARK proof — continuing the verification infrastructure that on Layer 1 separated recomputation from checking.

For the user of an EVM-equivalent Rollup — whose execution corresponds exactly to the specification of Layer 1 — the trust foundation would be different. The validity of Rollup blocks would be decided by the same consensus as a Layer 1 transaction, so that an attack on their funds would require an attack on Layer 1 itself. From the inherited client diversity, a multi-prover system would arise without additional infrastructure. Because different Execution Clients use different proving procedures, a bug in any single procedure cannot finalize a false state — the deviation would be visible in consensus and would find no majority. The Security Council of the operator becomes superfluous, and automatic compatibility with the hard forks of Layer 1 replaces operator-specific rollup governance that would otherwise need to be kept in sync. The Bridge — the connection layer for deposits and withdrawals between the levels — disappears as a trust layer, because Withdrawals would be secured by the same consensus as an ordinary Layer 1 transaction, without Security Council and without challenge period. On the side of future operators, the entry threshold shifts from the million-dollar effort for proof system, audit, and Security Council to the configuration of a single call. The permissionless access that Layer 1 grants for individual transactions extends to the creation of entire Rollup networks.

The gain remains tied to two conditions, of which the first concerns the costs of verification. As the second condition, the Witness Trace must be available on-chain and reaches the magnitude of five to ten times the Rollup batch — an expenditure that remains manageable only because the data availability capacity motivation explicitly names the redundancy, since EVM-equivalent rollups maintain complex proof systems solely to reproduce what Layer 1 already provides. Source: Justin Drake, ethresear.ch (January 2025).

of Layer 1 has grown structurally.²⁰⁶ The Witness remains compact only under the restructured State organization from Section 5.4. With today’s tree structure it would be two orders of magnitude larger and prohibitive. Added to this is a throughput limit, because in the first phase every node on Layer 1 fully recomputes every invocation of the precompile. The number of invocations per block therefore remains limited until SNARKification replaces the repeated execution. The second condition concerns the scope of resolution, because the exposed State Transition Function supports neither custom opcodes nor proprietary precompiles or divergent transaction types. Any deviation from EVM equivalence therefore leads back into self-managed settlement, in which the user again trusts the operator’s institutions. Most Rollups today are EVM-compatible but not EVM-equivalent, and the resolution is initially open only to that part of the ecosystem whose execution matches the specification of Layer 1.

In the target state, execution would thus be brought into the first security class, insofar as a Rollup remains EVM-equivalent and the compact Witness form and protocol-level verification are available. A strand of research investigates the generalization of the EXECUTE precompile to a VM-agnostic basis — an approach belonging to the Lean Ethereum direction and standing here as an outlook. For existing Rollups with their own proof system, the Bridge with its trust assumptions would remain a transitional phenomenon diminishing in significance with the spread of Native Rollups. One power the operator retains regardless: the order of transactions, over which the centrally controlled Sequencer continues to decide alone. The following section addresses the relocation of Sequencing to Layer 1 as well. From the convergence of both directions emerge the complete Trustless state with its Finality Stack and the Settlement role, in which a heterogeneous ecosystem of chains definitively records its state changes on Ethereum.

The Shared Order: Based Sequencing and Based Preconfirmations

Resolving the Execution resource leaves the operator one remaining service: the order in which the transactions of their Rollup are processed. The Sequencer, which every major operator deploys as a single, self-controlled component, bundles three authorities. It can omit a transaction, enabling a local censorship at the Rollup level that Layer 1 addresses at the protocol level for its own blocks (Section 5.5). It determines the ordering of transactions and can extract the value that follows from it. And its failure halts the entire Rollup, because liveness depends on the infrastructure of a single company. For the user this means that the inclusion of their transaction and the timing of their withdrawals depend on the availability of a component that no protocol binds. The three authorities structurally repeat what the preceding section negotiated for Layer 1, but they lie in the hands of a third actor — the operator — who joins the Builders and stakers of the base layer. The target state hands the ordering to Layer 1: Based Sequencing lets the Proposer of the slot order the Rollup transactions, and Based Preconfirmations give the user a confirmation in approximately 2 seconds for this.

The mechanism rests on a property that every Rollup already possesses: its execution follows deterministically from the order of its transactions. Once the sequence is fixed, every Rollup node computes the same state from it, and whoever fixes the order has done everything decisive, without executing themselves. Based Sequencing uses this property and dispenses with a dedicated ordering instance: the Proposer of the Layer 1 slot includes the next Rollup block as a data packet in their own block, and with this inclusion the order of the Rollup transactions is binding.²⁰⁷ The user continues to send their transaction to the Rollup; it travels as part of the packet through the Layer 1 block without becoming a Layer 1 transaction itself, and the Rollup nodes then execute the fixed sequence. In place of the single company server steps the entire Validator set of Layer 1; the liveness of the Rollup is identical with the liveness of Layer 1; and participation in the ordering is permissionless. With the Sequencer, the surrounding infrastructure disappears: separate consensus, escape hatch, and proprietary ordering rule beyond Layer 1 are eliminated. A Based Rollup is no longer a network with its own ordering — its blocks arise as part of the Layer 1 blocks, and what remains is an execution environment over the shared ordering.

Because all Based Rollups use the same ordering, the same Proposer orders their blocks within the same slot — a basis whose significance for the interplay of Rollups Section 5.6-D develops. The neutrality layer of the preceding section accordingly extends to the Rollup, to the same extent and with the same qualification with which it was addressed there. One building block is still missing from the procedure: whoever is to give a commitment regarding the forthcoming order must be established in advance. This is provided by the Deterministic Proposer Lookahead (EIP-7917, DEPL since Fusaka): the protocol computes in advance and bindingly which validator proposes the block in which of the upcoming slots — a publicly visible sequence of the next Proposers.²⁰⁸ Before this anchoring, the sequence was manipulable, because a validator could shift the allocation by changing their effective balance — a path the deterministic computation closes. The price of the handover is speed, because a central Sequencer confirms in approximately 0.25 seconds, while a Based Rollup without further mechanics does so only with the next Layer 1 block — after up to 12 seconds. On this difference the operators’ decision for their own Sequencer had so far depended. The target state’s answer is Based Preconfirmations, hereafter Preconfs. A subset of validators registers voluntarily as Preconfirmers and deposits additional stake as security. Whoever sends a transaction receives from the next responsible Preconfirmer — identified by the Lookahead sequence — an immediate commitment regarding the inclusion and position of their transaction.²⁰⁹ If the Preconfirmer fails to honor the commitment, they lose a portion of the deposited stake through Slashing. The commitment reaches the user after approximately 2 seconds and is economically secured. Cryptographic finality remains absent — a remainder that the Finality Stack of the following section puts in context. Based Sequencing thus forms the second building block of the strategic reorientation whose framework Section 5.1 carries.

The proof of concept for the architecture has been running on Mainnet since May 2024: Taiko has operated since then as the first Based Rollup and has processed over 900 million transactions without downtime as of April 2026.²¹⁰ Since August 2025, Preconfs have been running on Mainnet in a first phase via a permissioned list of Preconfirmers, with confirmation times of approximately 2 seconds. The proof carries a qualification: the Preconf layer runs permissioned, and its opening is on the roadmap for 2026 and thus still outstanding. As an Ethereum-equivalent Rollup, Taiko also satisfies the condition on which the inherited protection of the Execution resource depends — and the candidate for the convergence of both directions is named.

Three Open Limits

Three limits remain open, of which the first is economic: with the ordering, its revenues migrate too — the value of ordering flows to the Proposers of Layer 1, and the operator loses a revenue source. The value lands where it finances security, as the revenues feed the security budget whose composition Section 5.5-C developed. On this loss hangs the reluctance of existing operators, and the operational evidence follows the pattern: Taiko started as a Based Rollup, and no existing major operator has made the switch. The second limit concerns the prerequisite itself, because the deterministic Lookahead that enables Preconfs makes the future Proposer publicly predictable and thus a reachable target for a targeted denial-of-service attack. A line of research under the name Single Secret Leader Election pursues the opposite and keeps the identity of the Proposer secret until their slot is executed, to shield them from the attack. The advance commitment of Preconfs and the protection of the Proposer thus currently stand as architectural choices against each other.²¹¹ The third limit is the separation of directions: the shared ordering does not make a Rollup trustless as long as its Execution remains with its own Verifier Contract, and the resolution of the preceding section and that of this section only take effect together.

In the target state, the two services a Rollup today performs itself would individually be relocated to Layer 1: verification of execution via the protocol-level check, ordering via shared Sequencing. The operator who at the start of the section held both directions would hold neither. The following section assembles from both directions the complete picture: the Rollup as an execution environment whose ordering and correctness Layer 1 itself carries and whose confirmations a three-tier Finality Stack arranges.

The Convergence: The Trustless Rollup and Its Finality Stack

The Rollup at the end of the preceding section has handed over its Sequencer and is nonetheless not trustless. Its operator (the Rollup company) can no longer corrupt any transaction, and no failure of its infrastructure halts the Rollup any longer. The order is fixed by the Proposers of Layer 1. Yet what the ordered sequence brings about is still checked by the operator’s Verifier Contract. If it accepts a faulty State Root — for instance through a bug in the proving circuits — the users’ funds are incorrectly recorded, even though the ordering was correct. A Rollup that conversely only uses EXECUTE verification is checked by the consensus of Layer 1, but its operator still orders and can omit or fail. The two-class problem — the finding from the beginning of the section — is thus in both cases only halved, and only the combination of both mechanisms closes both gaps simultaneously. The section first describes what such a Rollup is, and then the three confirmation levels that a user receives there, from the first commitment to final finality.

A Rollup combining both mechanisms — hereafter the ”converged Rollup” — uses all three modules of Layer 1: data availability (Section 5.2), ordering of transactions (Section 5.6-B), and verification of Execution (Section 5.6-A). After the Rollup nodes have computed the new state from the fixed sequence, the EXE-CUTE verification confirms the transition through the same consensus that also checks the blocks of Layer 1. The operator’s Verifier Contract — on which the funds were still hanging just moments ago — becomes superfluous, and with it the risk of a faulty State Root. A converged Rollup therefore carries no trust assumption beyond Layer 1. What remains of it is an execution environment: its own fee market, its own state, and the applications on it — without its own Sequencer, without its own proof system, without a Security Council, and without its own governance. In the discourse of the ecosystem the converged Rollup bears the name Ultrasound Rollup, and with Taiko Gwyneth an implementation is in development that explicitly aims at the combination of both mechanisms.²¹² Creating a Native Rollup has shrunk to one invocation of the EXECUTE precompile, and because the ordering is open to all validators, such a Rollup would be the first to be permissionlessly replicable. The consequences of the interplay for the relationship of Rollups to one another are developed in Section 5.6-D.

At the protocol level, both mechanisms rely on the enshrined Proposer-Builder Separation that the chapter has already carried as a capacity building block (Section 5.2) and as a neutrality condition (Section 5.5). The separation of building from proposal gives the Proposer the position from which it orders the Rollup blocks. And it opens the time window in which EXECUTE verification is integrated into the Layer 1 block.²¹³ The verification itself flows into the infrastructure that Section 5.2 developed for Layer 1: the L1 zkEVM, which validates a block via proof and replaces recomputation. The EXECUTE verification carried via SNARK proof reverses the current relationship of proof systems. In the baseline state, every Rollup maintains its own; in the target state, a single one — the zkEVM of Layer 1 with its multiply implemented provers — checks the state transitions of all EVM-equivalent Rollups.²¹⁴ The timelines of both projects are explicitly coupled, since the maturity of the zkEVM is simultaneously the prerequisite for protocol-level Rollup verification.

The Tiered Finality Stack

What the user of a converged Rollup receives as confirmation is tiered across three layers with three different types of guarantee. The first layer delivers after approximately 2 seconds the Preconf — the economically secured commitment of a registered Layer 1 validator. The second layer delivers the Fast Confirmation Rule (PLAN), an attestation-based rule without a hard fork, specified as a pull request in the consensus-specs and in client implementation.²¹⁵ It declares a Layer 1 block deterministically confirmed once sufficiently many attestations support it — after approximately 13 seconds. It presupposes that at least three quarters of the stake attest honestly and network latency remains below three seconds. With it, the Layer 1 confirmation falls from approximately 13 minutes to approximately 13 seconds, accelerating exchange deposits and bridging by approximately 98 percent.

The third layer is finality itself. The roadmap goal is Single-Slot Finality, but the practically converging design — whose architecture and price Section 5.5-D developed as three-slot finality — reduces irreversible finalization in the target state to approximately 36 seconds.²¹⁶ The stack tiers three types of guarantee in ascending strength: the secured commitment after approximately 2 seconds, the deterministic confirmation after approximately 13 seconds, and the cryptographic finality after approximately 36 seconds. For the user of a converged Rollup, each waiting time corresponds to a nameable guarantee, and the strongest guarantee no longer costs minutes.

The reach of convergence remains limited, and its limits are those of both directions. It applies to Rollups that remain EVM-equivalent and adopt Based Sequencing. Both are decisions of the operators, and the ecosystem therefore retains a spectrum of attachment levels, from full convergence to the sovereign chain with minimal binding to Layer 1. The Stack itself is unequally mature: the middle layer is active, the first runs partially and permissioned, the third is a research subject beyond 2029. Added to this are two qualifications of the carriers. The zkEVM currently achieves its speed on security assumptions whose formal hardening is pending in graduated milestones. And the deterministic confirmation rests on the honesty of three quarters of the stake — a precondition that refers back to the unsecured distribution from Section 5.5-C.

In the target state, the two-class problem would thereby be resolved for the converged part of the ecosystem. A Rollup there is an execution environment of Layer 1, ordered by its Proposers, checked by its consensus, confirmed in its Stack. What loads such a layer can carry once other systems make binding entries on it is developed in the two following sections: first the Settlement of tokenized values, then the role for a heterogeneous ecosystem of chains.

The Relationship of Rollups and the Settlement of Tokenized Values

The Rollup that at the end of the preceding section stood as an execution environment of Layer 1 does not exist in the target state alone. Whoever moves funds from one Rollup to another today crosses the border between two foreign security systems, with their own Bridge, their own deadlines, and their own trust assumptions on both sides. The convergence of both mechanisms changes the border itself, because with the security system of the individual Rollup, the foreignness between Rollups also dissolves. Both questions of the section depend on the same property: what the Rollups can guarantee one another is simultaneously what the layer offers external users. This section therefore first develops what follows from the shared ordering and the shared finality horizon for the relationship of Rollups to one another. It then asks what loads the layer carries once not only its own ecosystem makes entries on it. It finds the answer with the tokenized capital of the traditional financial world, whose booking presents the most demanding requirement profile.

The new relationship begins with the ordering, because the handover of Sequencing has effects beyond the individual Rollup: the same Proposer orders the blocks of all Based Rollups within the same slot (Section 5.6-B). The relative order of transactions of two Rollups thus arises in a single act, holds across the Rollup boundary, and no longer depends on the coordination of independent systems. Whoever trades on two Rollups simultaneously plans against a single binding sequence rather than against two mutually independent order-ings whose relationship no one guarantees. Because the same verification decides on the state transitions of all converged Rollups, their entries also share a common finality horizon. A transfer between two such Rollups would be finalized on both sides in the same Stack, according to the same deadlines and under the same assumptions (Section 5.6-C). A Bridge with its own trust assumptions — whose disappearance Section 5.6-A developed for the relationship with Layer 1 — would no longer be needed. For an application spanning multiple Rollups, the decisive uncertainty would shift from trust in foreign systems to the waiting time until finality.

Composability — the ability of applications to interlock across system boundaries — reaches its strongest form in atomic composition, where two operations stand in the same block and either both succeed or both fail.²¹⁷ The atomic form remains unachievable in the target state, because it would require synchronous communication between Rollups within a single slot — which neither the shared ordering nor the protocol-level verification delivers. What would be achievable is the second level of the work’s four-level logic: asynchronous Composability with deterministic guarantees, tendentially below a slot. Compared to the baseline state in which most connections run via the third level, the gain would lie less in speed than in the type of guarantee. In place of trust in third-party systems would come a nameable deadline with cryptographic backing. The preceding section announced a second consequence, and it concerns the growth of the ecosystem. Because a converged Rollup could be permissionlessly replicated and every copy would arise under the same ordering, each new Rollup would enter the described relationship from the outset. The ecosystem would grow as a set of execution environments over a common foundation, and its diversity would remain a question of specialization rather than security.

This relationship becomes practically usable through a layer that relieves the user of managing the borders. An Intent is the declaration of a desired outcome rather than a prescribed execution path. The user specifies what value should arrive on which Rollup, and a Solver — a market actor specialized in this — takes on the path and execution for a fee. The standard ERC-7683 (Cross-Chain Intents, DEPL) normalizes the form of such Intents across Rollups, and the Open Intents Framework (DEPL) assembles the associated ecosystem infrastructure.²¹⁸ The deterministic confirmation of Layer 1 shortens the deadline after which the settlement of a Solver is fixed — a function of the Finality Stack from the preceding section. Solvers operate where liquidity and Settlement security are highest, and therefore route demand to the layer that combines both. The limit lies below the standard: ERC-7683 makes Intents portable, but Solvers maintain protocol-specific liquidity positions and proprietary routing logic, so that the execution environment unifies more slowly than the form of Intents.

Binding Settlement of Tokenized Values

Binding Settlement presents a requirement profile that goes beyond throughput. An entry must become final within a nameable deadline, its execution must favor no one, its correctness must be verifiable without permission, and its existence must be claimable for decades. The converged layer would deliver each of the four requirements from the inventory of the chapter. Finality would be carried by the tiered Finality Stack (Section 5.6-C), equal treatment by the protocol-level neutrality (Section 5.5), verifiability by the universally accessible verification (Section 5.3), and lasting claim by the differentiated State management (Section 5.4). Here equal treatment is more than a fairness property, because a booking location that can delay or omit individual entries is unsuitable as neutral infrastructure between competitors. Added to this is a property no single module delivers: the entry depends on no custodian whose continued existence the holder must verify — it would depend on the protocol itself. For institutional users, the Stack would translate into a guarantee whose strength grows with each of its layers and whose strongest form no longer costs business days.

The demand for such a layer is not a postulate of the target state. Tokenized values — referred to in the financial discourse as Real World Assets — already exist in the double-digit billions on the Ethereum Mainnet, the largest single booking location of the category.²¹⁹²²⁰ The American market infrastructure opened the category regulatorily at the end of 2025, but maintains finality in its pilot architecture at the central custodian, while the converged layer would carry it as a property of consensus.²²¹ What today lies there uses the guarantees of the baseline state, and the requirement profile of these users is simultaneously the standard against which the target state must measure itself. One requirement the layer does not fulfill itself: the confidentiality of business transactions — because the public booking exposes positions and counterparties that institutional actors cannot disclose — and the protocol-level target picture for that is developed in Section 5.1.

The section began with a structural problem and ends with a property that follows from its resolution. A layer that would carry its own Rollups without institutional trust — thereby resolving the two-class problem for the converged part — would offer external capital precisely the guarantees on which binding Settlement depends. Incoming capital deepens liquidity, and deepened liquidity attracts Solvers and further capital. Each level would raise the economic and securityrelated switching costs. A booking location whose departure becomes ever more expensive approaches the state in which its function is no longer replaceable. The qualification rests not on any single innovation. It rests on the interaction of the architectures the chapter has developed from capacity to neutrality. The finding thus stands: two mechanisms, each bringing one direction to Layer 1, would yield a layer — internally deterministically ordered, externally a booking location without institutional precondition. Whether this role reaches beyond its own ecosystem to chains that are not Rollups is addressed in the concluding section of 5.6.

Research Horizon: Heterogeneous Chains and Autonomous Agents

The question with which the preceding section closed reaches beyond the target state, and that changes the status of the answer. No specification in the roadmap answers whether the converged layer also carries systems that are not Rollups, or serves actors who are not humans. Both extensions are regarded in the roadmap’s environment as a goal of the layer, and precisely for that reason their presentation requires the explicit marking of their status. This section therefore distinguishes two quantities: the architecture developed in the preceding sections and here only applied, and the adoption by new systems and actors — which carries no maturity level and is carried as a research horizon. The verdict of 5.6, which closed with the preceding section, depends on none of the following statements. The first question concerns chains with their own consensus that would wish to bind themselves to the layer without becoming Rollups. Structurally, the weaker part of the offering would be open to such a system: it could periodically record its block history in the layer and would gain a finality that its own consensus does not produce. Disputes over its own past can thus be resolved against an external standard whose neutrality the system need not provide itself. What it does not gain is the property of the converged Rollup, because verification of its state transitions remains its own, and with it every assumption of its consensus. An economic binding is also conceivable — for instance through collateral deposited on the layer — but this would supplement rather than replace the assumptions of the foreign consensus. The binding of heterogeneous systems therefore remains economic or institutional, while Rollups receive a cryptographic one, and the two-class problem that the section closed for Rollups would return at their external boundary in another form. The ecosystem’s discourse nonetheless carries the layer as the foundation of entire chain ecosystems — claiming the scope of a civilizational infrastructure whose significance reaches beyond any single application.²²² What mechanisms could carry such a role and whether foreign consensus systems would adopt it is not laid out in the target state and remains a subject of open research.

Autonomous Agents as Users

The second question concerns an actor class whose needs present the requirement profile of binding Settlement in sharpened form. Autonomous agents — software systems that commission, provide, and pay for services without human approval — are excluded from bank accounts, signing of contracts, and legal entities. A booking location without institutional precondition (Section 5.6-D) would not be the better option among several for such actors — it would be the only one. Machine counterparties could extend no credit from relationship to each other. Every service would require settlement delivery against delivery, whose guarantee is verified rather than negotiated. The amounts are small, the frequency high, and the counterparty changing — a profile for which institutional payment infrastructure provides neither accounts nor prices. An agent would hold its own balance, provide collateral from its own holdings, and require no custodian acting on its behalf for either. The path for this is not outstanding: the Intent layer (Section 5.6-D) carries the coordination and payment between agents without any human intermediation between commission and settlement. The layer records what satisfies its rules, regardless of who declares a result, and precisely therein lies the accessibility for actors without legal form.

The guarantees of the layer would be machine-readable, their deadlines nameable, and their access condition exhausted in the possession of a key — a combination no institutional settlement system offers. That confirmation is available in seconds and deterministically — a function of the Finality Stack (Section 5.6-C) — matches the deadline to the frequency of machine interaction. Added to this would be requirements that human users do not pose: an identity tied to no person, a reputation that is machine-verifiable, and a verification of rendered services without courts and without contractual partners. For the first of these, the answer already stands in the chapter, because the account architecture from Section 5.3 binds authorization to programmable rules rather than to a person. Draft ERC-8004 normalizes identity, reputation, and validation registers on the layer for this purpose — an explicitly early reference point documenting a direction.²²³ What the draft does not carry is the question of liability and oversight, since an actor without legal form is also an actor against whom no claim is enforceable. The structural finding does not depend on this maturity level: the same layer carries two demand classes under the property bundle that the preceding section derived for tokenized capital, and the machine actors demand the same bundle for the same reasons — only without the alternative. Whether the actor class becomes a demand class depends on developments outside the protocol, and no statement in the chapter gains or loses with it.

Both questions share the same status: they lie beyond the target state specified by the roadmap, and beyond the maturity levels with which this work substantiates its findings. The section records them because the architecture implies them, and it does not answer them because the assumption rests on no specification against which an answer could be verified. The open variable in this context is their adoption by systems and actors over which the protocol has no authority. For the overall picture of the section, the architecture already connects both dimensions of the settlement role. The target image is in this respect architecturally complete. What remains open is only whether the second demand class materializes. The assessment in the following section therefore applies to the target state developed in sections 5.2 through 5.6, not to the horizon this section marks.

5.7 Target-State Assessment

Target-State Assessment of the Critical Conditions

The preceding sections have unfolded the target state along its technical directions, from execution through verification and state to neutrality and the architecture of Layer 2. The following assessment shifts register and maps what has been unfolded onto the twelve criteria of the evaluation framework, beginning with the three Critical Conditions whose rating caps the overall verdict. It applies to the target state as an architecturally coherent design state, not to the operational current state. Throughout, it carries the maturity levels of the taxonomy: from delivered deployment maturity (DEPL, IMPL) through planning anchoring (PLAN) to unproven research (RES), since no classification may exceed its maturity level. The assessment is simultaneously reduced to the architectural level, as the current-state comparison, the full three-level synthesis, and robustness against partial realization belong in the overall chapter synthesis (Chapter 6).

The three Critical Conditions — Security and Trust Burden (I.2), Neutrality and Censorship Resistance (II.1), and Minimum Viable Guarantees (I.4) — undergo different improvements in the target state.

I.2 stands at Met with Qualification in the target state. The trust-burden reduction runs across nearly every protocol layer: Relay-Trust-Elimination through ePBS (PLAN/SFI Glamsterdam), Validator-Trust-Reduction through the L1-zkEVM (active EF roadmap), and RPC-Trust-Reduction through Stateless Clients and Helios (DEPL/IMPL). Two residual risks remain beyond protocol reach: the zkEVM Proving Conjecture — the possibility that an adversarial prover proves a false state transition — and the access layer, consisting of wallets, frontends, and DNS, which in principle lie outside protocol control.²²⁴

The finality profile of I.4 is strengthened in the target state by the three-tier stack: Based Preconfirmations approx. two seconds (DEPL), Fast Confirmation Rule approx. 13 seconds (PLAN, consensus-specs PR #4747), and Three-Slot Finality approx. 36 seconds (RES, horizon post-2029). Liveness under attack is secured through the Inactivity Leak as an automatic self-healing mechanism; censorship resistance through FOCIL (PLAN/SFI Hegotá-Headliner) as a protocol-enforced inclusion mandate. I.4 stands at Met.²²⁵ The four I.4 aspects — finality, liveness, degradation mode, and censorship resistance under attack — are strengthened or maintained in the target state.²²⁶

II.1 undergoes the decisive step-change of the target state: from Conditionally Met in the IS-state to Met with Qualification in the target state. The three-layer system of FOCIL, ePBS, and Encrypted Mempool addresses the structural neutrality gaps of the IS-state and lifts the only Critical Condition that in the IS-state forced the cascade to the middle suitability level.²²⁷ The remaining limits cap the level at Met with Qualification: builder concentration, which ePBS addresses but does not resolve; Lido at approx. 23 percent of staked ETH without a protocol cap; and geographic node distribution with approx. 39 percent US nodes.²²⁸

The post-quantum inventory of the target state is cross-sectionally relevant across all three Critical Conditions: at the consensus layer, leanXMSS via Beam Chain (post-2029, RES) is the target path; at the DA layer, the KZG-to-STARK transition occurs in the Full Danksharding final state; at the execution layer, the ECDSA exit via NAA and Validation Frames (EIP-8141, CFI Hegotá Non-Headliner) provides the migration path. The hash-based aggregation from 5.3 serves as the shared layer. Deployed are secp256r1 (EIP-7951) and Helios; EIP-8141 is at status PLAN; EIP-7932 and Binary Trees are at status RES.²²⁹

The PQ Research Team of the Ethereum Foundation (January 2026) coordinates all paths; the Emergency Response Plan is documented; Strawmap signature sizes show ML-DSA at 2.4 to 4.6 kilobytes and SLH-DSA at 7.9 to 49.9 kilobytes versus 64 bytes for ECDSA, with state bloat on the order of 59-fold for ML-DSA.²³⁰ The PQ pre-material as a whole assesses the situation as: architecturally laid out, not secured; the paths are defined for all three layers, but no path is complete and no time-critical milestone is guaranteed.²³¹ The Metaculus estimate of a roughly 20 percent probability of a cryptographically relevant quantum computer before 2030 is the quantified risk framework — an external assessment, not a forecast of this work.²³²

Target-State Assessment of the Structural and Qualitative Criteria

The three Structural Conditions all stand at Met in the target state.

I.1 (Functional Indispensability): All three anchor indicators — DeFi TVL dominance, stablecoin issuance, and developer ecosystem — reach the highest anchor level above the 50 percent threshold. Native Rollups bind the technical option of switching for EVM-equivalent rollups at the protocol level; cloud concentration at approx. 59 percent across three providers qualifies the level without depressing it.²³³ Settlement attraction through ERC-7683 and Native Rollups is the decisive improvement over the IS-state.²³⁴ Cloud concentration is unchanged relative to the IS-state: approx. 59 percent of hosted Execution Layer nodes across three providers (AWS 35.5%, Hetzner 13.8%, OVHcloud 9.7%), declining since 2022.²³⁵

I.3 (Coordination Function): The reach of the protocol as coordination layer expands in the target state from settlement and DA to execution verification and MEV economics. Native Rollups structurally raise switching costs for EVM-equivalent rollups, because switching the settlement layer surrenders protocol-level verification. All Top-10 L2s settle on Ethereum in the target state.²³⁶ The settlement function for tokenized values — RWA over 17 billion US dollars, BUIDL as benchmark — is the new qualitative layer of the coordination function.²³⁷

III.1 (Long-Term Stability): Three decouplings document the progress — zkEVM decouples verification from execution; Stateless Clients decouple verification from holding state; Tiered State decouples node requirements from state growth. The upgrade track record — Shanghai, Dencun, Pectra, and Fusaka without mainnet-critical incidents, Fusaka with the semi-annual schedule met for the first time — is the empirical stability proof.²³⁸ Lido and validator concentration remain structurally unchanged — no roadmap feature addresses the concentration directly.²³⁹

The six Qualitative Criteria all stand at Met with Qualification in the target state.

II.2 (Generative Capacity): Three levels of generative capacity — Compute (zkEVM), UX (NAA + Passkeys), and L2 generation (Native Rollups) — substantiate the level assignment. Limits: RISC-V without governance anchoring, EOF withdrawn. Validator concentration without a cap is the remaining structural problem.²⁴⁰

II.3 (Technical Integrity): The Execution Layer Specification is the executable reference implementation that replaces the Yellow Paper in the specification role. Limit: formal verification of the zkEVM Prover Circuit exceeds the capacity of current formal methods.²⁴¹ The ELS as the operative specification reference — not as a theoretical document — is the qualitative advance for II.3.²⁴²

II.4 (Accessibility): Three levels — users (NAA and Passkeys via EIP-7702 DEPL and EIP-7951 DEPL), verifiers (Stateless Clients, Helios), and developers (stable EVM, ELS). Limit: the 32-ETH solo-staking threshold is not directly lowered by any roadmap feature; hardware relief is achieved indirectly via zkEVM-based attestation.²⁴³

III.2 (Governance Quality): The strategic pivot of February 2026 is the strongest proof of governance quality — a paradigmatic change of direction without crisis or fork, accomplished through informal consensus and public communication.²⁴⁴

III.3 (Interoperability without Lock-in): Three lock-in resolutions — relay dependency through ePBS (PLAN), L2 proof systems through Native Rollups (RES), RPC trust through Trustless RPC (RES/PLAN). The EVM remains a structural bilateral lock-in that does not depress the level.²⁴⁵

III.4 (Hardware Agnosticism): No ASIC dependency; ARM-compatible; Stateless Clients as the long-term path toward smartphone verification. Cloud concentration unchanged relative to the IS-state; the IS-level Met with Qualification is maintained, not improved.²⁴⁶

Target-State Overall Profile

Table 5.1 shows the level distribution of the twelve criteria in the target state.

Level	Criteria	Count
Met	I.1, I.3, I.4, III.1, III.2, III.3	6
Met with Qualification	I.2, II.1, II.2, II.3, II.4, III.4	6
Conditionally Met	—	0
Open	—	0

The target-state profile is 6-6-0-0. All six Qualitative Criteria stand at least at Met with Qualification; the condition for Grade Good is thereby met.²⁴⁷

5.8 Overall Verdict

The M3 cascade determines the overall verdict from the target-state profile in five examination steps. The starting point is the level distribution in Table 5.1.²⁴⁸

First step: Does a Critical Condition stand at Open? — No. The cap at Conditionally Suitable is removed. Second step: Does a Critical Condition stand at Conditionally Met? — No. In the IS-state, II.1 stood at Conditionally Met and set the cascade to the middle category; in the target state, II.1 has risen to Met with Qualification. The second cascade cap thereby falls. The verdict lies above the middle category.²⁴⁹

Third step: Are at least two Structural Conditions weakened — that is, below Met with Qualification? — No. I.1, I.3, and III.1 all stand at Met; no third cap. Fourth step: Do I.2 and II.1 stand below full Met? — Yes, both stand at Met with Qualification. The simple Suitable verdict is thereby excluded; the result is the next category above the middle: Suitable with Conditions. Fifth step: The grade is determined by the Qualitative Criteria. All six stand at least at Met with Qualification — that yields Grade Good.²⁵⁰

The target-state verdict is: Suitable with Conditions, Grade Good.

The comparison with the IS-verdict shows the shift: the IS-state received the verdict Suitable under Considerable Conditions, Grade Good. The target state stands one verdict level higher, at the same grade. The progress lies in the foundation of suitability — in the jump of II.1 from Conditionally Met to Met with Qualification — not in the fine quality of the qualitative criteria, which in their totality remain stable.

A Crisis-Response Gap runs across the limits of several criteria and is not fully priced into the target-state verdict: builder concentration in block production is not addressed at its economic roots by ePBS; Lido concentration at approx. 23 percent without a protocol cap remains a structural dependency without an automated corrective; and the Emergency Response Plan is present as a documented procedure, but not enforced as a protocol mechanism. These three aspects converge in a gap that limits II.1 and III.1 and qualifies III.2 — and that is the subject of investigation in Chapter 6.²⁵¹

The target-state verdict rests on architectural coherence at graduated implementation maturity: the target state is technically specified and internally consistent; the post-quantum migration is architecturally laid out, but not secured; and the resilience of the system under crisis conditions — the question of whether the conditions to which suitability is tied also hold in adversarial scenarios — is the open question that Chapter 6 investigates.²⁵²