Optimism gas settings for a first OP Mainnet transaction

Optimism lets you limit execution spending for an ordinary OP Mainnet transaction through its gas limit and maximum fee per gas. That limit doesn't cap the separate L1 data charge. Review the complete ETH requirement before approving your first submission, including any configured operator fee.

An OP Mainnet balance for the intended action

A transaction originating on OP Mainnet needs ETH in the sending account on that network to cover its fees. ETH held on Ethereum doesn't automatically fund the same address on this Layer 2 network. Check the selected network before adjusting gas settings.

Token holdings don't replace the ETH fee balance for an ordinary wallet transaction. Leave room for fees alongside any ETH value the transaction sends. Bridging funds onto the network introduces a separate transaction path.

Execution settings separate gas quantity from gas price

Maximum fee per gas

An EIP-1559 transaction uses maxFeePerGas to cap its execution price per unit of gas. Multiplying this cap by the transaction's gas limit gives its maximum execution-fee allowance. Keep the units consistent when comparing that product with an ETH balance. L1 data and operator charges sit outside this calculation.

Room for the base fee

The block's base fee sets the required starting price. A maximum below that base fee can't qualify for inclusion. A higher maximum doesn't automatically spend the entire allowance. Execution pricing uses the block's base fee plus the effective priority fee.

Room for the priority fee

maxPriorityFeePerGas limits the tip within the overall execution-price cap. Its value can't exceed the overall cap. The effective tip can reach that maximum only when maxFeePerGas leaves enough room above the base fee. Don't add the maximum tip again when calculating the execution ceiling; the overall price cap already includes it.

Gas limit

The gas limit caps computational units, while the price fields specify the cost per unit. Lowering the limit doesn't reduce the work a contract needs. An insufficient allowance can prevent successful execution. A larger valid limit provides room for execution, while actual gas usage determines the execution charge.

The L1 data fee remains outside the execution cap

OP Mainnet's standard transaction format doesn't provide a sender-set maximum for the L1 data fee. This Layer 1 charge pays for publishing transaction data to Ethereum, separately from executing the transaction on L2. Its estimate reflects compressed transaction size, Ethereum data prices, and chain-configured pricing parameters. Blob-enabled configurations incorporate Ethereum's blob base fee. After the Fjord upgrade, the calculation uses a FastLZ-based estimator for compressed transaction size. Consequently, a gas-unit estimate alone can't describe the complete transaction cost.

Lowering the execution-price cap doesn't directly reduce the data the transaction publishes. Ethereum's base fee and blob base fee can change between estimation and inclusion. A data-fee estimate therefore remains a quote, even when the wallet exposes an editable execution maximum.

The operator fee follows the chain's active rules

The post-Isthmus fee model includes an operator component. It combines a configured constant with a gas-usage-based charge. Its constant and scalar aren't ordinary sender-controlled gas settings. Jovian changed the operator-fee formula, so a calculation must match the chain's active upgrade rules. Zero-valued parameters can produce a zero charge; the component's presence in the model doesn't establish a positive surcharge. Deposit transactions have a zero L2 operator fee, regardless of the operator-fee parameters. That exception applies to the deposit transaction. It doesn't make the originating Ethereum transaction free or establish the fee for a later wallet transaction on OP Mainnet.

View full-size image

An estimate and an affordability check answer different questions

A low expected fee can coexist with a larger balance requirement because transaction validation checks whether the account can cover its maximum costs. The sending account needs enough ETH for the execution allowance, the L1 data fee, and the worst-case operator charge, alongside any ETH value it sends. The affordability check doesn't mean every reserved amount becomes a final charge. An excessive execution cap can therefore contribute to an insufficient-funds rejection even when the estimated fee looks affordable.

View full-size image

Gas estimation evaluates the requested call against network state. Changing the sender, destination, transaction data, or contract state can change the work execution requires. Retaining an old estimate after those inputs change can misstate the required allowance. Fresh estimation addresses that change; raising every fee field doesn't diagnose its cause.

Wallet suggestions and manual settings before signing

Keep a fresh wallet suggestion when it provides enough execution gas and the complete fee estimate fits your budget. Manual editing offers control over the execution allowance when the wallet exposes those fields. Compare these options for the same requested transaction. A smaller execution maximum leaves the data charge and any operator charge to account for.

View full-size image

• If the request targets OP Mainnet, confirm the selected network, sending account, and intended recipient or contract.
• If you retain suggested settings, check whether the estimate includes L1 data and any applicable operator charge.
• If you edit the price cap, preserve room for the base fee and the tip you intend to offer.
• If you change the gas limit, retain enough units for the requested execution.
• If the full ETH requirement exceeds your budget or balance, stop before signing and broadcasting.

Once these conditions hold, submit only the selected transaction. A returned hash identifies the submission. An available transaction receipt records inclusion and execution status. Match that status and the resulting application state to the requested action. Before signing and broadcasting, declining the request leaves this transaction unsubmitted. Closing the wallet after broadcast doesn't retract it.

The receipt records the charge for the executed transaction

For an included transaction, multiplying the receipt's gasUsed by effectiveGasPrice gives the execution charge. The complete OP Mainnet fee also includes its L1 data charge and applicable operator charge. Compare matching components when reconciling the receipt with a wallet preview; the execution calculation alone doesn't represent the full bill. A receipt's status distinguishes successful execution from failure: 1 means success, and 0 means failure. Unused gas allowance doesn't become execution spending merely because you permitted a higher limit. Operator-fee accounting also refunds unused allowance after execution. A difference between the preview and the paid fee can therefore reflect ordinary allowance accounting.

A first confirmation and Ethereum finality serve different purposes

OP Mainnet typically includes a transaction in an L2 block within about two seconds, giving a soft confirmation that relies on the sequencer. The protocol calls this state unsafe until Ethereum receives the supporting transaction data. Hard finality typically follows within about 15 to 30 minutes of submission, once Ethereum finalizes that data. Network conditions and batch publication affect these timings. A larger execution bid doesn't bypass the data-publication and Ethereum-finalization requirements.

Services taking an off-chain action should wait for at least the safe stage, when the transaction's data has reached Ethereum. Standard Bridge withdrawals have a separate waiting requirement. If an application requires a safe or finalized block, its acceptance point comes later than the first L2 confirmation.

Still wondering about Optimism?