FV-SOL-9 Unbounded Loops

TLDR

Overly verbose iterations can result in failed transactions, denial of service, and reduced contract usability

Code

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract UnboundedLoopExample {
    address public owner;
    address[] public recipients;
    uint256 public rewardAmount = 1 ether;

    constructor() {
        owner = msg.sender;
    }

    // Adds a recipient to the list (for testing)
    function addRecipient(address _recipient) external {
        recipients.push(_recipient);
    }

    // Distributes rewards to all recipients in the array
    function distributeRewards() external {
        require(msg.sender == owner, "Only owner can distribute rewards");

        // Unbounded loop over dynamic array "recipients"
        for (uint256 i = 0; i < recipients.length; i++) {
            // For demonstration, we assume "transfer" sends the reward.
            // In practice, we might call an ERC20 transfer or similar function.
            (bool success, ) = recipients[i].call{value: rewardAmount}("");
            require(success, "Transfer failed");
        }
    }

    // Receive Ether to fund the contract
    receive() external payable {}
}

Classifications

Dynamic Array (FV-SOL-9-C1)

This issue arises when a loop iterates over a dynamic array (an array whose size can grow over time) without bounds or a reasonable upper limit

Unrestricted Mapping (FV-SOL-9-C2)

Solidity mappings do not provide a way to iterate over keys natively. However, if developers use an array to track mapping keys for iteration, looping through the keys can lead to unbounded loops if the array grows indefinitely

Recursive Calls (FV-SOL-9-C3)

Although Solidity does not support native recursion due to lack of stack depth, developers may attempt recursive-like behavior by using repetitive function calls that mimic loops

Reentrancy Loops (FV-SOL-9-C4)

When a loop involves multiple calls to external contracts (e.g., token.transfer() or someOtherContract.call()), the gas cost becomes unpredictable and can be higher than expected due to the external call’s complexity.

Non-Optimized Nested Loops (FV-SOL-9-C5)

Nested loops are particularly costly because the gas cost grows exponentially with each layer of nesting. This is especially problematic when the loop conditions are based on user data or dynamic array lengths

Mitigation Patterns

Batch Processing (FV-SOL-9-M1)

Break down large loops into smaller batches, allowing users to process data over multiple transactions rather than a single on

Gas Hard Limit (FV-SOL-9-M2)

Set a gas threshold or limit for loop processing and exit the loop once it approaches that threshold

Avoid Dynamic Data in Loops (FV-SOL-9-M3)

Limit loop iterations to fixed-sized arrays or arrays with capped sizes. Avoid using user-input data or dynamic arrays in loop conditions

Events Instead of Iteration (FV-SOL-9-M4)

In cases where a function needs to notify many users or accounts, consider emitting events instead of looping through recipients, allowing users to handle their own state separately

Actual Occurrences

• https://solodit.cyfrin.io/issues/h-04-unbounded-loop-in-_removenft-could-lead-to-a-griefingdos-attack-code4rena-visor-visor-contest-git

Content