Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
Gas griefing uses adversarial inputs, state, or callees to make another party waste gas or to stop a required operation from completing. Expensive code is not automatically vulnerable: the caller normally pays for its own failed transaction. The issue becomes security-relevant when a relayer or protocol sponsors the cost, when one malicious item blocks a shared batch, or when growing state makes a required maintenance path permanently exceed available gas.
Unbounded iteration over a storage array is the clearest case. If users can grow the array but only an administrator can process it, an attacker may push the loop beyond the block gas limit. Solidity's security guidance on gas limits and loops warns that this can stall contract functionality.
Other cases include a sponsored meta-transaction that performs expensive work before checking an invalid signature, a batch that reverts because one recipient's callback fails, and a caller that assumes an exact amount of gas reaches a subcall. Under EIP-150, a call requesting too much gas receives at most all but one sixty-fourth of the caller's available gas. Code must check subcall success and preserve enough gas to handle failure safely.
Trace who controls every loop bound, dynamic allocation, external call, and storage write. Measure the maximum from reachable state, not a convenient test fixture. Ask whether an attacker can add entries cheaply while cleanup costs the protocol more, and whether progress can resume after one item fails.
Gas tests should cover empty, typical, and maximum batches; accumulated production-sized state; cold storage accesses; revert data from hostile callees; and deliberately constrained transaction gas. Assert both cost and liveness: a failed item must not corrupt bookkeeping or make all later items unreachable. Repeat measurements on the deployment's target chain because opcode pricing and block limits differ.
An arbitrary cap such as 100 iterations is not a universal fix. Derive limits from measured worst-case gas and leave margin for repricing and integration overhead.
Firepan can identify source-level loop bounds, expensive user-controlled paths, and unchecked external calls in submitted code. It cannot guarantee future gas schedules, chain block limits, or the cost of arbitrary deployed callees.
Is every out-of-gas revert gas griefing?
No. Griefing requires an adversary to impose cost or deny progress under the system's threat model.
Should external calls never appear in loops?
Not categorically. Small bounded batches can be valid, but failure handling and worst-case callee behavior must be tested.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Understand the ERC-20 allowance overwrite race, its transaction-ordering conditions, and safer approval and spending designs.
Understand how Ether can reach a contract without its receive logic and how to review exact-balance assumptions safely.
Learn when block timestamps are safe for coarse scheduling, when they create exploitable assumptions, and how to test timing boundaries across EVM networks.