EIP-8115 Batch settlement of priority fees at the end of the block (Batch priority fees at end of block)
Hegota Declined for Inclusion · Fees & gas · EIP status Draft · created 2025-12-30
Priority fees that used to be paid out right after each transaction finishes are instead summed up after all transactions in the block have finished and paid out once.
Why it is needed
Of the fees paid when sending a transaction on Ethereum, the priority fee is credited to the fee recipient that built the block right after each transaction finishes. As a result, every transaction in a block writes to the same place, the fee recipient's account balance, which makes parallel execution of transactions difficult. It can also happen that a sender only has enough balance after earlier transactions in the same block are processed, which complicates the mempool logic that manages pending transactions. For the fee recipient, accounting is cumbersome because a payment that logically should be one is received as hundreds of small payments. Proposals to log ETH movements also become inaccurate if priority fees are left out, and adding an entry for every transaction makes them expensive. This EIP credits the priority fee once at the end of the block, which solves these problems together.
What changes
Today
- The priority fee is credited to the fee recipient immediately after each transaction finishes
- Every transaction writes to the fee recipient's balance, which limits parallel execution
- The fee recipient receives hundreds of small payments in a single block
- Some transactions only have a balance once an earlier transaction's fee has been credited, which complicates mempool management
After EIP-8115
- The priority fees summed over all transactions in the block are credited once after all transactions have finished
- No fee is credited during transaction execution, which makes parallel execution easier
- The fee recipient receives one payment per block
- The priority fees received can be spent from the next block onward
Who is affected
- Validators and fee recipients: They receive priority fees once per block, and that money can only be spent in the next block.
- Block builders and MEV operators: The original says builder infrastructure may need to be updated and that liquidity requirements for MEV use may change.
- Client teams: The fee handling logic must be changed to remove per-transaction credits and credit the summed amount at the end of the block.
- Wallet and mempool operators: Cases where a balance appears thanks to an earlier transaction's fee credit disappear, which simplifies handling of pending transactions.
In depth
Specification: the settlement point moves to the end of the block
EIP-1559 priority fees SHALL no longer be credited after each individual transaction finishes. Instead, all priority fees incurred in the block are summed and credited once after all transactions in the block have been processed. The credit must happen before EIP-4895 withdrawals are processed. So the block processing order is: execute all transactions, credit the summed priority fees, then process withdrawals.
Motivation: four problems caused by per-transaction credits
The original lists four problems with the current approach. First, limited parallelization: every transaction writes to the fee recipient's account balance, so it is hard to execute transactions concurrently. Second, mempool complexity: the sender of a transaction may only have enough balance after earlier transactions in the same block are processed, which complicates the logic for pending transactions. Third, accounting complexity: the fee recipient receives hundreds of small payments for what logically should be one. Fourth, inaccurate logs: proposals to log ETH movements become inaccurate and less useful if priority fees are left out, and adding an entry for every fee payment makes them expensive.
Rationale: parallel execution and accurate balance logs
The original describes this EIP as a step toward fully accurate ETH balance logs. Crediting fees in a batch also improves parallel execution. Today, a transaction can start with an insufficient balance and become executable only as the priority fees of earlier transactions are credited bit by bit. After the batch credit at the end of the block, that kind of dependency no longer arises.
Backward compatibility and security: spendable from the next block
The fee recipient receives priority fees at the end of the block instead of bit by bit with each transaction, so the money can be spent from the next block onward. The original says that because of this, block builder infrastructure may need to be updated and liquidity requirements may change for MEV use. It states that there is no security impact.
Status and Hegotá discussion
This EIP is in Draft status, so its content may still change. In fork discussions, it was accepted as a Hegotá candidate (PFI) on the 07.30 ACDE #242 call, where it was noted that parallel execution and UX improve but that the fees can only be spent in the next block. Later, on the 09.10 ACDE #245 call, it was declined (DFI) for Hegotá together with EIP-8188 and EIP-8358. All three received low ratings, and only Nethermind supported 8115, but it backed off, saying this was not an issue worth fighting for.