Go-Ethereum – How to Specify Priority Fee and Max Fee per Gas in Geth’s JSON-RPC API?

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.

Good question!

A hard fork doesn't necessarily mean the functionality wouldn't be backwards compatible. It means that users of the blockchain need to upgrade their clients, and that clients with the old version are no longer compatible with the blockchain. I would word it like this: client compatibility and function compatibility are different things.

Yes, you can still use the legacy transaction model, but it will not benefit from the newest changes. Here's some more info: https://eips.ethereum.org/EIPS/eip-1559#backwards-compatibility . You just can't use the legacy clients (they won't get synchronized).

Granted, it's a bit tricky to try to figure out what does it exactly mean that the EIP is backwards compatible. All the places just say "yes it's compatible, it just won't benefit from the new system". So I'm not 100% clear on that.