Root + Impact

Description

ConfidencePool ties outcome finality to value movement: every claim/sweep sets claimsStarted = true, and flagOutcome's pre-claim re-flag correction window is gated on claimsStarted == false. The sole exception is sweepUnclaimedBonus, which intentionally does not latch claimsStarted (to stop a 1-wei donation from griefing the re-flag window). That exemption is safe for its donation-recovery branch, but it also applies to the branch that empties the accounted bonus: when riskWindowStart == 0, the sweep sends the entire totalBonus to recoveryAddress and reduces totalBonus to 0, yet still leaves the re-flag window open.

Because the bonus can leave the pool before finality, a subsequent moderator correction from SURVIVED to good-faith CORRUPTED recomputes bountyEntitlement from the already-drained snapshotTotalBonus. The named whitehat then receives only the staked principal instead of the whole pool. This contradicts DESIGN.md §12 ("the entire pool is the named attacker's bounty"), §5 (a CORRUPTED flag sweeps "the pool whole, bonus included"), and §4 ("finality is correctly tied to value movement") — none of which reconcile this sweep-then-correct sequence.

Impact:

The named whitehat, the party the confidence pool exists to reward is deprived of the entire bonus, which the protocol readme calls "economically required." The funds are not destroyed (they land at the sponsor-controlled recoveryAddress), so this is a value misallocation from whitehat to sponsor rather than a total-pool loss, which bounds the severity at Medium. The triggering sweep is permissionless, so the leak can be forced by anyone front-running a transient SURVIVED flag, and it breaks a documented safety mechanism (the §4/§5/§12 guarantees for the good-faith bounty path).

Proof of Concept

1. alice stakes 100; the sponsor contributes a 400 bonus. The registry reaches CORRUPTED without any active-risk state ever being observed on-chain, so riskWindowStart == 0.

2. The moderator initially judges the breach out-of-scope and flags SURVIVED (an honest first call — §4 exists to allow correcting it).

3. Anyone (a griefer, or the sponsor) calls sweepUnclaimedBonus(). Since riskWindowStart == 0, the full 400 bonus is treated as unowed, transferred to recoveryAddress, and totalBonus is zeroed. claimsStarted remains false.

4. The moderator gets better information — the breach was in-scope after all — and corrects with flagOutcome(CORRUPTED, goodFaith=true, whitehat). The re-flag succeeds (claimsStarted == false), but bountyEntitlement is now snapshotTotalStaked + snapshotTotalBonus = 100 + 0 = 100.

5. whitehat calls claimAttackerBounty() and receives 100 instead of the intended 500; the 400 bonus is permanently stranded at recoveryAddress.

Recommended Mitigation

Make the accounted-bonus sweep a finality event, consistent with §4: set claimsStarted = true only inside the branch that reduces totalBonus (i.e. within if (totalEligibleStake == 0 || riskWindowStart == 0)), so the re-flag window closes once the accounted bonus has actually left the pool. The donation-only branch keeps not latching, preserving the 1-wei anti-griefing property the current code relies on. (Alternatively, on a re-flag into CORRUPTED, reconcile snapshotTotalBonus against the pool's live balance but latching-on-drain is the smaller, cleaner change.)