Gas Management

Every Polygon transaction pays for execution in MATIC, and the price it pays is set by block-level conditions — the base fee that rises and falls with demand, the priority tip validators collect, and the gas limit each Bor block can hold. Reading those conditions before you sign is what keeps an application reliable: a transaction priced too low stalls in the mempool, and one priced blindly high wastes user funds. With blocks arriving every ~2 seconds on chain 137, fees on Polygon are usually low but not static, and tracking them lets you confirm transactions promptly while keeping MATIC costs predictable. This guide shows how to read gas data from https://polygon.therpc.io/YOUR_API_KEY and turn it into pricing decisions that benefit both your users and your operations.

Gas Fundamentals

Block gas limit: Each Bor block has a maximum amount of gas it can hold, which caps the total work — and therefore the number and size of transactions — that fit in one ~2s slot on Polygon. The getBlockGasLimit example reads it from the latest block; your transaction's gas usage must stay under this ceiling, and a near-full block is a signal of congestion.
Price dynamics: Gas price on Polygon moves with demand. When blocks fill, the base fee climbs to ration space; when demand falls, it drifts back down. Because chain 137 is high-throughput and fees are typically low, these swings are smaller than on Ethereum L1 but can still spike during NFT mints, airdrops, or heavy DeFi activity on apps like QuickSwap or Aave.
EIP-1559 on Polygon: Polygon implements the EIP-1559 fee market, so each transaction pays a protocol-set baseFeePerGas (burned) plus a maxPriorityFeePerGas tip that goes to the validator. You set maxFeePerGas as the ceiling you will pay and maxPriorityFeePerGas as the tip; the network charges the current base fee plus your tip, refunding the difference. The getOptimalGasPrice example averages recent blocks' baseFeePerGas as a starting point.
Estimation strategies: Use eth_estimateGas to size the gas limit for a specific call, and recent-block base-fee sampling to set the fee. Static estimates are simple but can under- or over-shoot during fast-moving congestion; sampling the last several blocks adapts to current conditions at the cost of extra RPC calls. Always add a margin to the estimated gas limit so a slightly heavier execution path does not run out of gas.

Implementation Strategies

1// Get block gas limit
2const getBlockGasLimit = async () => {
3  const block = await web3.eth.getBlock('latest');
4  return block.gasLimit;
5};
6 
7// Estimate optimal gas price
8const getOptimalGasPrice = async () => {
9  const blockCount = 10;
10  const latest = await web3.eth.getBlockNumber();
11  const blocks = await Promise.all(
12    [...Array(blockCount)].map((_, i) => web3.eth.getBlock(latest - i))
13  );
14 
15  const gasPrices = blocks.map((block) => block.baseFeePerGas);
16  return Math.floor(gasPrices.reduce((a, b) => a + b) / blockCount);
17};

Optimization Techniques

Dynamic price adjustment: Sample baseFeePerGas from the last several Bor blocks right before signing and set maxFeePerGas to that base fee plus a buffer (commonly 1.5–2x to ride out the next few blocks) plus your tip. Re-estimate per transaction rather than hardcoding a price, since Polygon's base fee shifts block to block.
Batch to cut per-unit cost: When you have many similar operations, route them through a multicall or a batching contract so a single transaction amortizes the fixed per-transaction overhead across all of them. This lowers total MATIC spent and frees block space on chain 137 for everyone.
Off-peak execution: "Off-peak" on Polygon means stretches of lower demand — outside major mint or airdrop events and away from peak trading hours on the busiest DeFi venues — when the base fee sits at its floor. Defer non-urgent work (sweeps, rebalances, batch settlements) to those windows to pay the lowest base fee.
Gas limit optimization: Call eth_estimateGas for the exact transaction, then add a modest safety margin (around 10–20%). Too tight a limit risks an out-of-gas revert that still costs MATIC; too loose wastes nothing on EIP-1559 chains since unused gas is not charged, but a wildly high limit can be rejected by tooling and obscures real cost — estimate, don't guess.
EIP-1559 strategy by use case: For time-sensitive transactions (liquidations, arbitrage, claiming a limited mint) bid an aggressive maxFeePerGas and a healthy maxPriorityFeePerGas so you land in the next block. For routine or background work, set a conservative ceiling near the current base fee with a small tip and accept that inclusion may take a few extra ~2s blocks in exchange for lower cost.

Block gas limit: Each Bor block has a maximum amount of gas it can hold, which caps the total work — and therefore the number and size of transactions — that fit in one ~2s slot on Polygon. The getBlockGasLimit example reads it from the latest block; your transaction's gas usage must stay under this ceiling, and a near-full block is a signal of congestion.

Price dynamics: Gas price on Polygon moves with demand. When blocks fill, the base fee climbs to ration space; when demand falls, it drifts back down. Because chain 137 is high-throughput and fees are typically low, these swings are smaller than on Ethereum L1 but can still spike during NFT mints, airdrops, or heavy DeFi activity on apps like QuickSwap or Aave.

EIP-1559 on Polygon: Polygon implements the EIP-1559 fee market, so each transaction pays a protocol-set baseFeePerGas (burned) plus a maxPriorityFeePerGas tip that goes to the validator. You set maxFeePerGas as the ceiling you will pay and maxPriorityFeePerGas as the tip; the network charges the current base fee plus your tip, refunding the difference. The getOptimalGasPrice example averages recent blocks' baseFeePerGas as a starting point.

Estimation strategies: Use eth_estimateGas to size the gas limit for a specific call, and recent-block base-fee sampling to set the fee. Static estimates are simple but can under- or over-shoot during fast-moving congestion; sampling the last several blocks adapts to current conditions at the cost of extra RPC calls. Always add a margin to the estimated gas limit so a slightly heavier execution path does not run out of gas.

Implementation Strategies

1// Get block gas limit
2const getBlockGasLimit = async () => {
3  const block = await web3.eth.getBlock('latest');
4  return block.gasLimit;
5};
6 
7// Estimate optimal gas price
8const getOptimalGasPrice = async () => {
9  const blockCount = 10;
10  const latest = await web3.eth.getBlockNumber();
11  const blocks = await Promise.all(
12    [...Array(blockCount)].map((_, i) => web3.eth.getBlock(latest - i))
13  );
14 
15  const gasPrices = blocks.map((block) => block.baseFeePerGas);
16  return Math.floor(gasPrices.reduce((a, b) => a + b) / blockCount);
17};

Optimization Techniques

Dynamic price adjustment: Sample baseFeePerGas from the last several Bor blocks right before signing and set maxFeePerGas to that base fee plus a buffer (commonly 1.5–2x to ride out the next few blocks) plus your tip. Re-estimate per transaction rather than hardcoding a price, since Polygon's base fee shifts block to block.

Batch to cut per-unit cost: When you have many similar operations, route them through a multicall or a batching contract so a single transaction amortizes the fixed per-transaction overhead across all of them. This lowers total MATIC spent and frees block space on chain 137 for everyone.

Off-peak execution: "Off-peak" on Polygon means stretches of lower demand — outside major mint or airdrop events and away from peak trading hours on the busiest DeFi venues — when the base fee sits at its floor. Defer non-urgent work (sweeps, rebalances, batch settlements) to those windows to pay the lowest base fee.

Gas limit optimization: Call eth_estimateGas for the exact transaction, then add a modest safety margin (around 10–20%). Too tight a limit risks an out-of-gas revert that still costs MATIC; too loose wastes nothing on EIP-1559 chains since unused gas is not charged, but a wildly high limit can be rejected by tooling and obscures real cost — estimate, don't guess.

EIP-1559 strategy by use case: For time-sensitive transactions (liquidations, arbitrage, claiming a limited mint) bid an aggressive maxFeePerGas and a healthy maxPriorityFeePerGas so you land in the next block. For routine or background work, set a conservative ceiling near the current base fee with a small tip and accept that inclusion may take a few extra ~2s blocks in exchange for lower cost.

Gas Management

Gas Fundamentals

Implementation Strategies

Optimization Techniques

See also

Prêt à utiliser cela en production ?

Gas Management

Gas Fundamentals

Implementation Strategies

Optimization Techniques

See also