The EVM under the hood: gas, storage and calldata

The machine in one paragraph

The Ethereum Virtual Machine executes bytecode one opcode at a time against a stack of 256 bit words, at most 1,024 deep. Every node that validates a block re-executes every transaction in it and must reach the same result, byte for byte. That single requirement explains the whole design: no floating point, no system clock, no randomness, no unbounded loops, and a price on every operation so that no transaction can make every node on the network do unbounded work for free.

Five places to keep data

Transient storage arrived with the Dencun upgrade in March 2024 (EIP-1153). It behaves like storage for the length of one transaction and then vanishes, which makes it ideal for reentrancy locks, callbacks and flash accounting. Uniswap v4 depends on it.

What a transaction costs before it runs

Every transaction pays an intrinsic cost before a single opcode executes:

Since the Pectra upgrade in May 2025, EIP-7623 adds a floor for transactions that are mostly data. Count tokens as zero bytes plus four times nonzero bytes. The transaction pays the greater of its normal cost and 21,000 plus 10 gas per token. Ordinary contract calls rarely hit the floor, because their execution gas dwarfs their calldata; it exists to cut the worst case amount of calldata a block can carry, which made room to raise blob capacity.

Fusaka, in December 2025, capped any single transaction at 2²⁴ = 16,777,216 gas (EIP-7825), so no transaction can occupy most of a block by itself.

Warm and cold: the first touch is the expensive one

Since the Berlin upgrade in 2021 (EIP-2929), the EVM tracks which accounts and storage slots a transaction has already touched. The first access pays for the disk read a node may have to do. Every later access in the same transaction is priced as a cache hit.

Some things start warm: the sender, the recipient, every precompile and, since Shanghai (EIP-3651), the block's fee recipient. An access list lets you pre-warm the rest at 2,400 per address and 1,900 per slot, which is slightly cheaper than paying the cold price during execution, but only when you know in advance exactly what will be touched.

SSTORE: the most expensive thing you can do

Writing storage creates or changes state that every full node must keep. The price depends on what the slot held at the start of the transaction and what you are writing:

Refunds are paid back when the transaction finishes, and since London (EIP-3529) they are capped at one fifth of the gas the transaction used, down from one half. The same EIP removed the SELFDESTRUCT refund and cut the clearing refund from 15,000 to 4,800, which together killed the old trick of minting "gas tokens" by filling storage when gas was cheap and clearing it when gas was dear.

How Solidity lays out storage

State variables are assigned slots in declaration order. Values smaller than 32 bytes are packed into the same slot while they fit, which is why the order you declare variables in can change what every function costs. Mappings and dynamic arrays cannot know their size, so their contents are placed at hashed locations derived from the slot they were declared in:

contract Vault {
    uint128 public totalShares;   // slot 0, low 16 bytes
    uint64  public lastUpdate;    // slot 0, next 8 bytes (packed)
    address public owner;         // slot 1 (20 bytes do not fit beside 24 used)
    mapping(address => uint256) public shares;   // slot 2 holds nothing itself
    uint256[] public history;     // slot 3 holds the length
}

// shares[user] lives at   keccak256(abi.encode(user, uint256(2)))
// history[i]  lives at    uint256(keccak256(abi.encode(uint256(3)))) + i

Two consequences are worth internalizing. Reading two packed variables costs one cold SLOAD, not two, if they share a slot. And every mapping entry lives at an effectively random slot, so iterating a mapping is impossible onchain and each new key written is a fresh 20,000 gas slot.

Memory: cheap until it is not

Memory starts empty in every call frame and grows in 32 byte words. You pay for its high water mark with a cost that has a linear and a quadratic part:

The quadratic term is negligible for normal contracts and prohibitive for anything that tries to hold a large data structure in memory. It is the EVM's way of capping how much RAM a transaction can demand from every node.

Calls, value and the 63/64 rule

A CALL pays the account access cost, plus 9,000 if it sends value and a further 25,000 if that creates a new account. A value transfer also hands the callee a free stipend of 2,300 gas, historically enough to emit an event and famously not enough to do much else, which is why transfer() and send() broke when opcode costs were repriced (EIP-1884 in the Istanbul upgrade of 2019 raised SLOAD from 200 to 800 gas) and why modern code uses call with an explicit check.

Since EIP-150 in 2016 a caller can forward at most 63/64 of its remaining gas to a callee. That bounds call depth in practice and guarantees the caller always keeps enough gas to handle a failed call.

Logs: the cheap way to publish data

An ERC-20 Transfer event has three topics (the event signature and the two indexed addresses) and 32 bytes of data, so it costs 1,756 gas. Storing the same 32 bytes in a fresh slot costs 20,000 or more. Contracts cannot read logs, but indexers, explorers and wallets can, so anything only needed offchain belongs in an event.

Worked example: one ERC-20 transfer, two prices

Why does sending a token to a new holder cost so much more than sending it to an existing one? Walk through a plain implementation, sending 1,000 USDC worth of a 6 decimal token:

The 17,000 gas difference is almost entirely one thing: creating a storage slot that did not exist. Real tokens add their own overhead, and proxies add a DELEGATECALL, so measured figures run higher, but the shape is always the same. The same reasoning tells you why airdropping to thousands of fresh addresses is expensive and why claim based distributions push that cost onto the claimer.

Deploying code

A new contract's address is determined before it exists, which is what makes counterfactual wallets and deterministic deployments possible:

Deployed code costs 200 gas per byte to store and may not exceed 24,576 bytes (EIP-170), with init code capped at twice that (EIP-3860). The size limit is why large protocols are split into libraries, facets and modules.

Precompiles: native code at fixed addresses

Some operations are far too slow to write in EVM bytecode, so they are built into every client and exposed at fixed addresses, called like contracts and priced like opcodes.

What this means when you write code

1. Treat storage as the budget

   Pack related small values into one slot, read a slot once and keep it on the stack, and use constant and immutable for anything fixed, since those live in bytecode and cost no SLOAD at all.

2. Use the cheap locations for temporary things

   Locks, flags and values passed between callbacks belong in transient storage. Arguments to external functions can stay in calldata instead of being copied to memory.

3. Publish, do not store, what only humans read

   History, receipts and analytics belong in events. Contracts only need to store what contracts need to read.

4. Measure, do not guess

   Foundry gas reports and snapshots show the cost of every function and catch regressions in review. The numbers above explain the results; the tools tell you the truth.

// A reentrancy lock in transient storage (Solidity 0.8.28 or later).
// TLOAD and TSTORE cost 100 gas each, so the lock costs about 300 gas,
// and the slot clears automatically when the transaction ends:
// no 20,000 gas first write and no refund bookkeeping.
bool transient locked;

modifier nonReentrant() {
    require(!locked, "reentrant call");
    locked = true;
    _;
    locked = false;
}
// If you write it in assembly instead, use a namespaced slot (ERC-7201
// style), never slot 0: transient state variables are laid out from 0.

What is changing next

Every number in this guide is the mainnet schedule as of September 2026. The next upgrade, Glamsterdam, was heading for its Sepolia testnet fork in early October 2026 with mainnet targeted for later in the year. Its headline changes are enshrined proposer builder separation (EIP-7732) and block level access lists (EIP-7928), which let clients execute non overlapping transactions in parallel. Neither headline change alters the cost model described here, but Glamsterdam’s candidate list has also carried gas repricing proposals, so check the final EIP list before relying on a specific figure.

Common questions

Where to go next