Hi everyone - I wanted to collect some thoughts on gas price policy. Some of the concerns I raised in the gas spike thread (Pre-PIP Discussion: Addressing Reorgs and Gas Spikes - #5 by Thogard) have begun manifesting in some strange ways and I’ve begun seeing 10+ min delays on some transactions that I wouldn’t expect delays on. I plan to put a PIP together but there are multiple ways to address the issue and I’m unsure which would be preferred by the community.
Take a look at the stats on this block:
https://polygonscan.com/block/40351727
At FastLane we do lots of transaction monitoring. We were trying to debug why a transaction hadn’t landed. The bundle had a maxGasPrice of ~95 and a maxPriorityFee of ~95. It was submitted about twenty minutes prior to this block. It finally landed in the block that came after this block.
Note that:
- The block is NOT full
- The base fee 67.090413299 Gwei
- The LAST transaction in the block has a gas price of 97.090413299 Gwei)
So why did the tracked transaction not land in this block, even though it had been waiting for 20 min? It had a maxGasFee of 90 and maxPriorityFee of 90… should be fine for when the baseFee is 67, right?
Well… no.
Note that for that block the lowest accepted gasprice was 97.0904… which equals base fee + 30.
so even though the tracked transaction had a high enough gasprice to pass both the 30 Gwei floor and the 67 Gwei base fee, it seems that for some reason or another the 30 gwei floor is being checked against the EffectiveGasTip (maxGasPrice - baseFee) rather than just against the maxGasPrice.
In the case of the tracked tx, with a maxGasPrice of 95 and a base fee of 67 that meant there was only a 28 Gwei EffectiveGasTip. This caused the tx to fail the price >= 30 check and therefore it wasn’t mined until the baseFee dropped below 65.
So I think there are a few options:
-
This is an intended feature and we leave it alone.
-I don’t think this is the case and I don’t think this is ideal either as it would be very hard for wallets to predict. (we’d be pegging a % increase (baseFee goes up or down a fixed percentage of its current value) against a nominal increase (30 gwei)… def not optimal as the impact of 30 gwei against baseFee will be huge during low baseFees and meaningless against high baseFees. -
Fix this in bor
-I can write a pr to the bor code that updates the calculation in bor so that the 30 Gwei floor is checked against the maxGasPrice instead of the EffectiveGasTip. This feels like both the easiest but also the most “centralized” option. -
One of a variety of PIPs
-a PIP to remove the gas floor of 30 Gwei
-a PIP to change the gas floor of 30 Gwei to be a “minimum base fee” of 30 Gwei for the purposes of EIP-1559 calculations (this could branch multiple ways, too)
-a PIP to change the 30 gwei floor to impact the maxGasFee rather than the EffectiveGasTip
-a PIP to change EIP-1559’s structure
-a PIP for an even better solution that someone else thinks up
So I figured I’d just kinda float the problem out to the forum and see if anyone has any strong preferences before I spend any time authoring a PIP. Would love to hear any thoughts / concerns / questions you all have 
