# Per-entry failure isolation in payout loops

Loops over stored tokens/recipients that revert on one bad entry, blocking all payouts

_Area: Smart contract access control and control flow. Seen in 3 disclosed reports; latest 2024-04-26. Updated 2026-10-23._

## How it works
A payout, refund, recall, or migration path iterates a stored list of tokens or recipients and calls a transfer/mint helper for each entry. The code assumes every entry is a valid transfer that will succeed. That assumption breaks when an entry carries a zero amount, a sentinel address, or depends on an external cap the forward path may exhaust. The token reverts, and because the loop is all-or-nothing, every other payout in the batch is blocked. When the bad entry is permanent, the whole path stays bricked.

## Where it shows up
- Payout loops over a stored `tokenAddresses`/recipient array where entries persist with zero balance or zero amount [E3](https://bugbountylibrary.com/r/sherlock%3A2023-02-openq%3AH-4.md).
- Refund/recall paths that reuse the same mint logic as the forward path, so an external cap (e.g. minter allowance) makes the refund revert [E1](https://bugbountylibrary.com/r/c4%3A2024-03-taiko%3AM-04.md).
- State values initialized to `address(0)` then later migrated from, where `balanceOf(address(0)) > 0` forces a `transferFrom` from the zero address [E2](https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-29.md).
- Tokens known to revert on zero-value transfers, or that allow burns to `address(0)`.

## How to review
The invariant: every entry the loop can reach must be transferable, or the loop must isolate failures per entry. Check that (1) zero-amount and zero-address entries are filtered or removed before iteration; (2) refund/recall paths do not depend on external caps the forward path may exhaust [E1](https://bugbountylibrary.com/r/c4%3A2024-03-taiko%3AM-04.md); (3) migration code never calls `transferFrom` from a sentinel address [E2](https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-29.md); (4) a single bad entry cannot revert the whole batch. Confirm the loop cannot be made to revert by one entry.

## Variants seen
- Refund path reuses mint logic; external minter allowance exhaustion traps bridged funds [E1](https://bugbountylibrary.com/r/c4%3A2024-03-taiko%3AM-04.md).
- Sentinel `address(0)` holds dust, forcing a reverting `transferFrom` from zero [E2](https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-29.md).
- Refunded token stays in list with zero total, `transfer(0)` reverts, list cannot be reset [E3](https://bugbountylibrary.com/r/sherlock%3A2023-02-openq%3AH-4.md).

## Impact and severity
Funds trapped or payouts permanently bricked; in E1 bridged USDC and ETH locked in the vault. Severity is high when the bad entry is permanent and the loop is all-or-nothing. In E2 a single 1-wei transfer to `address(0)` blocks all flywheel creation; in E3 one deposit-and-refund bricks payouts permanently [E2](https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-29.md)[E3](https://bugbountylibrary.com/r/sherlock%3A2023-02-openq%3AH-4.md).

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2024-03-taiko%3AM-04.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-29.md
- E3: https://bugbountylibrary.com/r/sherlock%3A2023-02-openq%3AH-4.md