In May, the Protocol cluster welcomed a trio of new cluster coordinators and promised updates to follow.

After months of settling in and aligning with contributors cluster-wide, across the EF and across the Ethereum ecosystem, we are now happy to share Protocol’s priorities: what Protocol is for, the commitments that govern its work through 2029, and what those commitments require of the forks now entering scope.

With Glamsterdam approaching mainnet, Protocol has entered the Hegotá scoping season. We used the process described in an August 28 post: 62 EIPs proposed for inclusion, multiple Glamsterdam retrospectives, 16 contribution templates, and several cluster-wide working sessions. That process helped roughly 60 researchers and engineers to determine a shared set of priorities. Those priorities cover the longer-term roadmap and are focused through a critical path. That path starts with how we scope Hegotá.

This post communicates that shared set of cluster-wide priorities. For our grade on every Hegotá candidate, read the companion: EF Protocol: The Hegotá EIP Opinion Post and Tier List.

I. The north star

The EF Protocol cluster is aiming for Ethereum L1 to be quantum-resistant across all three layers (execution, consensus, and data) by December 2029. That date lines up with the 2029 migration targets independently set by Google, Cloudflare, and Microsoft. Estimates for Q-day will sharpen as time progresses. Its timing is outside anyone’s control, which is exactly why we have fixed a target rather than waiting for certainty. For now, Ethereum L1 should plan for Q-day happening as early as 2030. Planning for Q-day in 2030 is a deliberately aggressive assumption. Most credible estimates place Q-day later, some much later, and we may never see it at all.

Shipping post-quantum readiness early is the secure thing to do. It is the strategically responsible thing to do. It is the clearest signal we can send that Ethereum intends to exist 50, 100, and 1,000 years from now. Ethereum’s instinct, rightly, is to distrust all-in bets, and so do we. Here, though, we are making that bet deliberately. Q-day cannot be scheduled, so we have assigned ourselves a self-imposed deadline.

The EF Protocol cluster will treat this self-imposed deadline as non-negotiable at least until January 2027, when quantum progress will be reassessed with the guidance of outside experts.

II. The plan

Two cadences to December 2029
Client teams can realistically begin Hegotá implementation in late Q4 2026. Under the July Strawmap, full post-quantum readiness sits in L*, five hardforks after Glamsterdam. Shipping Glamsterdam in December 2026 and L* in December 2029 requires an average cadence of 7.2 months per fork. That schedule is quite aggressive, and leaves little room for error should a fork take longer to ship than anticipated year in advance.

The August 19 Strawmap update added a minimum viable post-quantum (MV-PQ) L1 milestone at J*. The post-quantum public-key registry sits in I*. The post-quantum heartbeat on the consensus layer, leanDA sampling on the data layer, and leanSPHINCS transactions on the execution layer sit in J*. A 12-month cadence from Glamsterdam can reach that contingency milestone by December 2029.

MV-PQ is a temporary safeguard
MV-PQ is designed to keep Ethereum operating through Q-day with reduced guarantees. Researchers are still defining exactly what that reduction in guarantees would look like. Full resistance across execution, consensus, and data remains the December 2029 target. The remaining work includes post-quantum attestations, required for full economic finality to complete consensus design.

Flexible fork order after J*
The Strawmap may swap K* and L*, moving lean consensus forward by one fork and mandatory execution proofs back by a fork. Reaching full post-quantum readiness in K* by December 2029 implies a 9-month cadence. We are planning Hegotá, I*, and J* as one delivery sequence while that ordering will only be finalized once research matures and client capacity is better understood.

Parallel delivery across the ecosystem
The cadence these milestones demand will require an incredible amount of teamwork, within Protocol and beyond. Forks will overlap, shipping Hegotá simultaneously while I* specifications mature and J* through L* research produces testable components. Simply shipping the forks in a linear sequence cannot meet the December 2029 schedule. Doing so will require tighter communication inside the cluster, and engaging client teams, grant recipients, academia, and the wider community so the pipeline from research to mainnet accelerates with every fork.

Delivering PQ-readiness will also take more hands than any prior fork sequence, including cryptographers, client devs, researchers, security reviewers, and testing capacity, inside the EF and well beyond it. This will be an ecosystem-wide effort.

III. The five multi-fork research arcs

Simultaneously working on several forks is how the Protocol cluster carries all of its interconnected work, near-horizon and long-horizon alike, beyond the immediate push to reach minimum viable post-quantum. These efforts are organized around five multi-fork research arcs: fast finality, post-quantum, privacy, state, and zkEVM.

Fast finality

Fast finality reduces Ethereum’s time to finality from minutes to seconds. The current design direction decouples finality from block production and rebuilds the consensus layer around an available chain and a finality gadget. Specifications and prototypes are underway, aimed at I*, where decoupled consensus is the leading headliner candidate.

Post-quantum

The post-quantum arc (as described in “II. The Plan” above) delivers the December 2029 commitment and it spans all three layers: consensus, data, and execution. Cryptographic agility is critical to the execution layer, where native account abstraction lets signature schemes be swapped without a hard fork per scheme. Frames provides that property with its approach to native account abstraction. The consensus layer, however, cannot rely on cryptographic agility; its cryptography and aggregation schemes can only change through a hard fork. Consensus cryptography gets the opposite treatment as a result. It gets battle-tested and hardened before rollout, and consensus components wait for the complete PQ design instead of shipping one at a time.

Privacy

The privacy arc is working toward privacy as a protocol guarantee, so that users can transact, hold balances, and interact with applications without exposing their financial history or trusting third parties. We believe this work should start in Hegota to deliver native, trustless, censorship resistant private transactions on Ethereum L1. Later work focuses on post-quantum privacy at scale, and encrypted mempools that conceal transaction contents until inclusion.

State

The state arc keeps state growth and access from becoming Ethereum’s binding constraint. Its work includes migrating to a new trie, sustainable state growth, and decentralized access to current and historical state. The largest design and migration work is expected to begin in I* and continues beyond it.

zkEVM

The zkEVM arc moves execution proofs from available and optional, to expected, to mandatory. Validators eventually verify a succinct proof and stop re-executing every block. Under the current Strawmap ordering, mandatory proofs arrive in K*. One reordering is in review: swap the PQ attestation and mandatory proofs milestones. PQ attestations would move forward from L* to K*, and mandatory proofs would move back from K* to L*, while the rest of each fork stays where it is. If that happens, mandatory proofs arrive one fork later so the largest remaining piece of consensus PQ arrives one fork sooner. Either way, the push to ship an L1 zkEVM also drives forward formal verification tooling, workflows, and verified cryptographic components that other arcs benefit from, post-quantum in particular.

IV. How we set priorities & ship them

Our imperative, first published in the July all-Protocol update, remains:

“Concentrate Protocol on what only Protocol can do and will do, and complete the Strawmap items that allow Ethereum to uphold the Mandate.”

Glamsterdam’s completion and the December 2029 commitment move post-quantum work from a long-horizon research concern into near-fork delivery. The post-Glamsterdam priority ladder records that change and places formal verification across the remaining research arcs as shared tooling.

The ladder sets priority; the maturity pipeline sets how work earns inclusion:

Research → EIP → Prototype → Devnet → PFI → CFI → SFI → Mainnet

Each step should add evidence, reduce uncertainty, and make ownership visible before the next commitment is made. A devnet can send work back to research. PFI, CFI, and SFI signal rising confidence among AllCoreDevs; they do not substitute for implementation evidence. Much of what Protocol is uniquely positioned to do is moving ideas across this whole pipeline.

V. The next fork, as the first test

This section is about Hegotá specifically. Protocol’s view of the fork now being scoped. The companion post, EF Protocol: The Hegotá EIP Opinion Post and Tier List, details how the Protocol cluster grades every EIP, with a specific explanation for each EIP. In this section, we cover the priorities, commitments, and scope boundaries that produced those views.

Hegotá is not the PQ fork; it is the fork that decides whether the PQ forks happen on time. Its SFI’d headliners are EIP-7805 Fork-choice enforced Inclusion Lists (FOCIL) on the consensus layer and EIP-8141 Frame Transaction on the execution layer. They must ship together safely, with the interaction between inclusion and the new transaction model tested as part of the fork’s main engineering lift.

There is little appetite for additional consensus-layer scope. FOCIL is Hegotá’s consensus-layer centerpiece. Our appetite beyond it is close to zero unless an addition directly supports post-quantum readiness. Each additional consensus-layer item draws from the same researchers and client devs needed to specify and prototype decoupled consensus and prepare I* and J* when their Hegotá implementations are completed.

Preserving CROPS as a whole

The Mandate defines Protocol’s job through CROPS: Censorship Resistance (CR), Open Source and Free, as in Freedom (O), Privacy (P), and Security (S). These properties are one set of protocol guarantees. Open-source development and open participation are the baseline for every fork. Hegotá makes specific commitments across the other 3.

Censorship resistance (CR)

FOCIL’s goal is to improve Ethereum’s transaction inclusion guarantees by enabling multiple validators to impose constraints on builders’ blocks. They do so by specifying a set of transactions that must be included via ILs for the block to be considered valid by attesters. EIP-8369 VOPS Profiles for FOCIL Eligibility defines which transactions are eligible and what validators must verify, so FOCIL’s guarantees can extend to future transaction types. Together, they are Hegota’s direct commitment to censorship and capture resistance.

Privacy (P)

Ethereum is still missing some basic protocol support that privacy applications need. EIP-8250 Keyed Nonces lets many users share the same sender for better anonymity, while giving their transactions separate nonces so they do not block one another. EIP-8272 Recent Roots lets private transactions use recent onchain state in a form FOCIL can check, so they can benefit from its inclusion guarantees. Together, they remove two major barriers to trustless, censorship resistant private activity on L1 and should ship with Frames.

Security (S)

Frame transactions makes transaction validation, execution, and gas payment programmable at the protocol level. It gives accounts a native route away from vulnerable secp256k1 keys, supports signature aggregation, and lets new signature schemes be introduced without a hard fork for each scheme. It also keeps account validation and fee payment permissionless. Keyed nonces and recent roots complete the Frames core needed for Hegotá.

EIP-8365 BLS Withdrawal Credential Retirement starts the retirement process for withdrawal credentials that remain tied to vulnerable cryptography. The work can begin now without waiting for the full post-quantum consensus design.

The Frames-extension package hardens accounts directly. EIP-7906 Transaction Assertions via State Diff Opcode lets transactions verify specified effects before committing, protecting against attacks such as drainers, EIP-8298 SETCODEFROM Code Reuse Instruction lets delegated accounts become full smart-contract accounts, and EIP-8151 Account Code Restricted ecRecover blocks legacy key authentication once an account has real code. The last 2 form the account path for retiring secp256k1 as a master key.

The bounding pair treats worst-case block construction as security work: EIP-8279 Block Access List Byte Floor and EIP-8131 Unified Transaction Content Floor put a predictable gas floor under adversarial block content. Any later use of resulting headroom is a separate scope decision.

Delivering FOCIL and Frames safely, and testing the interaction between them, is Hegotá’s core engineering commitment. Every addition competes with that testing surface and must clear the necessity bar.

VI. What to expect

The companion post publishes the Protocol cluster’s Hegotá tier list and explanation of every grade. If you read one thing beyond this post, read the companion.

Lastly, we want your questions. We’re hosting a Reddit AMA on r/ethereum on September 16 at 2pm UTC to talk through these priorities, the Hegotá tier list, and anything else on your mind. Submit questions ahead of time using the form here. The sharper the question, the better the thread.