66 proposals were on the table. Two made Hegotá's cut.

What Did Hegotá's Scoping Process Actually Decide?

Ethereum's next upgrade after Glamsterdam started with a candidate pile big enough to fill a roadmap for years. Nine days later, the tracker showed how little of it survived first contact with scheduling reality.

Hegotá's scoping process has, so far, decided almost nothing definitively — but it has decided two things. Of the 66 proposals scoped in August 2026, exactly two hold Scheduled for Inclusion (SFI) status on the live EIP-8081 meta document: EIP-7805 (FOCIL) and EIP-8141 (Frame Transaction) . Roughly 50 EIPs remain at Proposed for Inclusion, and none has been formally declined . Everything else is still an argument in progress.

Quick Answer: Hegotá, Ethereum's upgrade after Glamsterdam, was scoped from 66 candidate proposals in August 2026. Only two have reached Scheduled for Inclusion on the EIP-8081 tracker — EIP-7805 (FOCIL) and EIP-8141 (Frame Transaction). About 50 remain at Proposed for Inclusion, with a Q2 2027 target that is expected but unconfirmed.

The "66" figure traces to a 16 August 2026 scoping push by Ethereum Foundation researcher Toni Wahrstätter, picked up the following day by CoinDesk, Cointelegraph and Decrypt . That coverage is a snapshot of a candidate pool, not an approved feature list — and it already lags the record. Those articles described FOCIL as the sole SFI item with Frame Transactions merely at Considered for Inclusion; All Core Devs Execution call #244 on 27 August 2026 moved EIP-8141 to Scheduled for Inclusion, while flagging that its specification may still change .

Wahrstätter's argument for narrowing was blunt about the tradeoff:

"A fork can't be a wishlist" — developers "can't do everything at once," — Toni Wahrstätter, researcher at the Ethereum Foundation (source: Decrypt, 2026-08)

The tracking document itself is EIP-8081, "Hardfork Meta - Hegotá," authored by Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo and Parithosh Jayanthi, created 11 November 2025 and still in Draft status . Its timing fields tell you how early this is: activation entries for the Sepolia and Hoodi testnets and for mainnet are all still blank, to be filled once client teams settle timings. Ethereum.org's draft Hegotá roadmap page lists Q2 2027 as expected but explicitly not confirmed . Glamsterdam, targeted for the second half of 2026, gates when Hegotá work begins in earnest. Execution client teams were asked to submit Hegotá preference rankings by 10 September 2026 — the next real signal of which of those ~50 PFI items have implementation support behind them .

How 66 Candidates Get Cut to Two: The EIP-7723 Stage Model

The funnel that turns a large candidate pool into a shipped fork is a three-stage model defined in EIP-7723 and applied through the EIP-8081 meta document: Proposed for Inclusion (PFI), Considered for Inclusion (CFI), and Scheduled for Inclusion (SFI) . PFI is an open petition — anyone can propose. CFI signals client developers consider the proposal worth prototyping. SFI means it is slated for inclusion in the fork, subject to specification changes. Most PFI items never advance past the first stage, which is why the widely quoted 66-proposal figure describes an application pool rather than a feature list.

The narrowing was driven by an explicit scoping argument. Ethereum Foundation researcher Toni Wahrstätter's 16 August 2026 push framed the problem bluntly — "a fork can't be a wishlist" — and warned that developers "can't do everything at once" . The test he proposed was not conceptual merit but delivery evidence: does a proposal have realistic client implementations, devnet coverage, testnet time, and a credible path to shipping in 2027? Proposals that cannot demonstrate that pipeline are candidates for deferral, not rejection — proposals that miss this cut can still be reconsidered for a later upgrade .

The 10 September 2026 preference-ranking deadline for execution client teams is the practical gate. Rankings reveal which PFI items have engineering support behind them rather than authorial enthusiasm, and they are the input that moves proposals into CFI and then SFI .

How quickly that machinery moves is already visible. The mid-August press snapshot — reported by CoinDesk on 17 August and Cointelegraph on 16 August 2026 — showed FOCIL as the sole SFI item, with Frame Transaction still at CFI . Eleven days later, All Core Devs Execution call #244 on 27 August 2026 moved EIP-8141 to Scheduled for Inclusion, while noting its specification may still change . The live EIP-8081 now lists both EIP-7805 and EIP-8141 under Scheduled for Inclusion .

Two operational lessons follow for anyone tracking this fork. First, treat the 66 figure as a dated scoping snapshot, not a roadmap. Second, SFI is a scheduling decision, not a technical freeze — a scheduled EIP can still have its specification revised, be re-scoped, or drop out before mainnet activation entries are filled in EIP-8081 . The stage labels tell you where consensus stands on a given day; they do not tell you what will run on mainnet in 2027.

FOCIL (EIP-7805): What Inclusion Lists Actually Enforce

FOCIL — Fork-Choice Enforced Inclusion Lists, specified in EIP-7805 — is a censorship-resistance mechanism that makes transaction inclusion a condition of block validity rather than a builder's discretionary choice. Each slot, a committee of 16 validators (IL_COMMITTEE_SIZE = 2^4) is selected to publish inclusion lists drawn from their own mempool view, and the next block must satisfy those lists to be voted canonical . The EIP was created on 2024-11-01 by Thomas Thiery, Francesco D'Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann and Jihoon Song, and remains in Draft status .

The mechanism runs on a tight intra-slot clock. During roughly the first 8 seconds of slot N, the 16 committee members each assemble an inclusion list from the pending transactions they can see locally and gossip it to the network. Validators keep accepting inclusion lists until about the 9-second mark, after which the view freezes and no further lists count for that slot. The proposer or builder of slot N+1 is then obliged to include the listed transactions, and attesters vote only for blocks that satisfy every stored list from non-equivocating committee members .

That last clause is the substantive change. Under proposer-builder separation, a builder that dislikes a particular transaction — or is compelled by an external policy to omit it — can simply construct a block without it, and nothing in the protocol objects. FOCIL converts omission into a fork-choice penalty: a non-compliant block does not attract attestations and therefore struggles to become canonical. Compliance stops being a courtesy that depends on builder goodwill and becomes an economic requirement for getting a block accepted. The design's deliberate use of 16 independent committee members rather than a single proposer means censoring a transaction requires suppressing a set of validators, not persuading one.

What FOCIL does not do is worth stating plainly, because it is routinely conflated with the privacy discussion around Hegotá. FOCIL hides nothing. Transaction contents, sender and recipient addresses, and amounts all remain fully visible on-chain exactly as they are today . Its contribution to the privacy stack is availability, not confidentiality: a valid, fee-paying deposit into or withdrawal from a privacy pool becomes materially harder for any single builder or proposer to leave out of a block . Privacy protocols that operate on-chain are precisely the category most exposed to selective exclusion, which is why inclusion guarantees and privacy tooling are discussed in the same breath even though they solve different problems.

FOCIL reached Hegotá by way of a deferral rather than a fresh proposal. It was originally in scope for Glamsterdam and was removed over concerns that shipping enshrined proposer-builder separation (ePBS) and FOCIL in the same fork would introduce untested interaction complexity at mainnet scale . Both changes touch block construction and fork-choice behaviour, and the combined surface was judged too large to validate in one release cycle. That history explains FOCIL's current standing in EIP-8081: it arrives at Hegotá with more devnet exposure and client familiarity than most of the roughly 50 proposals still sitting at Proposed for Inclusion, which is a large part of why it was the first item to reach Scheduled for Inclusion .

EIP-8141 Frame Transactions: Ethereum's Native Account Abstraction Bet

EIP-8141, "Frame Transaction," is the second proposal to reach Scheduled for Inclusion in Hegotá, and it introduces a new EIP-2718 transaction type — FRAME_TX_TYPE 0x06 — that decomposes a single transaction into discrete frames which validate the transaction, approve gas payment, and execute user operations . It was created on 29 January 2026 by a ten-author group including Vitalik Buterin, lightclient, Felix Lange, Yoav Weiss, Alex Forshtat, Dror Tirosh, Shahaf Nacson, Derek Chiang, Toni Wahrstätter and Stavros Vlachakis, and remains in Draft status even after ACDE #244 on 27 August 2026 moved it to SFI with the caveat that its specification may still change .

The stated motivation is protocol-level account abstraction: under the frame model, in the authors' phrasing, "an account simply becomes an address with code" rather than an address permanently bound to one fixed ECDSA signature path . The benefits the specification cites follow directly from that decoupling — a native off-ramp from elliptic-curve authentication toward post-quantum signature schemes, native key rotation, batch call processing, simpler smart accounts, and alternative fee payment that does not route through a centralized third-party relayer .

For an ordinary wallet, that translates into features currently implemented at the contract or relayer layer moving into the native transaction format: sponsored gas, multi-action transactions bundled into one atomic submission, social recovery, multisig-style validation, spending policies, and alternative signature schemes. The practical difference is not new capability so much as removed dependency — today a wallet offering sponsored gas needs a bundler or paymaster infrastructure sitting between the user and the network, and the frame model makes the payer role a field in the transaction envelope instead.

The specification's constants define both the cost model and the structural limits:

Source: EIP-8141 specification, eips.ethereum.org .

The 12,000-gas intrinsic cost against a 475-gas per-frame increment is worth reading as a design signal: the fixed overhead dominates, so the marginal cost of adding frames is deliberately low, which favours batching. A 64-frame ceiling caps the worst-case validation work a single transaction can impose on a block builder.

One open question sits above all of this. EIP-8141 is not the only native account-abstraction design on the table — client teams have been weighing it against the competing EIP-8130 proposal, and that comparison was live in the same discussions that produced the 10 September 2026 deadline for execution-client preference rankings . SFI status means EIP-8141 is scheduled, not frozen. Its specification can change, and the account-abstraction question inside Hegotá is closer to settled than resolved.

The Privacy Bundle That Hasn't Made SFI Yet: EIP-8250 and EIP-8272

EIP-8250 and EIP-8272 are the two frame-transaction extensions that turn account abstraction into a usable privacy primitive, and neither one is scheduled for Hegotá. Both sit at Proposed for Inclusion in the EIP-8081 meta document, both are Draft, and both list EIP-8141 as a hard requirement . That dependency matters for reading the odds: a scheduled parent does not pull its children along, so the privacy outcome most commentary attached to Hegotá currently rests on one of three EIPs actually being on the calendar.

EIP-8250, Keyed Nonces for Frame Transactions, was created on 16 April 2026 by Thomas Thiery, Toni Wahrstätter, lightclient and Vitalik Buterin. It replaces the single linear sender nonce with a nonce_keys/nonce_seq pair, where each key manages an independent sequence tracked by a NONCE_MANAGER system contract at 0x0000000000000000000000000000000000008250. MAX_NONCE_KEYS is 16 and MAX_NONCE_SEQ is 2⁶⁴ − 1, with key 0 aliasing the legacy account nonce for backward compatibility . The problem it solves is head-of-line blocking. Privacy pools route many unrelated users through one shared sender address, so under today's linear nonce a single stuck or delayed transaction blocks or invalidates every pending withdrawal queued behind it. Disjoint non-zero key sets are replay-independent, which lets concurrent transactions leave the same sender — a nonce domain derived from a privacy nullifier being the worked example in the specification . One caveat is easy to miss: EIP-8250 does not relax EIP-8141's public-mempool guidance of one pending frame transaction per sender. It removes the protocol-level obstacle; keyed-aware mempool policy is still unfinished work.

EIP-8272, Recent Roots for Frame Transactions, was created on 15 May 2026 by Thomas Thiery, Vitalik Buterin and Toni Wahrstätter, and addresses a different bottleneck: validation. A frame transaction can declare verified recent commitment-tree roots inside its signed envelope, so a spend proof can be checked without reading mutable storage belonging to other accounts . Public mempool rules cannot safely allow arbitrary reads of changing third-party storage, because a state change under the reader invalidates queued transactions and opens a denial-of-service vector. A system contract at 0x0000000000000000000000000000000000008272 stores roots keyed by source_id and slot; clients verify before frame execution that each referenced source, slot and root exists and is still recent. RECENT_ROOT_LENGTH is 8192 with a usable window of 8191, and MAX_RECENT_ROOT_REFERENCES is 16 .

The Ethereum Foundation's Protocol Architecture group set out why the three EIPs are argued as a set rather than individually: with EIP-8141, EIP-8250 and EIP-8272 in place, a privacy pool can act as both the sender and the fee payer while anyone broadcasts the transaction, so the broadcaster no longer needs special privileges and the trusted relayer drops out of the design . Wahrstätter's public framing has been similar. "Together with Frames, these enable privacy pools where the pool itself can pay fees," he said, describing the combination of protocol-level inclusion guarantees and reduced wallet activity exposure (source: Decrypt, 2026-08).

For traders reading this as a catalyst, the distinction to hold is between scheduled and candidate. Roughly 50 EIPs currently sit at PFI with none formally declined, so PFI is a wide holding pen rather than a shortlist . If EIP-8250 and EIP-8272 are cut, they remain eligible for a later fork — but privacy pools would keep depending on relayers through Hegotá, and the "native privacy" headline attached to the upgrade would describe an unfinished stack (source: Cointelegraph, 2026-08).

Why FOCIL and Frame Transactions Have to Ship Together for Privacy to Work

FOCIL and Frame Transactions solve two different halves of the same problem, and either one alone leaves privacy pools dependent on a trusted intermediary. EIP-7805 governs whether a transaction gets into a block; EIP-8141 governs who can pay for it and how it is authenticated . Both are now Scheduled for Inclusion in EIP-8081, after ACDE #244 on 27 August 2026 moved EIP-8141 to SFI . That pairing is the reason the privacy framing attached to Hegotá is credible at all.

Consider each without the other. Frames without FOCIL gives a privacy-pool withdrawal a clean protocol-native shape — the pool acts as sender and fee payer, gas is approved in a dedicated frame, and no relayer needs special privileges to broadcast it . But a single builder or proposer can still decline to include it. Under proposer-builder separation, block content is chosen by parties who can screen transactions by address or calldata pattern, and a privacy-pool withdrawal is a recognisable target. A more private transaction format does not create a right to be included.

FOCIL without Frames inverts the gap. An inclusion-list committee of 16 validators builds lists from its mempool view during roughly the first 8 seconds of slot N, and attesters only vote for slot N+1 blocks that satisfy every stored list from non-equivocating members — so inclusion becomes a condition of canonicality rather than a builder's discretion . That guarantee only applies to a valid, fee-paying transaction already sitting in the mempool. Getting it there is the current friction point: a user withdrawing to a fresh address has no ETH to pay gas, so a relayer signs and broadcasts on their behalf, reintroducing exactly the intermediary the design is meant to eliminate.

Ethereum Foundation researcher Toni Wahrstätter has framed the combination as the point of the bundle — that together with Frames, these changes enable privacy pools where the pool itself can pay fees, pairing protocol-level inclusion guarantees with reduced wallet activity exposure . The Ethereum Foundation's Protocol Architecture post on the Hegotá meta thread makes the same argument from the implementation side: with the pool as both sender and fee payer, anyone can broadcast, so the broadcaster stops being a privileged role .

One caveat deserves emphasis, because the shorthand around this upgrade routinely overstates it. None of this makes Ethereum a private chain. Ordinary ETH transfers stay fully transparent after Hegotá — amounts, addresses and contents remain public on-chain, exactly as they are today. FOCIL itself hides nothing; it enforces inclusion of transactions whose contents are still entirely visible . What the pairing removes is protocol-level friction that currently pushes privacy applications onto trusted relayers. Users see privacy only where an application layers a privacy protocol on top, and only after wallets, clients, mempool policy and audits catch up .

Hegotá's Timeline: What Has to Happen Before Q2 2027

Hegotá's Q2 2027 date is an expectation, not a commitment. Ethereum.org's draft Hegotá roadmap page lists Q2 2027 as expected but not confirmed , and the tracking document EIP-8081 still carries blank activation entries for Sepolia, Hoodi and mainnet, to be filled once client teams settle timings . Until those fields are populated, there is no devnet or testnet schedule to hold anyone to.

The first gate is the fork ahead of it. Glamsterdam targets the second half of 2026, and Hegotá work only begins in earnest once that upgrade clears — a successor fork cannot outrun its predecessor through devnets, public testnets and mainnet activation . Any Glamsterdam slippage shifts Hegotá's window with it, which is why the 2027 framing has stayed loose.

The next concrete checkpoint is closer. Execution client teams were asked to submit Hegotá preference rankings by 10 September 2026 . Those rankings are the practical filter on which of the roughly 50 Proposed for Inclusion items get client attention, since implementation capacity — not enthusiasm on a call — determines what reaches a devnet . EIP-8250 and EIP-8272 both sit in that pool, so the rankings are the nearest readable signal on whether the privacy bundle travels together or piecemeal.

A rough sequence, on current information:

• 10 September 2026 — client preference rankings due; PFI items with no client sponsor lose momentum .
• H2 2026 — Glamsterdam activation; Hegotá specification work moves to the front of the queue .
• Undated — devnets, then Sepolia and Hoodi activation epochs written into EIP-8081, then a mainnet block .

One piece of context that is settled: the name. Ethereum names execution-layer forks after Devcon host cities and consensus-layer forks after stars, so Hegotá is a portmanteau of the EL release "Bogotá" and the CL release "Heze" . EIP-8081 itself was created on 11 November 2025 by Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo and Parithosh Jayanthi, and remains in Draft .

What Could Still Change — and What to Watch Next

Nothing in Hegotá's current scope is locked. Scheduled for Inclusion is a planning status, not a specification freeze: when All Core Devs Execution call #244 moved EIP-8141 to SFI on 27 August 2026, developers explicitly noted that the Frame Transaction specification may still change . Both scheduled items — EIP-7805 and EIP-8141 — remain in Draft status, and reporting on the scoping process has noted that proposals which miss the cut can still be reconsidered for a later upgrade .

The scoped set can also grow before it shrinks again. Roughly 50 EIPs currently sit at Proposed for Inclusion, and none has been formally declined . That queue includes gas-accounting and state-growth work with real mainnet consequences — EIP-8131's uniform floor of 64 gas per user-controlled transaction byte, EIP-8279 extending that accounting to Block Access List data, and EIP-8368's recalibration of state-growth pricing as the gas limit rises toward 500–600M . Any of those could displace a privacy item if client teams rank throughput and state health higher than relayerless withdrawals.

Shipping code is a separate gate from shipping a specification. Frame transactions require execution clients to implement transaction type 0x06, frame execution, APPROVE/TXPARAM/SIGPARAM semantics, gas accounting and mempool restrictions; wallets need per-frame receipts, payer semantics and new validation paths; explorers and indexers need to parse frame receipts and payer fields . EIP-8250 is candid about its own gap: it removes the protocol-level obstacle to concurrent sends from one address, but does not relax EIP-8141's public-mempool guidance of one pending frame transaction per sender, leaving keyed-nonce-aware mempool policy still to be designed .

Three concrete signals are worth tracking, in order of proximity:

• The client preference rankings. Execution client teams were asked to submit Hegotá rankings by 10 September 2026 — the first hard read on whether privacy, account abstraction or gas repricing leads the fork .
• PFI-to-CFI movement for EIP-8250 and EIP-8272. Neither has cleared Considered for Inclusion. Until they do, the relayerless privacy-pool story stays theoretical, since it needs all three EIPs .
• The EIP-8141 versus EIP-8130 resolution. Developers have been weighing the scheduled Frame Transaction design against the competing EIP-8130 native account-abstraction approach; a reversal here would reset the privacy bundle's foundation .

The practical takeaway for traders and builders: treat Hegotá as a 2027 roadmap item with two anchor tenants and an unsettled middle, not as a shipped feature set. Ethereum.org's draft roadmap page lists Q2 2027 as expected but not confirmed, and EIP-8081 still has blank activation entries for Sepolia, Hoodi and mainnet . Watch the ACDE call notes rather than the headlines — the stage transitions in EIP-8081 are the only record that reliably tracks what is actually being built.

Frequently asked questions

Is Hegotá's scope finalized?

No. Hegotá's scope is still open. EIP-8081, the "Hardfork Meta - Hegotá" tracking document created on 2025-11-11 by Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo and Parithosh Jayanthi, remains in Draft status with blank activation entries for Sepolia, Hoodi and mainnet . Of the roughly 66 candidates discussed in the August 2026 scoping push, only two — EIP-7805 (FOCIL) and EIP-8141 (Frame Transaction) — hold Scheduled for Inclusion status, while about 50 sit at Proposed for Inclusion with none formally declined . Read the list as a working shortlist, not a locked feature set.

Does Hegotá make Ethereum transactions private?

No. Ordinary ETH transfers stay fully transparent after Hegotá — sender, recipient and amount remain visible on-chain, and FOCIL in particular hides nothing about transaction contents . What the privacy bundle changes is protocol-level friction: EIP-8141, EIP-8250 and EIP-8272 would let a privacy pool act as both sender and fee payer so any party can broadcast the transaction without special privileges, removing the trusted-relayer dependency that privacy apps rely on today . Privacy still comes from applications built on top, not from the base layer.

What's the difference between FOCIL and Frame Transactions?

They solve different problems. FOCIL (EIP-7805) is a censorship-resistance mechanism: an inclusion-list committee of 16 validators (IL_COMMITTEE_SIZE = 2^4) is selected each slot, builds inclusion lists from its mempool view during roughly the first 8 seconds, and attesters vote only for blocks satisfying those lists — making inclusion a condition of block canonicality . EIP-8141 restructures the transaction itself, adding FRAME_TX_TYPE 0x06 with separate validation, gas-approval and execution frames to enable native account abstraction — sponsored gas, key rotation, batch calls and alternative signature schemes . A relayerless privacy pool needs both: Frame Transactions to pay its own fees, FOCIL so the resulting transaction cannot be quietly excluded.

Why are EIP-8250 and EIP-8272 not scheduled yet?

Both are dependent proposals still at Proposed for Inclusion in EIP-8081, and each explicitly requires EIP-8141 to ship first . EIP-8250, Keyed Nonces (created 2026-04-16), replaces the single linear sender nonce with up to 16 independent nonce keys managed by a system contract at 0x…8250, fixing the head-of-line blocking that lets one stuck transaction stall unrelated withdrawals from a shared pool address . EIP-8272, Recent Roots (created 2026-05-15), lets a frame transaction declare verified commitment-tree roots — RECENT_ROOT_LENGTH 8192, MAX_RECENT_ROOT_REFERENCES 16 — so spend proofs validate without unsafe reads of mutable third-party storage . Neither has cleared client review, and both remain Draft.

When will Hegotá activate on mainnet?

There is no confirmed date. Ethereum.org's draft Hegotá roadmap page lists Q2 2027 as expected but not confirmed, and EIP-8081 carries no activation entries for Sepolia, Hoodi or mainnet until client teams settle timings . The schedule is gated upstream by Glamsterdam, targeted for the second half of 2026, since serious Hegotá implementation work only begins once that fork clears . Execution client teams were asked to submit Hegotá preference rankings by 10 September 2026, which is the next concrete checkpoint .

Enjoyed this article? Subscribe to get new stories by email whenever they're published.

Subscribe