I know the maxFeePerGas = baseFeePerGas + maxPriorityFeePerGas in EIP-1559. But I found this transaction. https://etherscan.io/tx/0xe753607fff85bb9298b90d4dc3357c92d82add1f9a09b48c348fdd7e97a68cd2 I can't understand how this transaction could be executable. I hope anyone to explain about this.

3 Answers 3


I don't know if this is the case for that specific transaction, but in general there are various ways how transactions get executed.

There's the traditional way, where one submits a transaction, nodes relay it onwards and a miner/validator picks it up at some point for inclusion in a block. This type usually requires valid gas amounts, although in theory one can submit almost any type of gas fees and hope for the best - some clients block dumb fees and validators typically refuse dumb fees. But in theory many type of weird combinations are possible.

Then there's the second way of MEV. This is where you don't submit your transaction publicly for nodes to propagate. Instead, you send it directly to a MEV relay system where a validator picks it and includes in their block. The gas amounts can be weird here, since gas is not how the transaction is paid for possibly. The transaction inclusion can be paid for, for example, by a direct ETH bribe. So you can send a transaction with maybe even zero gas fees, but include a direct bribe in Eth, and greedy validators include it just for the bribe amount.

There are probably some other types as well, but these are the most common types.


maxFeePerGas = baseFeePerGas + maxPriorityFeePerGas

This isn't exactly true.

For a transaction to be valid, it only has to pay the full amount on baseFeePerGas. Whatever that's left is paid as a tip with the amount up to maxPriorityFeePerGas.

Let say a transaction has maxFeePerGas=300 and maxPriorityFeePerGas=10. And when this transaction reaches a node, Ethereum network has decided that baseFeePerGas=250.

After the baseFeePerGas is paid, the transaction has 50 to spend(i.e. 300-250=50). Then only 10 is paid as the priority fee, let's call it effectivePriorityFeePerGas, leaving 40 to spare(i.e. 50-10=40). During the execution, 260 is used to deduct from the balance of the sender.

On the other hand, if maxPriorityFeePerGas=300 with other parameters being the same as above, effectivePriorityFeePerGas is set to 50 because that's the largest amount the transaction can spend after paying baseFeePerGas. And all 300 maxFeePerGas will be used to deduct from the balance.

More proper equation might be:

maxFeePerGas = baseFeePerGas + effectivePriorityFeePerGas


baseFeePerGas is not under the control of the transaction submitter. The amount is settled when the block is mined. Before that, it is just an assumption based on previous values. The submitter only specifies maxFeePerGas and maxPriorityFeePerGas. Your calculation is a little bit wrong in the sense that max** values represent a range, while baseFeePerGas is an absolute value.

The submitter pays at least the baseFeePerGas and additionally some amount from maxPriorityFeePerGas until their sum does not exceed the maxFeePerGas. Therefore, the resulting paid fee could be less or equal to the maxFeePerGas.

If a submitter sets maxPriorityFeePerGas to be equal to maxFeePerGas, then after the baseFeePerGas is settled during the block execution, the validator will receive the complete amount of maxFeePerGas. This is because any difference between maxFeePerGas and baseFeePerGas is covered by the specified maxPriorityFeePerGas.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.