Ethereum’s 21,000 Gas Rule Ends as State Creation Gets Its Own Price

Ethereum’s Glamsterdam upgrade will make a basic ETH transfer depend on something wallets have long treated as irrelevant: whether the recipient already exists in Ethereum’s state. The familiar 21,000 gas payment remains for an existing account, but a transfer that creates a new onchain account adds 183,600 units of state gas. For users, this is a new kind of fee estimation risk. For Ethereum, it is an attempt to price the permanent burden that new state places on every node.

For years, 21,000 gas has been Ethereum’s simplest number. It has been the default embedded in wallets, exchange withdrawal systems, faucet scripts, payment links and smart contract tests. A plain transaction that moves ETH from one externally owned account to another has been assumed to have a fixed execution cost.

Glamsterdam changes the meaning of “plain.”

CoinDesk reported that sending ETH to an existing account will continue to consume 21,000 units of execution gas. But sending ETH to an address that has never appeared in Ethereum’s records will also require 183,600 units of state gas. The result is not merely a higher fee for an unusual kind of payment. It is Ethereum separating two different costs that had previously been bundled together: processing a transaction now, and making the network remember something indefinitely.

That distinction matters because Ethereum is preparing to raise capacity without making node operation unsustainably expensive. More block space can serve more transfers and applications. More permanent state, however, means more data that full nodes must store, retrieve, verify, synchronize and eventually provide to users and applications.

A payment is not always just a payment

A conventional ETH transfer begins as signed transaction data. The sender specifies a recipient, an ETH value, a nonce and fee settings. Ethereum verifies the signature and nonce, checks that the sender can afford both the transfer and fees, then updates balances.

If the recipient account already exists, the relevant state is already part of Ethereum’s global account database. The network changes the sender balance, changes the recipient balance and records the transaction’s effects. That familiar path remains subject to the 21,000 execution gas baseline.

A never-before-seen recipient is different. Ethereum must create an account record in the state. That record becomes part of the shared database every validating full node needs to retain and make available. It is not temporary computational work that disappears once a block is finalized. It is an addition to the chain’s long-lived operational footprint.

The simplest way to express the new resource requirements is:

The final column is useful for understanding the scale of the change, but developers should not automatically treat it as one ordinary gas meter. Glamsterdam’s point is to distinguish execution demand from state demand. Fee software must estimate and price the relevant dimensions correctly, rather than multiplying 204,600 by a single legacy gas-price assumption and calling the job complete.

A worked example makes the operational difference clearer. Assume an execution-gas price of 15 gwei, and, solely for illustration, assume state gas is also priced at 15 gwei. One ETH equals 1 billion gwei.

Under that assumption, creating the recipient account adds 0.002754 ETH to a transfer. The new-recipient payment costs about 9.7 times as much as the existing-recipient payment, even though the sender may be transferring the same amount of ETH to an address that looks identical in a wallet interface.

The equal 15-gwei assumption does not mean state gas is simply another part of the ordinary execution-gas charge. The 183,600-unit component exists precisely because Ethereum is accounting for state as a distinct resource. A production fee estimator therefore needs to obtain the applicable execution price and the applicable state price through the mechanism Glamsterdam ultimately exposes, then calculate the two charges separately. If both prices happen to be equal, the arithmetic above applies. If state gas carries a different price, the new-account fee becomes:

(21,000 × execution-gas price) + (183,600 × state-gas price)

This is why a balance transfer can become conditional on recipient history. An address may look valid in both cases. It may be a 20 byte value, pass checksum validation and have never received a single wei. Yet its status in Ethereum’s historical state determines whether a payment simply modifies existing records or creates a fresh record that the protocol must preserve.

What state gas is actually charging for

State gas is not a charge for generating a new cryptographic address. Wallet software can generate addresses privately and essentially without cost. Nor is it a punishment for new users. It is a charge attached to an action that expands Ethereum’s permanent shared state.

Every full node needs to maintain a view of the state necessary to validate subsequent blocks. In practical terms, that means an account created by a first inbound transfer can impose continuing storage and serving work beyond the block in which it was created. A large state also raises hardware requirements, increases synchronization burdens and makes it harder for smaller operators to independently validate the network.

Ethereum has historically faced an awkward incentive problem here. The network prices short-term execution well because each block has a gas budget. But creating data that lasts for years has not always carried a price aligned with its durable burden. State gas is an effort to make that externality visible at the transaction level.

The change pairs a 200 million-gas test ceiling, up from 60 million, with EIP-7928 block-level access lists that identify the accounts and storage slots a block will touch before execution. That lets clients parallelize independent reads and transaction checks rather than force validators to replay a larger block mostly in sequence; Nethermind said its implementation passed 2,302 performance tests while processing 570.7 billion gas in 195 seconds. The goal is to raise throughput without turning block validation into a hardware-cost jump for node operators.

New recipient account added to Ethereum state183,600 state gas prices persistent burden

indexed state datanew account state

Clients index and retrieve it

Full nodes store it

State gas therefore changes the business logic of payments. Using the 15-gwei illustrative assumption, an exchange that processes 10,000 withdrawals to existing addresses would reserve about 3.15 ETH for the 21,000-unit execution component. If all 10,000 withdrawals instead initialize new accounts, the combined fee requirement rises to about 30.69 ETH. The incremental state charge is 27.54 ETH.

That is not a marginal accounting detail for products distributing small amounts of ETH. A faucet that sends 0.001 ETH per claim would spend 0.000315 ETH in fees for an existing recipient in this example, leaving most of the intended grant intact. For a new recipient, it would spend 0.003069 ETH in fees, more than three times the value of the faucet payment itself. The service must either subsidize that difference, reduce the grant, require recipients to use an already initialized address or redesign the onboarding flow.

The same applies to wallet onboarding. A wallet that wants to sponsor a new user’s first 0.005 ETH transfer would need to budget 0.003069 ETH for the illustrated fee, rather than 0.000315 ETH for a repeat recipient. The recipient still receives 0.005 ETH, but the sponsor’s total outlay rises from 0.005315 ETH to 0.008069 ETH. At scale, that difference turns “first-use” acquisition cost into a separate line item.

The economics could also influence product design. A wallet that sponsors a user’s first transaction may need a larger fee reserve. An exchange could distinguish between withdrawals to previously used addresses and withdrawals that initialize an account. A payments company may choose to fund a recipient through an existing smart account or another settlement route, depending on its own architecture and user experience goals.

The access list connection

The state charge arrives alongside a broader Glamsterdam push to make block processing more predictable and more parallel. The upgrade’s block-level access lists tell Ethereum clients which accounts and storage locations a block expects to touch before execution begins. That advance information lets clients prepare data and evaluate unrelated work concurrently, rather than treating every transaction as an unknown dependency.

CoinDesk reported in a later update that testing included block-level access lists and a 200 million gas limit on a test network, while stressing that the higher limit was a test setting rather than a mainnet commitment. The design goal is clear: Ethereum wants additional capacity, but with better information about the state each block will access.

Access lists and state gas solve different problems. An access list helps a client know which existing data it needs and which operations can safely run independently. State gas accounts for the lasting cost when a transaction enlarges the state itself. One improves scheduling. The other prices persistence.

Developers should not assume that adding an access list makes the new-account charge disappear. Declaring an intended state touch is not the same as avoiding new persistent state. Likewise, parallel execution can make the network more efficient without changing the fact that a newly created account must be retained after the transaction finishes.

What breaks when 21,000 is hard coded

The obvious failure is an underfunded transaction. A wallet that sets a gas limit of exactly 21,000 for every ETH payment may produce a transaction that cannot cover the new account path. The user sees a failed submission or an inexplicable estimation error precisely when sending to someone new.

The less obvious failures are often worse.

An exchange may use 21,000 to precompute withdrawal fees, then absorb the difference or reject withdrawals after a user request has already been accepted. At the illustrative 15-gwei price, each new-account withdrawal carries an additional 0.002754 ETH state cost. A business that quotes a flat fee based only on 21,000 execution gas either passes that cost through explicitly, subsidizes it from its own balance or discovers the mismatch after the withdrawal has been requested.

A faucet may budget for a fixed number of claims per day and exhaust funds far earlier when it serves fresh addresses. A bridge’s operational scripts may incorrectly classify an ETH transfer as simple and cheap because they inspect the transaction type but not the destination’s state status.

Smart contract developers have another trap. A contract that forwards ETH cannot safely assume its recipient always has the same cost profile. Contract logic should never depend on 21,000 as an invariant for a value transfer, particularly where call stipends, reimbursement limits or relayer budgets are involved. A contract can send value to an address whose account state may differ from one invocation to the next.

The practical checklist is straightforward:

1. Replace fixed 21,000 estimates with node-backed simulation and estimation that understands both execution and state requirements.

2. Obtain and apply the execution and state fee components separately. Do not infer a state-gas price from a legacy execution-gas quote unless the protocol explicitly makes them identical.

3. Query the recipient’s state when useful for user messaging, but do not make a preflight query the sole source of truth. State can change before inclusion.

4. Set fee and resource limits with a safety margin, especially in batch systems and sponsored transactions.

5. Treat first-time recipients as a separate operational class in forecasts, accounting and customer support.

6. Test on the relevant public test networks before mainnet activation, including empty addresses, previously funded addresses and addresses that have been touched but hold no ETH.

The key design principle is to estimate the transaction that will execute, not the transaction category a product believes it is sending.

A more honest price for Ethereum growth

There will be friction. A first ETH payment becomes less intuitive, wallet interfaces need to explain why destination history matters, and businesses that subsidize fees will discover that onboarding has a higher marginal cost than repeat usage.

But the alternative is to pretend that permanent state is free while steadily raising the operational burden on the nodes that make Ethereum credible. That model can support growth only until it turns decentralization into a cost center too large for ordinary operators.

Glamsterdam’s end of the 21,000 rule is therefore more than a technical footnote. It signals that Ethereum’s next capacity phase will be built on more explicit resource accounting. Execution consumes block time. State consumes a longer-lived share of the network itself. Developers who separate those ideas now will avoid broken payments later, and will be better positioned for an Ethereum where scalable throughput does not require ignoring the cost of what the chain must remember.