Polygon pricing is set by the base fee, priority tip, and gas used

29 July 2026 Last updated

Polygon pricing is the POL-denominated cost of executing a Polygon PoS transaction: gas used is multiplied by the effective per-gas price, which combines a burned base fee with a validator priority tip. A Type 2 transaction also states a maximum fee and a maximum tip, so the wallet caps exposure without paying the entire cap automatically. The base fee follows recent block demand, the tip competes for inclusion, and contract complexity sets gas consumption. This page shows how to read those fields, calculate a transparent example, compare wallet and RPC quotes, and separate network fees from swap slippage or service charges. It assumes Polygon PoS mainnet, chain ID 137, and its native gas token, POL.

A 25 gwei priority-fee floor matters before the live base fee and gas used determine the final POL charge.

Reading the fee fields before confirmation

Crucially, Polygon pricing appears on the confirmation screen as four linked values before a transaction is signed: gas limit, estimated gas, maximum fee, and maximum priority fee.

• Network: Polygon PoS mainnet uses chain ID 137 and POL for gas.
• Gas limit: This is the authorized ceiling on gas units, not the predicted charge.
• Estimated gas: Simulation forecasts the execution path and the units it should consume.
• Maximum fee: maxFeePerGas caps the combined base fee and priority tip per gas unit.
• Maximum priority fee: maxPriorityFeePerGas caps the validator tip per gas unit.

MetaMask normally presents one estimated POL total, while ethers.js and web3.js expose the underlying fields for applications. Read the network first, then compare the gas estimate with the limit. A wide limit creates headroom for execution; it does not charge every authorized unit. The signed caps matter only after the transaction meets the included block’s base fee.

A low fee cap can leave a valid transaction pending

A Type 2 Polygon transaction remains pending when maxFeePerGas falls below the next block’s base fee, even if its nonce and signature remain valid onchain.

Because account nonces execute in order, one underpriced transaction can hold later transactions from the same address in the pending queue. A wallet’s speed-up action submits a replacement with the same nonce and higher fee caps; a cancellation uses that nonce for a replacement transfer. Both are new signed transactions competing for inclusion, and both require a viable base-fee cap. Raising only the gas limit does not solve underpricing because gas units and price per gas are separate dimensions. Replacement nodes also require a price bump over the pending transaction, so a negligible increase may be rejected by local transaction-pool policy.

Place the cap above the quoted base-fee estimate when timing matters, then choose how much priority tip the desired inclusion window justifies.

How much POL does a transaction actually spend?

A Polygon PoS transaction spends gasUsed × effectiveGasPrice, where the effective price equals the included block’s base fee plus the allowed priority tip within the sender’s cap.

A hypothetical plain POL transfer consumes its fixed 21,000 gas with a 30 gwei base fee, a 25 gwei maximum tip, and an 80 gwei maximum fee. The allowed tip is the smaller of 25 gwei and 80 minus 30 gwei, so it remains 25 gwei. The effective price is 55 gwei. Multiplying 21,000 by 55 produces 1,155,000 gwei, equal to 0.001155 POL. The transferred POL amount sits outside this network-fee calculation.

For a fiat display, multiply the final 0.001155 POL fee by the chosen POL market quote. Keep that conversion separate because it changes independently of onchain gas. A decentralized-exchange interface may show price impact beside gas; that is an asset-exchange term, not part of the validator fee.

Base fee follows block demand

Polygon PoS derives the next base fee from the previous block’s gas use relative to its target, raising it above target and lowering it below target.

Bor, the Polygon PoS execution client, calculates the target from the block gas limit and configured target percentage. Its post-Dandeli fallback target is 65%, and the accepted configuration range spans 1% through 100%; the fallback base-fee denominator after Bhilai is 64. Post-Lisovo header validation limits a base-fee move to 5% of the parent block’s base fee. Wallets read baseFeePerGas from recent block headers and forecast the next step; a stale quote loses headroom as consecutive blocks move in the same direction. These rules bound each step, while the actual base fee remains a live property of the block being built.

Priority tip buys ordering, not execution certainty

The Polygon priority tip goes to the block producer and influences transaction ordering, while the base-fee portion is removed from circulation through the protocol’s burn mechanism. Polygon PoS mainnet requires a minimum priority fee of 25 gwei. A higher tip competes more strongly when transactions contend for space, yet it does not change contract logic, repair a reverting call, or guarantee a particular position. Match the tip to urgency after establishing enough max-fee headroom for the base fee.

Gas used converts contract work into POL

Gas used measures EVM computation and state access, so two transactions sharing the same per-gas price produce different POL charges when their execution paths differ.

Intrinsic transaction work

Every EVM transaction begins with intrinsic gas before contract code runs. Calldata adds measurable work, and an EIP-2930 access list predeclares addresses or storage keys the execution expects to touch. The transaction type does not erase these units; it changes how the sender quotes their price.

Plain POL transfer

A plain native POL transfer with no calldata has an intrinsic cost of 21,000 gas. This fixed unit count makes a simple transfer the cleanest benchmark for comparing two per-gas quotes at the same block.

Contract call

Contract calls add 4 gas for each zero calldata byte and 16 gas for each non-zero byte under the EVM schedule. An EIP-2930 access list adds 2,400 gas per address and 1,900 gas per storage key. A Uniswap swap or Aave position update also executes contract instructions and storage changes, so simulation supplies the useful total rather than a universal fixed count.

Execution and refunds

The receipt’s gasUsed records the charged execution after applicable refunds. EIP-3529 caps a transaction’s refund at one-fifth of gas consumed, while unused gas below the submitted limit remains uncharged. A reverted call still pays for work already performed, which makes simulation quality part of the fee decision.

Fee caps protect a balance without setting the final charge

Background for this sits in Polygon tutorial. maxFeePerGas limits the combined price per gas, while maxPriorityFeePerGas limits only the tip; neither field becomes an automatic charge merely by multiplying against gasLimit.

The effective tip is min(maxPriorityFeePerGas, maxFeePerGas − baseFee). The final network charge is gasUsed × (baseFee + effective tip). Before acceptance, the sender must cover the gas limit multiplied by the maximum fee, plus any POL value being transferred. Unused gas and unused fee-cap headroom stay with the sender, so compare final receipts with the estimate rather than treating the maximum as money spent.

Fee quotes need the same block and units

A useful Polygon fee comparison aligns the same network, block context, transaction data, and units before comparing MetaMask, Polygon Gas Station, or an RPC response.

In the common configuration, Polygon Gas Station builds 3 recommendation bands from the last 15 blocks returned through eth_feeHistory. Its safe-low, standard, and fast bands use the 10th, 25th, and 50th percentiles of observed priority fees. A wallet can add its own buffer to the maximum fee, while ethers.js or web3.js can surface raw RPC values. Compare base fee, tip, and gas estimate separately; otherwise, a larger execution estimate can look like a higher per-unit quote.

Normalize every quote to gwei before comparing it. One gwei equals 1,000,000,000 wei, while 1 POL contains 1,000,000,000 gwei because POL uses 18 decimal places. Then apply each quote to the same simulated gas count. The smallest projected total with enough fee-cap headroom is the meaningful comparison, not the smallest tip in isolation.

Do legacy transactions pay a different Polygon fee?

Legacy Type 0 transactions use one gasPrice field, but Polygon PoS still divides an included payment under EIP-1559 rules and burns its mandatory base-fee share.

The legacy gas price must cover the block’s base fee; the portion above it becomes the validator tip. Type 2 gives the sender separate controls for the total price and tip, so Polygon pricing is easier to audit when demand changes between signing and inclusion. The EIP-2718 envelope identifies Type 2 as 0x02, followed by 12 RLP-listed fields covering chain ID, nonce, fee caps, gas limit, call data, access list, and signature components. Use Type 2 unless an older integration accepts only gasPrice.

POL replaced MATIC without changing the fee arithmetic

POL replaced MATIC as the Polygon PoS gas token, while the EVM fee equation, 18-decimal precision, and 1-to-1 migration relationship preserved the same application-level fee denominations, as broken down in Working with polygon.

POL follows the ERC-20 interface on Ethereum and uses OpenZeppelin components, while native POL on Polygon PoS pays execution fees. One POL equals 1,000,000,000,000,000,000 wei, and one gwei equals 1,000,000,000 wei. Older interfaces may retain a MATIC label, so the decisive checks are chain ID 137, the native balance shown for Polygon PoS, and the receipt’s effective gas price.