State Creation Gas Cost Increase

The teal panels are commentary: why the rule exists, what problem it solves, which other EIP it leans on, and where each magic number comes from.

The abstract quietly contains both halves of the EIP:

• A price. One unit — CPSB — derived from a policy target ("don't grow state faster than 120 GiB/yr at a 150M limit"). Everything that makes state is charged in multiples of it.
• A meter. State creation gets its own gas dimension, so the price can be cranked up without shrinking the budget for compute — and so the EIP-7825 per-tx cap stops blocking large deployments.

"Average state growth" and "reference gas limit" are the tell that CPSB is a policy knob, not a measured constant — unlike the benchmark-derived numbers in EIP-8038 / EIP-7904.

Gas is supposed to track real cost to a node. But a byte that lands in the state trie costs a node the same regardless of which opcode put it there. The pre-8037 schedule charges by opcode (a 20k flat SSTORE, a 200/byte code deposit) rather than by bytes-of-state, so identical disk impact carries different prices. EIP-8037's fix is to price the byte, not the opcode.

The scary part is the super-linear response. Naively you'd assume 2× the gas → 2× the state. Reality was ~3×, because cheap state invites behavior that wasn't worth it before. So as the community pushes toward 150M–300M to scale L1, the state-growth curve bends upward faster than the limit does.

650 GiB is the soft wall where ordinary nodes start to degrade — and degraded nodes mean fewer people can run them, which is a decentralization problem, not just a UX one. This is the same scaling-safety program as 7825, 7623, 7904 — each removes one bottleneck that would otherwise cap the gas limit.

• CPSB = 1530 — gas charged per byte of new state. Derived from the 120 GiB/yr @ 150M policy target →
• 64 — on-disk bytes for a new storage slot: 32-byte key hash + 32-byte value. Breakdown →
• 120 — on-disk bytes for a new account leaf (key + nonce + balance + codeHash + storageRoot).
• 23 — bytes for a 7702 delegation: 0xef0100 (3) + address (20).
• 16 — borrowed from 7002's MAX_WITHDRAWAL_REQUESTS_PER_BLOCK; the most storage writes any system call is expected to do. Used here →

Notice the pattern: a state op's state-gas is always bytes × CPSB. The three "bytes" constants are the only per-op variation.

EIP-8011 proposed the abstract machinery: give gas a cost vector, and meter the block by max() over dimensions instead of sum(). 8037 is the first EIP to actually switch one dimension on — state — and leaves the rest collapsed into "regular."

Why max() not sum()? A block is "full" when it would overload the network. Different resources overload independently: a block can be heavy on compute or heavy on new state. Summing them double-penalizes a tx that's heavy on one and light on the other. Metering each axis separately lets the builder pack a compute-heavy tx and a state-heavy tx into the same block — that's the throughput win.

The subtle, powerful consequence: you can raise the state price arbitrarily (to protect disk) and it never steals from the compute budget, because they're now separate axes.

gas_left is clamped to at most TX_MAX_GAS_LIMIT − intrinsic_regular_gas. Any gas the user supplied beyond that cap can't be regular-gas — so it lands in state_gas_reservoir, where only state charges can reach it.

This statically enforces "regular-gas ≤ 7825 cap" with a single gas field. Running out of gas_left just looks like ordinary out-of-gas — no new error type. Meanwhile a giant contract deploy can pour, say, 38M of state-gas through the reservoir while its compute stays under the 16.7M cap.

Why hide the reservoir from GAS? Contracts use gasleft() to budget sub-calls; exposing reservoir gas would let a contract accidentally forward state-only gas into a compute context. (This is also the root of the ERC-4337 caveat.)

State-gas is charged exactly when a slot goes from "absent" to "present" in the trie, and refilled when that's undone within the same tx. The guiding question is always: "does a new leaf exist at the end of this transaction?"

• Row 2 (0→0→x): a genuinely new slot → charge.
• Row 1 (0→x→0): a slot that was created and then zeroed in the same tx → no net new leaf → refill the charge.
• Rows 3–5: the slot already existed at tx start (orig ≠ 0) or no creation happened → state size is unchanged → state-gas is untouched. Clearing an old slot is handled by the ordinary regular-gas refund in EIP-8038, not here.

This mirrors the classic EIP-2200 original/current/new state machine — but split so the creation piece lives on the new axis.

The whole table reduces to one rule: charge 120·CPSB only if a brand-new account leaf appears, and L·CPSB for the L bytes of code.

The 684/161 distinction is the interesting case: an address that someone pre-funded with ETH (balance, but no code, zero nonce) already has a leaf. Deploying a contract there updates that leaf rather than adding one — so you skip the 120-byte account charge and pay only for the code. The EIP is careful to get this right because counterfactual / pre-funded deployment addresses are common (think CREATE2 factories, smart-wallet deployment).

Charge-then-refill (rather than charge-on-success) keeps metering conservative: the gas must be reserved before the frame runs, so a tx can't sneak in a creation it didn't budget for. If the creation doesn't stick, the reservation comes back.

This looks asymmetric with the SSTORE/CREATE refill rules — and it's deliberate. EIP-6780 already restricts real account deletion to the same-transaction-as-creation case. EIP-8037 chooses not to reward that path with a refill, because offering a refund for create-then-destroy would re-open exactly the kind of gas-refund gaming that 3529 and 7778 spent years closing. You paid to create; the transient work was real; no money back.

The mental model: state_gas_reservoir behaves like a second gas counter that obeys the same frame semantics gas always has. Revert → unused/charged-but-undone gas flows back up. Exceptional halt (e.g. invalid opcode, out-of-gas) → that frame's allotted gas_left is burned, but state-gas it never committed is still refunded, because the state change it would have caused didn't happen.

Keeping these aligned with existing semantics is what lets clients implement the second dimension without rewriting their call-frame machinery — a recurring design goal across 8011/8037 ("minimal changes to the protocol").

A 7702 authorization's true state impact depends on the authority's current on-chain state, which isn't known at intrinsic-gas time (before execution). Two unknowns:

• Does a fresh account leaf get created? (→ the 120-byte charge)
• Are the 23 delegation bytes genuinely new, or is the slot already a delegation / being cleared? (→ the 23-byte charge)

The EIP charges the maximum up front (new account + new delegation) and refunds whichever pieces turn out not to apply. This is the same conservative "reserve worst case, refill on discovery" pattern as the new-account rules — it guarantees a tx always pre-pays for the most state it could create.

This mirrors 7702's own structure, where PER_EMPTY_ACCOUNT_COST is charged then partially refunded if the authority already existed — 8037 just re-expresses that refund in the two-dimensional world.

You can't know how much new state an opcode makes until you've read the current state (is the slot empty? does the account exist?). That's exactly 7928's post-state bucket. So 8037 naturally slots state-gas into the post-state phase — charged at end-of-opcode, once the answer is known — while the predictable warm/cold access fees stay in the pre-state phase on gas_left.

Excluding the reservoir from the GAS_CALL_STIPEND check keeps the 2,300-gas stipend's meaning intact: the stipend is about compute headroom, which lives in gas_left.

This is the 8011 rule in code. The header's gas_used is the bottleneck dimension — the taller of the two bars — and that's what's checked against the limit and what drives the base fee. A user still pays the sum of their two dimensions, so UX is unchanged; only the block-fullness arithmetic differs.

The 7778 variant swaps tx_gas_used_after_refund for the pre-refund value, so refunds don't shrink the block's accounted compute — closing the same loophole 7778 targets, now per-dimension.

System contracts run with a fixed 30M gas budget every block. They write storage (a ring buffer of block hashes, beacon roots, a withdrawal queue…). If a storage write suddenly costs 64·CPSB = 97,920 state-gas instead of 20,000, a system call that used to fit in 30M might run dry — and a failing system call is a consensus problem, not a user inconvenience.

So 8037 hands them exactly enough extra headroom to absorb the worst case: 16 fresh slots × the new per-slot state cost. Pinning 16 to 7002's existing bound means the margin tracks the real worst case rather than a guess. Putting the surplus in the reservoir keeps it usable only for state, so the change can't silently expand their compute budget.

• 50% utilization is the keystone. Under EIP-1559-style fees, the base fee pushes usage toward the target, which is half the limit. So on average only half a block's gas is available for state before the base fee bites — hence the /2.
• 150M reference is a deliberate middle ground between today's 60M and a hoped-for ~300M: high enough that CPSB won't need re-deriving immediately, low enough that the day-one price hike isn't brutal.
• 120 GiB/yr is the policy choice — slow enough to keep nodes under the 650 GiB wall for years, given the ~390 GiB starting point.

Because it's a policy number, the EIP says plainly: if a future limit increase changes expected growth, just re-derive CPSB in a follow-up EIP. Turn the dials below to feel how sensitive it is.

The disk doesn't care whether a byte arrived via SSTORE or CODECOPY — but the gas schedule charged anywhere from 200 to 313 gas/byte for it, a ~1.5× spread with no physical justification. That spread is an arbitrage surface: rational actors route state creation through the cheapest opcode, distorting behavior for no reason.

8037 collapses the whole column to a single number, CPSB, and lets the only legitimate variable — how many bytes — set the price. Same disk impact, same cost, regardless of path. The bars below show the "before" spread snapping to one harmonized height (and rising to the level needed to actually bound growth).

The byte counts are the literal fields a client must persist for a new leaf, hashed key included. There's no fudge factor.

The footnote matters: real state growth is worse than these numbers, because inserting a leaf also rewrites intermediate trie nodes (branch/extension nodes, RLP encoding overhead). By pricing only the lower bound, 8037 errs toward under-charging — a conscious choice to avoid over-penalizing users while still bending the growth curve. If anything, it leaves room to raise CPSB later.

The 23-byte auth figure is why 7702 is in the requires list at all: the delegation indicator is a genuinely new kind of state, and it had to be assigned a byte cost like everything else.

This is the most elegant bit of the whole proposal. 7825 caps per-tx gas to bound worst-case block-validation time (a DoS / sync-time concern). 8037 makes state expensive. Stack them naively and you've accidentally banned contracts bigger than 7.5 kB — well under the EIP-170 24 kB limit. That would break real deployments.

The resolution rests on a clean principle: 7825's cap exists to bound the work that can't be parallelized away. Compute and the act of writing fit that. But the long-term cost of state existing doesn't threaten single-block validation time at all — it's a slow, cumulative, disk-capacity problem, governed by the block-level state-gas limit, not the per-tx cap. So state-gas is rightly exempt from 7825, and the reservoir is just the plumbing that delivers that exemption through a one-field gas API.

The example budgets 5M regular gas for constructor execution on top of the base costs — realistic for a heavy deploy — and still only clears ~7.5 kB without the fix.

Put the pieces together and you get a virtuous loop: separate metering → state price can rise to whatever protects the disk → that price increase doesn't tax compute → so the block gas limit can keep rising for throughput → which is the original goal. 8037 isn't just a tax; it's the piece that makes future gas-limit increases safe on the state axis.

Users won't notice the two dimensions — but eth_estimateGas absolutely must. A naive estimator that still thinks in one combined number could under-fund the state dimension and silently bounce transactions. This is the practical reason the EIP keeps the per-tx interface single-valued (tx.gas) even while the accounting is two-dimensional: minimize the blast radius on tooling.

Nick's-method factories rely on a transaction signed by a key nobody controls, with a gas limit frozen at signing time. You can't bump that gas limit without the key — so once deployment costs more than the frozen limit, that exact transaction is dead on any chain where it hasn't already run.

It's a non-issue for chains where these canonical addresses already exist, and a genesis-time chore for brand-new chains. The EIP flags it because so much tooling assumes CreateX et al. live at fixed addresses everywhere.

This is why 2780 is a hard dependency. The instant new accounts get expensive inside the EVM but a top-level value transfer that creates the very same account stays at 21k, you've built an arbitrage: route account creation through a cheap transfer. The same byte of state would have two wildly different prices again — re-introducing exactly the inconsistency harmonization set out to kill.

2780 restores the symmetry by charging the new-account surcharge at the transaction's entry point too, so every path that births an account pays the same. (2780 does much more — it overhauls intrinsic gas — but this surcharge is the part 8037 leans on.)

One-dimensional block packing is "fill to the limit." Two dimensions turns it into a knapsack-flavored problem: you want to fill both the regular and state axes efficiently, and the most profitable mix is non-obvious. That's a real lever for sophisticated builders. The EIP's honest position is that the harm is bounded — simple "greedy until something saturates" still gets you most of the way — and this concern is inherited directly from 8011, which carries the same caveat.

Hiding the reservoir from GAS is what makes the reservoir model safe for ordinary contracts — but it has a cost. ERC-4337 account abstraction meters how much gas each user-operation consumes by sampling gasleft() before and after — and that sample is now blind to state-gas. Worse, the reservoir is shared across the whole bundle, so accounting done purely with gasleft() deltas can mis-attribute or cross-subsidize between users.

The mandate is therefore unavoidable: 4337 infrastructure must track state-gas charges and refills explicitly, out of band from gasleft(). It's a concrete example of how a clean protocol-level abstraction (one gas field, hidden reservoir) pushes complexity outward to the layers that were exploiting the old transparency.