Ethereum protocol roadmap — network upgrades and long-range research

• 7702 EIP
  Set code for EOAs EL included OS

  Lets an ordinary wallet temporarily run contract code, enabling batching, sponsored fees and scoped permissions.

  Account-abstraction features arrive for the accounts nearly everyone already uses, with no move to a new address. Transaction bundling, gas sponsorship and key-scoping improve day-to-day safety and usability, narrowing the gap between simple and smart accounts across the ecosystem.

• 7251 EIP
  Increase the MAX_EFFECTIVE_BALANCE CL included O

  Raises a validator maximum effective balance from 32 to 2048 ETH, letting stake consolidate into fewer validators.

  Operators can merge many small validators into one and solo stakers can compound rewards, shrinking the total validator count. A smaller set lowers peer-to-peer message and signature-aggregation load, easing the burden on every node and helping consensus scale while node operation stays broadly runnable.

• 7002 EIP
  Execution layer triggerable withdrawals EL+CL included SO

  Lets validators exit or partially withdraw from their withdrawal credentials, without the active validator key.

  Withdrawal credentials represent ultimate ownership of staked funds, yet previously could not force an exit, leaving stakers dependent on node operators. Enabling exits from the execution layer closes a real trust gap, especially for pooled and delegated staking, with a fee that guards the request queue against spam.

• 6110 EIP
  Supply validator deposits on chain EL+CL included S

  Reads validator deposits directly from block data, removing consensus-layer deposit voting.

  Deposits are taken from the execution block instead of proposer voting over polled data, making forged deposits infeasible and cutting deposit delay from around twelve hours to roughly thirteen minutes. It also removes a polling dependency, hardening a security-critical part of the staking path.

• 7691 EIP
  Blob throughput increase EL+CL included O

  Raises target and maximum blobs per block, expanding the data availability Layer-2 rollups post to Ethereum.

  More blob capacity gives rollups more room to publish their data to Ethereum, reinforcing the security those layers inherit from the base chain. Fee parameters are retuned so the blob market stays stable as capacity grows.

Pectra combined execution and consensus changes to make the validator lifecycle safer and lighter, and to put account-abstraction features within reach of everyday accounts. Fewer, larger validators ease the messaging load every node carries, and execution-layer exit and deposit paths remove trust gaps in how stake enters and leaves the network.

• 7594 EIP
  PeerDAS — peer data availability sampling EL+CL included OS

  Nodes verify blob data by sampling small random pieces instead of downloading all of it.

  Full nodes once downloaded every blob to confirm availability. PeerDAS has each node check only a small random sample, relying on erasure coding and the wider network for the rest. Data-availability cost stops scaling with the number of blobs per node, so capacity can rise without pricing ordinary operators out of running a node.

• 7892 EIP
  Blob-parameter-only hardforks EL+CL included O

  Defines lightweight forks that adjust only blob-capacity parameters, nothing else.

  Blob capacity can rise in small, well-observed steps as sampling proves stable in production. Isolating blob parameters into minimal forks lowers coordination risk and the chance of consensus bugs, making data scaling a controlled process rather than one large jump.

• 7935 EIP
  Set default gas limit to 60M EL included O

  Raises the execution clients default block gas target toward 60 million.

  A higher default lifts per-block execution capacity for users and applications, and coordinating it across clients keeps validators aligned rather than fragmented. Other Fusaka limits keep worst-case blocks bounded so the higher target does not strain smaller nodes.

• 7951 EIP
  Precompile for secp256r1 curve support EL included SO

  Adds cheap on-chain verification for secp256r1 (P-256) signatures used by secure hardware.

  Wallets and contracts can verify signatures from passkeys and phone secure enclaves at low cost. That strengthens account security and lowers the barrier to self-custody for mainstream users, while staying interface-compatible with existing use.

• 7825 EIP
  Transaction gas limit cap EL included SO

  Caps any single transaction at about 16.7 million gas at the protocol level.

  Bounding per-transaction gas limits worst-case building and validation cost, shrinking denial-of-service surface. Predictable bounds help clients keep block processing times stable across varied hardware, protecting smaller operators as the block gas limit rises.

PeerDAS lets the network carry far more rollup data without asking each node to store all of it, so verifying the chain stays within reach of ordinary hardware. Keeping node operation affordable keeps the network in many independent hands as data demand grows.

• 7732 EIP
  Enshrined proposer-builder separation CL scheduled CROS

  Moves the proposer-builder split into the protocol, replacing trusted external relays with an in-protocol path.

  Block building is dominated by a few specialised builders reached through off-protocol relays the proposer must trust. Enshrining the split lets the proposer commit to a builder in-protocol, with the block revealed and attested without a trusted relay. That removes a fragile central piece and a point that could be pressured to censor transactions.

• 7928 EIP
  Block-level access lists EL scheduled OS

  Records the accounts and storage a block touches, enabling parallel validation and cheaper verification.

  A block-level access list declares up front the state the whole block will read and write. Clients can then load state and validate transactions in parallel instead of discovering dependencies one at a time. Cheaper, faster verification keeps running a full node accessible to more participants.

• 7688 EIP
  Forward-compatible consensus data structures CL scheduled OS

  Migrates consensus data structures so verifiers stay valid across upgrades without changes.

  Stable, forward-compatible merkleization means light clients and independent verifiers do not break each time an unrelated feature changes. That lowers the maintenance burden of verifying the chain and keeps the verifier ecosystem diverse across successive upgrades.

• 7782 EIP
  Reduce block latency CL considered

  A proposal to halve slot time from 12 to 6 seconds, cutting time-to-inclusion.

  Shorter slots reduce how long a transaction waits and spread bandwidth more evenly, but they raise the bar on propagation and hardware for smaller validators. It is actively discussed but was not selected as a headliner, so its inclusion is genuinely unsettled.

ePBS writes the proposer and builder split into the protocol, so validators no longer depend on trusted relays to receive blocks, removing a central point that could be pressured to exclude transactions. Block-level access lists let clients verify blocks in parallel, keeping the cost of checking the chain low as throughput grows.

• 7805 EIP
  Fork-choice enforced inclusion lists (FOCIL) CL headliner CR

  The selected headliner: a validator committee builds inclusion lists that proposers must honour, enforced by the fork-choice rule.

  Inclusion lists let a committee name transactions the next block must include if they are valid and there is room, and honest validators reject a block that ignores the list. Censoring a transaction then costs the block itself, making timely inclusion a protocol-enforced property rather than a norm. FOCIL is the selected censorship-resistance headliner for the upgrade.

• 8141 EIP
  Frame transaction EL committed O

  Native account abstraction, committed as a minor feature: a transaction type whose validation and fee payment are defined by contract-call frames.

  It moves account abstraction into the protocol, so an account becomes simply an address with code, without the external relayer and separate mempool that ERC-4337 relies on. Reducing off-protocol infrastructure supports decentralization and a simpler trust model. It supersedes the earlier, withdrawn native account-abstraction design.

• 6800 EIP
  Ethereum state using a unified verkle tree EL under discussion OS

  Under discussion: replaces the state trie with a verkle tree to shrink proofs and enable stateless clients.

  Small witnesses would let a client verify a block without holding the full state — the core of statelessness. It is under discussion for this upgrade alongside 2D PeerDAS, a further data-availability scaling step; neither is committed, and the tree design itself may still evolve.

Hegotá is shaping up around censorship resistance. Its selected headliner, FOCIL, lets a committee of validators force valid transactions to be included, turning censorship resistance from something the network hopes for into something the protocol enforces. Native account abstraction is committed as a minor feature, while verkle-tree statelessness and 2D PeerDAS remain under discussion.

Nothing here is committed. Ideas floated for this slot include shorter six-second slots — undecided between Hegotá and this fork — and, on a longer arc, verifying Layer-1 execution with a ZK-EVM, with no date. Names follow the alphabetical star convention: Fulu, Gloas, Heze, then an I-star as it is defined.