Potential Unbounded Loop in Payout Contract

[AmeanAsad]

Description:

There are a few external view functions in the PayoutFactory contract that loop over all previous payouts, for example:

  /**
     * @dev Returns the total claimable amount over all previously generated payout contracts.
     * @param account The address of the payee.
     */
    function releasable(
        address account
    ) external view returns (uint256 totalValue) {
        uint256 length = _payouts.length;
        for (uint256 i = 0; i < length; i++) {
            PaymentSplitter rewards = PaymentSplitter(payable(_payouts[i]));
            totalValue += rewards.releasable(account);
        }
    }

The above function loops over all previously generated payouts to find the number of releasable payments for a given payee. This causes an issue because as the number of payees grow, the gas fees on calling this function will also grow. The amount of gas spendable on a given FVM transaction is limited by the block limit of the FVM. Therefore, at some point, it is likely that the gas costs to run this function are higher than the actual block limit, which would cause this function to effectively revert forever.

It is important to note that this would not lock the contract for node operators though. Deployed earnings will still be safe and claimable by node operators. Node operators would be able to still claim their earnings through the releaseAll function by modifying the offset. Node operators can also individually interact with the deployed PaymentSplitter contracts to claim their rewards.

This however, significantly impacts the UX for claiming earnings, as users will no longer certain information from the contract.

Potential Solutions

• Implement a loop limit on any function that loops through previous payouts:

external view functions on the FVM are "free" to use via public RPC's. When interacting with a external view function on a public RPC, the node behind that RPC takes care of the gas fees. Therefore, we can leverage this by implementing a limit on the amount of payout contracts looped through and repeatedly call the RPC endpoint until exhaust the list. We have to be careful about rate limiting here but it is unlikely that we'll run into that.

[lordshashank]

Can't we just cap the length to a certain number to avoid this problem?