Consider using eth_maxPriorityFeePerGas to derive priority fees.

[jxom]

Ethers Version

^6

Search Terms

No response

Describe the Problem

Could be a nice addition to rely on eth_maxPriorityFeePerGas for more accurate priority fee estimation instead of relying on a hardcoded 1 gwei. The eth_maxPriorityFeePerGas endpoint suggests an estimated priority fee.

This would also fix an issue where other OP Stack chains such as: Zora, Base, etc, won't pick up the hardcoded 0.001 gwei assigned on the network config (as it only applies to the OP Mainnet network).

If the node doesn't implement eth_maxPriorityFeePerGas, ethers could fall back to gasPrice - block.baseFeePerGas.

Code Snippet

No response

Contract ABI

No response

Errors

No response

Environment

No response

Environment (Other)

No response

[ricmoo]

Discussion: #4358

On OP, the value 1000000 is used, as provided by the OP team, but yes, I would love to be able to rely on a programmatic way of getting this value, rather than setting a per-network value as ethers currently does.

I would worry about using the heuristic gasPrice - baseFee though, since during fork transitions this value could fluctuate in unpredictable ways. Since deployed code tends to not get updated, making future assumptions about this value could be dangerous. Unless someone like @timbeiko signs off on it and is made aware this calculation will be assumed?

Some backends also simply “don’t respond” if an endpoint isn’t found, so I’d be concerned with stalling in this case.

But I’m open to discussion and curious about the current state of support for this endpoint. And also whether backends that ghost you on unknown endpoints is still a problem. :)