should consider minimum priority fee when calculating `maxPriorityFeePerGas`

[egonspace]

In calculating maxPriorityFeePerGas as following code:

core/packages/gas-fee-controller/src/fetchGasEstimatesViaEthFeeHistory/calculateGasFeeEstimatesForPriorityLevels.ts

Line 75 in 1dadf04

const adjustedPriorityFee = medianPriorityFee

const medianPriorityFee = medianOf(priorityFees);
  const adjustedPriorityFee = medianPriorityFee
    .mul(settings.priorityFeePercentageMultiplier)
    .divn(100);

If minimum priority fee in block history is same to the median value, then the tx having 97% of the median as
maxPriorityFeePerGas may not be accepted by txpool.

For example, let's assume the following situation.
priorityFees = [10, 10, 10, 10, 10, 11, 12, 13, 14]
median is 10 (5th element)
and adjustedPriorityFee = 9.7 (10 * 97%)
So txpool may reject the tx because of the priorityFee less than min value.

Actually, some chain uses fixed priorityFee to have the all same effectivePriorityFeePerGas in block fee history so
metamask fails to send a transaction without manual setting of gas.

Are you willing to improve this?
How about to use median * 97% but at least set it to be greater than min?

[peter941221]

Thanks for raising this — I dug into the issue and the underpricing failure mode makes sense.

Before I work on a patch, could a maintainer confirm the intended fix location?

This issue points to the historical local eth_feeHistory path in packages/gas-fee-controller/src/fetchGasEstimatesViaEthFeeHistory/calculateGasFeeEstimatesForPriorityLevels.ts, but in current HEAD the gas-fee flow seems to be organized differently.

Should this still be fixed in the local fee-history estimation path, or has the relevant logic moved elsewhere?

If that historical path is still the right layer, the smallest fix seems to be keeping the discounted-median heuristic but flooring the adjusted priority fee at or above the minimum observed priority fee from the sampled history, so fixed-tip chains do not get underbid.