Vitalik Buterin has spent the first half of 2026 making an unusually specific case for how Ethereum scales β not from a conference stage, but through blog posts and X threads that landed in late February and again on July 4. There was no keynote and no formal whitepaper. What exists instead is a set of written proposals, an Ethereum Foundation research framework called the "strawmap," and a hard fork already running in devnet. Those are the things worth tracking, because they carry dates and code.
The short version: Ethereum's data-availability scaling shipped in December 2025 and has already been tuned upward twice. The execution-layer scaling work arrives with Glamsterdam in the second half of 2026. And the ambitious figure everyone is quoting β 10,000 transactions per second on layer 1 β is a 2029 target attached to a seven-fork sequence, not anything landing this year.
What Fusaka already delivered
Ethereum's Fusaka upgrade went live on mainnet on December 3, 2025, combining the Osaka execution-layer changes with the Fulu consensus-layer changes. Its headline feature was PeerDAS (EIP-7594), which changed how nodes verify that blob data is actually available. Instead of every node downloading every blob, nodes now sample small portions of the data and infer availability statistically.
That single change is what unlocks blob capacity growth. Fusaka shipped alongside EIP-7892, which introduced blob-parameter-only (BPO) forks β lightweight forks that adjust blob targets without requiring a full network upgrade β and EIP-7918, which reworked blob base-fee behavior. The official Fusaka roadmap page lists the full slate, which also included history expiry (EIP-7642), a per-transaction gas cap (EIP-7825), and a secp256r1 precompile (EIP-7951) that makes passkey-based wallet flows cheaper.
The BPO mechanism has been used twice. BPO1 activated on December 9, 2025, raising the blob target to 10 with a maximum of 15. BPO2 followed on January 7, 2026, lifting the target to 14 with a maximum of 21. The Ethereum Foundation's Checkpoint #8 update describes that as roughly a 2.3x increase in layer-2 data space compared with pre-Fusaka levels. Further increments have been paced deliberately, with client teams reviewing network telemetry between steps rather than raising parameters on a fixed calendar.
The Danksharding question, answered accurately
This is where a lot of coverage goes wrong, so it is worth stating plainly: full Danksharding has no announced ship date. It is not scheduled for 2026, and it was never a discrete upgrade with a fixed launch.
Danksharding is a design endpoint β a state in which blob capacity is large enough that rollups post data at negligible cost, with availability verified entirely through sampling. PeerDAS is the first production implementation of the sampling machinery that makes that endpoint reachable. The path from here runs through incremental blob increases via BPO forks and through the propagation improvements in Glamsterdam, not through a single flag-flip event. Any timeline that gives Danksharding a launch date is describing something that does not exist on the protocol calendar.
Glamsterdam: the next real fork
Glamsterdam pairs the "Amsterdam" execution-layer upgrade with the "Gloas" consensus-layer upgrade, and ethereum.org lists it as planned for H2 2026. It has two headliner EIPs.
- Enshrined proposer-builder separation (EIP-7732). ePBS moves the proposer-builder relationship into the protocol itself, removing the dependence on third-party relays. Critically for scaling, it expands the data propagation window from about 2 seconds to roughly 9 seconds within the 12-second slot β which is what makes higher blob counts safe rather than merely possible on paper.
- Block-level access lists (EIP-7928). BALs publish, ahead of execution, which parts of state a block will touch. That lets clients process transactions in parallel instead of strictly sequentially, and it is the prerequisite for meaningfully higher gas limits.
Glamsterdam entered its final devnet phase in mid-June 2026 with a 200 million gas limit as the working target. Testnet and mainnet dates have been discussed but not locked; recent forks have needed two to four months of public-testnet seasoning, which puts realistic mainnet activation in the back half of the year. The upgrade after Glamsterdam, currently called HegotΓ‘, is already collecting headliner proposals, with FOCIL β a censorship-resistance mechanism β among the candidates.
Buterin's February argument: charge for state, not just compute
In late February, Buterin published a proposal that marked a genuine shift in emphasis. After years of pointing scaling questions toward layer 2, he argued for renewed attention to the base layer β and specifically for unbundling how gas is priced.
The core idea is that Ethereum currently charges one blended price for two very different things: temporary computation and permanent additions to state. His proposal would introduce a distinct state-creation fee, making it more expensive to deploy contracts or create new accounts while leaving more headroom for ordinary transactions to get cheaper. As CoinDesk reported, the stated goal is to avoid a future in which Ethereum processes more transactions but becomes so data-intensive that only large, well-funded players can afford to participate.
Lean Ethereum and the 2029 numbers
On July 4, Buterin published the "Lean Ethereum" framing, building on a strawmap that Ethereum Foundation researcher Justin Drake had introduced in February. He called it "the third major iteration of Ethereum in the same way that the Merge was the second," and said that over three to four years "almost every major piece of the protocol will be replaced."
Five north-star goals organize the plan: a fast L1, a "gigagas" L1 at roughly 10,000 TPS, a "teragas" L2, a post-quantum L1, and a private L1. Those are slated across seven forks running to 2029, each roughly six months apart. Buterin was explicit that quantum safety "has shifted up a LOT in priority" and that privacy "is no longer an afterthought, it is a first class goal."
The most technically radical piece is verification. Rather than having validators re-execute every transaction, Ethereum would verify blocks through recursive STARK proofs made an enshrined core component of the protocol. Buterin has also expressed a preference for the protocol eventually targeting RISC-V or a purpose-built "leanISA" directly, with the EVM surviving as a compiler-level feature β while acknowledging, in his own words, that "that shift is still far away."
What to actually watch
For anyone tracking this on a trading or building horizon, the near-term signals are narrow and concrete: whether the next BPO forks push blob targets past 14/21, whether Glamsterdam clears public testnets on schedule, and whether the 200M gas limit target survives devnet testing.
The 10,000 TPS figure is a 2029 destination with seven forks between here and there, and the heaviest lifting β STARK verification, a new instruction set, post-quantum cryptography β is explicitly slated for 2028 and beyond. The realistic 2026 story is narrower but real: rollups got roughly 2.3x more data space in January, and Glamsterdam is built to let that number climb further without pushing node operators out of the network.