EIP-8131: Unified Transaction Content Floor

Flat 64 gas per content byte at the floor, covering calldata, access-list entries, authorizations, and blob versioned hashes.

Abstract

Charge every user-controlled byte in a transaction (calldata, access-list entries, EIP-7702 auths, EIP-4844 blob hashes) at a flat 64 gas at the floor. One rule replaces EIP-7623/EIP-7976 and EIP-7981 and closes the auth and blob hash floor gaps. Worst-case user-controlled tx content per block is bounded by block_gas_limit / 64 ≈ 0.89 MB. Fewer than 4% of mainnet transactions hit the new floor.

Motivation

EIP-7623 introduced a floor cost on calldata bytes to cap worst-case block size. EIP-7976 raised that floor to a uniform 64 gas per calldata byte, zero and non-zero alike (by treating every byte as 4 floor tokens at 16 gas each). EIP-7981 extended the same 64 gas/B rate to access-list bytes via a flat data-cost surcharge of 1,280 gas per address and 2,048 gas per storage key. The principle is consistent across both: every user-controlled content byte priced at 64 gas at the floor.

EIP-7702 authorization tuples (up to 108 B each) and EIP-4844 blob versioned hashes (32 B each) were added without matching floor terms and still pay nothing at the floor.

Each per-component extension has needed its own EIP and its own constants. This EIP folds EIP-7976 and EIP-7981 into a single per-byte rule covering every user-controlled tx-content field, and pulls authorization tuples and blob versioned hashes into the same rule. The result is one formula that auto-prices any future variable-length tx field at the same rate, and a worst-case content bound provable from arithmetic.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Constants

TX_BASE                        = 21000
FLOOR_GAS_PER_BYTE             = 64    # per-byte floor rate established by EIP-7976 (calldata) and EIP-7981 (access lists)
ACCESS_LIST_ADDRESS_BYTES      = 20
ACCESS_LIST_STORAGE_KEY_BYTES  = 32
AUTH_TUPLE_BYTES               = 108   # EIP-7702 authorization tuple worst-case RLP
BLOB_VERSIONED_HASH_BYTES      = 32

Transaction floor

tx_floor = TX_BASE + FLOOR_GAS_PER_BYTE * (
      len(tx.data)
    + ACCESS_LIST_ADDRESS_BYTES      * num_access_list_addresses
    + ACCESS_LIST_STORAGE_KEY_BYTES  * num_access_list_storage_keys
    + AUTH_TUPLE_BYTES               * num_authorizations
    + BLOB_VERSIONED_HASH_BYTES      * num_blob_versioned_hashes
)

A field absent from a given transaction type contributes zero (the corresponding count is zero).

Charging

require tx.gas >= max(intrinsic, tx_floor)
tx.gasUsed   =   max(execution_gas_used, tx_floor)

Intrinsic gas is unchanged. The max(intrinsic, floor) shape of EIP-7623 is preserved.

Rationale

One per-byte rate

Pricing every content byte at the same FLOOR_GAS_PER_BYTE already used by EIP-7976 for calldata and by EIP-7981 for access-list bytes makes the worst case invariant to the attacker’s choice of field or byte value: calldata, access-list entries, authorization tuples, and blob versioned hashes all yield 1/64 bytes per gas at the floor. The optimum collapses to B = block_gas_limit / 64. The bound holds independent of the network compressor, attacker strategy, or content composition.

Content-only, not full RLP

Charging every encoded byte (envelope and signature included) would make legacy transactions strictly cheaper than equivalent EIP-1559 transactions for the same payload, because legacy has a smaller envelope. Content-only is type-symmetric: two transactions with identical content pay identical floor regardless of tx type.

TX_BASE covers envelope

Envelope, signature, and type prefix total at most ~130 bytes for every transaction type defined to date. At FLOOR_GAS_PER_BYTE that is ~8,300 gas, well below TX_BASE = 21,000. Charging envelope explicitly would add ~5,000 gas to every bare ETH transfer; treating TX_BASE as covering it implicitly avoids the regression.

Standard intrinsic unchanged

The standard intrinsic per-byte rate (EIP-2028: 4 gas per zero, 16 gas per non-zero) is preserved. It prices EVM and state work per byte and is unrelated to the bandwidth-bound floor. Raising it would increase intrinsic cost for every transaction with non-zero data without improving the bandwidth-defense properties this EIP targets.

Per-auth term is a constant

AUTH_TUPLE_BYTES = 108 is the maximum RLP size of an EIP-7702 authorization tuple (2 B list header + 9 B chain_id + 21 B address + 9 B nonce + 1 B y_parity + 33 B r + 33 B s). Using a constant rather than len(rlp_encode(auth)) keeps the floor computable from counts alone; typical mainnet auths (chain_id 1, small nonce) over-pay by ~1,024 gas.

Backwards Compatibility

Hard fork.

Floor impact vs current mainnet baseline (EIP-7623 calldata floor, no floor term for access-list bytes, authorization tuples, or blob versioned hashes; mainnet sample 1,500 random blocks, 441,271 transactions, May 2026):

The “bind rate” is the share of transactions whose tx_floor exceeds intrinsic plus execution gas, i.e. transactions whose tx.gasUsed is set by the floor rather than by execution. Aggregate bind rate rises from 1.49% to 3.28%, and total network gas rises by 3.56%.

The repricing concentrates exactly where this EIP intends:

• Type 4 (SetCode): bind rate jumps from 0.04% to 20.63% because authorization tuples (108 B × 64 gas = 6,912 gas per auth) are uncovered today and newly priced. Average type-4 floor rises from 240 k to 587 k.
• Type 3 (blob carriers, calldata-light): already 60% bind rate under today’s floor, since blob-carrier transactions execute well below 7976-style calldata cost. This EIP raises the average floor from 69 k to 84 k as the 32-byte blob versioned hashes get priced.
• Legacy, EIP-2930, EIP-1559 (98.3% of traffic): bind rate moves at most ~1.7 pp, driven by access-list bytes moving into the floor and by EIP-7623 zero-byte calldata catching up to the EIP-7976 / EIP-8131 rate.

When does the floor bite? For calldata-only transactions:

tx_floor > gas_used  ⇔  calldata_bytes  >  (gas_used − TX_BASE) / FLOOR_GAS_PER_BYTE

A typical token transfer (68 B calldata, ~50 k gas) has tx_floor = 25,352, well under gas_used. A 50 k-gas tx needs more than 453 B of calldata before the floor bites.

Wallets and eth_estimateGas MUST compute the new floor.

Test Cases

Bare ETH transfer

tx.to = recipient, tx.value = 1 ether, tx.data = b"", no access list, no authorizations, no blob hashes.

• tx_floor = TX_BASE = 21,000 gas. Unchanged.

Calldata-only transaction

10,000 calldata bytes, no other variable-length content.

• tx_floor = 21,000 + 64 × 10,000 = 661,000 gas. Identical across all transaction types carrying the same calldata.

Access-list entry: address with one storage key

• tx_floor = 21,000 + 64 × (20 + 32) = 24,328 gas.

EIP-7702 with one authorization

• tx_floor = 21,000 + 64 × 108 = 27,912 gas.

EIP-4844 with six blob versioned hashes

• tx_floor = 21,000 + 64 × (6 × 32) = 33,288 gas.

Security Considerations

Block-size bound

Every content byte the transaction contributes is paid at FLOOR_GAS_PER_BYTE via tx_floor. Implicit per-tx bytes (envelope, signature, type prefix) are covered by TX_BASE:

content_bytes_per_tx * FLOOR_GAS_PER_BYTE  ≤  tx_floor  ≤  tx.gasUsed

Summing across user transactions:

sum(content_bytes) ≤ sum(tx.gasUsed) / 64 ≤ block_gas_limit / 64

At a 60M gas limit, the bound is 60,000,000 / 64 ≈ 0.89 MB of attacker-controlled content per block. It is derived from arithmetic, requires no compression assumption, and survives a change of the network compressor.

Envelope and signature contribute at most ~130 × (block_gas_limit / TX_BASE) ≈ 372 KB at a 60M gas limit, well below MAX_RLP_BLOCK_SIZE.

Type symmetry

Two transactions carrying identical content pay identical floor regardless of transaction type.

Gas estimation

Wallets and eth_estimateGas MUST compute tx_floor alongside intrinsic gas. Without it, estimates for floor-bound transactions are too low and submissions will be rejected at validation.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Toni Wahrstätter (@nerolation), "EIP-8131: Unified Transaction Content Floor [DRAFT]," Ethereum Improvement Proposals, no. 8131, January 2025. Available: https://eips.ethereum.org/EIPS/eip-8131.