---
eip: 2780
title: Resource-based intrinsic transaction gas
description: Decompose the flat intrinsic transaction cost into explicit primitives priced to match the resources a transaction actually consumes
author: Matt Garnett (@lightclient), Uri Klarman (@uriklarman), Ben Adams (@benaadams), Maria Inês Silva (@misilva73), Anders Elowsson (@anderselowsson), Anthony Sassano (@sassal), Dragan Rakita (@rakita)
discussions-to: https://ethereum-magicians.org/t/eip-2780-reduce-intrinsic-cost-of-transactions/4413
status: Last Call
last-call-deadline: 2026-11-01
type: Standards Track
category: Core
created: 2020-07-11
requires: 2718, 2929, 2930, 6780, 7623, 7702, 7708, 7928, 8037, 8038
---

## Abstract

This EIP decomposes the flat `21,000` intrinsic transaction cost into explicit primitives, each priced to match the resources a transaction actually consumes. A plain ETH transfer to an existing account remains at `21,000` execution gas, and contract-creation transactions cost the same whether or not they carry value. Transactions that create new accounts or interact with [EIP-7702](./eip-7702.md) pay the additional runtime costs they incur.

In addition, the new primitives are split into intrinsic gas and runtime gas. **Intrinsic gas** is the state-independent cost of including the transaction in a block and is the sole input to the transaction-validity check. **Runtime gas** covers the state-dependent charges, such as new account creation and delegation resolution. Runtime gas is charged before the first frame is entered and is metered in the same way as gas inside the frame. Running out of runtime gas does not invalidate the transaction. Instead, the transaction is included, execution is skipped, and the pre-execution state changes are reverted.

This EIP does not change calldata or access-list metering.

## Motivation

The flat `21,000` intrinsic cost charges every transaction the same amount regardless of what it does. A zero-value transaction to an existing account and a value transfer that creates a new account both pay `21,000`, even though the latter touches an extra account, writes an extra balance, emits a log, and permanently grows the state. The single constant both over-prices the simplest paths and under-prices the ones that consume real, lasting resources.

This EIP replaces the constant with a decomposition into named primitives, each priced to the resource it represents. The goal is to make every transaction's cost reflect its actual work:

- **Accuracy.** Signature recovery, account accesses, account writes, value transfers, and state creation are billed separately, so cost tracks usage.
- **State growth is internalized.** A value transfer that creates an account, like a contract-creation transaction, pays `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` in state gas. This aligns top-level value transfers with internal `CALL`-based account creation, which already pays for the new leaf, and prices the durable state cost the flat base ignored.
- **Composability.** Pricing intrinsic cost as a sum of the same primitives used elsewhere in the gas schedule lets future repricings (e.g. of cold-account access in [EIP-8038](./eip-8038.md), or of state bytes in [EIP-8037](./eip-8037.md)) flow through automatically, without re-deriving a bespoke constant.
- **No worst-case reservation.** State-dependent costs, such as new account creation and delegation resolution, are charged at runtime only when a transaction incurs them, rather than reserved up front. Intrinsic gas covers only inclusion and remains the sole validity input, so a transaction that funds inclusion but not a runtime charge is included, charged for the gas consumed, and reverted, exactly like an out-of-gas halt inside a call frame.

## Specification

### Parameters

| Name | Value | Definition |
| :----: | :----: | :---- |
| `TX_BASE_COST` | 12,000 | Sender cost: ECDSA recovery, the sender's account access, the sender's account write and inclusion in block |
| `TX_VALUE_COST` | 6,000 | Recipient balance write and [EIP-7708](./eip-7708.md) transfer log performed by a value transfer |

The remaining values are defined in other EIPs and referenced here:

| Name | Value | Source | Definition |
| :---- | :----: | :----: | :---- |
| `COLD_ACCOUNT_ACCESS` | 3,000 | [EIP-8038](./eip-8038.md) | Cold account touch |
| `WARM_ACCESS` | 100 | [EIP-8038](./eip-8038.md) | Warm account touch |
| `ACCOUNT_WRITE` | 9,000 | [EIP-8038](./eip-8038.md) | First write to an account leaf |
| `CREATE_ACCESS` | 12,000 | [EIP-8038](./eip-8038.md) | Contract-deployment account access and write |
| `EXECUTION_PER_AUTH_BASE_COST` | 7,816 | [EIP-8037](./eip-8037.md) | Per-authorization base: calldata, ECDSA recovery, cold authority access, and warm writes |
| `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` | 183,600 | [EIP-8037](./eip-8037.md) | State gas for one new account leaf |
| `STATE_BYTES_PER_AUTH_BASE × CPSB` | 35,190 | [EIP-8037](./eip-8037.md) | State gas for one 23-byte delegation indicator |

The two state-gas products change whenever `CPSB` changes. Execution-gas and state-gas semantics are defined by [EIP-8037](./eip-8037.md).

### Intrinsic gas costs

A transaction's intrinsic base cost is decomposed into the following explicit primitives:

- `tx.sender` is charged `TX_BASE_COST` in execution gas, accounting for one ECDSA recovery, the sender's account access and write, and the inclusion of the transaction's bytes in the block.
- `tx.to` is charged based on its type:
  - if self-transfer (`tx.sender == tx.to`), there are no charges;
  - if `None` (contract-creation transaction), charge `CREATE_ACCESS` in execution gas; the new-account state charge depends on whether the deployment target exists and is charged at runtime;
  - otherwise, charge `COLD_ACCOUNT_ACCESS` in execution gas (covering the recipient touch, charged at the cold rate unconditionally).
- `tx.value` is charged based on its value:
  - if zero, there are no charges;
  - if non-zero and self-transfer, there are no charges;
  - if non-zero and contract creation, there are no charges; the recipient balance write is already covered by `CREATE_ACCESS`;
  - otherwise, charge `TX_VALUE_COST` in execution gas.
- each [EIP-7702](./eip-7702.md) authorization is charged `EXECUTION_PER_AUTH_BASE_COST` in execution gas.

The recipient touch and the authority access (inside `EXECUTION_PER_AUTH_BASE_COST`) are charged at the cold rate every time, even if the account would be warm (for example, via an access list), keeping intrinsic gas computable without any state read.

These charges replace the legacy contract-creation transaction charges and EIP-7702's flat `PER_EMPTY_ACCOUNT_COST × authorization_list_length` intrinsic charge.

Calldata and access-list metering remain unchanged.

### Runtime gas costs

Once the transaction passes the intrinsic gas check, the state-dependent gas costs (i.e., runtime costs) are applied. The runtime charges happen in a distinct window — the pre-execution phase — after the transaction is already deemed valid but before the first EVM frame is entered. This phase includes the following actions, in order:

1. The available gas is split into `gas_left` and `state_gas_reservoir`, and all the gas accounting counters are initialized, per [EIP-8037](./eip-8037.md);
2. [EIP-7702](./eip-7702.md) authorizations are processed;
3. The recipient account is added to the [EIP-7928](./eip-7928.md)'s Block-Level Access List (its access was already charged at the cold rate at the intrinsic phase, and it is warm from transaction start);
4. The remaining account creation and access costs are applied.

Like every charge in this EIP, each runtime charge is split into execution gas and state gas per [EIP-8037](./eip-8037.md): account accesses and writes are execution gas, while durable state growth (new account leaves and net-new delegation bytes) is state gas. This mirrors how a `CALL` frame is metered: accesses, account creation, and writes are charged as state is touched, not up front.

Running out of gas during these runtime charges does **not** invalidate the transaction. Validity is decided solely by the intrinsic gas check.

If the transaction goes out-of-gas in this pre-execution phase, the sender pays for all gas consumed, and all pre-execution state changes are reverted, including any [EIP-7702](./eip-7702.md) delegations. The included transaction still increments the sender's nonce and pays its gas fees. By contrast, if the transaction goes out-of-gas after entering the first EVM frame, the delegations applied during the pre-execution phase stay in place, per [EIP-7702](./eip-7702.md); the state gas that paid for them — each authority's account-creation and delegation-indicator bytes — therefore stays consumed, since that state persists beyond the frame. Runtime state charges whose state is instead rolled back with the frame (for example, a contract-creation transaction's new-account charge; see below) are refilled in LIFO order per [EIP-8037](./eip-8037.md), and execution-gas runtime charges (such as a delegation-target access) remain consumed.

If a contract-creation transaction's initcode reverts, the transaction remains valid and any state gas charged at runtime is refilled in last-in, first-out (LIFO) order, per [EIP-8037](./eip-8037.md): the portion the charge drew from `gas_left` is credited back to `gas_left`, and only the remainder returns to the `state_gas_reservoir`.

On an exceptional halt, the same LIFO refill applies. A plain value transfer to a new account executes no code and so cannot revert. Its new-account state charge is therefore never rolled back this way. The exception is a transfer to an empty precompile, which does execute and can fail, though on mainnet all precompiles are already pre-funded.

#### [EIP-7702](./eip-7702.md) authorization processing

While processing each valid authorization, the following charges are applied **at most once per authority**:

- if the authority account does not already exist, charge `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` in state gas for the new account leaf;
- if this is the first write to the authority within the transaction, charge `ACCOUNT_WRITE` in execution gas; the charge is skipped when the write is already paid for, namely when the authority:
  - is `tx.sender`, covered by `TX_BASE_COST`;
  - was written by a preceding valid authorization;
  - is `tx.to` of a value-bearing transaction, covered by `TX_VALUE_COST`;
- if the authorization sets a non-zero delegation target, the authority had no delegation indicator at transaction start, and no earlier authorization set one for that authority in this transaction, charge `STATE_BYTES_PER_AUTH_BASE × CPSB` in state gas. Clearing an indicator does not refund this charge or make a later set chargeable again. An indicator present at transaction start can be cleared and re-set without paying this charge.

Authorization validation and warming retain the ordering in [EIP-7702](./eip-7702.md): check the chain ID and nonce bound, recover the authority, add it to `accessed_addresses`, and then check its code and current nonce. An authorization skipped because of the latter checks still warms the recovered authority; one rejected before recovery does not. The state-dependent charges above apply only after validation succeeds, before applying the authorization.

#### Account creation and access charges

If the transaction is not a contract creation, then the following charges are applied:

- if the recipient is non-existent and `tx.value > 0`, charge `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` in state gas (never applies to a self-transfer, whose recipient is the already-existing sender);
- if the recipient is an [EIP-7702](./eip-7702.md) delegated account, additionally charge the delegation-target access in execution gas: `COLD_ACCOUNT_ACCESS` if cold, `WARM_ACCESS` if warm.

For a contract-creation transaction, if the deployment address does not already exist, per the existence rule of [EIP-8037](./eip-8037.md), charge `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` in state gas.

### Transaction reference cases

Costs are split between the intrinsic phase and the runtime phase, each in execution gas and state gas, per [EIP-8037](./eip-8037.md). "execution" denotes contract execution charged at the standard schedule; it, and every runtime charge, is drawn from the gas passed into the first frame, so that frame is entered with the gas remaining after the runtime execution and state charges. The recipient touch is charged at the cold rate at the intrinsic phase; the only runtime account access is the delegation-target load, shown at the cold rate — a target warmed beforehand pays `WARM_ACCESS` rather than `COLD_ACCOUNT_ACCESS`. Create rows assume the deployment target does not already exist; a pre-existing target pays no new-account state charge. A plain ETH transfer to an existing EOA remains at the legacy `21,000` execution gas; the other rows show the decomposition for each transaction shape.

| Case | Intrinsic (execution / state) | Runtime (execution / state) | Total (execution / state) |
| :---- | :---- | :---- | :----: |
| ETH transfer to self | `TX_BASE_COST` / 0 | 0 / 0 | 12,000 / 0 |
| No-transfer to EOA / empty account | `TX_BASE_COST + COLD_ACCOUNT_ACCESS` / 0 | 0 / 0 | 15,000 / 0 |
| No-transfer to contract | `TX_BASE_COST + COLD_ACCOUNT_ACCESS` / 0 | execution / 0 | 15,000 + execution / 0 |
| ETH transfer to existing EOA | `TX_BASE_COST + COLD_ACCOUNT_ACCESS + TX_VALUE_COST` / 0 | 0 / 0 | 21,000 / 0 |
| ETH transfer to contract | `TX_BASE_COST + COLD_ACCOUNT_ACCESS + TX_VALUE_COST` / 0 | execution / 0 | 21,000 + execution / 0 |
| No-transfer to 7702 delegated | `TX_BASE_COST + COLD_ACCOUNT_ACCESS` / 0 | `COLD_ACCOUNT_ACCESS` + execution / 0 | 18,000 + execution / 0 |
| ETH transfer to 7702 delegated | `TX_BASE_COST + COLD_ACCOUNT_ACCESS + TX_VALUE_COST` / 0 | `COLD_ACCOUNT_ACCESS` + execution / 0 | 24,000 + execution / 0 |
| ETH transfer to self, sender 7702 delegated | `TX_BASE_COST` / 0 | `COLD_ACCOUNT_ACCESS` + execution / 0 | 15,000 + execution / 0 |
| ETH transfer creating new account | `TX_BASE_COST + COLD_ACCOUNT_ACCESS + TX_VALUE_COST` / 0 | 0 / `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` | 21,000 / 183,600 |
| Create transaction, `tx.value` = 0 | `TX_BASE_COST + CREATE_ACCESS` / 0 | 0 / `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` | 24,000 / 183,600 |
| Create transaction, `tx.value` > 0 | `TX_BASE_COST + CREATE_ACCESS` / 0 | 0 / `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` | 24,000 / 183,600 |
| Create transaction, `tx.value` > 0, `created_address.balance` > 0 | `TX_BASE_COST + CREATE_ACCESS` / 0 | 0 / 0 | 24,000 / 0 |

### Interactions with other EIPs

- **[EIP-2929](./eip-2929.md) (warm/cold accounting).** The sender access folded into `TX_BASE_COST`, the recipient's `COLD_ACCOUNT_ACCESS`, and the authority access inside `EXECUTION_PER_AUTH_BASE_COST` are all charged at the intrinsic phase at fixed cold rates, independent of the account's warm/cold state — an access-list entry for the recipient or an authority does not discount them. The sender, the recipient, and each processed authority are added to `accessed_addresses`, so subsequent execution-level touches are warm. The only runtime account access is the delegation-target load, which follows the standard EIP-2929 warm/cold model: `COLD_ACCOUNT_ACCESS` if cold, `WARM_ACCESS` if warm. The same model governs all execution-level account touches, including internal `CALL`s.
- **[EIP-2930](./eip-2930.md) (access lists).** Access lists keep their existing per-entry charges and warming semantics for execution-level touches. Listing the recipient or an authority does not reduce the intrinsic cold-rate charges; it only pre-warms the address for execution.
- **[EIP-7623](./eip-7623.md) (calldata floor).** EIP-7623 floors a transaction's cost at `21,000 + TOTAL_COST_FLOOR_PER_TOKEN × tokens_in_calldata`, where the flat `21,000` is the intrinsic base this EIP decomposes. With this EIP active, that base term is replaced by the transaction's decomposed base — `TX_BASE_COST` plus the applicable recipient and value primitives (`COLD_ACCOUNT_ACCESS` and `TX_VALUE_COST` for a value transfer to a different account, or `CREATE_ACCESS` for contract creation). Per-authorization charges and initcode word charges are excluded from this base, so the floor and its validity check rest on the same per-transaction base as the rest of intrinsic gas rather than a stale constant. Like the floor, this base is state-independent, so the state-dependent runtime charges (the new-account state-gas charge and the delegation-target access) do not enter it. The calldata schedule itself is unchanged; only the base the floor sits on moves.
- **[EIP-7702](./eip-7702.md) (set EOA code).** `TX_BASE_COST` is unchanged when the sender is delegated or an authorization changes its delegation. An authorization supplies a delegation target address, not the target's code. Computing the intrinsic charge does not require loading that code; resolving a delegation for execution does. When `tx.to` is a delegated account, resolving the delegation loads the target's code, charged `COLD_ACCOUNT_ACCESS` on first touch or warm thereafter, following the standard EIP-2929 `accessed_addresses` model. Setting a delegation (writing the 23-byte pointer) is distinct from resolving one (reading the target's code); the resolution charge is genuine work and is not prepaid by the authorization. Authorization cost itself is decomposed: `EXECUTION_PER_AUTH_BASE_COST` — which already includes the authority's cold access — is charged per authorization at the intrinsic phase, while the state-dependent charges (`STATE_BYTES_PER_NEW_ACCOUNT × CPSB` for a non-existent authority, `ACCOUNT_WRITE` for the first write to the authority within the transaction, and `STATE_BYTES_PER_AUTH_BASE × CPSB` for net-new delegation bytes) are charged at runtime during authorization processing, replacing the worst-case `PER_EMPTY_ACCOUNT_COST` intrinsic charge and refund.
- **[EIP-7708](./eip-7708.md) (ETH transfers emit a log).** Every non-zero-value transfer to a different account emits a transfer log; its cost is folded into `TX_VALUE_COST` alongside the recipient balance write rather than priced as a separate primitive.
- **[EIP-7928](./eip-7928.md) (block-level access lists).** `tx.sender` is accessed at the intrinsic phase and `tx.to` at the runtime phase, so both are included in the block-level access list even when the transaction reverts.

## Rationale

### Intrinsic versus runtime gas

The split follows a single line: can the charge be computed without reading state? Signature recovery, the sender's access and write, the transaction's block bytes, the value charges, and the per-authorization base are all fixed by the transaction's fields alone, so they are intrinsic and decide validity. The recipient touch and the authority access are also intrinsic, charged unconditionally at the cold rate: a top-level account is loaded from cold state once per transaction, and pricing that load at a fixed cold rate — rather than discounting the rare case where an access list pre-warmed it — keeps the charge state-independent without underpricing the work. The state-touching remainder is runtime, billed as each account is actually loaded: whether the recipient, an authority, or a deployment target exists, and whether a delegation must be resolved.

Charging the runtime part as the first frame is entered makes the top-level transaction behave like an ordinary `CALL`: a frame is metered against the gas handed to it, and exhausting that gas halts the frame without unwinding the caller's decision to make the call. Here the "caller" is block inclusion, and the intrinsic check is its decision; a runtime out-of-gas therefore cannot retract validity. Keeping validity on a state-independent quantity is also what lets a block builder decide inclusion without executing the transaction, and lets later EIPs price new state-dependent work at runtime without ever touching the validity boundary.

### Pricing only the work each transaction does

The decomposition charges each primitive once, where the resource is consumed: signature recovery and the sender's access and write in `TX_BASE_COST`; the recipient touch in `COLD_ACCOUNT_ACCESS`; the recipient balance write and transfer log in `TX_VALUE_COST`; and durable state creation in `STATE_BYTES_PER_NEW_ACCOUNT × CPSB`. A zero-value transaction pays only for the touches it makes, while a value transfer that creates an account pays for the new leaf it adds. This removes the cross-subsidy in the flat base, where simple transactions overpaid and state-creating ones underpaid.

The new-account state charge does not apply to `CREATE`/`CREATE2`: the `GAS_CREATE` opcode base already prices internal account creation, and top-level contract-creation transactions pay `CREATE_ACCESS` intrinsically plus the same state-gas charge at runtime when the deployment target does not already exist. Charging the state-growth cost on top-level value transfers that create accounts aligns them with the `CALL`-based creation path, which has always paid for the new leaf.

### Deriving the decomposition from measured client run times

The gas costs are based on measured client execution times, following the same approach as [EIP-8038](./eip-8038.md): collect block runtimes, estimate the runtime of a single transaction, and convert that estimate to gas.

#### Data collection

The EEST `test_ether_transfers_onchain_receivers` benchmark generates blocks containing different numbers of transactions, with and without value. Receivers include the sender itself, existing EOAs, contracts with shared or unique code, and EIP-7702 delegated accounts. Contract cases cover both 24 KiB and 64 KiB code sizes. The suite also tests non-existent receivers, but those cases are excluded from the transaction-cost comparisons because value transfers to them include account-creation work charged separately through state gas.

We run each test block multiple times on Besu, Erigon, Ethrex, Geth, Nethermind, and Reth to capture variation in execution time. The block runtimes and transaction counts provide the inputs to the analysis. The [supporting report](../assets/eip-2780/gas-cost-report.md) presents the results collected from September 25 to October 12, 2026.

#### Runtime estimation

A non-negative least-squares (NNLS) linear regression estimates the runtime of a single transaction from the total block runtime:

```text
block_runtime_ms = intercept_ms + slope_ms_per_tx × transaction_count
```

The intercept captures fixed block overhead. The slope estimates the additional runtime of one transaction. Both are constrained to be non-negative.

Separate models are fitted for each client and receiver case, and for transactions with and without value. The zero-value case slope is reported as `ZERO_VALUE_TRANSFER`, while the with-value case slope is reported as `VALUE_TRANSFER`. Their difference for the same client and receiver estimates the additional runtime of transfering ETH (and the corresponding account updates). The [runtime results](../assets/eip-2780/runtime_estimation.csv) include the fitted slopes and model diagnostics.

#### Mapping runtime estimates to gas costs

The estimated runtimes are converted to gas at a target of **75 Mgas/s**:

```text
gas_estimate = ceil(75_000_000 × runtime_ms / 1000)
```

For a transfer to an existing EOA, the zero-value estimate covers `TX_BASE_COST + COLD_ACCOUNT_ACCESS`. The with-value estimate covers the same work plus `TX_VALUE_COST`. This receiver case allows the two parameters to be compared without account creation or contract execution:

| Parameter | Benchmark estimate | Selected gas cost |
| :--- | :--- | ---: |
| `TX_BASE_COST` | Zero-value gas estimate minus the selected `COLD_ACCOUNT_ACCESS`, clipped to zero | 12,000 |
| `TX_VALUE_COST` | Gas estimate of the difference between the value-bearing and zero-value runtimes | 6,000 |

`COLD_ACCOUNT_ACCESS` is taken from EIP-8038 at 3,000 gas. The selected costs therefore give 15,000 gas for a zero-value transfer and 21,000 gas for a value transfer to an existing EOA.

The [supporting report](../assets/eip-2780/gas-cost-report.md) also compares each client's worst estimate for self-transfers, ordinary transfers, and delegated transfers, with value and zero-value transfers shown separately. The selected values are pricing targets informed by these measurements, rather than exact maxima across every client and receiver case.

### Not metering the transaction envelope as calldata

Only `tx.data` bytes are metered at the calldata schedule; the envelope RLP (`nonce`, `gas*`, `to`, `value`, `v`, `r`, `s`) is not. Pricing full-transaction bytes would make intrinsic gas depend on `gas_limit` and variable-length signature elements — creating a fixed-point estimation problem, since `gas_limit` would depend on the signature, which itself encodes `gas_limit` — and would couple the fee to one serialization, weakening [EIP-2718](./eip-2718.md) type neutrality and future encodings. Treating calldata as opaque bytes avoids both issues. A plain ETH transfer carries empty `tx.data` and so pays zero calldata gas regardless.

### Self-transfers

A self-transfer (`tx.sender == tx.to`) charges neither the recipient touch nor the value cost: the account is already accessed and written as the sender, and EIP-7708 emits no transfer log when sender and recipient coincide. Only `TX_BASE_COST` applies to the intrinsic base. If the sender is delegated, the delegation-target access and any delegated execution are still charged at runtime.

### Decomposing authorization cost

[EIP-7702](./eip-7702.md) charges `PER_EMPTY_ACCOUNT_COST` per authorization at the intrinsic phase and refunds it when the authority already exists, over-reserving gas the transaction may never use. Splitting the cost removes the over-charge: only `EXECUTION_PER_AUTH_BASE_COST` — the calldata, signature recovery, cold authority access, and warm writes every authorization performs — is knowable without state access and stays intrinsic. The new-account leaf, the first-write `ACCOUNT_WRITE`, and the delegation-indicator bytes depend on state and are charged at runtime during authorization processing, billed only for the authorities that incur them.

## Backwards Compatibility

This EIP is **not** backward compatible. It is a consensus gas repricing that must be activated at a network upgrade. Wallets, RPCs, gas estimators, and any logic that assumes a flat `21,000` intrinsic base must update, particularly to account for the state-gas charge on transactions that create new accounts.

## Test Cases

Costs are given as intrinsic + runtime, by case. These examples omit calldata, access-list, and initcode word charges and, except in case 8, authorization charges; executed code is charged separately. Delegation-target accesses shown at the cold rate cost `WARM_ACCESS` instead when the target is already warm:

1. Self-transfer (`from == to`): `12,000` intrinsic, `0` runtime. If the sender is 7702-delegated, the delegation-target access is additionally charged at runtime, per case 5.
2. Zero-value transaction to a distinct existing or empty EOA: `15,000` intrinsic (`TX_BASE_COST + COLD_ACCOUNT_ACCESS`), `0` runtime, `0` state. A contract recipient additionally pays for execution; a delegated recipient also pays for the delegation-target access. A self-target has a `12,000` intrinsic base, with delegated execution charged as in case 1.
3. Value transfer to an existing EOA: `21,000` intrinsic, `0` runtime, `0` state.
4. Value transfer creating a new account (recipient non-existent): `21,000` intrinsic execution; `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` = `183,600` runtime state.
5. Value transfer to a 7702-delegated account: `21,000` intrinsic + `COLD_ACCOUNT_ACCESS` runtime = `24,000` execution gas plus contract execution.
6. Contract-creation transaction, `value = 0`: `24,000` intrinsic execution; `183,600` runtime state if the deployment target did not exist, `0` otherwise.
7. Contract-creation transaction, `value > 0`: `24,000` intrinsic execution (identical to the `value = 0` case, since the recipient balance write is covered by `CREATE_ACCESS`); `183,600` runtime state if the deployment target did not exist, `0` otherwise.
8. EIP-7702 transaction: `TX_BASE_COST` is unchanged even when the sender assumes code. Each authorization is charged `EXECUTION_PER_AUTH_BASE_COST` (which already covers the cold authority access) at the intrinsic phase; at runtime, a non-existent authority additionally pays `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` state, the first write to the authority within the transaction pays `ACCOUNT_WRITE` execution, and net-new delegation bytes add `STATE_BYTES_PER_AUTH_BASE × CPSB` state — replacing the flat `PER_EMPTY_ACCOUNT_COST` intrinsic charge and refund.
9. Contract-creation transaction whose initcode reverts (value-bearing or not): the transaction remains valid; the `183,600` new-account state-gas charge is refilled in LIFO order per [EIP-8037](./eip-8037.md) — credited to `gas_left` up to the portion the charge drew from it, with the remainder returning to the `state_gas_reservoir`.
10. Transaction whose gas covers intrinsic cost but not a runtime charge — e.g. a value transfer to a non-existent recipient or a contract creation to a non-existent target lacking gas for the new-account state charge, or a transfer to a delegated account lacking gas for the delegation-target access: the transaction is valid and included, halts out-of-gas, and all runtime state changes — including any applied EIP-7702 delegations — are reverted; it is **not** invalidated.

Blocks of pure ETH transfers should be tested across all EL clients (e.g. on Perfnet) to confirm the pricing matches measured run times at the chosen throughput anchor.

## Security Considerations

The decomposed charges, intrinsic plus runtime, sum to at least the legacy `21,000` for any transaction that moves value to a distinct, cold account, and add state gas for transactions that grow the state. No path is cheaper than under the flat base in a way that increases per-block resource consumption; the change reallocates cost to match resources and prices state growth that was previously not priced.

Moving the state-dependent charges to runtime lowers the validity threshold (a simple call is valid at `TX_BASE_COST + COLD_ACCOUNT_ACCESS` rather than `21,000`), but does not enable underpriced work. A transaction that passes the intrinsic check yet runs out of runtime gas is still included and the sender still pays for every gas unit consumed, with all state changes reverted — exactly the cost profile of an out-of-gas inside a call frame. The runtime mechanism thus charges the same resources as before; it only relocates where, in the lifecycle, the gas is metered.

The semantics of `SELFDESTRUCT` are unchanged. Per [EIP-6780](./eip-6780.md), only contracts created within the same transaction may be fully deleted; this EIP does not reprice or modify any `SELFDESTRUCT` side effects.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).