A wallet that still hardcodes 21000 as the gas limit for every ETH transfer will keep working for transfers to accounts that already exist. It will also accept, include, and charge the sender for transfers to accounts that do not. The ETH never arrives. That is the Glamsterdam change that lands on RPC operators first.
Glamsterdam is the combined Gloas (consensus) and Amsterdam (execution) upgrade, expected on mainnet in Q4 2026. The public testbed is already running. Platåberget launched on 13 August 2026 (chain ID 7091047534). The Gloas fork activated at epoch 1,536 on 20 August 2026, 07:50 UTC. The block gas limit ramps to 200,000,000 at epoch 1,566, a few hours after that fork.
The existing Ethereum gas fees guide still describes mainnet today: one gas dimension, a flat 21,000 intrinsic cost, eth_estimateGas returning how many units a simulation consumed. Glamsterdam keeps the JSON-RPC method name. It changes what the number means.
Two dimensions, one tx.gas field
EIP-8037 splits metering into execution gas and state gas. Execution gas prices CPU, calldata, and account access. State gas prices durable trie growth at a fixed cost per state byte (CPSB) of 1,530.
The byte counts are the point:
| What is written | Bytes | State gas (bytes × 1,530) | Osaka equivalent |
|---|---|---|---|
| New account leaf | 120 | 183,600 | 25,000 |
| New storage slot | 64 | 97,920 | 20,000 |
| EIP-7702 delegation indicator | 23 | 35,190 | 12,500 (auth base) |
| 24 KiB runtime code | 24,576 | 37,601,280 plus account leaf | ~200 gas/byte |
CPSB is derived so that, at a 150,000,000 reference block gas limit and 50% state-gas utilization, state grows at 120 GiB/year. EIP-8037's own back-of-envelope: after the 30M to 60M gas-limit bump, Geth state sat at ~390 GiB and was adding ~326 MiB/day. Unchanged, a 200M gas limit implied ~387 GiB/year and a trip through the 650 GiB performance cliff in under a year. The repricing is how the 200M floor is supposed to be survivable.
Transactions still have a single gas field. There is no new JSON-RPC parameter. EIP-8037 splits tx.gas at pre-execution into gas_left (capped by the EIP-7825 per-transaction execution cap of 16,777,216 minus intrinsic) and a state_gas_reservoir (whatever remains). State charges draw from the reservoir first, then from gas_left. The GAS opcode returns gas_left only.
That last sentence is the bundler bug. ERC-4337 EntryPoint metering via gasleft() deltas cannot see reservoir-funded state gas. One UserOperation can spend another UserOperation's reservoir without showing up in either delta. Bundlers that trust gasleft() on Amsterdam need an explicit state-gas path.
eth_estimateGas has to return a covering tx.gas: execution plus state. A node that still reports the execution-gas portion alone will under-estimate every state-creating path.
21,000 is a special case, not a constant
EIP-2780 decomposes the old flat intrinsic cost. TX_BASE_COST is 12,000. TX_VALUE_COST is 6,000. COLD_ACCOUNT_ACCESS is 3,000 under EIP-8038. For a value transfer to an existing EOA those three numbers still sum to 21,000, all execution gas, zero state gas.
State-dependent charges (new account leaves, net-new 7702 delegation bytes) are runtime, not intrinsic. Intrinsic gas is state-independent and is the only validity check. Runtime out-of-gas does not reject the transaction. The tx is included, the sender pays for gas consumed, and state changes revert.
| Path | Intrinsic execution | Runtime state | Covering tx.gas |
|---|---|---|---|
| ETH transfer to existing EOA | 21,000 | 0 | 21,000 |
| ETH transfer creating a new account | 21,000 | 183,600 | 204,600 |
| Self-transfer | 12,000 | 0 | 12,000 |
| Zero-value call to an existing account | 15,000 | 0 | 15,000 + execution |
| Create tx, empty deployment address | 24,000 | 183,600 + L × 1,530 | well above 16.7M for large L |
| ETH transfer to a 7702-delegated account | 21,000 | 0 | 24,000 + execution (cold target access at runtime) |
The 183,600 figure is 120 × 1,530. It is charged when the recipient has no trie leaf (zero balance, zero nonce, empty code). A wallet that treats 21,000 as a ceiling, or an indexer that flags any transfer above 21,000 as "not a simple transfer," is wrong on Amsterdam.
The included-and-reverted path is the one that will generate support tickets. A 21,000-gas transfer to a never-seen address passes the intrinsic check, runs out of state gas in the pre-execution phase, and lands on-chain as a failed transaction the sender still paid for. eth_estimateGas against a Glamsterdam client is the way to see 204,600 before that happens.
What actually breaks in eth_estimateGas
The method signature does not change:
curl -s -X POST "$PLATABERGET_EL_RPC" \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_estimateGas",
"params": [{
"from": "0xYourFundedAddress",
"to": "0x1111111111111111111111111111111111111111",
"value": "0x1"
}]
}'
Use an EL RPC from the live list on plataberget.dev. Do not point to at a precompile: those addresses are already funded. Point it at an address that already has a leaf, and a correct Amsterdam node returns 0x5208 (21,000). Point it at a never-seen address and the same call should return 0x31f38 (204,600). If both come back 21,000, the node is not applying EIP-8037 runtime charges in estimation.
The JSON-RPC shape is still a single quantity. execution-apis PR 852 adds two-dimensional gas to tracing; it does not split eth_estimateGas. Until that (or a successor) ships, wallets have to treat the returned value as covering tx.gas, not as execution gas alone.
Three classes of production code fail this test today.
Hardcoded limits. Wallets, relayers, and "simple transfer" helpers that skip eth_estimateGas and write gas: 21000 will under-fuel new-account sends. Deterministic-deployment factories with baked-in gas limits (Nick's method at 100,000, CreateX, ImmutableCreate2Factory) will not redeploy on fresh Amsterdam-from-genesis networks. Existing mainnet and L2 deployments are unaffected. New devnets are.
Clamps at the EIP-7825 cap. Execution gas is still capped at 16,777,216 per transaction. State gas is not. EIP-8037's own 24 KiB deploy example is 37,784,880 gas. A 64 KiB contract (EIP-7954 raises the code size cap from 24 KiB to 64 KiB) is 65,536 × 1,530 = 100,270,080 in code-deposit state gas alone, plus the 183,600 account leaf. Any estimator, proxy, or SDK that min()s the result against 16,777,216, 30,000,000, or the historical 21,000 "transfer" constant will return a number that cannot deploy.
Geth --rpc.gascap. The long-standing default is 50,000,000. That is below a 64 KiB deploy and below some factory-heavy tests at the 200M block gas floor. eth_call / eth_estimateGas against a stock cap will error with a gas-allowance failure while eth_sendRawTransaction of the same payload can still be valid, because the reservoir sits in tx.gas, not in the execution cap. Operators who left the default in place should raise it, measure CPU, and set a timeout that matches the new simulation bound. A 200,000,000-gas eth_estimateGas is a different cost center than a 30,000,000-gas one.
Cached estimates are in the same bucket. A 21,000 result is only reusable for that (from, to, value, data) tuple while to remains existent. An airdrop script that estimates once and reuses the figure for 10,000 recipients will be right for the ones who already hold the token and wrong for first-time recipients (new storage slot: 97,920 state gas on top of execution).
Load on the RPC path
Glamsterdam is not only a wallet problem. The operator-visible surface is larger than the gas table.
Simulation cost. eth_estimateGas and eth_call execute the reservoir model, two-dimensional block accounting, and EIP-7928 pre-state / post-state checks. At a 200M gas floor, a pathological estimate is several times the work of today's 60M mainnet. Timeouts that were tuned for Osaka will start returning -32000 / server-timeout to wallets during the first 200M blocks. Track p95 and p99 of eth_estimateGas separately from eth_getBalance.
Peer protocol. Execution clients must speak eth/70 (EIP-7975, paginated receipts) and eth/71 (EIP-8159, block-level access list exchange). BALs sit outside the block body. Receipt lists at 200M gas do not fit in a single legacy payload. Mixed-protocol peering after the fork is how you get "synced" nodes that cannot serve eth_getBlockReceipts or that stall on BAL fetch.
ePBS. EIP-7732 moves proposer-builder separation on-chain. Relays remain optional for extra features, but the builder API flow, payload-timeliness committee, and builder deposit path (EIP-8282, contracts at 0x0000bff46984e3725691fa540a8c7589300d8282 / 0x000064d678505ad48f8ccb093bc65613800e8282 on Platåberget) are consensus-critical. RPC operators who also run validators or builders need matching CL+EL pairs. The Ethereum Foundation Platåberget announcement publishes ethpandaops/<client>:glamsterdam-devnet-8 images for that pairing; tagged client releases were still catching up at network launch.
State growth vs archive. The 120 GiB/year target is a protocol budget, not a promise that your disk will grow at 120 GiB/year. Archive nodes still keep history. What changes is the rate at which new leaves arrive, and the cost of the RPC methods that create them. If you bill by compute units, eth_estimateGas on a state-heavy payload just got more expensive to serve while remaining one JSON-RPC call. Flat 1:1 pricing does not have that surprise. Compute-unit schedules that already mark eth_estimateGas as a heavy method should be re-benchmarked against Platåberget, not against Osaka traces.
Refunds. EIP-7778 stops counting execution-gas refunds toward block fullness. State-gas refills (reverted creates, SSTORE 0→x→0 in the same tx) still net out of evm_state_gas_used, because the leaf was never durable. Any fee-prediction code that assumes "refunds shrink gasUsed in the header" needs to read the two-counter rule: header gas_used is max(block_execution_gas_used, block_state_gas_used). Receipt cumulativeGasUsed is the sum of what senders paid, which is a different number.
What to run on Platåberget this week
Platåberget is the place to break gas estimators. The network page is explicit that dApp EVM work should still target Sepolia once that fork happens. Infra, wallets, bundlers, and eth_estimateGas wrappers should not wait.
A minimum operator checklist, against a Glamsterdam EL:
eth_estimateGasof a 1-wei transfer to an address with a leaf. Expect 21,000.- The same call to a fresh address. Expect 204,600, not 21,000 and not 183,600.
- A 24 KiB create. Expect a covering
tx.gasabove 16,777,216. If your proxy clamps to 16,777,216, the deploy is dead. - A 64 KiB create. Confirm
--rpc.gascap(or the equivalent on Erigon, Nethermind, Reth, Besu) is high enough to return an estimate at all. - An ERC-4337 bundle that creates accounts inside a UserOperation. Confirm the bundler is not using
gasleft()as the only state-gas meter. - An airdrop that SSTOREs a new slot per recipient. 97,920 state gas per new slot, not 20,000.
- Peer with eth/70 and eth/71. Fetch a full block's receipts and its BAL.
- Watch estimate-call p99 while the gas limit sits at 200M.
Client images at time of writing: ethpandaops/geth:glamsterdam-devnet-8, ethpandaops/reth:glamsterdam-devnet-8, ethpandaops/nethermind:glamsterdam-devnet-8, ethpandaops/erigon:glamsterdam-devnet-8, ethpandaops/besu:glamsterdam-devnet-8, with CL counterparts on the same tag. Check the devnet-8 spec notes for the live list. The Glamsterdam package itself is tracked as EIP-7773.
What this does not change
ETH is not converted. Account balances are not migrated. Existing contracts keep their bytecode. The JSON-RPC names eth_estimateGas, eth_call, eth_feeHistory, and eth_gasPrice stay. EIP-1559's base-fee update still looks at parent.gas_used versus parent.gas_target; only the definition of gas_used in the header becomes the max of two counters.
L2s that keep their own gas schedules are not Amsterdam. A 21,000 hardcoded transfer on Arbitrum or Base is a separate question. The failure mode to worry about on Ethereum L1 is the one above: a covering gas limit that used to be a constant, and an RPC stack that still treats it as one.
The Ethereum RPC method reference is the live list of methods Dwellir serves on mainnet today. Those endpoints will follow the network through Glamsterdam the same way they followed Pectra and Fusaka. Teams that want to put Platåberget traffic on managed infrastructure, or that need eth_estimateGas to stay fast when the simulation bound moves from 60M to 200M, can get an API key or talk to the Dwellir team.
- Related: Ethereum gas fees explained (current mainnet model)
- Related: What is a nonce in crypto?
- Specs: EIP-8037, EIP-2780, EIP-7773
- Testnet: Platåberget · devnet-8 spec notes · EF announcement, 17 August 2026
