Gas Management

Gas on Base is paid in ETH, and although fees here are a small fraction of Ethereum mainnet thanks to the OP Stack rollup design, block-level gas mechanics still decide whether your transactions land promptly and what they cost. The per-block gas limit caps how much work fits in each ~2s block; the EIP-1559 base fee moves with demand; and a transaction that underprices its fee can stall while one that overprices it wastes ETH. Understanding these at the block level is what makes a Base app reliable under load. Get gas management right and you give users transactions that confirm quickly and predictably, while keeping your own costs — and theirs — as low as the L2 allows.

Gas Fundamentals

• Block gas limit: each Base block has a maximum total gas, read from block.gasLimit as in the helper below. The sum of gas used by all transactions in a block cannot exceed it, so any single transaction must request less than the limit, and during busy periods only so much work fits per ~2s block — the rest waits for the next.
• Gas price dynamics: the price you pay tracks demand for block space. When Base sees heavy activity — a popular Aerodrome or Uniswap pool, a mint, a consumer-app spike — the base fee rises; when demand falls, it drops. Because the L2 posts data to Ethereum, the L1 data-availability cost is also a component of the total fee.
• EIP-1559 on Base: Base uses the EIP-1559 model. Each block carries a baseFeePerGas (burned, algorithmically adjusted up or down based on how full the previous block was) plus a priority fee (tip) you add to incentivize quick inclusion. You set maxFeePerGas (the ceiling you will pay) and maxPriorityFeePerGas (the tip); you are charged the base fee plus your tip, never more than the max.
• Estimation strategies: eth_estimateGas gives the gas units a call needs; reading recent blocks' baseFeePerGas (as getOptimalGasPrice does) informs the fee. The trade-off is freshness versus cost — sampling more historical blocks smooths spikes but adds latency, while estimating from only the latest block reacts fast but can misprice during a sudden surge. Always add a buffer above the estimate to absorb the next block's base-fee change.

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: read the current baseFeePerGas before each send and set maxFeePerGas to roughly twice the base fee plus your tip, so the transaction survives a base-fee increase in the next ~2s block without you overpaying when demand is calm. Recompute per transaction rather than hardcoding a value.
• Batching: combine multiple actions into one transaction — a multicall or a contract method that performs several state changes — to amortize the fixed 21,000-gas transaction overhead across more work, lowering the effective per-action cost. This matters most for apps issuing many small writes on Base.
• Off-peak execution: Base's base fee rises and falls with usage, so non-urgent transactions (batch settlements, sweeps, scheduled jobs) cost less when activity is low. "Off-peak" here is demand-driven, not clock-driven — watch the recent base-fee trend on https://basescan.org or via RPC and queue deferrable work for the troughs.
• Gas limit optimization: set the gas limit from eth_estimateGas plus a modest safety margin. Too low and the transaction reverts out-of-gas, wasting the fee; too high wastes nothing directly (unused gas is refunded) but can crowd your nonce planning — aim for accurate estimates with a small buffer.
• Aggressive vs. conservative fees: for time-sensitive paths (liquidations, arbitrage, claiming a limited mint) use an aggressive maxFeePerGas and a healthy tip to win inclusion in the next block; for routine or background transactions on Base, a conservative maxFeePerGas near the current base fee with a minimal tip saves ETH at the cost of possibly waiting a few more blocks.

See also

• eth_gasPrice - Get current gas price
• eth_estimateGas - Estimate gas cost for transaction
• Working with Blocks - General block handling