+
+ Every unit of EVM gas pays for a specific system resource. We decompose gas into 7 categories so you can see
+ what a transaction actually spent its gas on.
+
+
+ {/* Resource categories */}
+
+
Resources
+
+
+ Pure EVM execution. The cost of running instructions: arithmetic, logic, control flow, stack
+ manipulation, and precompile execution (ecrecover, bn256Pairing, etc.). For opcodes that touch storage
+ or accounts, only the base “warm access” cost is counted here — the cold penalty goes
+ to Address Access.
+
+
+
+ The cost of expanding EVM memory. The EVM charges a quadratic fee as memory grows, meaning large memory
+ usage gets disproportionately expensive. Applies to any opcode that reads, writes, or returns memory.
+
+
+
+ The first-touch penalty for accounts and storage slots (EIP-2929). The first time a transaction accesses
+ an address or storage slot, it pays a cold access surcharge. Repeat accesses within the same transaction
+ are warm and much cheaper. This incentivizes access locality.
+
+
+
+ The cost of writing to Ethereum’s persistent state. This is the bulk of what SSTORE charges
+ (beyond the base and cold costs), the code deposit cost when deploying contracts, and SELFDESTRUCT fund
+ transfers. Net state cost can be computed as State Growth − Gas Refund, since clearing storage
+ slots generates refunds.
+
+
+
+ The cost of data that nodes must store but the EVM doesn’t re-read. This includes LOG event data,
+ contract deployment code storage overhead, and a portion of intrinsic transaction costs. A share of
+ per-byte calldata cost is also attributed here.
+
+
+
+ The cost of indexing LOG event topics in the block’s bloom filter. Each topic on a LOG opcode has
+ a portion of its per-topic charge attributed to bloom filter maintenance, with the remainder going to
+ History.
+
+
+
+ The cost of including transaction calldata in the block. This only appears at the transaction level
+ (always zero for individual opcodes) and scales with the number and type of calldata bytes, plus a fixed
+ overhead from the intrinsic base cost.
+
+
+
+
+ {/* How it works */}
+
+
How it works
+
The decomposition happens in three layers:
+
+ -
+ Opcode level — Each EVM opcode’s gas is split
+ into the resources it consumes based on its semantics. For example, a cold SLOAD splits into a small
+ Compute portion (the warm base) and a larger Address Access portion (the cold premium). A CREATE splits
+ across Compute, Address Access, State Growth, and History. The invariant{' '}
+ sum of all 7 resources = total gas holds for every single opcode.
+
+ -
+ Transaction level — Opcode-level resources are summed
+ across all call frames in the transaction. Precompile execution gas is added to Compute. Intrinsic gas
+ (the fixed cost every transaction pays before EVM execution) is decomposed across Compute, History,
+ Address Access, State Growth, and Block Size based on whether it’s a regular transaction or
+ contract creation, plus per-byte calldata costs.
+
+ -
+ Block level — Transaction-level resources are summed
+ across all transactions in the block.
+
+
+
+
+ {/* Precompiles */}
+
+
Precompile calls
+
+ Calls to precompiled contracts (ecrecover, sha256, bn256Pairing, etc.) appear as separate call frames.
+ Their execution gas is attributed entirely to Compute, while the parent CALL opcode retains only its
+ access overhead.
+
+
+
+ {/* Gas refunds */}
+
+
Gas refunds
+
+ SSTORE operations that clear storage slots generate gas refunds. Refunds are reported separately and are
+ not subtracted from any resource category.
+
+
+