Why Unbounded Loops Will Cripple Your Protocol's Future

Attackers exploit unbounded loops to drive transaction gas costs to the block limit, bricking core protocol functions. This is not theoretical; it's how the BNB Smart Chain PancakeBunny exploit ($45M loss) was executed.\n- Attack Vector: Iterate over a dynamically-sized array controlled by the user.\n- Result: Legitimate users cannot call the function, causing a permanent denial-of-service.

Shift from push-based (protocol iterates) to pull-based (users claim) architecture. This pattern is used by Uniswap V3 staking and Compound-style reward distributors.\n- Core Pattern: Let users trigger their own state updates via a claim() function.\n- Enforcement: Implement strict, immutable gas limits on any remaining loops using OpenZeppelin's Arrays library.

Unbounded logic in Chainlink Automation upkeep checks can cause consistent failure, stalling critical price updates or liquidation triggers. The griefing cost is just the gas to trigger the revert.\n- Vulnerability: An upkeep checkData function that loops over unbounded user data.\n- Impact: Oracle staleness, leading to insolvent positions or frozen DeFi pools.

A malicious proposal can embed an unbounded loop in its execution path. If passed, it permanently bricks the governance executor, as seen in early MakerDAO scare scenarios. The attacker only needs to win one vote.\n- Mechanism: Proposal execution runs a loop over all token holders.\n- Outcome: Protocol upgrades and parameter changes become impossible.

Static analysis with Slither detects loop patterns dependent on untrusted storage. Dynamic fuzzing with Foundry proves gas bounds under adversarial inputs.\n- Tooling: Run slither --detect unbounded-loops.\n- Proof: Fuzz tests with deal to max out array lengths and measure gas.

Cheaper gas on Optimism or Arbitrum does not solve unbounded loops; it only lowers the attacker's cost. The griefing attack becomes more economically viable at scale.\n- False Security: Developers assume low cost prevents spam.\n- Reality: Attack ROI improves, making L2s a more attractive target for sustained DoS.

Unbounded loops cause transaction costs to scale with user input size, not protocol logic. A governance proposal with 10,000 voters can cost 1000x more than one with 100, creating a denial-of-service vector. This is why Compound-style governance often forks into new, empty chains for voting.

Every iteration writes to storage, bloating the global state. This cripples node sync times and increases archival storage costs exponentially. Protocols like Aave and Uniswap V2 faced this; solutions like storage proofs (zk) and state expiry (Ethereum) are complex mitigations for a self-inflicted wound.

During network stress (e.g., an NFT mint or market crash), your protocol's loop becomes the block gas limit's victim. It will revert consistently, breaking core functionality. This is not hypothetical—it's why MakerDAO's liquidation mechanisms moved to off-chain keepers and dYdX migrated to a dedicated appchain.

Move the loop off-chain. Compute the result (e.g., reward distribution, vote tally) and submit a cryptographic proof (Merkle root) on-chain. Users claim outcomes via merkle proofs. This pattern is used by Uniswap V3 staking rewards, Optimism airdrops, and ERC-20 permit approvals via EIP-2612.

Never push funds in a loop. Instead, assign entitlements and let users pull their share. This transforms an O(n) on-chain cost into O(1) for the protocol and O(1) per interested user. This is the core innovation behind gasless meta-transactions, ERC-2771, and Superfluid's streaming money.

When loops are unavoidable, enforce strict bounds and process in chunks. Use checkpointing to resume work across multiple transactions. This is how Curve's gauge weight voting and Compound's COMP distribution were redesigned to handle unlimited users without hitting gas limits.