incoherent lastBaseFeePerGas on matic

[PierreJeanjacquot]

Ethers Version

5.7.2

Search Terms

lastBaseFeePerGas matic

Describe the Problem

On matic network the lastBaseFeePerGas provided by provider.getFeeData() seems to be incoherent (strongly decorrelated from gasPrice) this causes creating underpriced type 2 transactions.

example:

ethers.getDefaultProvider('matic').getFeeData().then(console.log)

{
  lastBaseFeePerGas: BigNumber { value: "18" },
  maxFeePerGas: BigNumber { value: "1500000036" },
  maxPriorityFeePerGas: BigNumber { value: "1500000000" },
  gasPrice: BigNumber { value: "30000000040" }
}

lastBaseFeePerGas is only 16 wei when gasPrice is 30 Gwei.

I tried several public RPC + infura, the answer is always similar, what am I missing? Should I use legacy tx?

Code Snippet

ethers.getDefaultProvider('matic').getFeeData().then(console.log)

Contract ABI

No response

Errors

No response

Environment

Altcoin - Please specify (e.g. Polygon), node.js (v12 or newer)

Environment (Other)

polygon/matic

[ricmoo]

Looking at the other values in that fee data, it looks correct. You see the maxFee = 2 * lastBaseFee + priorityFee.

The problem lies in how polygon implemented EIP-1559, which basically means all transactions are participating in a bidding war during congestion (similar to how Ethereum was prior to EIP-1559).

As a result, you need to use an external gas station (again, similar to Ethereum pre-1559) to get a meaningful suggested gas price. Based on the above numbers it looks as though the network is under heavy congestion or the nodes gasPrice method is heavily over-estimating.

Also keep in mind you must add the priorityFee to the last base fee. The base fee is merely the component that is burned, and is provided so people can adjust and compute based on their own desired priority fee, which they must add.

Make sense?

[PierreJeanjacquot]

Thank you for your answer @ricmoo it makes sense!
I'm also curious on what makes the matic implementation of EIP-1559 so different from mainnet.