Ethereum's Hegota Upgrade: Can State Expiry Finally Solve the Bloat Problem?

Ethereum's state never forgets. Every account ever created, every storage slot ever written by a smart contract, and every byte of deployed code remains in the global state trie indefinitely. As of early 2026, that trie contains roughly 360 million accounts and 1.5 billion storage slots, with the on-disk state database in Geth consuming approximately 390 GiB. Running a full node now demands 2 TB of NVMe storage at minimum, and that number climbs every week.

This is the state bloat problem: an ever-growing dataset that every full node must store, index, and serve. The Ethereum Foundation's Stateless Consensus team flagged it as a threat to decentralization in their December 2025 report, “The Future of Ethereum's State”, warning that if only well-funded operators can afford to run nodes, censorship resistance suffers. The upcoming Hegota upgrade, slated for late 2026, is the first hard fork where state expiry may finally move from research to implementation.

What Is State and Why Does It Only Grow?

Ethereum distinguishes between history and state. History is the sequence of blocks and transactions: it can be pruned because past blocks are not needed to validate the current chain tip. EIP-4444 already allows clients to drop block bodies older than about one year. State is different. It is the current snapshot of all accounts, contract storage, and code that the EVM needs to execute the next block.

In Ethereum's account model, every account persists once created. A contract deployed in 2016 that nobody has called in years still occupies space in every full node's state trie. Storage slots written by abandoned DeFi protocols remain indexed. Unlike Bitcoin's UTXO model, where spent outputs are naturally removed from the active set, Ethereum's state only grows.

Key distinction: History expiry (EIP-4444) drops old block bodies and receipts. State expiry targets the live dataset of accounts and storage slots. They solve different problems: history affects initial sync time, while state affects every block execution.

How Fast Is State Growing?

The problem accelerated in late 2024 when Ethereum validators raised the block gas limit from 30 million to 60 million. According to EIP-8037, daily new state creation jumped from approximately 105 MiB to 326 MiB. At that pace, the state database grows by roughly 7 to 14 GiB per week, depending on the client. Archive nodes, which store every historical state root, can reach 15 TB or more.

This growth is not just a storage cost. Larger state means slower disk reads, more RAM pressure for caching, and longer initial sync times. An Ethereum Research analysis demonstrated that keeping only one year of active state would reduce the dataset from roughly 359 GB to 81 GB: a 78% reduction. Median storage read latency dropped 46%, and P99 block insertion time fell 21%.

Where the bytes come from

Not all state is created equal. The Ethereum Research analysis found that storage trie nodes (contract storage slots) are the largest component of state, followed by account nodes and contract code. Inactive DeFi contracts, abandoned token approvals, and dust accounts from airdrops collectively occupy significant space despite generating no economic activity.

State Expiry Proposals: Two Competing Approaches

The Ethereum Foundation's Stateless Consensus team outlined two main variants of state expiry in their December 2025 report. Both share the same goal: move inactive state out of the hot dataset while preserving the ability to restore it later.

Mark, expire, revive

In this model, each state element (account, storage slot, or code chunk) is tagged with a “last touched” timestamp or epoch. After a defined inactivity period, the element is removed from the active trie but its cryptographic commitment (a hash) is retained. Any transaction can revive expired state by providing a proof that the data matches the retained commitment, along with gas payment for the resurrection cost. EIP-8188 proposes adding a “last-written block” field to every account and storage slot to enable this tracking.

Multi-era expiry

This approach divides chain history into fixed-length eras. State created or accessed during a given era belongs to that era's subtree. When an era expires, its entire subtree can be pruned, while any still-active entries must be re-witnessed into the current era. This simplifies bookkeeping but forces applications to periodically “touch” their state to keep it alive.

Leaf-level expiry (EIP-7736)

The most concrete proposal is EIP-7736, which targets leaf-level data in a Verkle tree. Each extension node carries an “update epoch” counter. When an epoch is due to expire, the extension and its suffix nodes are deleted. The draft specifies an epoch length of 15,778,800 seconds (roughly six months) with two concurrently unexpired epochs, meaning state remains accessible for about one year before expiring. A new transaction type handles resurrection using a Verkle proof.

Research, not shipping code: As of late 2026, none of these proposals have been finalized for a specific hard fork. EIP-7736 remains in Draft status and depends on the tree migration (discussed below). The Ethereum Foundation's report explicitly states it is a team proposal, not official EF consensus.

The Tree Migration Prerequisite

State expiry proposals assume a different data structure than Ethereum's current hexary Merkle Patricia Trie. EIP-6800 proposed migrating to a unified Verkle tree, which produces smaller witnesses and enables stateless clients that verify blocks without storing the full state.

However, the Ethereum roadmap has shifted. By mid-2026, core developers were debating whether to skip Verkle trees entirely in favor of binary hash trees, which offer quantum resistance that Verkle's elliptic-curve-based commitments do not. The shift introduces uncertainty: EIP-7736 explicitly depends on EIP-6800, so if the tree format changes, the state expiry specification must be rewritten.

Regardless of which tree format wins, the migration itself is enormous. Every account, storage slot, and code hash must be converted from the current trie into the new structure: a one-time operation that touches the entire state. Proposals for offline migration (such as EIP-8347 for partitioned binary trees) aim to spread this cost across multiple blocks rather than halting the chain.

Comparing State Expiry Proposals

Near-Term Mitigation: Repricing State Creation

While state expiry requires a tree migration and years of engineering, one near-term fix is already advancing. EIP-8037 proposes raising the gas cost of creating new state elements so that growth does not outpace hardware improvements as the gas limit continues to rise. Under the proposal, contract deployment costs increase roughly 10x and new account creation roughly 8.5x. The target is approximately 60 GiB of new state per year at a 300 million gas limit with 30% average state-gas utilization.

EIP-8037 reached Last Call status with a deadline of November 1, 2026, and was under consideration for the Glamsterdam upgrade. The approach acknowledges a fundamental tension: gas pricing cannot guarantee a fixed growth rate because demand elasticity is unknown. If developers value cheap state creation highly, gas repricing merely slows growth rather than stopping it.

What Breaks When State Expires

State expiry is not just a node operator concern. It changes assumptions that smart contracts have relied on since Ethereum launched.

Contracts that assume permanent storage

Today, a contract can write to a storage slot and read it back years later with certainty. Under state expiry, a read to an expired slot would fail unless the caller provides a resurrection proof. This means that contracts with infrequently accessed storage (governance timelocks, vesting schedules, long-duration escrows) would need to either periodically touch their state or rely on callers to supply witnesses.

Token balances and approvals

ERC-20 balances stored in a mapping could expire if the holder does not interact with the token contract for a full expiry period. The tokens are not lost: the balance can be revived with a proof. But the user experience shifts. Wallets would need to detect expired balances and automatically construct resurrection transactions before transfers.

Cross-contract reads

Composability in DeFi relies on contracts reading each other's state. If a lending protocol reads an expired price oracle storage slot, the call reverts. DeFi protocols would need fallback logic or require that critical state be kept alive through periodic writes.

Community pushback

The Ethereum Magicians forum raised concerns about expiring state that is frequently read but rarely written. A price oracle updated monthly might be read thousands of times per day. Under write-based expiry tracking, it could still expire between updates. One proposed mitigation: differentiate pricing between initial-epoch reads and subsequent reads, incentivizing callers to pay for resurrection early in a cycle.

The Ethereum Foundation's Three-Pronged Strategy

The December 2025 blog post outlined three complementary approaches, not just state expiry:

• State expiry: moving inactive state out of the hot dataset, recoverable with proofs
• State archive separation: splitting hot (frequently accessed) and cold (historical) data so that node performance stays stable as the chain grows
• Partial statelessness: nodes store only subsets of state, with wallets and light clients caching what they need and providing witnesses to validators

In the near term, the team prioritizes archive improvements, better RPC infrastructure for serving historical queries, and easier-to-run partial stateless nodes. Full state expiry is positioned as a longer-term goal that depends on the tree migration and application-layer readiness.

Bitcoin's UTXO Model: A Natural Contrast

Bitcoin approaches state growth fundamentally differently. Its UTXO model tracks only unspent transaction outputs. When a UTXO is spent, it is removed from the active set. As of mid-2025, Bitcoin's UTXO set contained roughly 173 million entries occupying approximately 11 GB on disk. Compare that to Ethereum's 360 million accounts and 1.5 billion storage slots taking up 390 GiB.

Bitcoin is not immune to state growth concerns. Ordinals inscriptions and BRC-20 tokens contributed to a surge in UTXO count starting in 2023. But the UTXO model provides a built-in cleanup mechanism that Ethereum lacks: every spent output disappears from the active set. For a deeper comparison of how these models affect scalability, see our analysis of the long-term sustainability of Bitcoin's UTXO set.

Hegota: What We Know So Far

Hegota combines two upgrade tracks: “Hegotá” on the execution layer (named after Bogotá) and “Heze” on the consensus layer. Core developers named it at the final All Core Developers call of 2025, positioning it as the successor to Glamsterdam.

The scope is not finalized. Candidates discussed publicly include:

• Tree migration (Verkle or binary): the prerequisite for leaf-level state expiry
• History and state expiry mechanisms deferred from Glamsterdam
• Additional execution-layer optimizations and gas schedule adjustments

Whether state expiry itself makes it into Hegota or is deferred yet again depends on progress with the tree migration and community consensus on the backward-compatibility implications. The upgrade is targeted for the second half of 2026, but Ethereum's upgrade timeline has historically slipped.

Projected Node Storage Requirements

The following projections assume current growth rates continue and compare scenarios with and without state expiry. These are rough estimates, not predictions: actual growth depends on gas limit changes, demand patterns, and protocol upgrades.

The difference is stark. State expiry with a one-year window could bring node requirements back to levels achievable on consumer hardware, preserving the decentralization properties that make a full node network meaningful. Without it, Ethereum risks concentrating validation among professional infrastructure providers.

The Backward Compatibility Tension

Ethereum's greatest strength is also the obstacle to state expiry: backward compatibility. The social contract since genesis has been that deployed contracts work forever. State expiry breaks that promise, or at least adds conditions to it.

The counterargument: the current trajectory also breaks promises. If node costs rise to the point where independent validation becomes impractical, the network loses the decentralization that makes its guarantees meaningful in the first place. The Ethereum Foundation frames this as a tradeoff between application-layer convenience and protocol-layer sustainability.

Lessons from the Pectra upgrade suggest that the community can absorb breaking changes when the motivation is clear and migration paths exist. State expiry will require wallet-level support for resurrection proofs and may push DeFi protocols to adopt new patterns for state management.

Implications for Cross-Chain Development

Ethereum's state bloat problem is specific to its account model and the EVM's unbounded storage semantics. Other blockchain architectures avoid it through different design choices.

Bitcoin's UTXO model inherently limits state growth because spent outputs are pruned. Layer 2 protocols built on Bitcoin can inherit this efficiency advantage. For example, Spark operates off-chain using statechains and FROST threshold signatures. Since Spark transfers do not create persistent on-chain state, the protocol does not contribute to base-layer bloat. Transfers happen by rotating signing keys rather than writing to a global trie, sidestepping the entire class of problems Ethereum is now racing to solve.

For developers evaluating which stack to build on, state sustainability is an underappreciated factor. A protocol that requires periodic “keep-alive” transactions to prevent state expiry adds ongoing costs that compound over time, especially for applications with many long-lived user positions.

What to Watch Next

The path from research to shipping state expiry involves several milestones:

1. Tree format decision: Verkle trees versus partitioned binary trees. This gates every state expiry proposal
2. Migration mechanism: whether the conversion happens in a single fork or spreads across multiple blocks via offline migration
3. Expiry parameters: epoch length, number of concurrent epochs, and resurrection gas costs
4. Application readiness: wallet support for resurrection proofs and DeFi protocol updates
5. Hegota scope finalization: whether state expiry, the tree migration, or just the prerequisite tracking (EIP-8188) makes the cut

Developers building on Ethereum should follow the EIP-7736 discussion on Ethereum Magicians and the state pruning benchmarks on ethresear.ch for the latest data. Those building on Bitcoin Layer 2s can explore the Spark SDK documentation for an architecture that avoids persistent state growth by design. For a broader view of how Verkle trees reshape state management, see our dedicated research article.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.