search

MetaMask / core

This monorepo is a collection of packages used across multiple MetaMask clients
MIT License
290 stars 187 forks source link

`minSuggestedMaxPriorityFeePerGas` is too broad #756

Closed tgmichel closed 2 weeks ago

tgmichel commented 2 years ago

Description

Currently, a set of hardcoded minimum priority fee constants are defined:

low - 1GWEI
mid - 1.5GWEI
high - 2GWEI

If the fee oracle returns values below these (i.e., on eth_feeHistory fallback), they are overwritten with the hardcoded minimums, which are suggested to the user instead.

This causes many issues in custom EVM chains with full EIP1559 compatibility, where miners do not necessarily impose a tip for transactions to be included (i.e., PoS networks, where the monetary incentives come through different mechanisms). An extra priority fee might help on high congested blocks, but zero-priority transactions can perfectly fill half-empty blocks. In other words, the miner (or block proposer) still has other incentives to include them.

Proposed solution

Ideally, calculateEstimatesForPriorityLevel function should just proxy the values returned by the oracle without making further assumptions on the payload other than type compliance; and Metamask UI should not force users to provide a non-zero tip (at least not in custom RPC endpoints).

Kayryu commented 9 months ago

We encounter the same issue.

mcmire commented 2 weeks ago

The fee history fallback was removed in #4210, so this should no longer be an issue. Feel free to comment if this is not the case and we will look further into this.