Ethereum Hegota Upgrade

Main Paper

Ethereum Hegota Upgrade - Consensus HK[33] -Shuen Rui (Impossible Finance), Rongxin (WPRC)                                12 Feb 2026

Hegota is a late-2026 Ethereum upgrade track aiming to (i) reduce the hardware burden of verifying blocks, (ii) make transaction inclusion harder to censor, and (iii) reduce pre-inclusion intent leakage that enables common MEV strategies. [1][2]

(i) Node operators benefit if verification no longer requires storing ever-growing state locally — reduces the "data-center only" drift that's pricing out solo stakers [4][9]. (ii) Users benefit if transaction inclusion becomes protocol-enforced rather than dependent on a small set of builders/relays [3]. (iii) Traders and apps benefit if fewer transactions leak intent pre-inclusion, reducing front-run/sandwich exposure and reliance on private order flow ($1.38B extracted across EVM networks in 2023) [5][10].

The point is pipeline hardening: storage burden (state) + inclusion power (builders) + intent visibility (mempool) are three separate leverage points; addressing only one tends to push the problem into the other two. [3][5][9]

A user wants to execute a large on-chain swap without (a) getting copied/sandwiched by bots that see the order early, or (b) being quietly delayed or excluded by a dominant block builder. Today: The user submits to the public mempool. A bot sees the swap, front-runs it, and profits off the price movement. The user can also route to a private relay like Flashbots Protect — but now they're trusting a centralized intermediary not to censor or leak. After Hegota: (i) User sends an encrypted transaction envelope — the network can validate fees and nonce but not the trade intent [5]. (ii) A validator committee publishes inclusion lists containing pending transactions they observed [3]. (iii) The block builder includes listed transactions or risks producing a block that won't be treated as canonical by fork choice [3]. (iv) After inclusion, decryption keys release and the payload executes — the "visible-in-mempool" window that enables common MEV strategies is gone [5]. Failure mode: If key release fails or is delayed, the envelope still executes and pays fees (preserving chain liveness), but the payload is skipped. The user pays gas but isn't front-run, and the chain doesn't stall. This is the explicit design trade-off: liveness over guaranteed execution when key infrastructure fails [5].

1. Verkle Trees: WPRC Discussion [23]: https://docs.google.com/document/d/1MFBepgKaDpoUda0gpyuxqu_ZOvP1ACYd1GQnrntYIZI

Makes verifying Ethereum more like “check a small proof” than “store a giant database,” which lowers the long-run hardware floor for running a node. [4][9]. What & why: Replaces the Merkle Patricia Trie with a Verkle-based commitment scheme (Pedersen commitments on the Bandersnatch curve) so state access can be proven with much smaller witnesses, enabling stateless-leaning verification. This targets the core decentralization risk: state is ~50 GB and grows permanently, making solo staking progressively harder. [4][9]. How: (i) Wider tree (256-way branching vs current hexary/16) reduces depth and proof path length. (ii) Vector commitments eliminate sibling-hash disclosure required in Merkle proofs, compressing membership proofs significantly. (iii) Multi-proof aggregation compresses many per-block state accesses into fewer proofs, making witness delivery feasible within slot timing. [4][12]. Migration: Dual-tree transition — new Verkle tree for writes and accessed state, frozen read-only Merkle tree for legacy data. Exact fork scope and sequencing remain uncertain. [1][4]. Comparison: (i) vs. current Merkle Patricia Trie: Much smaller proofs, but shifts cryptographic assumptions from hash collision resistance (well-understood) to discrete log hardness (newer). (ii) vs. Binary Merkle + STARKs: STARKs are post-quantum secure; Verkle is not. Verkle has a more mature implementation path today, but Vitalik has discussed potentially skipping it for a STARK-based tree if complexity proves too high. [5]. Trade-offs: Implementation and migration complexity is the primary schedule risk (explicitly raised in planning materials). [1] (ii) Statelessness increases dependence on witness generation/serving; if that concentrates in a few providers, decentralization gains can be diluted. [9]

1. EIP-4762: If proofs become part of what nodes must handle, this EIP makes proof-related work "paid for" — so attackers can't cheaply force expensive witnesses. What & why: Reprices state access to reflect witness costs; without this, a stateless path can be attacked by cheaply forcing large witnesses. [6] How: (i) Gas schedule incorporates witness-related accounting for state operations. [6] (ii) This pushes apps toward “witness-friendly” access patterns over time. [6] Trade-offs: (i) Can create fee surface changes for state-heavy DeFi; magnitude depends on final parameterization and rollout. [6]

2. FOCIL EIP-7805: Today, a handful of builders decide which transactions make it on-chain and can quietly drop any they don't like. FOCIL adds a validator jury whose "must include" list is enforced by consensus — ignore it and the network rejects your block. What & why: A committee publishes inclusion lists; blocks that ignore them are penalized via fork choice. This moves inclusion from social norm to consensus-level constraint. [3][7] How: (i) Random committee selection per slot from existing validator set. (ii) Committee gossips inclusion lists built from their mempool view. (iii) Builders must include listed transactions (subject to validity and full-block constraints). (iv) Attesters treat non-compliance as disqualifying when voting — exclusion becomes a consensus fault, not a missed revenue opportunity. Security requires only a 1-of-N honesty assumption among committee members. [3] Comparison: (i) vs. ePBS (Glamsterdam): ePBS separates building from proposing but doesn't mandate inclusion. FOCIL closes that gap. [7] (ii) vs. private order flow (Flashbots): Private channels reduce some MEV but concentrate routing and censorship power. FOCIL moves guarantees into consensus rules. [3][5] Trade-offs: (i) Adds bandwidth and coordination overhead per slot. [3] (ii) Committee members receive no explicit rewards — free-rider risk if validators opt out to save bandwidth. [3] (iii) Does not currently cover blob transactions. Post-Fusaka, L2s consume most blockspace via blobs; without blob inclusion guarantees, censorship pressure can migrate to that layer. [3][2]

3. Encrypted Mempool EIP-8105: Submitting a transaction today is like playing poker face-up. Encrypted mempools let you play face-down — the network knows you're playing and charges you for it, but nobody sees your hand until the deal is done. What & why: Introduces an encrypted transaction type where validity fields (gas, fee, nonce) are visible but the payload is hidden until keys release after inclusion. Aims to make public submission safe without private order flow dependence. [5] How: (i) Envelope/payload split — calldata encrypted, envelope always pays fees. (ii) Key-release mechanism still debated: threshold, delay, or committee-based designs. (iii) Proposal supports multiple key providers via trust-graph rather than locking to one committee. Plaintext transactions remain unchanged. [5] Competing proposal: LUCID targets the same headliner slot — validators directly control encryption rather than external key providers. Both under ACD evaluation. [2][12] Comparison: (i) vs. Flashbots Protect / private mempools: Off-protocol, trusted, fragmenting. Enshrined encryption is protocol-native and permissionless. [5] (ii) vs. commit-reveal: Traditional approach requires two transactions and multi-block latency. This provides single-transaction, same-block execution. [5] Trade-offs: (i) Key provider concentration can migrate centralization from builders to key providers — a risk migration, not elimination. [5][9] (ii) Liveness-first envelope semantics impose direct user costs when key release fails (gas paid, payload skipped); final execution guarantees are not yet stable. [5] (iii) MEV compression alters builder economics in ambiguous directions — could reduce private-orderflow advantage (decentralizing) or compress margins toward scale (centralizing). [5]

Thomas Thiery ("soispoke") – EF. Lead author of EIP-7805; focuses on making inclusion enforceable via fork choice rather than builder discretion. [3] Barnabé Monnot – EF.  Co-author of EIP-7805; mechanism design around builder centralization and how consensus rules can bound it. [3] Terence Tsao — Offchain Labs. Co-author of EIP-7805; signals rollup teams care about L1 inclusion guarantees as L1 becomes a settlement/ordering layer. [3] Guillaume Ballet — Ethereum client engineering. Author of EIP-4762; treats statelessness as an economics problem — without repricing, witness-heavy verification is DoS-vulnerable. [6] Jannik Luhn — Shutter Network. Drives the encrypted mempool proposal and design space; background in encrypted mempool deployments on Gnosis Chain. [5][12] Wei Han Ng & Carlos Pérez — EF, Stateless Consensus team. Co-authored "The Future of Ethereum's State," framing state growth as the primary decentralization constraint. [9]

Marc Harvey-Hill — Nethermind. Popularized the "Holy Trinity" framing (ePBS + inclusion enforcement + encryption) used to argue for composing these features. [7]

[1] Ethereum Foundation. "Hegota Timeline." 22 Dec 2025. [2] Ethereum Foundation. "Checkpoint #8." 20 Jan 2026. [3] EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL). 1 Nov 2024. [4] Ethereum.org. "Verkle Trees." Updated 25 Aug 2025. [5] Ethereum Research / Ethereum Magicians. "Universal Enshrined Encrypted Mempool." 17 Dec 2025. [6] EIP-4762: Statelessness gas cost changes. 3 Feb 2022. [7] Etherworld. "Hegota Should Complete the Holy Trinity of Censorship Resistance." 2026. [9] Ethereum Foundation (Wei Han Ng, Carlos Pérez). "The Future of Ethereum's State." 16 Dec 2025. [10] Amiri et al. VLDB 2024 (Vol. 17). MEV extraction figures across EVM networks. [12] Ethereum Magicians. "EIP-8105: Universal Enshrined Encrypted Mempool." 17 Dec 2025.

Definition: Hegota is Ethereum's second hard fork of 2026 (targeting H2), following Glamsterdam. It combines two major thrusts: making Ethereum stateless (validators no longer need to store the full chain) and making it censorship-resistant at the protocol level (no single actor can block or front-run your transactions).

Name origin: "Hegota" = Heze (consensus layer, named after a star) + Bogota (execution layer, named after a Devcon host city).

Key candidates:

• Verkle Trees — compact state proofs enabling stateless clients
• FOCIL (EIP-7805) — fork-choice enforced inclusion lists
• Encrypted Mempools (EIP-8105) — hide transaction contents until block inclusion
• State/History Expiry — pruning old data to reduce node storage requirements

Why it matters: Ethereum's state is ~50 GB and growing permanently. Running a node requires increasingly expensive hardware, pushing validation toward data centers. Meanwhile, a handful of builders dominate block production and could censor transactions at will. Hegota attacks both problems simultaneously.

Definition: Verkle Trees are a new data structure that replaces Ethereum's current Merkle Patricia Trie. They use a cryptographic technique called Pedersen commitments (on the Bandersnatch elliptic curve) to produce dramatically smaller proofs of state data. "Verkle" = Vector commitment + Merkle.

The problem they solve:

• Currently, proving a single piece of state data requires a "witness" of ~3 KB per account
• Worst case: ~18 MB per block — too large to broadcast within Ethereum's 12-second slot
• Result: every validator must store the entire ~50 GB state locally
• This makes solo staking progressively harder as state grows ~60 GB/year

How Verkle Trees fix it:

• Proof size drops from ~3 KB to ~200 bytes per account (15x smaller)
• Wider tree (width 256 vs current 16) = shallower tree = shorter proof paths
• Vector commitments let you prove a value without revealing sibling nodes
• Multiple proofs within a block compress into a single proof via multi-proof aggregation

The transition plan:

1. After the hard fork, a new Verkle tree stores all new edits and accessed state
2. The old Merkle Patricia Trie is frozen (read-only, no longer editable)
3. Both run in parallel during migration — the old tree is gradually retired
4. Addresses expand from 20 to 32 bytes to support the new structure

Plain language: Imagine Ethereum's current state as a library where checking out any book requires copying the entire floor plan. Verkle Trees replace this with a system where you only need a tiny index card to prove any book exists. Validators verify the index cards — they don't need to store the library.

Definition: FOCIL (EIP-7805) is a mechanism where a committee of randomly selected validators publishes lists of transactions that must be included in the next block. If a builder ignores these lists, the network rejects their block. Censorship resistance is enforced by consensus, not by goodwill.

The problem it solves:

• A few sophisticated builders dominate Ethereum's block production
• Builders have the power to censor transactions — simply by not including them
• Today this power is rarely exercised, but it's a social norm, not a technical guarantee
• If a government or regulator pressured dominant builders, there's currently no structural defense

How FOCIL works:

1. Committee selection: Each slot, a random set of validators is chosen as Inclusion List (IL) committee members
2. IL construction: Each member looks at the public mempool and builds a list of valid pending transactions
3. Builder constraint: The block builder must include transactions from all collected ILs
4. Fork-choice enforcement: Attesters (other validators) only vote for blocks that satisfy IL constraints. A block that ignores ILs gets no votes and can't become canonical
5. Safety valve: If the block is genuinely full (at gas limit), missing some IL transactions is tolerated

Security model: Requires only a 1-out-of-N honesty assumption. As long as one committee member honestly includes a transaction, censoring it requires either bribing the entire committee or filling every block to capacity — both far more expensive than today's approach of simply paying a builder to exclude it.

Plain language: Today, one builder decides what goes into a block. FOCIL means a jury of validators also gets a say. If the jury says "include this transaction," the builder must comply or the entire network rejects their block.

Definition: Encrypted mempools wrap transactions in "encrypted envelopes" that hide their contents (what the transaction actually does) until after they're included in a block. Builders and searchers can see that a transaction exists and that it pays fees, but can't see what it does.

The problem it solves:

• When you submit a transaction, its contents are visible in the public mempool before inclusion
• MEV searchers see your trade and front-run it, sandwich it, or back-run it
• In 2023, MEV bots extracted $1.38B+ from Ethereum users
• Users responded by routing through private channels, which centralizes power with builders who control private order flow
• FOCIL can force inclusion, but if builders can still see contents, they can manipulate ordering

How it works:

1. Envelope structure: Transaction specifies gas, fee, and nonce (needed for validity) but the actual calldata/payload is encrypted
2. Always-execute guarantee: The envelope always executes and pays fees, even if decryption fails. This prevents liveness attacks
3. Decryption timing: Decryption keys become available only after the transaction is committed to a block
4. Opt-in: Plaintext transactions continue to work alongside encrypted ones — this is additive, not mandatory

Plain language: Right now, submitting a transaction is like playing poker with your cards face-up. Encrypted mempools let you play face-down until the hand is dealt. Searchers can see you're playing, but not what you're playing.

Definition: A term coined by Marc Harvey-Hill (Nethermind) for three complementary mechanisms that together provide end-to-end censorship resistance across Ethereum's entire transaction pipeline. Each addresses a different attack surface:

• ePBS (EIP-7732, shipping in Glamsterdam): Removes trusted relays as censorship chokepoints between proposers and builders
• FOCIL (EIP-7805, proposed for Hegota): Prevents builders from silently excluding transactions
• Encrypted Mempool (EIP-8105, proposed for Hegota): Prevents builders from seeing or front-running transaction contents

Why all three? Each alone has gaps. ePBS removes relays but builders can still censor. FOCIL forces inclusion but builders can still see and reorder. Encrypted mempools hide contents but don't guarantee inclusion. Only together do they close every seam in the pipeline.

Definition: Two complementary strategies to stop Ethereum's storage requirements from growing forever. History expiry prunes old block data. State expiry archives old account/contract data. Together, they could reduce node storage from terabytes to gigabytes.

History Expiry (already partially live):

• Clients can drop old blocks and transactions (currently: everything pre-Merge)
• Saves 300-500 GB per node
• Old data doesn't disappear — available via torrents, Portal Network, archive providers
• No consensus change required; clients simply stop storing what they don't need

State Expiry (proposed, not yet in any fork):

• Periodically archive old state trees (~1 year periods)
• Nodes only hold the most recent 1-2 trees
• Accessing expired state requires a Verkle/Merkle proof against the archived root
• The archived root itself is kept forever (just a single hash — trivial storage)

Scale of the problem:

• Full chain history: 3+ TB and growing
• Active state (accounts, contracts, storage): ~50 GB, grows permanently
• Archive node total: 15-20 TB
• Even accounts untouched since 2015 consume state space forever

Plain language: Ethereum currently keeps every document ever filed, forever, on every clerk's desk. History expiry moves old documents to a warehouse. State expiry goes further — clerks clear their desks entirely and keep only a receipt proving what was there.

Ethereum's post-Merge development phases:

• The Surge — rollup scaling (blob throughput, data availability)
• The Verge — statelessness and light-client verification (Verkle Trees)
• The Purge — historical cleanup (state/history expiry)
• The Splurge — protocol simplification

The 2025-2026 upgrade sequence:

1. Pectra (May 2025): Surge/Splurge — EIP-7702 account abstraction, validator improvements
2. Fusaka (Dec 2025): Surge — PeerDAS data availability sampling, blob scaling
3. Glamsterdam (H1 2026): Surge/Verge — ePBS, Block-level Access Lists, gas repricing
4. Hegota (H2 2026): Verge/Purge — Verkle Trees, FOCIL, encrypted mempools, state expiry

Why twice-yearly forks? Smaller, more frequent upgrades are less risky per-fork than annual monolithic releases. Each fork ships fewer changes, is easier to test, and creates a predictable cadence for the ecosystem to plan around.

Timeline (as of Feb 2026):

• Named: December 18, 2025 (ACDE call #226)
• Headliner EIP proposals: January 8 – February 4, 2026
• Deliberation: ongoing through late February
• Headliner not yet formally selected

Candidate features:

• FOCIL (EIP-7805): Already considered for Glamsterdam (pre-CFI), deferred to Hegota. Strong community support
• Encrypted Mempools (EIP-8105): Proposed as headliner. Complements FOCIL — argument to ship both together
• Verkle Trees: Top candidate, but implementation complexity means it may slip to I-star (the fork after Hegota)
• State/History Expiry: Partial history expiry already live post-Pectra. Full state expiry still under research
• 6-Second Slots: Under discussion but likely deferred to I-star