Root + impact

Description

The moderator may correct a flagged outcome until the first claim. Finality is latched by
claimsStarted, which every claim/sweep path is supposed to respect so that value does not move
before the correction window closes. For good-faith CORRUPTED the named whitehat is entitled to the
entire pool, principal plus the full bonus.

sweepUnclaimedBonus moves the bonus out of the pool but deliberately does not set claimsStarted.
When the moderator first flags SURVIVED on a CORRUPTED registry with no observed risk window
(riskWindowStart == 0), the whole bonus becomes sweepable to recoveryAddress, and anyone can
sweep it while the correction window is still open. If the moderator then corrects to good-faith
CORRUPTED, the re-snapshot reads a bonus of zero, so the whitehat's entitlement collapses to
principal only. The bonus that should have been part of the bounty is stranded at recoveryAddress.

Why this is not documented / accepted

Every step is a DESIGN-sanctioned action, yet the composition is not covered:

• Section 8 makes flagging SURVIVED on a CORRUPTED registry a valid moderator action (out-of-scope
  breach, stakers recover stake + bonus). The SURVIVED first step is legitimate, not user error.

• Section 5 documents the riskWindowStart == 0 bonus sweep to recoveryAddress, but it assumes the
  moderator later flags CORRUPTED "sweeping the pool whole." It never contemplates a pool already
  drained of its bonus before the CORRUPTED flag.

• Section 4 states finality is tied to value movement: "once value has left the contract, a
  corrective re-flag cannot be honored without breaking balance accounting." This finding is a value
  movement (the sweep) that does not latch claimsStarted, so the correction is honored on a drained
  pool. It violates section 4's invariant rather than being covered by it.

• The section-5 no-risk-window race (lines 111-127) is a different mechanism: a staker's
  claimExpired foreclosing CORRUPTED. This is the moderator's own SURVIVED to CORRUPTED correction.

• The code comment at ConfidencePool.sol:503-505 justifies the non-latch with "genuine reliance
  only comes from claim entrypoints." That premise is false here: the entire bonus, not dust or
  donations, is swept, and it is genuinely relied on by the good-faith CORRUPTED bounty.

Risk

Likelihood:

• The trigger requires a CORRUPTED registry with riskWindowStart == 0 (no pool interaction ever
  observed the active-risk window), a moderator who first flags SURVIVED (initial out-of-scope
  judgement), and a later good-faith CORRUPTED correction. This is the legitimate DESIGN section 4
  correction sequence, not a moderator bug, but it is a narrow path.

• The sweep is permissionless, so any observer front-runs the correction the moment SURVIVED is
  flagged. The bonus contributor and stakers cannot prevent it.

Impact:

• The named whitehat receives principal only instead of principal plus bonus. In the PoC the
  whitehat gets 100 of a 600 pool, and the 500 bonus is stranded at recoveryAddress.

• Value is misrouted, not destroyed (it sits at recoveryAddress, recoverable off-chain by the
  sponsor), and no principal is lost, which caps this at Low.

Proof of concept

test/unit/SweepReflagLead.t.sol (test_sweepBetweenReflags_shortsNamedAttackerTheBonus, passing):

Flow:

1. Alice stakes 100, a 500 bonus is contributed, registry is CORRUPTED with riskWindowStart == 0.

2. Moderator flags SURVIVED (initial out-of-scope judgement).

3. A random address calls sweepUnclaimedBonus; the whole 500 goes to recoveryAddress,
   claimsStarted stays false.

4. Moderator corrects to good-faith CORRUPTED naming the whitehat; bountyEntitlement re-snapshots
   to 100.

5. Whitehat claims and receives 100. The 500 is stranded at recoveryAddress.

Recommended mitigation

Reserve the bonus while the correction window is open even when riskWindowStart == 0, or block
sweepUnclaimedBonus until finality is latched. The simplest fix is to gate the sweep on
claimsStarted, so the bonus cannot leave before the outcome is final:

The anti-1-wei-grief reason the sweep avoids latching claimsStarted (DESIGN section 4) does not
require it to also move value pre-finality; the two concerns can be separated.