EIP-8297 Proposes Unified Binary Tree to Change Ethereum’s State Structure
Key Facts
The EIP-8297 draft proposes replacing the hexary Merkle Patricia trees used for Ethereum state with a partitioned binary state tree, in a move aimed at rebuilding how accounts are stored and proved on the network. The proposed design combines the account and storage trees into one structure, according to the Ethereum Improvement Proposals draft. The proposal is numbered 8297, and its draft was published on 11 June 2026. The document describes the work as a draft in the Core Standards Track, meaning the design is not an activated upgrade. The change matters because the state structure is the basis on which nodes verify account and storage data.
The draft says using a binary tree reduces the size of regular Merkle proofs, because proof size is linked to the number of siblings at each level and the tree’s depth, and a binary structure reduces that number compared with a structure with more branches. The proposal links this design to partitioning state into regions, enabling later proposals for expiring parts of the state or enabling partial stateless clients. These capabilities remain design possibilities that require further work and proposals; they are not functions the draft says will come into use immediately upon adoption of the tree. The proposal also sets no date for activating these changes. The current idea focuses on changing the state commitment structure as a basis for developing lighter ways to verify it.
To illustrate the cost of proving state in an extreme pressure scenario, the draft gives a theoretical example in which a block spends its entire 60 million gas budget touching one byte of code from many unchunked accounts. The document estimates that the data needed in the worst case to prove the state associated with this example would be about 1.8 gigabytes. The draft does not present this as a measurement of actual network use, but as an example explaining how proof size could become an obstacle under specific conditions. The binary tree aims to reduce the size of regular proofs, while the example shows why the proposal is concerned with how state is represented. The expected impact is therefore tied to the efficiency of data verification, not to a change in how transaction fees are calculated.
The draft places accounts, storage and code in a unified key space, with separate regions for account headers, code chunks and storage. The first byte of each key determines the region to which the data belongs, according to the proposal’s description. This arrangement differs from keeping account and storage data in two separate trees, as it combines them in a shared state structure. The draft says the change does not alter the gas schedule and does not require changes to Solidity or Vyper contracts. This means the proposed change affects state representation and verification, while leaving fee rules as described in the document.
A separate proposal, EIP-8347, sets out a plan to migrate state to the new tree. Its draft proposes converting the full state at a finalized checkpoint outside the consensus path, then synchronizing the binary state tree by replaying block-level access lists. The state commitment would then be switched as part of a coordinated hard fork. Nodes that obtain the state snapshot, either by downloading it or rebuilding it themselves, would need to verify it through a two-part check: rebuild the binary tree root, then confirm that rehashing the leaves under the Merkle Patricia structure reproduces the original state root. These steps are intended to verify the integrity of the transition before the new structure is adopted.
The proposed transition plan calls for a monitoring period during which validators publish signed roots for the binary tree for each block, while network consensus continues to rely on the Merkle Patricia tree. The binary tree would become the canonical state commitment only at the activation fork. During the transition period, nodes would apply each block’s updates to both trees, which the EIP-8347 draft says would roughly double state storage and commitment work, alongside increasing read and write operations. The draft also warns that the transition requires coordination with services that verify Ethereum state proofs, including bridges, light clients and consumers of the eth_getProof interface. This is because each account’s storage root would be removed and the tree hash would change, requiring updates to contracts and services that verify Merkle proofs.
The EIP-8347 draft does not set a date for activating the binary tree; it names an activation fork without scheduling it, leaving the date to a hard-fork proposal after a shadow-commitment monitoring period. This places the project in the context of long-term development, with no specific near-term release date in the proposal. In its 2026 priorities update, the Ethereum Foundation said work includes raising the gas limit toward 100 million and beyond, supported by block-level access lists, while continuing work on stateless clients and binary trees as a long-term path to scaling state. Justin Drake presented Lean Ethereum on 31 July 2025 as a personal vision and mission for the next decade, while acknowledging differing views within the foundation and community. The vision set ambitious targets of 10 thousand transactions per second for layer 1 and 10 million for layer 2, but it does not represent a confirmed timetable for activating EIP-8297.