# DoS via block gas limit permanently bricks functions that iterate over unbounded arrays Functions that iterate over dynamically growing arrays (such as refunding all participants or distributing rewards to all holders) can exceed the block gas limit as the array grows, making the function permanently uncallable. The Fomo3D exploit demonstrated a related attack: an attacker stuffed 13 consecutive blocks with high-gas transactions to prevent other players from calling the game's timer function. The defense is to avoid unbounded loops over growing data structures. When iteration is not required at all, mappings provide O(1) access without looping: a mapping lookup costs the same regardless of how many entries exist, making mappings structurally immune to the gas-limit bricking attack. When iteration is required, paginate using start/end index parameters so callers can process the collection in chunks rather than all at once, and use pull-payment patterns (users withdraw individually) instead of push patterns (contract pays everyone). The practical heuristic: for every loop, verify the list is bounded, and check whether a subset specification mechanism exists. Pagination by design prevents the gas limit from becoming a permanent bricking vector. Since [[insufficient gas griefing in relayer patterns allows forwarders to starve subcalls while outer transactions succeed]], gas accounting is fragile across the entire call chain, not just within a single function. Arrays managed via direct `delete` rather than swap-and-pop accumulate zero-value gaps; since [[Solidity delete on an array element zeroes the slot without reducing array length leaving a zero-value gap that breaks length-based iteration assumptions]], length-based iteration must traverse all gaps, inflating effective iteration cost above active element count and compounding the bricking risk. --- Relevant Notes: - [[DoS via unexpected revert exploits fallback functions that intentionally revert to block ETH transfers]]: another DoS vector, often co-present in batch payment patterns - [[evm memory gas costs grow quadratically making large allocations prohibitively expensive]]: gas costs compound the iteration problem via quadratic memory expansion - [[insufficient gas griefing in relayer patterns allows forwarders to starve subcalls while outer transactions succeed]]: another gas-based DoS mechanism in meta-transaction contexts - [[unbounded return data from external calls forces quadratic memory cost gas consumption via RETURNDATASIZE]]: sibling gas-based DoS exploiting quadratic memory costs through a different vector - [[induction variable overflow permanently bricks loop-dependent functions when counter types are too small for the iteration range]]: sibling loop DoS via Panic(0x11) rather than gas exhaustion; same loop patterns, different failure mechanism - [[Solidity delete on an array element zeroes the slot without reducing array length leaving a zero-value gap that breaks length-based iteration assumptions]]: arrays with accumulated zero-value gaps require more iterations than active element counts suggest, compounding the gas consumption that causes bricking Topics: - [[vulnerability-patterns]]