This EIP proposes an adjustment to calldata pricing by raising the floor cost from 64/64 to 96/96 gas per calldata byte. This brings the worst-case byte density of a pure-calldata block down to the byte density of an ETH-transfer-full block, so that no priced calldata composition is denser, per gas, than this anchor.
The 21,000-gas ETH transfer anchors both dimensions of a block. On the execution side, EIP-8007 has pushed worst-case execution as far as the current ETH transfer cost permits. On the bandwidth side, a block full of transfers is itself a data payload. Its envelopes, signatures, and per-transfer access-list records cannot be priced below 21,000 gas per transfer. A transfer-full block therefore sets an irreducible byte density. This is the most bytes per gas the protocol can be forced to carry and cannot price away.
Today a pure-calldata block is denser than this anchor. That makes calldata the binding bandwidth constraint on a slot. The gas limit must stay low enough that the densest priced block still fits within the network's bandwidth budget. This excess calldata density therefore holds the gas limit below what the transfer anchor alone would permit.
Bringing the worst-case pure-calldata density down to the transfer anchor removes calldata as the binding constraint. This proposal aims to:
Upon activation, the floor cost for calldata is increased to 96/96 gas per byte. The new parameters are:
| Parameter | Value |
|---|---|
STANDARD_TOKEN_COST |
4 |
TOTAL_COST_FLOOR_PER_TOKEN |
24 |
Recall that floor_tokens_in_calldata = (zero_bytes_in_calldata + nonzero_bytes_in_calldata) * 4. The floor cost is 96 gas per calldata byte (both zero and non-zero), since TOTAL_COST_FLOOR_PER_TOKEN * 4 = 96. The token abstraction is retained only for consistency with EIP-7623 and EIP-7976.
A transfer-full block cannot be repriced without charging more than 21,000 gas per transfer, so the goal for any data-pricing change is to make it the worst case by construction: every composition the protocol prices should carry at most as many bytes per gas as it does. Accounting for a worst-case transfer envelope (~130 bytes) plus its worst-case marginal block-access-list contribution (~91 bytes), a single transfer adds ~221 bytes for 21,000 gas, or a byte density of approximately 0.0105 bytes/gas.
EIP-7976 set the calldata floor at 64 gas per byte, so data-heavy transactions cost 64/64 gas per zero/non-zero byte. A pure-calldata block at that floor has a byte density of 1/64 ≈ 0.0156 bytes/gas, roughly 1.49× the transfer block density. The smallest possible lever to close this gap is to raise the floor to:
F* = ceil(1 / 0.01052) = ceil(95.06) = 96 gas/byte
At 96 gas per byte, a pure-calldata block has a byte density of 1/96 ≈ 0.0104 bytes/gas, which sits at or just below the transfer-anchor density. The target of 96 is therefore not arbitrary. It is the smallest integer floor F for which 1/F does not exceed the ETH-transfer block density of ~0.0105 bytes/gas. Choosing the floor this way ensures it does exactly the job it needs to do. It brings pure calldata down to the anchor line without overcharging beyond what the anchor requires.
By increasing calldata costs from 64/64 to 96/96 gas per byte for data-heavy transactions, this EIP also provides:
The floor cost mechanism ensures that transactions involving significant EVM computation continue to pay the standard 4/16 gas per byte for calldata, preserving the user experience for regular Ethereum operations.
For an illustration of the absolute effect, a 10 MiB uncompressed execution payload would require ~1.01B gas under 96/96 pricing, compared to ~671M gas under EIP-7976's 64/64 pricing and ~105M gas under EIP-7623's 10/40 pricing.
This is a backwards incompatible gas repricing that requires a scheduled network upgrade.
Wallet developers and node operators must update gas estimation handling to accommodate the new calldata cost rules. Specifically:
Wallets: Wallets using eth_estimateGas must be updated to ensure that they correctly account for the updated TOTAL_COST_FLOOR_PER_TOKEN parameter of 24. Failure to do so could result in underestimating gas, leading to failed transactions.
Node Software: RPC methods such as eth_estimateGas must incorporate the updated formula for gas calculation with the new floor cost values.
Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.
Testing for this EIP should verify the correct application of the new calldata cost floor of 96/96 gas per byte:
eth_estimateGas correctly accounts for the new TOTAL_COST_FLOOR_PER_TOKEN valueAs the maximum possible block size is further reduced compared to EIP-7976, no additional security concerns are introduced beyond those already addressed in the original proposals.
The same transaction bundling considerations from EIP-7623 apply:
The increased floor cost strengthens the incentive structure for appropriate data availability method selection without introducing new attack vectors.
This EIP addresses only the pure-calldata composition. Mixed compositions that combine cheap standard-rate calldata with byte-dense state access are out of scope. A higher calldata floor alone does not bring them to the anchor line, so they are left to a separate proposal.
Copyright and related rights waived via CC0.