Ethereum’s PBT Upgrade Clears Shadowfork, Targets Q4 2026

EIP-8297 ran on a mainnet shadowfork on October 29, 2026. The test was run by ethPandaOps. Full Ethereum deployment is targeted for Q4 2026. The proposal, called the Partitioned Binary Tree, or PBT, cleared the test. No firm activation date has been announced.

The fork, named glamsterdam-pbt-1, copied Ethereum mainnet and ran separately against live conditions. Actual funds were not at risk. The switch to PBT went smoothly. It gave developers a realistic test of a change to the chain’s underlying state structure.

Created on June 11, 2026, EIP-8297 reflects collaborative work that includes contributions from Ethereum co-founder Vitalik Buterin. It builds on earlier research into binary trees and Verkle trees, both explored as possible replacements for the current trie.

What does the state change?

Ethereum’s state is the network’s full record of account balances, smart-contract code, and data stored by those contracts. Today, Ethereum organizes that record with a hexary Merkle Patricia Trie, or MPT. PBT replaces the MPT with a binary tree, where every branch divides in two.

The simpler structure makes state easier to traverse and prove. PBT also folds account headers, contract storage, and contract code into one binary tree. Keys are grouped into designated zones, keeping related data closer together.

The design drops RLP, Ethereum’s current serialization format. The proposal identifies RLP as a source of proving difficulty. Eliminating it could ease work for zero-knowledge systems, which have struggled with the format Ethereum uses today.

What does PBT change for users?

Very little at activation, by design. EIP-8297 states that the upgrade is “not meant to change gas schedules or alter how the EVM operates.” Wallets should keep working, contracts should keep running, and users would not need to rewrite code.

The proposal’s immediate goals are “smaller state proofs” and “a path to state expiry without taking the network offline.” If PBT delivers smaller state proofs and simpler validity proofs, it removes a major obstacle for stateless clients. They depend on compact proofs. They verify blocks without storing the full state.

State expiry addresses a different pressure. Ethereum’s state keeps growing, and every full node must carry it. PBT is designed to support future expiry methods while preserving existing access patterns. The design could ease the long-term storage burden without taking the network offline.

What could still delay mainnet?

Gas savings are not part of activation-day design. Because PBT does not change gas schedules, any cost benefits would likely come through later upgrades that it enables. The state change comes first; lower execution costs would depend on what follows.

Execution remains the main risk. The reported shadowfork results cover only Besu, the client built by Consensys. Ethereum runs on multiple client implementations, and each must convert its state correctly. That makes results from other clients a necessary part of the rollout.

On glamsterdam-pbt-1, Besu nodes rebuilt their state directly from existing databases. The reconstruction took approximately 2 hours and 41 minutes. That gives Besu one measured benchmark. It does not establish how other clients will perform the same conversion.

When does PBT reach mainnet?

Full deployment is slated for Q4 2026, but no specific activation date has been announced. The next checkpoints are additional shadowfork rounds, results from other execution clients, and a published activation date. Until those tests clear, Q4 remains a target rather than a commitment.

For users, the practical change is limited to a data structure designed to support stateless clients, zero-knowledge proving, and eventual state expiry. For developers, the near-term test is operational: can the remaining clients convert Ethereum’s state correctly before the Q4 2026 window closes?