@ws4charlie would you see an issue with using EIP-1559 transactions with ZetaClient?

Here is a comparison of a legacy transaction and an EIP-1559 transaction:

Transaction fee:

• A legacy transaction fee is calculated as: gasPrice x gasUsed

• An EIP-1559 transaction fee is calculated as: (baseFee + gasTipCap) x gasUsed, see: metamask doc)

• From the perspective of CCTX fee charging: gasPrice == baseFee + gasTipCap

  In order to not touch the CCTX fee charging logic, zetaclient can simply post (baseFee + maxPriorityFeePerGas) as a replacement of gasPrice for EIP-1559 enabled chains.

Transaction building:

• A legacy transaction requires: gasPrice, gasLimit
  

• An EIP-1559 transaction requires: gasTipCap, maxFeePerGas, gasLimit
  

• Sending a EIP-1559 transaction without explicit gasTipCap or maxFeePerGas will result in error (in live tests).

  Where to get deterministic numbers of gasTipCap and maxFeePerGas when signing a TSS transaction?

• Remember the equation gasPrice == baseFee + gasTipCap. If gasTipCap becomes a field of CCTX outbound parameter, the zetaclient can then calculate baseFee as
  gasPrice - gasTipCap.

• The maxFeePerGas is the upper limit of gas price that the sender is willing to pay. The estimation of maxFeePerGas can be done by
  maxFeePerGas = gasTipCap + baseFee * 2

  See this gas fee estimation article: https://www.blocknative.com/blog/eip-1559-fees
  See ChainSafe's gas estimator for its bridge: https://github.com/ChainSafe/chainbridge-core/blob/main/chains/evm/calls/evmgaspricer/london.go#L65

  The current model of a CCTX outbound parameter only contains gasPrice and gasLimit. To support EIP-1559, a new field gasTipCap needs to be added.

Pending Transaction replacement:

A legacy transaction can be replaced by a new transaction with

• same nonce
• a higher gasPrice

An EIP-1559 transaction can be replaced by a new transaction with

• same nonce
• a higher gasTipCap, at least 10% higher
• a higher maxFeePerGas, at least 10% higher

See Alchemy doc: https://docs.alchemy.com/docs/retrying-an-eip-1559-transaction
See go-ethereum: https://github.com/ethereum/go- ethereum/blob/87246f3cbaf10f83f56bc4d45f0f3e36e83e71e9/core/txpool/legacypool/list.go#L323
and https://github.com/ethereum/go-ethereum/blob/87246f3cbaf10f83f56bc4d45f0f3e36e83e71e9/core/txpool/legacypool/legacypool.go#L146

When the gas stability pool kicks in:
-both gasPrice and gasTipCap needs to be increased by some percentage >= 10%
-again, remember the equation gasPrice == baseFee + gasTipCap
-zetaclient will calculates new baseFee as: gasPrice - gasTipCap
-zetaclient will calculates new maxFeePerGas as gasTipCap + baseFee * 2
-zetaclient will broadcast updated transaction with new gasTipCap and maxFeePerGas.

Two tasks to switch to EIP-1559

• Zetacore side adds a GasTipCap field to MsgVoteGasPrice, so the gas price store can track in state. Also, add a GasTipCap to CCTX outbound parameter. On CCTX creation, populate the median value similar to what we do for gasPrice. In gas stability pool, refresh the GasTipCap accordingly.
• Zetaclient side feeds the GasTipCap to zetacore and then use the GasTipCap in CCTX to build/sign outbound transaction.

In order to not touch the CCTX fee charging logic, zetaclient can simply post (baseFee + maxPriorityFeePerGas) as a replacement of gasPrice for EIP-1559 enabled chains.

If we can do this as a first step, this would work.

We will refactor the CCTX object later

Is the formula maxFeePerGas = gasTipCap + baseFee * 2 a standard ? Based on the docs it provides a 6 block buffer .
Should we increase that for some tx's like migration tx ?

Same for the gas tip , do you think that should be higher for tx's which are more important for the network ?

Is the formula maxFeePerGas = gasTipCap + baseFee * 2 a standard ? Based on the docs it provides a 6 block buffer . Should we increase that for some tx's like migration tx ?

Same for the gas tip , do you think that should be higher for tx's which are more important for the network?

It's a not a standard. It comes from the gas estimator. I think it's fine. We already have the mechanism of replacing/retrying a TSS transaction.