EIP-8116 Replacing the cumulative gas field in receipts (Replace cumulative receipt fields)
Hegota Considered for Inclusion · EVM & execution · EIP status Draft · created 2025-12-30
The gas field of the receipt stored in the block is changed from the running total since the start of the block (cumulativeGasUsed) to the amount that transaction used (gasUsed). The log index (logIndex) in RPC responses is also changed from a block-based index to a receipt-based index.
Why it is needed
Each time Ethereum processes a transaction, it leaves a receipt recording the result. Today the receipt does not record the gas used by that transaction but the sum of all gas used from the first transaction in the block up to this one (cumulativeGasUsed). So to find the gas used by one transaction, you also have to fetch the preceding receipt and subtract the two values. This is a hassle for RPC clients that want to verify things themselves rather than trust the node. In addition, because the receipt content is tied to the results of earlier transactions, receipts can only be built in order, even for transactions that touch entirely different state. This is an obstacle to parallel processing. The log index (logIndex) returned over JSON-RPC has the same problem. It is a number across the whole block, not within the receipt, so it cannot be determined without information about earlier transactions.
What changes
Today
- The receipt records the cumulative sum of gas used from the start of the block through that transaction (cumulativeGasUsed)
- To verify the gas usage of one transaction, you must also fetch the preceding receipt and subtract
- Receipt content is tied to earlier transactions, so even unrelated transactions are hard to process separately
- The RPC logIndex is a number across the whole block
After EIP-8116
- The receipt records only the gas that transaction used (gasUsed)
- Gas usage is verified with just one receipt and a Merkle proof
- Receipts become independent of earlier transactions, so the obstacle to parallel processing disappears
- logIndex becomes a number within the receipt
Who is affected
- Wallet & app developers: Apps that use verified gasUsed or cumulativeGasUsed values, and apps that order logs by block-level logIndex, must be updated to the new meaning.
- RPC clients and light clients: A single receipt is enough to verify a transaction's gas usage, so there is no need to fetch the preceding receipt as well.
- Client teams: Receipt construction and the logIndex calculation in JSON-RPC responses must change. The call classified this as technical debt cleanup.
- Ordinary users: There is nothing to do manually. Wallets and apps you use only need to update to the new data format.
In depth
Receipts record per-transaction gas usage
Every receipt created after this EIP is activated records the gasUsed of that transaction instead of cumulativeGasUsed. cumulativeGasUsed is a running total of all gas used by earlier transactions in the block, while gasUsed is the value for that single transaction. The original specification ends with this one sentence and does not describe any change to other receipt fields or to the encoding. According to the call record, this change lets a single Merkle proof verify a transaction's gas usage without fetching two receipts and computing the difference.
logIndex in JSON-RPC becomes a per-receipt number
The logIndex field inside logs in JSON-RPC responses has so far indicated the position of a log within the whole block. After this EIP it indicates the position of a log within its receipt. The original text states that this part is an RPC-only change, not an on-chain data change. In other words, the logs stored in the block stay the same, and only the number the node attaches to the response changes. The original Motivation points out that a logIndex that increases across the block has the same drawback as cumulativeGasUsed, and this change answers that point.
Two problems caused by cumulative fields
The original text lists two drawbacks of cumulativeGasUsed. The first is inefficient verification. An RPC client that wants to verify the gasUsed of an individual transaction must fetch the cumulativeGasUsed of consecutive receipts and compute the difference. The second is limited parallelism. Even transactions that touch only non-overlapping state cannot produce their receipts independently, because the receipt contents are stateful values that depend on the preceding receipt. The original text adds that logIndex has the same drawback, since it is a number that increases across the block rather than a per-receipt number.
Aligning on-chain data with the RPC data that is actually used
The original Rationale describes this EIP as a step toward aligning on-chain data with the RPC data that client applications actually consume. Concretely, it replaces the stateful components of the receipt, cumulativeGasUsed and logIndex, with per-transaction values. According to the Motivation, what RPC clients want is the per-transaction gasUsed, but the chain holds only the cumulative value, so verifying it directly required collecting consecutive receipts and computing. Putting the per-transaction value on chain from the start removes that gap.
Backwards compatibility: two points where apps must adapt
First, applications that use a verified gasUsed or cumulativeGasUsed value must be changed to fit the new on-chain semantics. Second, applications that depend on a block-wide logIndex also need adjustment, because logIndex becomes a per-receipt number. To learn the relative order of logs within a block as before, the original text suggests estimating it with transactionIndex * 4 + logIndex. The original says this keeps the ordering the same as before, but the absolute number values may be larger than they were. The original itself makes clear, with the word estimating, that this formula is an estimate and not an exact reconstruction.
Status: Draft, lowest priority among Hegota fork candidates
This EIP is a Draft proposal created on 2025-12-30, so the specification may still change. The Security Considerations section is also written only as None and may be filled in later. In core developer calls, it was accepted as a Hegota fork candidate (PFI) at 07.30 ACDE #242. The reason was that it lets a Merkle proof verify gas usage without fetching two receipts and computing the difference. At 10.08 ACDE #247 it was moved to the Hegota consideration list (CFI), but with the lowest priority. The assessment was that it is technical debt cleanup and not urgent. Inclusion in the fork has not been confirmed.