Ethereum's 3x throughput plan comes with a 37.7 million gas bill for new contracts

I've spent enough years watching Ethereum upgrades get sold as pure magic to know the fine print always lands somewhere. This time it's on state. The Glamsterdam repricing, scheduled for Q4 2026, wants to roughly triple base-layer throughput. But the bill for that speed is being handed to anyone who creates new accounts, new storage slots, or deploys new contract code. And that's not a small bill.

Let's talk numbers, because this is where the story gets real. Creating a new account currently costs 25,000 gas. Under EIP-8037 that jumps to 183,600 gas. A new storage slot goes from 20,000 to 97,920. Deploying 24 KiB of code plus a new account? That's 4,947,200 gas today. The candidate charge is 37,784,880. That's not a typo. It's a 7.6x increase on contract deployment that makes you wonder who exactly benefits from the tradeoff.

The state problem nobody wants to admit

Here's the core tension. Ethereum's gas limit went from 30 million to 60 million, and the average new state created each day jumped from about 105 MiB to 326 MiB. That's an annual pace of roughly 116 GiB. Now the proposal takes that post-increase rate and projects it against a deliberately severe 200 million gas-limit scenario. The extrapolation lands at 387 GiB of annual state growth. In case you're counting, that crosses the cited 650 GiB performance threshold within a year from the current 390 GiB starting point.

The EIP itself admits the earlier 30-to-60 million response was non-linear. So 387 GiB is a motivating extrapolation, not a measured forecast. But it's the number they're using to justify a common cost of 1,530 gas for every byte of new state. At a reference block limit of 150 million, that targets average growth of 120 GiB a year. Worst case at 200 million after repricing? 160 GiB a year. Spare me the roadmap talk. The math is what it's.

EIP-8038 is the quieter half of this upgrade. It tackles access to and writes of existing state, raising selected account and storage costs based on client benchmarks against a March 2026 state snapshot comparable to mainnet. Together, these proposals create a separate state-gas dimension. Users pay for execution and state separately. The split preserves room for computational work while capping permanent additions to network state. That's the theory.

And the practice? That's where the replay data gets uncomfortable.

The public repricing impact dashboard replayed 929,731,274 transactions across 4 million blocks from Dec. 3, 2024 through June 15, 2026. Each transaction was replayed against its canonical pre-transaction state under both the existing schedule and the candidate schedule. Under EIP-8037, 174,473,898 transactions failed at their original gas limit but succeeded with more gas. Under EIP-8038, that number was 84,708,228. The potentially broken group, transactions that couldn't be rescued even at a 10x gas ceiling, sits at 2,687,652 for EIP-8037 and 3,036,537 for EIP-8038.

Now, before the panic sets in, repeated activity from a busy application can dominate these counts. Millions of transactions don't mean millions of separate contracts at risk. But it does mean the fixable cohort is real work for frontends, bundlers, and infrastructure providers who must submit limits that reflect the new schedule.

The harder cohort is more interesting. These are transactions that fail for reasons more top-level gas can't cure. Fixed 2,300-gas stipends. Hardcoded gas forwarded to internal calls. Logic that branches on gasleft. Presigned transactions with fixed limits. The dashboard defines potentially broken as a baseline-successful transaction that the candidate schedule failed to rescue at the tested 10-times ceiling. It's a counterfactual risk classification, sure. Users, wallets, contracts, builders, and fee markets can adapt before mainnet. But adaptation is expensive and some of it's impossible without user migration.

The busywork tax is real

Let me translate this into something less abstract. If you're a builder, your day just got worse. Wallets, RPC providers, indexers, node tooling, and gas estimators must incorporate the new rules. Frontends and bundlers need to stop relying on cached constants or limits calibrated to the old schedule. Both EIPs require eth_estimateGas and related logic to account for the new costs. The Platåberget testnet announcement warned that tools built around a hardcoded maximum gas limit or a single gas dimension will break.

A plain ETH transfer to an existing account can still use 21,000 gas. But sending value to an account that doesn't exist yet adds a state-creation charge at runtime. Software that assumes every transfer fits the old constant? That software now needs revision. The public outreach report prioritizes versions of the eth-infinitism ERC-4337 EntryPoint and related smart-account stacks, including ZeroDev and Alchemy. It also identifies recurring counterfactual failures involving Across, Socket/Bungee, CoW Protocol, and 0x.

Immutable contracts make the toughest cases operationally expensive. A durable response might require a new EntryPoint, account, factory, or validator implementation followed by user migration. Other systems can be repaired through routing, batching, or gas-accounting changes. But that distinction is exactly what ERC-4337 bundlers must understand. Better simulation and higher submitted limits resolve fixable failures. A validation guard or internal gas assumption still reverts when the outer transaction receives more gas. That's the kind of nuance nobody puts in a press release.

Here's my hot take: the people who will feel this most aren't Ethereum's core developers. They're the application teams who already shipped code under yesterday's assumptions. The Glamsterdam fork was scheduled for Aug. 20 and reported live with the repricing schedule by Aug. 24. The published sequence moves from devnets to Sepolia and Hoodi, then mainnet. The 2026 roadmap target is still subject to testing. Fixed fork dates for Sepolia, Hoodi, and mainnet remain unannounced. Which seems like an even stronger argument for builders to start testing now rather than waiting for the dates to harden.

The real question is who adapts faster

Ethereum can price its way toward more throughput. That's the elegant part. But pricing changes the economics of every application built on top. The developers holding this bag are the ones who encoded yesterday's gas assumptions into immutable contracts and presigned transactions. Regular users can keep familiar workflows if wallets and infrastructure update correctly. That's a big if.

What should you actually do with this information? If you're a developer, resimulate your transactions against the candidate schedule yesterday. Review fixed stipends and internal call limits. Test affected paths while the testing window is still open. If you're a user of smart accounts or cross-chain bridges, this is the moment to pay attention to which implementations are planning migrations. The dashboards are public. The data is there.

The truth is that Ethereum is doing something rare: it's being honest about the cost of its own success. Higher throughput means more state. More state means nodes carry a heavier burden. Someone has to pay for that, and the design decision here's to bill the people who create the state. New accounts cost more. New storage costs more. New contracts cost a lot more. Existing patterns that don't create state? They get a relative discount. That's a clear economic signal if you bother to read it.

The question is whether the community can absorb that signal before mainnet. Builders that encoded yesterday's gas assumptions now have a limited window to prove their contracts and tools can survive tomorrow's schedule. The window is still open. But it won't stay open forever. I've seen enough upgrade cycles to know that the teams who treat testnets as genuinely mandatory are the ones who don't end up with a 3 million transaction edge case on mainnet. The rest get a lesson in accountability.