Home

Gas and Fee Management

6 min read

In the OP Stack, gas and fee management is a dual-layered system designed to cover both local execution costs on Layer 2 (L2) and the cost of submitting transaction data to Layer 1 (L1).

1. L2 Execution Gas Calculation

L2 execution gas is calculated by the EVM interpreter during the transaction lifecycle.

  • Static and Dynamic Gas: Each opcode has a constantGas fee (static cost) and often a dynamicGas fee. For example, MCOPY or KECCAK256 charge extra based on the size of the data processed.
  • Memory Expansion: The protocol charges a quadratic fee for expanding memory. This cost is calculated based on the difference between the current memory size and the new required size in 32-byte words.
  • State Access (EIP-2929): Gas costs for state-accessing opcodes (like SLOAD, BALANCE, and CALL) depend on whether an address or storage slot is “warm” or “cold.” Cold accesses (the first time in a transaction) cost significantly more (e.g., 2100 gas) than subsequent warm accesses (100 gas).
  • System Transactions: Specialized Deposit transactions marked as IsSystemTransaction are executed in an unmetered environment, meaning they do not consume L2 gas or count against the block gas limit.

2. L1 Data Fee Computation

Because OP Stack chains must post transaction data to Ethereum (L1), users must pay an L1 Data Fee (often called the Rollup Fee).

  • Rollup Cost Data: The protocol caches binary data for each transaction in a rollupCostData object to compute this fee efficiently.
  • Data Availability (DA) Size: The fee is primarily based on the estimated DA size of the transaction.
  • Jovian Fork Enhancements: In the Jovian upgrade, the protocol introduces a daFootprintGasScalar. This scalar is used to multiply the estimated DA size to ensure the block stays within a specific data availability footprint limit.
  • Computation Function: The L2 block context includes a specialized L1CostFunc that determines exactly how many Wei are required for the L1 portion based on current network conditions.

3. Fee Deduction and Total Cost

The total cost to a user is the sum of the L2 execution cost and the L1 data fee.

  • Total Cost Formula: The total amount deducted is: (GasUsed * GasPrice) + (BlobGas * BlobGasPrice) + Value + L1DataFee.
  • Effective Gas Tip: On EIP-1559 chains, the effectiveGasPrice is the sum of the base fee and the user’s priority tip. The miner receives the tip portion, while the base fee is typically handled by protocol rules.
  • Atomicity: Fees are deducted from the caller’s balance. If a transaction fails (e.g., ErrOutOfGas), the protocol uses a journal to revert all state changes except for the fee deduction itself, ensuring the miner is still compensated for the computation attempted.

The logic for calculating gas within the protocol is a multi-step process that accounts for computational effort, memory usage, and state interactions. It functions as a deterministic “meter” that runs alongside the execution of contract bytecode.

1. Intrinsic Gas

Every transaction begins with a base “intrinsic” cost before any contract code is even run. This includes a fixed fee for the transaction itself and a variable fee based on the size of the input data (calldata), where non-zero bytes are charged more heavily than zero bytes.

2. Execution Loop Metering

As the EVM processes each instruction (opcode), it calculates the cost using two primary components:

  • Constant (Static) Gas: A fixed amount deducted for the specific operation (e.g., a simple addition ADD always costs 3 gas).
  • Dynamic Gas: Costs that cannot be determined until the moment of execution because they depend on the size of the data or the current state of the blockchain.

3. Memory Expansion Logic

The protocol charges for the “footprint” of memory used during execution. Memory is measured in 32-byte words.

  • Linear Growth: There is a base cost for every new word added to memory.
  • Quadratic Scaling: As the memory grows larger, the cost increases quadratically to reflect the increased burden on the node’s hardware.
  • Expansion-Only Charging: You are only charged for newly expanded memory; if an operation uses memory that has already been paid for in a previous step, no expansion fee is applied.

4. State Access (Warm vs. Cold)

Following EIP-2929, the protocol maintains an accessList to track which addresses and storage slots have been touched during a transaction.

  • Cold Access: The first time an account or storage slot is accessed, the protocol charges a high “cold” fee (e.g., 2100 gas) because the node must perform a slow disk read.
  • Warm Access: Subsequent accesses within the same transaction are “warm” and cost significantly less (e.g., 100 gas) because the data is already in the node’s fast memory (cache).

5. Storage Modification Logic (SSTORE)

The cost of writing to storage is the most complex calculation in the protocol, determined by the Original, Current, and New values of a slot.

  • Creating a Slot: Changing a slot from zero to non-zero is the most expensive operation (e.g., 20,000 gas).
  • Modifying an Existing Slot: Updating a non-zero slot is cheaper (e.g., 2,900–5,000 gas).
  • No-Op Writes: Writing a value that is identical to the current value costs a minimal fee (e.g., 100 gas).
  • Refunds: If you clear a storage slot (change it back to zero) or reset it to its “original” value from before the transaction, the protocol adds a “refund” to a counter that is deducted from your final bill at the end of the transaction.

6. Contract Creation Metering

  • Initcode Cost: Per EIP-3860, the protocol charges a fee based on the size of the contract’s initialization code (2 gas per word).
  • Code Deposit: Once the contract is successfully created, the protocol charges a “deposit” fee for every byte of the resulting runtime code that must be permanently stored in the state (200 gas per byte).

7. Layer 1 (L1) Rollup Fees

In the OP Stack, a transaction must also pay for the cost of submitting its data to the Ethereum mainnet.

  • DA Size: This is computed based on the estimated Data Availability (DA) size of the transaction.
  • Scalars: In the Jovian upgrade, the protocol uses a daFootprintGasScalar to multiply the transaction size, ensuring the total block stays within the network’s data availability limits.

Graph View

Backlinks