# Claim eligibility not cleared after payout

Payout paths that leave eligibility, active flags, or counters live so the same claim can be reused

_Area: DeFi accounting and math bugs. Seen in 2 disclosed reports; latest 2024-10-31. Updated 2026-10-25._

## How it works
A payout path consumes a claim but does not clear the state that makes the claim valid. The assumption that "paying out implies the record is spent" is never enforced in code. Eligibility, an `isActive` flag, a request balance, or a legacy-status check stays live, so the same record can be claimed, deleted, or finalized again. The root cause is a missing state transition: the guard that gates entry is not the same field the payout path mutates.

## Where it shows up
- Reward/eligibility sets built by a view function that filters on one condition (e.g. quorum) but not on terminal states (cancelled, vetoed) [E1](https://bugbountylibrary.com/r/sherlock%3A2024-03-nouns-dao-2%3AH-2.md)
- Claim functions that convert or preview amounts without checking the epoch/settlement status first [E2](https://bugbountylibrary.com/r/sherlock%3A2024-03-amphor%3AH-1.md)
- Delete or removal paths that decrement a shared counter but never set the `isActive`/existence flag to false [E3](https://bugbountylibrary.com/r/sherlock%3A2024-10-debita%3AM-1.md)
- Upgrade or migration checks that only validate legacy status for one side of a boundary (batch number, version) [E4](https://bugbountylibrary.com/r/c4%3A2024-03-zksync%3AM-04.md)
- Any function that both mutates config and triggers registry removal in one call [E3](https://bugbountylibrary.com/r/sherlock%3A2024-10-debita%3AM-1.md)

## How to review
For every payout, claim, delete, or finalize path, identify the exact field that marks the record as consumed and confirm it is written before or atomically with the transfer. The invariant: after a successful payout, no later call can pass the same eligibility check for that record. Check that view functions used to build reward/eligible sets exclude all non-final states, not just the happy path. Check boundary conditions in migration/version checks on both sides of the threshold. Check that counters and index mappings stay consistent when a removal path is re-entered.

## Variants seen
- Cancelled proposals still counted as eligible for rewards, enabling create-vote-cancel spam [E1](https://bugbountylibrary.com/r/sherlock%3A2024-03-nouns-dao-2%3AH-2.md)
- Claim without epoch-settled check, returning zero shares and clearing another user's request [E2](https://bugbountylibrary.com/r/sherlock%3A2024-03-amphor%3AH-1.md)
- Repeated deletion of a zero-amount perpetual order corrupting `activeOrdersCount` [E3](https://bugbountylibrary.com/r/sherlock%3A2024-10-debita%3AM-1.md)
- Double finalize across old and new bridge when batch number equals the upgrade batch [E4](https://bugbountylibrary.com/r/c4%3A2024-03-zksync%3AM-04.md)

## Impact and severity
Rewards stolen from honest participants [E1](https://bugbountylibrary.com/r/sherlock%3A2024-03-nouns-dao-2%3AH-2.md), griefing that wipes others' deposit requests [E2](https://bugbountylibrary.com/r/sherlock%3A2024-03-amphor%3AH-1.md), corrupted order registry blocking legitimate deletions [E3](https://bugbountylibrary.com/r/sherlock%3A2024-10-debita%3AM-1.md), and double withdrawal of bridged funds [E4](https://bugbountylibrary.com/r/c4%3A2024-03-zksync%3AM-04.md). Severity rises where the reused record moves funds or blocks other users; the migration case is the most severe because it duplicates value.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2024-03-nouns-dao-2%3AH-2.md
- E2: https://bugbountylibrary.com/r/sherlock%3A2024-03-amphor%3AH-1.md
- E3: https://bugbountylibrary.com/r/sherlock%3A2024-10-debita%3AM-1.md
- E4: https://bugbountylibrary.com/r/c4%3A2024-03-zksync%3AM-04.md