What Is EIP-2930? Access Lists and Gas Optimization Explained

EIP-2930 introduced a new Ethereum transaction type that lets a transaction declare, upfront, a list of addresses and storage slots it expects to access during execution — an "access list" — which can reduce gas costs for transactions that touch storage slots the EVM would otherwise treat as unfamiliar ("cold") for the first time. It was introduced alongside the Berlin upgrade in April 2021 and, notably, laid groundwork used by later fee-market changes like EIP-1559.

The gas cost problem it addresses: cold versus warm access

Ethereum's gas pricing for reading or writing storage depends on whether a given storage slot or address has already been "touched" earlier in the same transaction. The first time a transaction accesses a particular storage slot or external contract address, it's charged a higher "cold access" gas cost, reflecting the actual cost of loading that data. If the same slot or address is accessed again later in the same transaction, it's now "warm," and subsequent accesses are charged a lower cost, since the data is already loaded.

This cold/warm distinction (introduced by EIP-2929, a companion EIP to EIP-2930) was itself a response to a separate problem: certain operations were historically underpriced relative to their real computational cost, which had been exploited in a handful of past network congestion and denial-of-service style incidents. Raising the cost of cold accesses closed that gap, but it also meant contracts that legitimately need to touch many different storage slots or external contracts within one transaction would pay more than before, unless there was a way to soften that cost for predictable access patterns.

What an access list actually does

EIP-2930 gives a transaction sender a way to pre-declare which addresses and storage slots the transaction will touch, as part of the transaction itself, before execution begins. The EVM then treats everything named in the access list as already "warm" from the very start of execution, rather than charging the higher cold-access cost the first time each item is actually touched during execution.

There's a cost to declaring the list itself — each address and storage slot listed adds a modest, fixed gas cost, separate from the discount it earns during execution. This means access lists are a genuine optimization only when the transaction was going to touch those same slots anyway during execution; declaring things unnecessarily just adds cost without benefit.

Scenario	Gas behavior
Storage slot accessed with no access list, first touch	Charged the higher "cold access" cost
Same storage slot accessed again later in the same transaction	Charged the lower "warm access" cost automatically
Storage slot pre-declared in an access list	Treated as warm from the start — cold-access cost avoided, but the declaration itself has a small fixed cost

Why this mattered for smart contract design

Certain categories of contracts benefited meaningfully from access lists — particularly ones with predictable, complex interaction patterns known in advance, such as contracts calling into several other fixed contracts within a single transaction (multi-hop swaps across specific pools, for instance). For those, correctly using an access list could reduce total gas cost, since avoiding several cold-access charges outweighs the small fixed cost of declaring the list.

In practice, adoption has been mixed — many everyday transactions don't benefit enough to bother, since figuring out the exact set of addresses and slots that will be touched requires some upfront analysis, and wallets and dapps don't always construct access lists automatically even when a transaction would benefit. It's a tool available to sophisticated contract interactions and to wallets/tooling that specifically implement the optimization, rather than something the average user manually configures.

Its connection to later fee-market changes

Beyond direct gas savings, EIP-2930 is notable for introducing a new "typed transaction" envelope format to Ethereum — meaning transactions could now carry a type identifier and type-specific fields, rather than the single flat transaction format used since Ethereum's launch. This typed-transaction structure is what EIP-1559 (introduced later, in the London upgrade) built on to add its own transaction type with base fee and priority fee fields — the fee mechanism most Ethereum users interact with today every time they see a gas estimate in their wallet.

How a developer or wallet decides what to include

Constructing a useful access list requires knowing, in advance, which storage slots and addresses a transaction is actually going to touch during execution — information that's typically derived by simulating the transaction first (many wallets and tools run a dry-run trace against current chain state to work this out automatically) rather than manually inspecting contract source code. Some development frameworks and libraries can generate an access list for you automatically as part of preparing a transaction, checking whether including it would actually reduce total gas cost given the specific slots involved, and simply omitting it if the fixed declaration cost would outweigh the savings.

A transaction type, not a mandatory feature

It's worth being clear that access lists are opt-in — EIP-2930 introduced a new transaction type (Type 1) that supports including one, but ordinary transactions without an access list remain completely valid and are, in fact, still the overwhelming majority of transactions sent on Ethereum today, since EIP-1559 transactions (Type 2, which also support optional access lists) became the more commonly used default afterward. Nothing about using or skipping an access list changes what a transaction can do — it only affects the gas accounting for storage and address access during execution.

Bottom line

EIP-2930 gave Ethereum transactions a way to pre-declare the storage and addresses they'll touch, letting the EVM treat those as already "warm" and avoiding the higher cold-access gas costs introduced by the same upgrade's storage repricing. Its direct gas savings matter mainly for complex, predictable contract interactions rather than everyday transfers, but its lasting legacy is arguably the typed-transaction format it introduced — the same structural foundation that later let EIP-1559 add the base-fee mechanism now central to how Ethereum gas fees work.