Arbitrum One
Arbitrum One
Bereit, das in der Produktion aufzurufen?
Das Free-Tier deckt persönliche Projekte ab. Pay-as-you-go skaliert ohne Karte.
Arbitrum One
Das Free-Tier deckt persönliche Projekte ab. Pay-as-you-go skaliert ohne Karte.
Gas on Arbitrum One is unusual: a transaction's fee, always paid in ETH, is the sum of an L2 execution cost and an L1 calldata-posting cost — the price of recording the transaction's data on Ethereum mainnet. Reading gas at the block level (baseFeePerGas, gasUsed, gasLimit per block) is what lets you understand both halves of that fee, because the L2 base fee tends to be low and stable while the L1 component rises and falls with Ethereum congestion. Get this wrong and transactions either get underpriced and stall or overpriced and waste user funds. Managing gas well means your dApp quotes accurate costs, sizes gas limits without over- or under-estimating, and times or batches submissions so users on GMX, Aave, Camelot, or your own contracts pay the least ETH for reliable inclusion.
gasLimit that caps total L2 execution gas across its transactions. A single transaction cannot exceed the block limit, so very heavy contract calls must be split — read gasLimit from the latest block to know the current ceiling.baseFeePerGas per block, so you can set maxFeePerGas and maxPriorityFeePerGas as you would on Ethereum. In practice the L2 base fee is low and priority fees matter little under a single sequencer; the variable you actually budget for is the L1 data component bundled into the effective price.eth_estimateGas for the gas units a call will consume, and eth_gasPrice or recent-block baseFeePerGas for pricing. The trade-off is freshness versus overhead — a per-transaction estimate is most accurate but adds latency, while caching a recent estimate is cheaper but risks underpricing if the L1 cost just spiked. Add a modest safety margin to estimates rather than sending exact values.baseFeePerGas across the last several blocks (as in getOptimalGasPrice above) and set maxFeePerGas from that rolling figure plus a buffer, so your transactions track the moving L1-driven cost instead of a stale hard-coded price.eth_estimateGas result plus a small margin. Over-estimating wastes nothing in refunded gas but can needlessly inflate maxFeePerGas * gasLimit reserved balance checks; under-estimating risks an out-of-gas revert. Re-estimate when calldata size or contract state changes materially.maxFeePerGas comfortably above the current base fee to guarantee fast inclusion; for routine or background transactions use a conservative maxFeePerGas close to base fee and accept slightly slower inclusion to save ETH.