Gas Management

Gas on OP Mainnet has two parts that no other guide can collapse into one: a small EIP-1559 L2 execution fee paid in ETH, plus an L1 data fee that covers the cost of posting your transaction's data to Ethereum L1 for settlement. Understanding both at the block level — what the gas limit allows, how the base fee moves with the ~2s-block fee market, and how the L1 component fluctuates with Ethereum congestion — is what keeps an OP Mainnet application reliable: transactions that price correctly get included promptly, while a fee set on L2 logic alone can underpay or overspend. Optimizing gas management lets users transact at a fraction of L1 cost while giving developers predictable inclusion and a smaller ETH bill across protocols like Velodrome and Synthetix.

Gas Fundamentals

Block gas limit: each OP Mainnet block has a maximum total gas, the ceiling on combined gas used by all transactions it can hold. A transaction whose gas exceeds the limit can never be included, and during demand spikes the limit caps throughput per ~2s block — read it from block.gasLimit as the example does.
Gas price dynamics: the L2 execution price moves with the EIP-1559 base fee, which rises when blocks fill and falls when they empty. Separately, the L1 data fee tracks Ethereum L1 congestion, so total cost can climb even when OP Mainnet itself is quiet because posting data to L1 got more expensive.
EIP-1559 on OP Mainnet: the L2 fee uses base fee plus priority fee. You set maxFeePerGas (a ceiling) and maxPriorityFeePerGas (the sequencer tip); you pay the prevailing base fee plus your tip, refunded the difference up to your max. Read block.baseFeePerGas to anchor estimates, as in getOptimalGasPrice.
Estimation strategies: use eth_estimateGas for the gas units a call will consume and sample recent baseFeePerGas for pricing, but remember neither captures the L1 data fee — account for it separately so your total budget is right. Conservative estimates risk being outbid; aggressive ones overspend.

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 gas pricing: sample baseFeePerGas over the last several OP Mainnet blocks (as getOptimalGasPrice does) and set maxFeePerGas to that trend plus headroom, refreshing per submission since the base fee shifts every ~2s. Re-price and resubmit if a transaction stalls because the base fee climbed past your ceiling.
Batching transactions: where your contracts support it, fold multiple operations into one call (multicall, batched router actions). Because the L1 data fee is driven by the data you post, batching amortizes that fixed L1 component across many operations and cuts per-action cost more than it would on L1 alone.
Off-peak execution: on OP Mainnet, "off-peak" means both quieter L2 blocks and calmer Ethereum L1 — since the L1 data fee tracks L1 congestion, the cheapest windows are when Ethereum mainnet gas is low. Schedule non-urgent transactions for those periods.
Gas limit optimization: estimate with eth_estimateGas and add a modest safety margin. Set too low and the transaction reverts out-of-gas (you still pay); set wildly high and you tie up funds and may overpay. Tune the margin to each contract's variability.
Aggressive vs. conservative fees: time-sensitive actions (liquidations, arbitrage) warrant an aggressive maxFeePerGas and higher priority tip for fast inclusion; routine or batch jobs can use a conservative ceiling near the recent base fee and simply wait. Match the strategy to how much a delayed inclusion actually costs you.

Block gas limit: each OP Mainnet block has a maximum total gas, the ceiling on combined gas used by all transactions it can hold. A transaction whose gas exceeds the limit can never be included, and during demand spikes the limit caps throughput per ~2s block — read it from block.gasLimit as the example does.

Gas price dynamics: the L2 execution price moves with the EIP-1559 base fee, which rises when blocks fill and falls when they empty. Separately, the L1 data fee tracks Ethereum L1 congestion, so total cost can climb even when OP Mainnet itself is quiet because posting data to L1 got more expensive.

EIP-1559 on OP Mainnet: the L2 fee uses base fee plus priority fee. You set maxFeePerGas (a ceiling) and maxPriorityFeePerGas (the sequencer tip); you pay the prevailing base fee plus your tip, refunded the difference up to your max. Read block.baseFeePerGas to anchor estimates, as in getOptimalGasPrice.

Estimation strategies: use eth_estimateGas for the gas units a call will consume and sample recent baseFeePerGas for pricing, but remember neither captures the L1 data fee — account for it separately so your total budget is right. Conservative estimates risk being outbid; aggressive ones overspend.

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 gas pricing: sample baseFeePerGas over the last several OP Mainnet blocks (as getOptimalGasPrice does) and set maxFeePerGas to that trend plus headroom, refreshing per submission since the base fee shifts every ~2s. Re-price and resubmit if a transaction stalls because the base fee climbed past your ceiling.

Batching transactions: where your contracts support it, fold multiple operations into one call (multicall, batched router actions). Because the L1 data fee is driven by the data you post, batching amortizes that fixed L1 component across many operations and cuts per-action cost more than it would on L1 alone.

Off-peak execution: on OP Mainnet, "off-peak" means both quieter L2 blocks and calmer Ethereum L1 — since the L1 data fee tracks L1 congestion, the cheapest windows are when Ethereum mainnet gas is low. Schedule non-urgent transactions for those periods.

Gas limit optimization: estimate with eth_estimateGas and add a modest safety margin. Set too low and the transaction reverts out-of-gas (you still pay); set wildly high and you tie up funds and may overpay. Tune the margin to each contract's variability.

Aggressive vs. conservative fees: time-sensitive actions (liquidations, arbitrage) warrant an aggressive maxFeePerGas and higher priority tip for fast inclusion; routine or batch jobs can use a conservative ceiling near the recent base fee and simply wait. Match the strategy to how much a delayed inclusion actually costs you.

Gas Management

Gas Fundamentals

Implementation Strategies

Optimization Techniques

See also

Pronto para usar isso em produção?

Gas Management

Gas Fundamentals

Implementation Strategies

Optimization Techniques

See also