Ethereum Intrinsic Gas: How EIP-2780 Replaces the Flat 21,000 Base

For years, “a basic Ethereum transaction costs 21,000 gas” has been a useful shortcut. It is also becoming an unsafe implementation assumption. EIP-2780 proposes to replace that single flat number with a resource-based calculation. This guide connects the proposal to blockchain infrastructure and separates what is live today from what is being tested for Glamsterdam.

As of September 21, 2026, Ethereum.org lists EIP-2780 as scheduled for Glamsterdam, while the official EIP remains in Review. Glamsterdam is still being tested before mainnet activation. The values below describe the current review specification, not a promise that every number will survive unchanged.

What Ethereum intrinsic gas means

Intrinsic gas is the minimum gas a transaction must cover before the EVM executes its first call frame. Today, most explanations start with a flat 21,000-gas base and then add charges for calldata, access-list entries, contract creation, or EIP-7702 authorizations.

Do not confuse intrinsic gas with the EIP-1559 base fee. Gas is the unit of work. The base fee and priority fee determine the ETH price per gas unit. If a transaction uses fewer gas units, that can reduce its fee, but the live gas price still depends on blockspace demand. Our gas-fee guide explains that multiplication separately.

Think of the current 21,000 base as a restaurant charging every table the same cover fee. EIP-2780 itemizes the bill: one line for admitting the sender, another for touching the recipient, another for moving value, and a separate runtime line when the action permanently creates state.

How EIP-2780 decomposes the old base

The current EIP draft defines a 12,000-gas TX_BASE_COST. It represents sender-side work such as signature recovery, account access and write, plus including the transaction bytes in a block. Other primitives are added only when the transaction shape needs them.

Transaction component	Current review-spec charge	Why it exists
Sender base	12,000 execution gas	Signature, sender access/write, block inclusion
Distinct recipient touch	3,000 execution gas	Cold account access under EIP-8038
Value transfer	6,000 execution gas	Recipient balance write and EIP-7708 transfer log
Top-level contract creation	12,000 execution gas	Deployment-account access and write
New account leaf	183,600 state gas	Durable state growth under the current EIP-8037 parameters

Calldata and access-list metering do not disappear. They remain additional parts of the intrinsic calculation. An EIP-7702 authorization also has its own fixed execution component, with state-dependent work charged later.

The important change is not simply “21,000 becomes 12,000.” The transaction fields determine the state-independent intrinsic amount, while state-dependent work moves into a pre-execution runtime phase.

Reference cases: what actually changes

The current draft gives several useful reference cases:

• Self-transfer: 12,000 intrinsic gas when sender and recipient are the same. The sender account is already being accessed and written, so charging a second recipient touch would duplicate work.
• Zero-value call to a distinct account: 15,000 intrinsic gas before any contract execution—12,000 for the sender plus a 3,000 cold recipient touch.
• ETH transfer to an existing account: still 21,000 execution gas—12,000 base, 3,000 recipient access, and 6,000 value-transfer work.
• ETH transfer to a new account: 21,000 intrinsic execution gas plus the current 183,600 state-gas charge at runtime for creating the account leaf.
• Top-level contract creation: 24,000 intrinsic execution gas plus the new-account state charge when the deployment address did not already exist.

These examples show why a headline such as “Ethereum removes the 21,000-gas transfer cost” is misleading. A normal value transfer to an existing account remains 21,000 in the current EIP. Some simpler shapes cost less; state-creating shapes can require substantially more total gas.

Intrinsic gas versus runtime gas

EIP-2780 draws the boundary around a practical question: can this charge be calculated from the signed transaction without reading Ethereum state?

If yes, it can be intrinsic. A block builder can test transaction validity from fields such as sender, recipient, value, calldata, access list, and authorization list. If the gas limit does not cover that state-independent minimum, the transaction is invalid and cannot be included.

If the cost depends on state—whether a recipient already exists or whether an EIP-7702 delegation target must be loaded—it is charged at runtime before the first EVM frame. If gas runs out during this pre-execution phase, the transaction remains valid and included, the sender pays for gas consumed, execution is skipped, and pre-execution state changes are reverted.

That distinction matters operationally. “Intrinsic gas passed” would no longer guarantee that contract code begins executing. Receipt status, traces, and estimator results remain necessary evidence.

What wallets, RPCs, and applications must revisit

Stop hardcoding 21,000 as a universal transfer limit

A value transfer to an existing ordinary account still matches 21,000 in the current draft. That does not make 21,000 a safe universal constant. A fresh recipient, a delegated account, a zero-value call, and contract creation follow different paths.

Use eth_estimateGas against the intended network and current state. Even then, treat an estimate as state-sensitive rather than permanent: the account may change between estimation and inclusion.

Preserve the difference between validity and success

Infrastructure that prechecks only intrinsic gas can accept a transaction that later exhausts gas during state-dependent pre-execution work. Wallets should simulate or estimate the complete path and communicate that an included transaction can still fail.

Test EIP-7702 delegated accounts

A transaction to a delegated account must resolve and access its delegation target. EIP-2780 moves that state-dependent access to runtime. Relayers and smart-account tooling should test existing and nonexistent authorities, warm and cold targets, skipped authorizations, and rollback after out-of-gas.

Recheck caps and buffers

EIP-7825 limits ordinary transaction execution gas, while EIP-8037 introduces separate state-gas accounting. A simplistic client-side maximum can reject a valid state-creating transaction or present the wrong budget. See the EIP-7825 transaction gas-limit guide for the difference between a per-transaction cap and the block limit.

A practical testing checklist

1. Inventory fixed constants. Search transaction builders, relayers, signing services, tests, and UI copy for 21000, 21_000, or assumptions that intrinsic gas equals transfer gas.
2. Cover transaction shapes. Test self-transfers, zero-value calls, existing recipients, nonexistent recipients, contract creation, calldata, access lists, and EIP-7702 authorizations.
3. Assert outcomes, not only estimates. Check inclusion, receipt status, gas used, logs, state changes, and revert behavior.
4. Use the designated test environment. The Ethereum Foundation announced Platåberget for testing Glamsterdam repricing. Verify the current network instructions through official channels because development networks can reset or change.
5. Pin the rule set. Record the EIP revision, client build, chain ID, and test date. Repeat tests against public testnets and final client releases before activation.

Risks and limitations

• Specification risk: EIP-2780 is still in Review. Costs, interactions, and edge cases can change before mainnet.
• Estimation risk: the recipient's existence or delegation state can change after a wallet estimates gas.
• Out-of-gas risk: passing intrinsic validation does not guarantee the first EVM frame is reached under the proposed runtime model.
• State-growth cost: sending value to a never-used address can create a permanent account leaf and trigger state gas. Address-looking data does not prove an account already exists.
• Tooling mismatch: an outdated wallet, RPC proxy, relayer, or hardware-wallet companion can disagree with upgraded nodes about the needed limit.
• Fee uncertainty: a lower gas-unit count does not guarantee a cheap transaction. Base fee, priority fee, and demand still set the ETH paid.
• Market risk: this protocol proposal does not predict ETH's price. Crypto assets remain volatile; never risk funds you cannot afford to lose.

Frequently asked questions

Is EIP-2780 active on Ethereum mainnet?

No. As of September 21, 2026, Ethereum.org lists it as scheduled for Glamsterdam and the EIP is in Review. Treat development-network behavior as testing, not mainnet activation.

Will a normal ETH transfer cost 12,000 gas?

Not a value transfer to a different existing account under the current draft. That case still totals 21,000 execution gas. The 12,000 figure is the sender base and also the intrinsic amount for a self-transfer before delegated execution.

Why can a new recipient cost more?

An address with no existing account requires Ethereum to add a durable account leaf when it receives value. EIP-2780 charges that state-dependent creation at runtime using EIP-8037's state-gas model.

Does lower intrinsic gas mean lower gas prices?

No. Intrinsic gas measures units of work. The base fee and priority fee price each unit. Demand can make a transaction expensive even when it consumes fewer units.

Do regular ETH holders need to upgrade or convert ETH?

No token conversion is required for an Ethereum network upgrade. Keep wallet software current and ignore anyone asking for a seed phrase or transfer to “upgrade” ETH.

Primary sources

• EIP-2780: Resource-based intrinsic transaction gas
• Ethereum.org: Glamsterdam roadmap
• Ethereum Foundation: Announcing the Platåberget Testnet
• Ethereum execution-specs: Glamsterdam test releases

Bottom line

EIP-2780 turns one familiar constant into an explicit resource bill. The current proposal keeps an ordinary value transfer to an existing account at 21,000 execution gas, lowers some simpler paths, and moves state-dependent creation or delegation work into runtime accounting.

For users, the practical rule is to trust a current wallet estimate more than a remembered constant. For developers, it is to test multiple state shapes, preserve the difference between validity and execution success, and track the Review specification through activation.

This guide is educational, not financial advice. Verify the current EIP and network status through primary sources, use development networks cautiously, and do your own research (DYOR/NFA).