Question
Legacy gasPrice vs EIP-1559 dynamic fees for Polygon PoS mainnet
Lax Lane
0 reputation · 24 Mar 2022, 12:04 UTC
110.5K views1
Loading…
0 reputation · 24 Mar 2022, 12:04 UTC
A signed transaction succeeds against a local Hardhat node but remains pending or is displaced when broadcast to Polygon PoS mainnet during base-fee volatility. The goal is to choose a fee configuration that transfers reliably from local development to mainnet without hardcoded values that become stale.
Polygon PoS follows EIP-1559 rules with a per-block base fee and an optional priority fee. Legacy gasPrice transactions remain accepted but may be priced as maxFeePerGas, and local nodes often use fixed or zero gas pricing that does not reflect mainnet conditions. Wallet and SDK implementations also differ on whether maxPriorityFeePerGas is populated through eth_feeHistory or static defaults.
Which approach fits this constraint: legacy gasPrice for broader tooling compatibility, or EIP-1559 maxFeePerGas and maxPriorityFeePerGas to track mainnet base-fee changes? When local eth_feeHistory results diverge from mainnet RPC responses, how should maxPriorityFeePerGas be derived?
Use EIP-1559 fields (maxFeePerGas and maxPriorityFeePerGas). Legacy gasPrice cannot track per-block base-fee changes and causes stuck or displaced transactions during volatility. Derive maxPriorityFeePerGas from a mainnet RPC endpoint—never from a local Hardhat node.
Polygon PoS has enforced EIP-1559 since its London-compatible fork (2022). When you send a legacy gasPrice transaction, nodes treat it as maxFeePerGas = gasPrice with an implicit, fixed maxPriorityFeePerGas. That tip cannot adjust when the base fee spikes, so the effective priority fee collapses and the transaction stalls or gets replaced. EIP-1559 transactions let maxFeePerGas absorb base-fee swings while your explicit maxPriorityFeePerGas preserves inclusion priority.
polygoneth_feeHistory and eth_maxPriorityFeePerGas.eth_maxPriorityFeePerGas. It returns a single recommended tip (typically 10–100 gwei on Polygon).eth_feeHistory for the last 20–50 blocks with reward percentiles [50, 75]. Compute the 50th–75th percentile of the returned effective priority fees.eth_feeHistory and eth_maxPriorityFeePerGas.maxFeePerGas and maxPriorityFeePerGas from the connected provider—no hardcoded values needed.maxFeePerGas = baseFeePerGas (latest block) + maxPriorityFeePerGas. Add a 1.2–1.5× buffer on the base fee if you compute it manually.maxPriorityFeePerGas ≥ 1–2 gwei; zero is valid but may be deprioritized.Rare in 2024+. Set gasPrice to 2–3× the recent mainnet base fee plus your desired tip. This is brittle—base-fee spikes will still break it.
Does your chosen RPC provider expose eth_maxPriorityFeePerGas and eth_feeHistory without depth caps? If either is missing or capped, the percentile fallback becomes mandatory and you should verify the provider's historical depth before relying on it.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 24 Mar 2022, 13:48 UTC
When migrating transaction signing from a local Hardhat node to Polygon PoS mainnet, the base fee fluctuates per block under EIP-1559 rules. Legacy gasPrice transactions require maxFeePerGas set at or above the current base fee to avoid displacement, but hardcoded values quickly become stale. A more reliable approach is to retrieve the latest block's baseFee via eth_getBlockByNumber and compute maxFeePerGas dynamically, while optionally setting maxPriorityFeePerGas as a modest percentage of that base fee to prioritize inclusion during volatility. Local eth_feeHistory results may diverge from mainnet RPC responses because Polygon PoS validators operate on separate schedules, so always validate against a live mainnet endpoint before broadcasting.