Yes, the transaction format for EIP-1559 is different. The current transaction format (now called legacy transactions) will still work, but will result in you always overpaying for transactions.
Legacy transactions have a gas price, whereas EIP-1559 transactions have a priority fee and max fee. The max fee is how much you are willing to pay in total for your transaction (so base fee and the priority fee combined). If you send a legacy transaction, the specified gas price will be used for both the priority fee and max fee. This will result in you paying the full difference between the base fee and the set gas price to the miner, since you didn't set a lower priority fee.
How you get the priority fee will also likely change, and you shouldn't need an API like ETH Gas Station for this anymore, but how this should be calculated will probably wait until after the launch of EIP-1559.
Web3.py appears to support EIP-1559 already, and will try to determine the best max fee and priority fee: https://github.com/ethereum/web3.py/pull/2055
EIP-1559 transactions are typed transactions (see EIP-2718), where the type for EIP-1559 transactions is specified as 0x02
. The payload of the EIP-1559 transactions consists of (as JSON):
{
"gas": "0x5208", // = gasLimit
"maxFeePerGas": "0xb2d05e00",
"maxPriorityFeePerGas": "0xb2d05e00",
"input": "0x", // = data
"nonce": "0xa",
"to": "0xc6d5a3c98ec9073b54fa0969957bd582e8d874bf",
"value": "0x0",
"accessList": [],
"chainId": "0x5"
}
Here is an example of the above EIP-1559 transaction on Etherscan (on Goerli): https://goerli.etherscan.io//tx/0xeb403182d4e2f2705d012e864ac5316c54ceddfc0ee583c730c918040520a75a
The raw transaction receipt of this transaction looks like this:
{
"blockHash": "0xee4df7e9d55b56162346fb779c074fe897bc6bb737051ab776a83a2b6f15962d",
"blockNumber": "0x4fef3c",
"contractAddress": null,
"cumulativeGasUsed": "0xa410",
"effectiveGasPrice": "0xb2d05e00",
"from": "0xc6d5a3c98ec9073b54fa0969957bd582e8d874bf",
"gasUsed": "0x5208",
"logs": [],
"logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"status": "0x1",
"to": "0xc6d5a3c98ec9073b54fa0969957bd582e8d874bf",
"transactionHash": "0xeb403182d4e2f2705d012e864ac5316c54ceddfc0ee583c730c918040520a75a",
"transactionIndex": "0x1",
"type": "0x2"
}
Note that the type is not used as transaction payload itself, but rather specified as the EIP-2718 transaction type (where a transaction consists of TransactionType || TransactionPayload
).
The maxFeePerGas
is the total fee you are willing to pay per unit of gas. maxPriorityFeePerGas
(which is sent to the miner) is the total priority fee you are willing to pay, which should be lower than or equal to the maxFeePerGas
. How much you end up paying is gas × (baseFee + maxPriorityFeePerGas)
, assuming maxFeePerGas
is higher than the current base fee. The difference between the maxFeePerGas
and the actual used gas price is "refunded".
Legacy transactions will still work, but the gasPrice
of legacy transactions will be used as both the maxFeePerGas
and maxPriorityFeePerGas
, so you'll never end up getting a refund. The miner will always take the difference between the base fee and the max fee. To get the full benefit of EIP-1559 it's recommended to set both fields.
For more details on how the max fees should be estimated or how EIP-1559 can be implemented in general, I recommend you check out the EIP-1559 Cheatsheet for Implementers.
Best Answer
Let's quickly understand how the fee is changed in EIP-1159.
In the EIP-1159 transaction; we supply
maxFeePerGas
andmaxPriorityFeePerGas
. The base fee is automatically calculated by the network.Now the base fee can increase/decrease but we have already supplied the max fee we want to pay in
maxFeePerGas
. So ifbaseFee
increases in the next block, the priority fee can be adjusted to make sure the total fee never crosses the max fee.Base Fee + Priority Fee <= Max Fee
Now about calculating the fee;
we need to get the base fee from the blockchain node and we can then decide how much max fee we want to make. Ideally, if you want your tx to be valid even after 6 blocks (assuming the base Fee increases to a maximum per block); you can use given formulae to calculate the max fee.
So in terms of how do we get each field: