# Execution-Independent Priority Fee ```yaml todo: replace with --- eip: tbd title: Execution-Independent Priority Fee description: Do not refund the priority fee portion of the transaction fee for unused gas after execution. author: Dankrad Feist (@dankrad), Ansgar Dietrichs (@adietrichs) discussions-to: tbd status: Draft type: Standards Track category: Core created: 2024-01-31 ``` ## Abstract This EIP changes the semantics of the priority fee ("tip") such that it is independent from the actual gas used by a transaction. The priority fee will always be equal to `tx.gas * priority_fee_per_gas`. ## Motivation The priority fee, as a minimum, needs to compensate the proposer or block builder for the increased risk from orphaning due to including the transaction (otherwise it is not rational to include a transaction). Orphan risk increases due to transmission delays (transaction size) and execution delays (gas consumed). With rollups, size becomes a more important factor, and it doesn't make sense anymore that the tip should be computed according to execution time, which can vary depending on state. ## Specification Change the [block validation rules](https://github.com/ethereum/execution-specs/blob/1fed0c0074f9d6aab3861057e1924411948dc50b/src/ethereum/shanghai/fork.py#L542) as follows (changes highlighted with comments): ```python def process_transaction( env: vm.Environment, tx: Transaction ) -> Tuple[Uint, Tuple[Log, ...], Optional[Exception]]: ... gas_used = tx.gas - output.gas_left gas_refund = min(gas_used // 5, output.refund_counter) # change: only refund base fee gas_refund_amount = (output.gas_left + gas_refund) * env.base_fee_per_gas priority_fee_per_gas = env.gas_price - env.base_fee_per_gas # change: use full gas limit for priority fee payment transaction_fee = tx.gas * priority_fee_per_gas total_gas_used = gas_used - gas_refund sender_balance_after_refund = ( get_account(env.state, sender).balance + gas_refund_amount ) set_account_balance(env.state, sender, sender_balance_after_refund) coinbase_balance_after_mining_fee = ( get_account(env.state, env.coinbase).balance + transaction_fee ) if coinbase_balance_after_mining_fee != 0: set_account_balance( env.state, env.coinbase, coinbase_balance_after_mining_fee ) elif account_exists_and_is_empty(env.state, env.coinbase): destroy_account(env.state, env.coinbase) ... ``` ## Rationale The priority fee, as a minimum, needs to compensate the proposer or block builder for the increased risk from orphaning due to including the transaction (otherwise it is not rational to include a transaction). Orphan risk increases due to * Delays from the block size (transaction calldata) * Delays from additional blob data transmission (EIP-4844 blobs) * Delays due to execution of the transaction (proportional to execution gas) Only the last one of these is proportional to execution gas used. But the tip is currently always proportional to execution gas used. Let's say a transaction has 1 blob and sets max gas = 1,000,000, and a priority fee of 100 GWei. A builder would expect to be paid a 100,000,000 GWei = 0.1 ETH tip. However, if the transaction only ends up using 100,000 gas, it will only pay a 0.01 ETH tip instead. Even simulating the transaction does not guard against this, as the gas used might depend on the exact state when the transaction is executed -- so only executing it in the exact order that a builder is planning to include it will guarantee inclusion. This might be acceptable for professional builders, but is less so for stakers who want to build blocks themselves. In a world with multiple different types of gas, it is better to have the priority fee be a fixed number per transaction, as this is predictable no matter if some types of gas are used up or not and guarantees that the builder will be compensated for orphan risk. This EIP does that by guaranteeing that the priority fee will always be equal to `tx.gas * priority_fee_per_gas`, which can be easily computed without fully execution a transaction. ## Backwards Compatibility Mainstream wallets already compute `tx.gas` to be the (simulated) transaction gas plus a small extra (e.g. 5%) to account for additional execution time triggered by state changes before the transaction is included. Very little would change for a user of such a wallet. In rare cases, the execution gas used by a transaction can vary significantly due to state. In this case, the priority fee for such a transaction can end up being much higher than a user expected. Such transactions cannot be handled by the default settings of most wallets and we can expect that users sending such transactions will be sufficiently knowledgable to consider the best priority fee setting on their own. ## Security Considerations No security risks are associated with the changes in this EIP. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).