---
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: Draft
type: Standards Track
category: Core
created: 2020-07-11
requires: 2718, 2929, 2930, 6780, 7523, 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. The costs of plain ETH transfers and contract creation transactions remain equal, while ETH transfers to new accounts and [7702](./eip-7702.md)-related transactions

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 as the first frame is entered, metered in same way as inside the frame. Running out of gas in runtime does not invalidate the transaction. Instead, the transaction is included, execution is skipped, and all state changes are reverted, as for any out-of-gas halt inside a frame.

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, the transfer log, 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` | 4,244 | Recipient balance write performed by a value transfer |
| `TRANSFER_LOG_COST` | 1,756 | [EIP-7708](./eip-7708.md) transfer log: `GAS_LOG + 3 × GAS_LOG_TOPIC + 32 × GAS_LOG_DATA_PER_BYTE` |

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` | 8,000 | [EIP-8038](./eip-8038.md) | First write to an account leaf |
| `CREATE_ACCESS` | 11,000 | [EIP-8038](./eip-8038.md) | Contract-deployment account access and write |
| `REGULAR_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. Regular-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 regular 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 regular gas; the new-account state charge depends on whether the deployment target exists and is charged at runtime;
  - otherwise, charge `COLD_ACCOUNT_ACCESS` in regular 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, charge `TRANSFER_LOG_COST` in regular gas;
  - otherwise, charge `TRANSFER_LOG_COST + TX_VALUE_COST` in regular gas.
- each [EIP-7702](./eip-7702.md) authorization is charged `REGULAR_PER_AUTH_BASE_COST` in regular gas.

The recipient touch and the authority access (inside `REGULAR_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 action, by 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 regular gas and state gas per [EIP-8037](./eip-8037.md): account accesses and writes are regular 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 state changes are reverted, including any [EIP-7702](./eip-7702.md) delegations. By contrast, if the transaction goes out-of-gas after entering the first EVM frame, the already applied delegations during pre-execution phase stay in place, per [EIP-7702](./eip-7702.md), and all runtime charges 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 prefunded.

#### [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 regular 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 writes the 23-byte delegation indicator into a previously empty slot (net-new delegation bytes), charge `STATE_BYTES_PER_AUTH_BASE × CPSB` in state gas.

For each authorization, after the gas charges of that authorization are processed, the authority is added to `accessed_addresses`, per [EIP-7702](./eip-7702.md).

#### Account creation and access charges

If the transaction is not a self-transfer nor 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;
- if the recipient is an [EIP-7702](./eip-7702.md) delegated account, additionally charge the delegation-target access in regular 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 regular 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 regular 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. The intrinsic + runtime totals match the legacy headline numbers.

| Case | Intrinsic (regular / state) | Runtime (regular / state) | Total (regular / 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 + TRANSFER_LOG_COST` / 0 | 0 / 0 | 21,000 / 0 |
| ETH transfer to contract | `TX_BASE_COST + COLD_ACCOUNT_ACCESS + TX_VALUE_COST + TRANSFER_LOG_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 + TRANSFER_LOG_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 + TRANSFER_LOG_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` | 23,000 / 183,600 |
| Create transaction, `tx.value` > 0 | `TX_BASE_COST + CREATE_ACCESS + TRANSFER_LOG_COST` / 0 | 0 / `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` | 24,756 / 183,600 |
| Create transaction, `tx.value` > 0, `created_address.balance` > 0 | `TX_BASE_COST + CREATE_ACCESS + TRANSFER_LOG_COST` / 0 | 0 / 0 | 24,756 / 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 `REGULAR_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 regular-gas intrinsic — the sum of the regular-gas intrinsic primitives (`TX_BASE_COST + COLD_ACCOUNT_ACCESS + TX_VALUE_COST + TRANSFER_LOG_COST` for value transfers, `TX_BASE_COST + CREATE_ACCESS` for contract creation) — 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 even when the sender temporarily assumes code; clients must not perform a disk code load to classify the sender, since EIP-7702 provides the code inline. 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: `REGULAR_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, priced explicitly as `TRANSFER_LOG_COST` rather than absorbed into the base.
- **[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 BAL 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 in `TX_VALUE_COST`; the transfer log in `TRANSFER_LOG_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 client runtimes

The values of `TX_BASE_COST` and `TX_VALUE_COST` are not set by intuition; they are derived from measured client execution times, using the same approach as [EIP-8038](./eip-8038.md).

The derivation uses the EELS `test_ether_transfers_onchain_receivers` benchmark, executed across all major execution-layer clients (Besu, Erigon, Geth, Nethermind, Reth). The benchmark fills blocks with ether transfers to four kinds of receiver, each exercising a different work path:

- transfers to a contract with shared code, where the code lookup is cached across transactions;
- transfers to a contract with unique 24 KiB code, forcing a fresh code read and JUMPDEST analysis on every transaction (the heaviest path);
- transfers to an existing EOA;
- transfers to a non-existent EOA, where the client must create a new account.

For each `(client, receiver)` pair, a non-negative least-squares (NNLS) model fits measured block runtime as a linear function of the number of transfers and the number of value-bearing transfers. The two fitted coefficients are the per-transfer base runtime and the additional runtime of moving value. Each coefficient is converted to gas at a fixed throughput anchor of 100 Mgas/s (`gas = ceil(100,000 × runtime_ms)`).

For any candidate target, the analysis surfaces each client's worst case across receiver types, separating clients that already meet the target from those that must optimize to reach it. The proposed `TX_BASE_COST` and `TX_VALUE_COST` are set as such targets: they align intrinsic cost with the resource usage of well-optimized clients while leaving slower clients a defined optimization goal.

The two empirical coefficients map onto the decomposition as follows:

- the per-transfer base runtime covers signature recovery, the sender's access and write, and the recipient touch → `TX_BASE_COST + COLD_ACCOUNT_ACCESS`;
- the value increment covers the recipient balance write and the transfer log → `TX_VALUE_COST + TRANSFER_LOG_COST`.

`COLD_ACCOUNT_ACCESS` is taken directly from [EIP-8038](./eip-8038.md), since the recipient touch is the same cold-account access priced there, and `TRANSFER_LOG_COST` is fixed by the [EIP-7708](./eip-7708.md) log shape (see [Transfer log cost](#transfer-log-cost)). `TX_BASE_COST` and `TX_VALUE_COST` are the residual parameters this EIP introduces.

As in [EIP-8038](./eip-8038.md), these numbers are provisional. At the 100 Mgas/s anchor some clients are currently slower than the target on the heaviest paths and must optimize to meet it; the values will be refined as client optimizations land and the benchmarks mature.

### Transfer log cost

`TRANSFER_LOG_COST` assumes a 32-byte log data payload because that is exactly the [EIP-7708](./eip-7708.md) transfer-log shape, not an arbitrary choice. The log is `LOG3`-shaped: three indexed topics (`keccak256("Transfer(address,address,uint256)")`, `from`, `to`) and a `data` field carrying a single `uint256` wei amount. Indexed topics do not count as data bytes, so the only data payload is the 32-byte amount — always a full word, never variable length. Hence:

`TRANSFER_LOG_COST = GAS_LOG + 3 × GAS_LOG_TOPIC + 32 × GAS_LOG_DATA_PER_BYTE = 375 + 3 × 375 + 32 × 8 = 1,756`

### 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.

### 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 `REGULAR_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:

1. Self-transfer (`from == to`): `12,000` intrinsic, `0` runtime.
2. Zero-value transaction to any address (existing, empty, or contract): `15,000` intrinsic (`TX_BASE_COST + COLD_ACCOUNT_ACCESS`), `0` runtime, `0` state. A self-target is `12,000`.
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 regular; `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` regular plus execution.
6. Contract-creation transaction, `value = 0`: `23,000` intrinsic regular; `183,600` runtime state if the deployment target did not exist, `0` otherwise.
7. Contract-creation transaction, `value > 0`: `24,756` intrinsic regular; `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 `REGULAR_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` regular, 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 runtimes 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 unpriced.

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).