TrendCrypt News

Ethereum’s 21,000 Gas Rule Is About to Break

Ethereum’s Glamsterdam upgrade changes a 21,000-gas assumption wallets have relied on for years, especially when ETH transfers create new accounts.

Published 2026-08-23

Updated 2026-08-23

Publisher Ananthi Reeta

Ethereum users have spent years learning one number:

21,000 gas.

It is the familiar minimum attached to a basic ETH transfer.

Wallets know it.

Developers know it.

Explorers display it.

Countless applications have quietly built assumptions around it.

Ethereum’s Glamsterdam upgrade is about to make that assumption much less reliable.

EIP-8037 changes how Ethereum charges for creating permanent state. Under its current parameters, creating a new account carries 183,600 units of state gas, compared with the 25,000-gas account-creation component used today. Creating new storage and deploying contracts also become substantially more expensive.

That does not mean every ETH transfer suddenly costs 183,600 gas.

The important distinction is the destination.

Sending ETH to an account that already exists in Ethereum state remains very different from sending ETH to an address that has never existed onchain and therefore needs a new account record created.

Ethereum’s developers are effectively separating two things that have long been bundled together:

moving ETH

and

making Ethereum store something new permanently.

For ordinary users, wallets should eventually hide most of this complexity.

For wallet developers, RPC providers and applications that still assume 21,000 is always enough, Glamsterdam creates a compatibility problem that needs to be fixed before mainnet.

Key Takeaways

Ethereum’s Glamsterdam upgrade includes EIP-8037, which significantly reprices operations that create permanent blockchain state.
A basic ETH transaction still has a 21,000-gas intrinsic component. Glamsterdam is not simply replacing 21,000 with one new universal number.
Sending ETH to a previously unused address can require additional gas because the transfer creates a new account in Ethereum state.
Under the current EIP-8037 parameters, the state-creation charge for a new account is 183,600 state gas.
Creating a new storage slot rises from 20,000 gas today to 97,920 state gas under the proposal’s current parameters.
EIP-8037 introduces a separate state-gas dimension rather than treating all transaction resource consumption as one gas counter.
Wallets using eth_estimateGas need updated RPC infrastructure capable of understanding the new accounting model.
Wallets or applications that hardcode 21,000 as the gas limit for every ETH transfer risk transaction failures.
Most users should not need to calculate state gas manually if wallets implement estimation correctly.
The goal is to make permanent state creation more accurately reflect the cost it creates for Ethereum nodes.
Ethereum’s state database was already around 390 GiB in early 2026, while state growth accelerated substantially after higher block gas limits increased network capacity.
The change shows a broader challenge for mature blockchains: raising throughput can expose old resource prices that were designed for a much smaller network.
Glamsterdam remains an upcoming network upgrade, so implementation details should be followed through final client releases rather than treated as immutable until activation.

What Is Changing?

EIP-8037 is called State Creation Gas Cost Increase.

Its purpose is larger than making ETH transfers more expensive.

Ethereum stores a growing database of:

accounts
smart-contract code
contract storage
balances
other persistent state

Every Ethereum node that needs the current state has to work with that database.

As Ethereum scales transaction throughput, users and applications can create new state faster.

That creates an uncomfortable problem.

Increasing the amount of computation Ethereum can process without changing how permanent storage is priced can allow state growth to accelerate much faster than node hardware improves.

EIP-8037 responds by making new state substantially more expensive.

It also introduces a new accounting model where state gas and ordinary execution gas can be measured separately.

This is one of several Glamsterdam changes aimed at repricing Ethereum resource consumption more accurately.

Ethereum’s official Glamsterdam roadmap describes related state-access repricing as necessary because operations accessing Ethereum’s growing state have become more demanding for nodes while their gas prices have not kept pace.

The important idea is:

permanent storage should cost according to the burden permanent storage creates.

What EIP-8037 Changes

Area	Old Assumption	Glamsterdam Direction
State Growth	Permanent Ethereum state has become increasingly expensive for nodes to maintain	New state gets priced more directly according to how much database space it creates
Gas Accounting	Most resource costs historically share one gas dimension	EIP-8037 introduces separate state-gas accounting alongside ordinary execution gas
New Accounts	Account creation has historically been relatively cheap	Fresh accounts receive a substantially higher state-creation charge
Storage	Creating a new storage slot costs 20,000 gas today	New storage becomes significantly more expensive
User Experience	21,000 is widely treated as the universal ETH-transfer gas limit	Wallets need to estimate the actual transaction instead of relying on that constant

Why 21,000 Gas Became An Ethereum Constant

The 21,000-gas figure is almost as old as Ethereum itself.

A basic transaction needs gas before the EVM executes more complicated contract logic.

For a normal ETH transfer between externally owned accounts, 21,000 became the familiar baseline.

That made it unusually convenient.

Applications could often assume:

ETH transfer = 21,000 gas

Users did not need to understand the individual operations underneath it.

Wallet software could estimate more complicated transactions dynamically while treating the simplest payment as predictable.

Over time, that stopped looking like an implementation detail.

It began looking like a rule.

But Ethereum has changed enormously since that rule was established.

The amount of permanent state is larger.

Block capacity is larger.

Smart-contract usage is more complex.

Accounts can now behave differently through newer mechanisms such as EIP-7702.

And Ethereum developers are trying to raise throughput further.

The old prices no longer necessarily reflect the resource costs of the network Ethereum is becoming.

21,000 Gas Is Not Actually Disappearing

This is the most important correction.

EIP-8037 does not simply delete Ethereum’s 21,000 transaction cost.

The familiar base remains part of transaction accounting.

What changes is what happens when the transaction also creates permanent state.

Consider two transfers.

Transfer A

Alice sends ETH to Bob.

Bob’s account already exists in Ethereum state.

Transfer B

Alice sends ETH to a completely fresh address that has never appeared in Ethereum state.

From the user’s perspective, both look like:

send ETH → address

From Ethereum’s perspective, they are different.

Transfer B requires the network to create a new account record.

Glamsterdam wants that additional permanent state to carry an additional cost.

When The 21,000-Gas Assumption Still Works

Transaction	What Happens	Why Gas Can Differ
ETH To Existing Account	21,000 gas remains the familiar base transaction cost	No new account state needs to be created
ETH To Fresh Address	Additional state-creation gas can apply	The transfer creates a new account in Ethereum state
Token Transfer	Depends on smart-contract execution and state changes	The 21,000 figure was never the complete cost for ERC-20 transfers
Contract Interaction	Gas depends on the operations executed	Storage, account access and state creation can all affect the estimate
Contract Deployment	State-creation costs rise significantly under EIP-8037	Deploying new code permanently expands Ethereum state

Sending ETH To A New Address Is The Important Edge Case

An Ethereum address can mathematically exist before Ethereum knows anything about it.

Someone can generate a wallet locally.

No blockchain transaction is required.

Until the address receives assets or otherwise creates state, Ethereum does not necessarily need an account record for it.

The first relevant transaction can change that.

When value is transferred to a previously non-existent account, the network creates new persistent state.

EIP-8037 prices that creation at:

120 state bytes × 1,530 gas per byte

which produces:

183,600 state gas

under the EIP’s current CPSB parameter.

That number has already produced an easy-to-misread headline:

ETH transfers could jump from 21,000 to 183,600 gas.

That is not the right interpretation.

The new cost applies to the state creation associated with a fresh account.

It is not a universal replacement for the base cost of every ETH transfer.

Why Ethereum Wants New Accounts To Cost More

Creating an account does something a normal transfer between existing accounts does not.

It adds information that Ethereum nodes may need to retain.

That record can persist long after the original transaction is forgotten by the person who sent it.

Multiply that across millions of accounts and contracts and state growth becomes infrastructure.

EIP-8037 estimates that Ethereum’s Geth state database was around 390 GiB in January 2026.

After the block gas limit increased from 30 million to 60 million, average daily new state reportedly rose from roughly 105 MiB to 326 MiB.

That was more than a threefold increase in daily state creation following a doubling of gas capacity.

The concern is what happens as Ethereum keeps scaling.

If state creation remains artificially cheap while block capacity rises dramatically, the database needed by nodes can grow faster than intended.

Eventually, node requirements become more demanding.

That can make running infrastructure more expensive.

And if fewer people can realistically run nodes, scaling creates a decentralization problem rather than solving one.

State Growth Is Different From Transaction History

Ethereum users sometimes think of blockchain storage as one giant list of old transactions.

State is more specific.

Transaction history tells you what happened.

Current state tells Ethereum what is true now.

It includes things such as:

account balances
account nonces
contract code
contract storage values

Execution clients need this information to determine what a new transaction does.

That makes state particularly important for node performance.

Ethereum can develop techniques for making historical information cheaper to store or retrieve without treating current state exactly the same way.

State growth therefore has its own scaling problem.

EIP-8037 is an attempt to make applications pay more accurately when they add to it.

Storage Slots Are Getting Much More Expensive Too

The fresh-address example gets attention because ordinary users understand ETH transfers.

Smart contracts face a larger change.

A contract frequently stores data using storage slots.

Under today’s model, setting a previously empty storage slot typically carries a 20,000-gas storage cost.

EIP-8037 estimates approximately 64 bytes of persistent state for that operation.

At 1,530 gas per state byte, the new state-gas charge becomes:

97,920 gas.

That is almost five times the old storage-creation price before other execution costs are considered.

Applications that create large amounts of permanent state therefore have much more reason to optimize it.

How State-Creation Costs Change Under EIP-8037

Operation	Current Cost	Current EIP-8037 Estimate
Create New Account	25,000 gas state-creation component	183,600 state gas under the current EIP-8037 parameters
Create New Storage Slot	20,000 gas	97,920 state gas
Deploy 24 kB Contract	About 4.95 million gas for creation and code deposit	About 37.8 million state gas before additional execution costs

Contract Deployment Changes Even More

Deploying smart contracts creates permanent code.

That makes deployment one of the clearest examples of state creation.

EIP-8037 estimates that depositing a roughly 24 kB contract currently costs about 4.95 million gas for creation and code storage.

Under the proposed state-byte pricing, the state component rises to roughly 37.8 million gas before additional regular execution costs.

That looks enormous.

The EIP introduces separate state-gas accounting partly because simply placing the larger charge inside Ethereum’s existing single transaction-gas model would create other problems.

One example is the transaction gas cap.

If all the increased state cost had to fit inside the same ordinary limit, reasonably sized contract deployments could become impossible.

Instead, Glamsterdam is moving toward multidimensional resource accounting.

Ethereum Is Splitting Gas Into Different Kinds Of Work

Historically, Ethereum presents users with one main gas concept.

Different operations consume different amounts, but everything ultimately contributes to the same transaction budget.

EIP-8037 changes that model for state creation.

The proposal tracks:

execution gas

and

state gas

separately.

A transaction still supplies one overall gas limit.

Internally, Ethereum can account for how much of that capacity was consumed by ordinary execution and how much came from creating persistent state.

The block also becomes constrained by whichever resource dimension is most heavily consumed.

This is technically more complicated.

It also allows Ethereum to price two fundamentally different resources separately.

Executing computation for one transaction is temporary.

Adding new state can create a cost for nodes far into the future.

Why This Matters Beyond Glamsterdam

Multidimensional gas is an important conceptual change.

Ethereum has historically compressed many resource types into one unit.

But blockchain execution consumes different resources:

computation
bandwidth
storage
state access

Those resources do not scale at identical rates.

Ethereum has already moved toward separating some costs.

Blob transactions, for example, have their own fee market for data used by Layer 2 networks.

EIP-8037 applies a related idea to state creation.

As Ethereum becomes more complex, one universal gas price becomes less able to describe the actual cost of everything the network does.

That is part of the reason upgrades can become more technically disruptive even when the user-facing goal is simply “scale Ethereum.”

For more context on how Ethereum’s scaling has already shifted activity toward separate fee markets, see TrendCrypt’s coverage of Layer 2 networks and Ethereum fees.

Why Wallets Could Break

The problem for wallets is not that the mathematics are impossible.

It is old assumptions.

Imagine wallet code contains logic equivalent to:

if transaction is a plain ETH transfer:
    gasLimit = 21000

That has worked for years.

After EIP-8037, it can be wrong when the destination requires account creation.

The EIP explicitly warns wallet developers that gas-estimation handling must be updated.

Wallets using eth_estimateGas need to ensure their RPC infrastructure correctly includes state-creation costs and returns enough total transaction gas.

Otherwise, an underestimated transaction can fail.

The user’s balance can be sufficient.

The recipient address can be correct.

The transaction can still run out of gas because the software used an obsolete assumption.

Which Ethereum Tools Need To Adapt

Tool	Typical Behavior	Glamsterdam Risk
Wallet With Dynamic Gas Estimation	Requests an estimate based on the actual transaction	Should adapt once its RPC infrastructure supports the new rules
Wallet With Hardcoded 21,000	Assumes every plain ETH transfer needs the same limit	Can underestimate transfers that create new state
RPC Provider	Calculates transaction requirements for wallets and apps	Must understand both execution gas and the new state-gas accounting
Smart-Contract App	Relies on estimates for storage and contract operations	Can fail if tooling ignores higher state-creation costs
Bundler	Packages account-abstraction operations	Needs special handling because state gas is not fully visible through ordinary gasleft() accounting

Good Wallets Should Hide Most Of This From Users

Ethereum users should not need to ask:

Has this address already created an account leaf in Ethereum state?

before sending money.

That would be terrible wallet design.

The wallet should inspect the transaction.

The RPC provider should understand the current network rules.

eth_estimateGas should return an appropriate estimate.

The wallet should add whatever safety margin its implementation requires.

The user should see:

estimated fee
recipient
amount
transaction details

and decide whether to proceed.

That is how Ethereum already handles complex smart-contract calls.

Glamsterdam makes reliable estimation more important even for something that previously looked too simple to require it.

If you want a deeper explanation of what wallets and explorers expose after a transaction is sent, TrendCrypt’s guide to reading a crypto transaction covers the main fields users encounter.

A Higher Gas Limit Does Not Always Mean A Higher Fee

This is another point likely to confuse users.

Gas limit is capacity.

Gas used is consumption.

Gas price determines how much each consumed unit costs.

If a wallet sets a higher limit, that does not automatically mean Ethereum charges the entire limit.

The final transaction cost depends on what the transaction actually consumes and the applicable fee conditions.

This distinction becomes even more important as Ethereum’s accounting becomes multidimensional.

Users should therefore avoid comparing only:

21,000 vs 183,600

and assuming the fiat cost rises by the same ratio for every transaction.

EIP-8037 itself provides estimated ETH costs using a very low 0.08 gwei base fee and shows why gas-unit increases do not translate mechanically into dramatic dollar costs when network fees are low.

Gas units and money are related.

They are not the same measurement.

Low Base Fees Make The Change Easier To Absorb

Ethereum’s scaling strategy has already pushed much activity toward Layer 2 networks and reduced pressure on mainnet fees compared with previous congestion cycles.

That creates an unusual environment for repricing.

Some operations can become much more expensive in gas terms without immediately recreating the dollar fees users remember from Ethereum’s most congested periods.

EIP-8037 estimates the state-gas portion of creating a new account at roughly 0.0000147 ETH using its reference base-fee assumption.

That estimate can change with network conditions.

The point is structural:

Ethereum can increase the gas charged for expensive resource use while broader scaling improvements keep the market price of gas comparatively low.

TrendCrypt previously examined the difference between rising gas demand and actual user costs in Ethereum gas fees.

Glamsterdam Is Trying To Prevent A Future Scaling Problem

Why make state more expensive just as Ethereum wants more activity?

Because scaling can create its own bottleneck.

Suppose Ethereum eventually processes several times more transactions per block.

That sounds positive.

But if applications also create several times more permanent state, node databases can expand rapidly.

Hardware requirements rise.

State synchronization becomes harder.

Database operations become slower.

Running a node becomes less accessible.

Increasing raw throughput without protecting node requirements can therefore undermine decentralization.

EIP-8037 is essentially asking applications to internalize more of the long-term cost they create.

If an action adds permanent data, it should pay more than an action that only performs temporary computation.

Why Ethereum Targets 120 GiB Of Annual State Growth

EIP-8037’s current pricing uses a parameter called CPSB:

cost per state byte

The proposal sets it at:

1,530 gas per byte.

That number is derived from a reference block gas limit of 150 million and a target state growth rate around 120 GiB per year under its modeling assumptions.

This is not a permanent law of Ethereum.

If block limits and observed state growth change significantly, later EIPs can adjust the parameter.

That makes the mechanism more flexible than permanently hardcoding unrelated prices for every state-creating operation.

New account?

Estimate the bytes created.

New storage slot?

Estimate the bytes created.

Contract bytecode?

Price the bytes deposited.

The goal is consistency.

Ethereum’s Old State Prices Were Surprisingly Uneven

One reason for EIP-8037 is that similar amounts of permanent state can cost very different amounts today.

The proposal calculates approximate existing costs per byte and finds large differences between:

deploying contract code
funding a fresh account
EIP-7702 delegation
adding storage slots

Some methods of creating permanent state are substantially cheaper per byte than others.

That creates bad incentives.

If two actions make nodes store similar amounts of information, there is little reason for one to be dramatically cheaper simply because Ethereum’s original gas schedule happened to price it differently.

EIP-8037 attempts to harmonize those costs around the amount of state created.

This Is Not Mainly A Fee-Revenue Upgrade

It would be easy to interpret higher gas costs as Ethereum trying to make transactions more expensive.

That misses the resource-management purpose.

Gas exists partly as a denial-of-service defense.

If an operation is expensive for nodes but cheap for attackers, someone can consume disproportionate network resources at low cost.

Gas repricing tries to keep the economic cost of an operation closer to the burden it imposes.

Ethereum’s official Glamsterdam roadmap makes the same argument for state-access operations: some reads have become more computationally demanding as Ethereum state grows while their gas costs remained comparatively low.

The objective is sustainable capacity.

Not simply a larger fee bill.

Existing Addresses Should Be Less Surprising

The most visible user-facing difference appears around fresh state.

If a recipient already exists, Ethereum does not need to create the same new account record.

That means ordinary transfers between long-used addresses are less affected by the headline account-creation number.

This is why statements such as:

“All ETH transfers will become nearly nine times more expensive”

are misleading.

The EIP distinguishes state creation from ordinary execution.

The address history matters.

The operation matters.

The state changes matter.

A single fixed number can no longer describe every supposedly “simple” transfer.

New Wallet Addresses Are Not Broken

Another likely misunderstanding is that users should stop generating fresh Ethereum addresses.

That is not what Glamsterdam means.

Fresh addresses remain valid.

The sender can still transfer ETH to them.

The network simply charges for the state created when that address becomes active.

The change concerns economic accounting.

It does not make unused addresses invalid or incompatible with Ethereum.

And because good wallets should estimate gas dynamically, many users may never consciously notice the difference beyond a different estimated fee.

Token Transfers Were Never 21,000-Gas Transactions

The 21,000 rule is often overgeneralized even before Glamsterdam.

Sending an ERC-20 token already involves smart-contract execution.

The transaction calls the token contract.

The contract updates balances.

Those state changes require additional gas.

So when someone says:

“An Ethereum transfer costs 21,000 gas,”

they usually mean a simple native ETH transfer.

Not every asset transfer on Ethereum.

That distinction becomes more useful as Ethereum’s gas model evolves.

The blockchain can have several transactions that look like “send money” to a user while performing very different work internally.

Smart Wallets Make The Boundary Even Less Simple

Ethereum accounts are also changing.

EIP-7702 allows externally owned accounts to temporarily adopt smart-contract functionality through delegation.

This blurs the old distinction between:

simple user account
smart-contract wallet

Glamsterdam’s repricing work explicitly interacts with EIP-7702 account and authorization state.

That makes hardcoded assumptions based on old account categories increasingly fragile.

Wallet software needs to understand what the network will actually execute.

Not what a transaction would have meant on Ethereum several upgrades ago.

TrendCrypt’s guide to crypto wallet signatures explains why transaction authorization and the operations being approved should already be treated separately from the wallet interface showing them.

Account Abstraction Creates Another Compatibility Problem

EIP-8037’s security section specifically calls out ERC-4337 bundlers.

Account-abstraction systems can combine multiple user operations inside one transaction.

Some existing accounting techniques use changes in the EVM’s gasleft() value to determine how much gas individual operations consumed.

The new state-gas reservoir complicates this.

State-gas usage is not always directly represented by the same gasleft() changes.

One user operation can also interact with the transaction-level state-gas accounting in ways bundlers need to track explicitly.

For ordinary users, this is invisible infrastructure.

For smart-wallet developers, it is exactly the kind of edge case that needs testing before activation.

Old Deterministic Deployment Tools Can Break Too

EIP-8037 identifies another unusual backwards-compatibility issue.

Some deterministic contract-deployment factories use pre-signed transactions with hardcoded gas limits.

One classic deployment method uses a transaction capped at 100,000 gas.

Under the new state-creation pricing, that may no longer be enough to deploy the factory.

The EIP specifically mentions tools such as:

ERC-2470
Create2Deployer
ImmutableCreate2Factory
CreateX

This does not break factories already deployed on existing networks.

The concern mainly affects new networks or test environments activating the new rules without those factories already present.

It is another example of the same theme.

Hardcoded gas assumptions age badly.

Glamsterdam Testing Is Already Focused On EIP-8037

The change is not merely a theoretical EIP sitting outside client development.

Ethereum’s execution-specification work has been shipping dedicated Glamsterdam devnet test releases covering EIP-8037 and its interaction with other upgrade components.

Devnet 7 testing included updated EIP-8037 behavior, while later test releases have continued refining and validating the implementation.

That testing is important because gas repricing touches:

transaction validity
execution clients
wallets
RPC methods
contract tooling
block builders
bundlers

A mistake in any one layer can produce very different symptoms.

The network can be working correctly while the wallet is wrong.

Why This Is A Wallet Problem Before It Is A User Problem

The ideal outcome is boring.

Ethereum upgrades.

Wallets have already updated.

RPC providers return correct estimates.

Users keep sending transactions.

That is how infrastructure upgrades should work.

The risk appears when software developers treat a long-standing behavior as permanent.

Twenty-one thousand gas has survived so long that it is easy to stop thinking of it as a parameter.

Glamsterdam is a reminder that protocol constants can become application assumptions.

Once thousands of applications rely on those assumptions, changing the protocol becomes an ecosystem migration.

The Main Compatibility Risks Around EIP-8037

Risk	What Goes Wrong	Likely Result
Underestimated Gas	Wallet or app supplies too little gas	The transaction can fail even though the user has enough ETH for the payment itself
Old SDK Assumptions	Software treats 21,000 as a fixed transfer rule	Applications can behave differently after the upgrade
Higher Contract Costs	An application creates large amounts of permanent state	Deployment or storage-heavy activity becomes more expensive
Account-Abstraction Complexity	Bundled operations interact with the new gas reservoir	Existing gas-accounting techniques may need changes
Misleading Headlines	Every ETH transfer is described as becoming 183,600 gas	Users may expect a universal fee increase that the EIP does not actually create

TrendCrypt Research Notes

TrendCrypt’s review of EIP-8037 suggests that “Ethereum is raising the cost of ETH transfers” is the wrong way to frame Glamsterdam’s state-creation change.

The more accurate framing is:

Ethereum is separating the cost of moving value from the cost of creating permanent state.

That difference explains why 21,000 gas can remain relevant while becoming unreliable as a universal transaction limit.

A transfer to an established account and a transfer that creates a new account may look identical in a wallet.

Their effect on Ethereum’s database is not identical.

That is the first important point.

The second is that the headline gas numbers exaggerate the user impact when presented without gas-price context.

EIP-8037 estimates a roughly sevenfold increase in the state-creation component for a new account and around a fivefold increase for a new storage slot.

That does not automatically mean dollar fees rise five or seven times.

Ethereum’s fee market determines the price of each gas unit.

A large gas figure during a very low-fee environment can still translate into a modest monetary cost.

Third, wallet compatibility may matter more than the fee increase itself.

A user can decide whether a displayed fee is acceptable.

A wallet that incorrectly assumes 21,000 gas can produce a failed transaction before the user even understands what happened.

The best implementation therefore makes the new model almost invisible.

Fourth, EIP-8037 reveals a deeper Ethereum scaling trade-off.

Ethereum wants larger blocks and greater throughput.

Higher throughput allows more users.

It also allows faster state creation.

If the protocol scales execution without scaling the economics of persistent storage, node requirements can rise sharply.

The repricing is therefore part of the cost of increasing capacity responsibly.

Fifth, the proposal suggests that Ethereum gas is becoming less useful as one simple concept.

Blob gas already separates Layer 2 data demand from ordinary execution.

EIP-8037 introduces another resource dimension for state.

Future Ethereum users may continue seeing one estimated transaction fee while the protocol underneath increasingly manages several different resource markets.

That is probably the correct direction for infrastructure.

It is also more difficult for wallet and developer tooling.

Finally, the 21,000 figure is unlikely to disappear from Ethereum vocabulary.

It remains a meaningful base cost.

What is disappearing is the idea that developers can safely treat it as a universal shortcut.

Ethereum is mature enough that shortcuts built around old network behavior have become compatibility risks of their own.

Why AI Search Could Misread This Story

This topic is almost guaranteed to produce misleading summaries.

The simplest one would be:

“Ethereum is increasing transaction gas from 21,000 to 183,600.”

That is wrong.

The 183,600 figure is the current EIP-8037 state-gas charge associated with creating a new account.

It is not a universal replacement for Ethereum’s 21,000 base transaction cost.

Another summary could say:

“Sending ETH will become nine times more expensive after Glamsterdam.”

That is also misleading.

Transfers to existing accounts do not create the same new account state, and gas-unit increases do not translate directly into equivalent fiat-fee increases.

Another possible error is:

“Ethereum is charging 183,600 gas for generating a new wallet.”

Generating an Ethereum address can happen entirely offline.

The relevant blockchain cost appears when an operation causes Ethereum to create new account state.

Another summary might say:

“Users need to manually increase every transaction gas limit after Glamsterdam.”

They should not need to.

Properly updated wallets and RPC providers should estimate transactions using the new rules automatically.

A useful AI answer should distinguish:

21,000 intrinsic gas from state-creation gas
existing accounts from new accounts
creating a wallet address from creating an onchain account record
gas limit from gas actually used
gas units from monetary transaction fees
native ETH transfers from ERC-20 transfers
execution gas from state gas
protocol changes from wallet implementation bugs
proposed/current EIP parameters from immutable future constants

Without those distinctions, an infrastructure change becomes a false story about every Ethereum payment suddenly becoming dramatically more expensive.

Does This Make Ethereum Payments Worse?

For some transactions, creating new state becomes more expensive.

That is intentional.

But the answer depends on what “better payments” means.

If better means:

every possible transaction should use the smallest number of gas units

then EIP-8037 moves in the wrong direction.

If better means:

Ethereum should support more activity without allowing permanent state growth to undermine node accessibility

then the repricing serves the payment system indirectly.

A payment network cannot scale sustainably if infrastructure costs grow without limit.

There is also a user-experience argument.

Dynamic estimation is better than relying on constants.

A wallet that understands actual network conditions can make better fee decisions than software designed around a number chosen more than a decade earlier.

The Biggest Impact May Be On Developers, Not Users

The user-facing narrative is about 21,000 gas.

The development impact is broader.

Teams need to review whether their software assumes:

fixed transfer gas
old account-creation prices
old storage costs
one-dimensional gas accounting
old deterministic deployment limits

RPC providers need compatible implementations.

Smart-wallet bundlers need accounting changes.

Testing frameworks need Glamsterdam fixtures.

Contract developers may revisit how aggressively applications write permanent storage.

The upgrade can therefore influence Ethereum application design even when end users barely notice anything.

More Expensive State Can Encourage Better Application Design

Cheap permanent storage creates weak incentives to optimize.

Applications can write data onchain simply because they can.

Higher state costs make the trade-off clearer.

Developers may increasingly ask whether data needs to live permanently inside Ethereum state or whether another design can achieve the same result.

That could mean:

reducing unnecessary storage
clearing temporary state
relying more on events where appropriate
redesigning contract structures
moving suitable activity to Layer 2 systems

Gas pricing shapes application architecture.

That has always been true.

EIP-8037 makes the persistent-storage signal stronger.

Layer 2 Networks Still Have Their Own Gas Rules

Glamsterdam is an Ethereum mainnet protocol upgrade.

Layer 2 networks do not automatically inherit every Ethereum gas price in exactly the same way.

Many rollups maintain their own execution environments and gas schedules while ultimately settling or posting data to Ethereum.

EIP-8037 itself notes that some deterministic deployment impacts do not automatically apply to existing Layer 2 networks because they maintain their own gas schedules.

Users should therefore avoid assuming that an Ethereum mainnet gas repricing produces the identical fee change on:

Arbitrum
Base
Optimism
other EVM-compatible networks

Compatibility and implementation depend on each network.

What Happens Next

The most important work now happens before mainnet activation.

Ethereum client teams need to continue testing Glamsterdam’s gas accounting.

RPC providers need to expose correct estimates.

Wallet developers need to remove assumptions that no longer hold.

Bundlers and account-abstraction infrastructure need to correctly attribute state-gas consumption.

Smart-contract developers need to understand how much more expensive persistent state becomes.

Recent Ethereum execution-specification releases show that EIP-8037 remains an active part of Glamsterdam devnet testing rather than a static specification that developers can ignore until upgrade day.

For ordinary users, the best signal will be much simpler.

Your wallet should continue producing sensible gas estimates without asking you to understand any of this.

If users need to manually decide whether a recipient account already exists in Ethereum state, the tooling has failed.

Important Context

EIP-8037 is part of an upcoming Ethereum network upgrade.

Its current specification provides concrete parameters such as CPSB = 1530, but Ethereum development continues through testing and client implementation before a mainnet fork activates.

Exact implementation details should therefore be checked against the final Glamsterdam specifications and client releases.

It is also important to separate this proposal from general Ethereum fee movements.

Gas repricing changes how much gas an operation consumes.

The market price of gas changes with network demand.

Those two forces together determine the actual fee a user pays.

A transaction consuming more gas can still be cheaper in ETH or dollars than an older transaction executed during a period of extreme congestion.

Final Thoughts

Twenty-one thousand gas became one of Ethereum’s most durable assumptions because it worked.

For years, a basic ETH transfer was simple enough that developers could treat the number almost like a physical constant.

Ethereum is now too large for that shortcut to describe every case.

A transfer can move value.

It can also create permanent state.

Those are different costs.

Glamsterdam’s EIP-8037 forces the protocol to start treating them that way.

For users, the change should mostly appear as a better gas estimate.

For developers, it is a warning.

Blockchains accumulate assumptions alongside state.

Some of those assumptions eventually become technical debt.

Ethereum wants higher throughput without allowing every increase in capacity to turn into uncontrolled database growth.

That requires making permanent state more expensive.

So the 21,000-gas rule is not exactly disappearing.

What is disappearing is the idea that it tells the whole story.

FAQ

Is Ethereum removing the 21,000 gas limit?

No. The familiar 21,000-gas intrinsic component still exists. Glamsterdam changes additional costs associated with state creation, which means 21,000 can no longer safely be treated as the correct total gas limit for every basic-looking ETH transfer.

Will every ETH transfer cost 183,600 gas after Glamsterdam?

No. The 183,600 figure refers to the current EIP-8037 state-gas charge for creating a new account. A transfer to an account that already exists does not require the same new-account state creation.

What is EIP-8037?

EIP-8037 is an Ethereum proposal included in Glamsterdam that increases and harmonizes the gas charged for creating permanent blockchain state. It also introduces separate state-gas accounting.

Why is Ethereum increasing state-creation gas?

Ethereum’s state database grows as users create accounts, contracts and storage. Higher throughput can accelerate that growth. EIP-8037 is designed to price persistent state more accurately and keep node requirements from growing too quickly.

Does creating a new Ethereum wallet cost gas?

Generating an Ethereum address itself does not require an onchain transaction. Gas becomes relevant when blockchain activity creates account state for that address.

Why can sending ETH to a new address cost more?

A fresh address may require Ethereum to create a new account record. Glamsterdam charges more for that permanent state creation.

Will wallets need to update for Glamsterdam?

Yes. EIP-8037 specifically says wallets and RPC infrastructure must update gas estimation to account for the new state-creation costs. Hardcoded gas limits can result in failed transactions.

Do users need to calculate state gas manually?

Normally, no. Updated wallets should use gas estimation and present the resulting transaction fee to the user.

What happens if a wallet still hardcodes 21,000 gas?

A transaction that needs additional state-creation gas could be underestimated and fail.

Are ERC-20 transfers affected by the 21,000 change?

ERC-20 transfers already require smart-contract execution and generally use more than 21,000 gas. Their cost can also be affected if the transaction creates new state.

Does higher gas usage mean Ethereum fees will rise by the same percentage?

No. Gas usage and gas price are different. The monetary fee depends on both the amount of gas consumed and the market price of gas at the time.

What is state gas?

State gas is the separate resource accounting introduced by EIP-8037 for operations that create permanent Ethereum state, such as new accounts, storage slots and contract code.

Will Ethereum Layer 2 fees change in exactly the same way?

Not necessarily. Layer 2 networks can use their own gas schedules and execution rules, so users should not assume every Ethereum mainnet repricing applies identically to every EVM-compatible network.

Is EIP-8037 already active on Ethereum mainnet?

No. It is being developed and tested as part of the upcoming Glamsterdam upgrade. Ethereum’s execution-specification project has been releasing Glamsterdam devnet tests that include EIP-8037.

What should Ethereum users do before Glamsterdam?

Most users should not need special action. The important work is primarily for wallet, RPC, smart-contract and account-abstraction developers. Users should keep wallet software current and rely on properly estimated transaction fees rather than manually forcing a 21,000 gas limit.