For as long as Ethereum has existed, sending ETH from one address to another has cost 21,000 gas. It is one of the very few numbers that survived every fork, every roadmap rewrite, and every philosophical argument the ecosystem has had since 2015. Wallets hardcode it. Fee estimators assume it. "Send max" buttons are built on it.

Glamsterdam, Ethereum's next major upgrade, puts an asterisk on it. And the Ethereum Foundation has been unusually blunt about what that means: any tool that relies on a hardcapped maximum gas limit will break and needs updating. That is worth understanding even if you never touch Ethereum L1 directly, because the reasoning behind the change tells you something about where every high-throughput chain is heading.

Short Version For Newcomers

Gas is Ethereum's unit for "how much work did this transaction cause". Every operation has a price tag in gas, you pay for the total, and each block has a gas limit that caps how much work fits inside it. Think of it as a metered utility bill.

State is the chain's permanent memory: every account balance, every deployed contract, every storage slot. The important thing about state is that it does not go away. A transaction takes a second to execute and then it's done, but the state it creates has to be stored by every node, forever, including nodes that sync ten years from now.

Ethereum has always priced those two things with one number. Glamsterdam splits them apart.

Paying For Permanence

The change lives in EIP-8037, and it comes down to one split: operations that create new permanent state get charged to a separate meter called state gas, while everything else stays on the familiar meter, now called execution gas.

Every new state byte gets a fixed price, `CPSB` (cost per state byte), currently set at 1,530 gas. Multiply that by how many bytes an operation actually writes to disk and you get its state-gas charge. A fresh account is 120 bytes on disk, so creating one costs 183,600. A storage slot, the 32-byte box that contracts use to remember things between transactions, takes 64 bytes once you count its key, so filling a fresh one costs 97,920. Slots are the most common way applications create permanent state, which is why that second number matters more than it looks. 

And the headline case: sending ETH to an address that already exists still costs 21,000, but sending it to an address that has never appeared on-chain adds that 183,600 charge at runtime. Roughly 204,600 total, close to ten times the number your wallet has been quietly assuming for a decade.

This is a correction as much as an increase. Deploying bytecode currently costs about 200 gas per byte of new state, while filling a storage slot costs about 313. Same disk, same permanence, different price, purely for historical reasons. EIP-8037 picks one number and applies it everywhere.

Bigger Blocks, Bigger Database 

The motivation is not revenue. Ethereum wants bigger blocks, and bigger blocks fill up the database faster.

Every full node keeps its own copy of the state, and Ethereum's security rests on ordinary people being able to run one on ordinary hardware. Once that database outgrows a consumer drive, running a node becomes a data-centre job, and the property that makes the chain worth trusting quietly erodes.

Today it sits around 390 GiB, most of a typical laptop SSD. When Ethereum last doubled block capacity, raising the gas limit from 30 million to 60 million, daily new state more than tripled, from roughly 105 MiB to 326 MiB. People did not simply use the extra room, they used it disproportionately for things that leave permanent data behind. Project that onto the 200 million gas limit Ethereum is aiming for and the EIP arrives at roughly 387 GiB per year, which crosses the 650 GiB mark where nodes noticeably slow down in under a year.

There is the trap: raise the limit in order to scale, and you price ordinary people out of running a node, which defeats the point of scaling. So the authors worked backwards. Decide how much state growth is tolerable, in this case 120 GiB per year, work out how much state a year of blocks could produce, and divide one by the other. Out falls 1,530 gas per byte, the number behind every figure in the table above.

Two Counters, One Block

A block used to have one counter. Now it has two, one per dimension, and the block's reported `gas_used` is whichever counter is higher. 

Two things follow from that. A block can be declared full while most of its execution capacity sits unused, as in the storage-heavy case above. And whichever dimension turns out to be the bottleneck is what drives the base fee, the price per unit of gas that everyone competing for that block has to pay.

Transactions get the same treatment. A transaction still carries one gas limit, but the protocol splits it into a normal budget and a reserve for state charges, which drain the reserve first and fall back to the budget once it runs dry. The useful consequence is that Ethereum's per-transaction gas cap now applies to execution gas only. Without that carve-out the new prices would have capped deployable contracts at around 7.4 KiB; instead Glamsterdam raises the contract size limit from 24 KiB to 64 KiB.

What Actually Breaks

If you maintain anything that touches Ethereum transactions, here is the checklist. Everyone else can skip to the last two sections without missing the argument.

• Anything hardcoding 21,000. Especially "send max" flows, which subtract an assumed fee from the balance. Send to a fresh address and the real cost is ten times that, so the transaction fails.
• Single-dimension gas estimation. `eth_estimateGas` has to return a limit covering both dimensions. One-number models will underprice anything that writes new state.
• Hardcoded maximum gas limits. Indexers and validators that reject blocks above a fixed ceiling will choke as the limit climbs.
• Metering with `gasleft()` deltas. The `GAS` opcode reports the normal budget only, so a before-and-after difference misses state gas entirely. ERC-4337 bundlers work exactly this way.
• Pre-signed deployment transactions. The deterministic deployer factories were signed with fixed limits, often 100,000, which no longer cover the cost. Existing chains are fine, but new networks starting from genesis need them regenerated.
• Contracts that write storage for users. Creating a struct, minting to a new holder, initialising a mapping entry: all new state, all now ~5× more.

About That 200 Million

The other number in the headlines is the 200M gas limit floor, up from roughly 60M today, and it is worth being precise about what that is. The fork does not set the gas limit. Validators do, through gas-vote signaling, and they will only step it up as nodes prove they can handle bigger blocks without falling behind on propagation. 200M is the design target the repricing unblocks, not a switch that flips on fork day. Expect a climb, not a jump.

Mainnet timing remains unconfirmed. Q4 2026 is the window most of the ecosystem is working toward, but the Foundation has consistently declined to name a date, and the honest read is that Sepolia and Hoodi activation are the signals to watch. EIP-8037 is also still in Review, so 1,530 is the current parameter rather than a promise.

Reactive Callbacks On Ethereum 

Reactive Network is its own chain with its own gas model, so none of this changes how reactive contracts are metered. What it changes is the far end of the pipe. When one of our callbacks lands on Ethereum it executes as an ordinary Ethereum transaction under Ethereum's rules, with a gas limit the developer chose when requesting it, usually set once as a constant and then forgotten about. That is exactly the kind of assumption this upgrade is designed to expose.

So if you run a reactive contract with an Ethereum destination, ask whether your callback ever writes state that did not exist before: minting to a first-time recipient, initialising a slot, deploying through a factory. If it does, the `CALLBACK_GAS_LIMIT` that worked comfortably last year may not cover it after Glamsterdam, and a callback that runs out of gas is a callback that does not do its job.

About Reactive Network

Reactive Network is an EVM automation layer built around reactive contracts — event-driven smart contracts for cross-chain execution. It runs on CometBFT consensus, providing deterministic finality with roughly one-second block times while maintaining full EVM compatibility. Reactive contracts subscribe to event logs across EVM chains and execute Solidity logic automatically when matching events occur, issuing cross-chain callback transactions when their conditions are met.

Website | Blog | X | Telegram | Discord | Docs

Build once — react everywhere!