Gas

Overview

Gas assigns protocol-defined costs to operations such as arithmetic, contract calls, memory expansion, storage changes, and cryptographic functions. A transaction sets a gas limit, and execution consumes gas according to the active schedule until it succeeds, reverts, or runs out. Gas is a resource measure rather than a currency amount. The final fee combines gas used with a price per gas unit and possibly additional components such as blob, data, or Layer 1 publication charges.

Wallets must estimate required gas and fee pricing separately. Developers should optimize expensive code without weakening safety and should test worst-case execution paths. Payment systems should record receipt gas used, effective price, and fee asset because estimates and maximum limits do not equal the final charge. A pending quote can change before inclusion, and a transaction that fails at execution may still consume a network fee. Payment systems should store the canonical transaction identifier, inclusion block, execution result, consumed resources, and effective fee reported by the final receipt. Operational policies should be tested against low-demand, congested, replaced, reverted, and reorganized transactions. Monitoring should distinguish a pricing error from delayed inclusion or failed execution, since each condition requires a different customer message and recovery action.

Wallet defaults, quoted caps, and minimum protocol charges are different values, so interfaces should label each field and avoid presenting a maximum authorization as the amount ultimately paid. An estimate should identify the fee unit, network, block context, and transaction parameters used to calculate it.

Practical implication: Gas measures execution resources, while gas price, fee components, and actual usage determine the amount a transaction pays.