EIP-8131 Unified transaction content floor price (Unified Transaction Content Floor)

Hegota Considered for Inclusion · Fees & gas · EIP status Draft · created 2025-01-21

Sets a minimum fee of 64 gas per byte on every byte a user fills in a transaction (calldata, access list, EIP-7702 authorizations, blob hashes). This arithmetically bounds the worst-case amount of data that fits in one block.

Why it is needed

Every node must handle the largest block an attacker can build, not the average block. That is why EIP-7623 introduced a floor price on calldata bytes, EIP-7976 raised that rate to 64 gas per byte with no distinction between zero and non-zero bytes, and EIP-7981 extended the same rate to access list bytes. However, EIP-7702 authorization tuples (up to 108 bytes each) and EIP-4844 blob versioned hashes (32 bytes each) were added without a corresponding floor, and they still pay no floor price at all. Also, every new field required a separate EIP and a separate constant. This EIP merges EIP-7976 and EIP-7981 into a single per-byte rule and closes the gap for authorization tuples and blob hashes under the same rule. Any variable-length field added in the future automatically gets the same rate, and the worst-case block content size gets an upper bound that can be proven by arithmetic alone.

What changes

Today

After EIP-8131

Who is affected

In depth

A single floor price formula

tx_floor = TX_BASE + FLOOR_GAS_PER_BYTE × (len(tx.data) + ACCESS_LIST_ADDRESS_BYTES × number of addresses + ACCESS_LIST_STORAGE_KEY_BYTES × number of storage keys + AUTH_TUPLE_BYTES × number of authorizations + BLOB_VERSIONED_HASH_BYTES × number of blob hashes). The constants are TX_BASE = 21000, FLOOR_GAS_PER_BYTE = 64, ACCESS_LIST_ADDRESS_BYTES = 20, ACCESS_LIST_STORAGE_KEY_BYTES = 32, AUTH_TUPLE_BYTES = 108, and BLOB_VERSIONED_HASH_BYTES = 32. A field that a transaction type does not have has a count of 0, so it contributes 0. The floor price can be computed from counts alone, not lengths.

Charging method: max(intrinsic, floor)

Validation requires tx.gas >= max(intrinsic, tx_floor), and settlement sets tx.gasUsed = max(execution_gas_used, tx_floor). The max(intrinsic, floor) structure introduced by EIP-7623 is kept as is. Intrinsic gas itself is not changed. The standard rates of EIP-2028 (4 gas per zero byte, 16 gas per non-zero byte) are the cost of EVM and state operations, and their purpose differs from the floor rate, which defends bandwidth. Raising the standard rates would raise the cost of every transaction with non-zero data, but it would not improve the bandwidth defense this EIP aims at.

Why the same 64 gas for every field

If every content byte is priced at the same rate, then whichever field and whichever byte value an attacker picks, the result at the floor is the same: 1/64 byte per gas. The worst case converges to B = block_gas_limit / 64, and this bound holds regardless of the network compressor, the attack strategy or the content composition. At a 60M gas limit, attacker-controlled content per block is about 0.89MB. Since content_bytes_per_tx × 64 ≤ tx_floor ≤ tx.gasUsed, summing over the whole block proves sum(content_bytes) ≤ block_gas_limit / 64 by arithmetic alone. Implicit bytes such as the envelope and signature are at most about 372KB at 60M, far smaller than MAX_RLP_BLOCK_SIZE.

Charge only content, and absorb the envelope into TX_BASE

If the whole RLP encoding (envelope and signature included) were charged, a legacy transaction with a smaller envelope would be strictly cheaper than an EIP-1559 transaction with the same content. Charging only content makes the types symmetric. Two transactions carrying the same content pay the same floor price regardless of type. The envelope, signature and type prefix together are at most about 130 bytes across all types defined so far, which at the 64 gas rate is about 8,300 gas, so they fit within TX_BASE = 21,000. Charging the envelope separately would add about 5,000 gas to every ETH transfer, a regression, so it is treated as implicitly covered by TX_BASE.

Authorization tuples are counted as a constant 108 bytes

AUTH_TUPLE_BYTES = 108 is the maximum RLP size of an EIP-7702 authorization tuple (list header 2B + chain_id 9B + address 21B + nonce 9B + y_parity 1B + r 33B + s 33B). Using a constant instead of len(rlp_encode(auth)) lets the floor price be computed from counts alone, without actual encoding. The trade-off is that a typical mainnet authorization with chain_id 1 and a small nonce pays about 1,024 more gas.

Mainnet impact: overall bind rate from 1.49% to 3.28%

Based on a sample of 1,500 mainnet blocks (441,271 transactions) from May 2026, the share of transactions where the floor price determines actual gas usage (bound) rises from 1.49% to 3.28% overall, and total network gas grows by 3.56%. The increase is concentrated where this EIP aims. Type 4 (SetCode) gets 108B × 64 gas = 6,912 gas newly added per authorization, so its bind rate jumps from 0.04% to 20.63%. Type 3 (blob carrying) already has 60.05% bound at the floor, and with blob hash charging the average floor rises from 69k to 84k. For legacy, EIP-2930 and EIP-1559, which make up 98.3% of traffic, the change in bind rate is at most about 1.7 percentage points. A typical token transfer with 68B of calldata using about 50k gas has a floor of 25,352 gas, which is lower than actual usage, so it is unaffected.

Status and fork discussion

This EIP is in Draft status, so its figures and design may still change. In the core developer calls, ACDE #246 on 09.24 moved EIP-8131 and the BAL byte floor EIP bundled with it to Considered for Inclusion (CFI) for the Hegota fork. CFI does not mean final approval. It means the proposal has moved on to the next stage.

Original EIP · ← EIPs