flagOutcome() lets the moderator correct a prior outcome call as long as claimsStarted is still false. This window exists specifically so a moderator can fix a wrong scope judgement (e.g. an initial SURVIVED later found to actually be an in-scope CORRUPTED) before any participant's payout locks in. The codebase's own design doc states the safety argument explicitly: a corrective re-flag is safe because "once value has left the contract, a corrective re-flag cannot be honored without breaking balance accounting" i.e. the guarantee only holds if no value leaves before claimsStarted flips.
sweepUnclaimedBonus() breaks that guarantee. It transfers real funds to recoveryAddress whenever riskWindowStart == 0, but deliberately never sets claimsStarted. This means the "safe" re-flag window can remain open after real value has already left the contract exactly the condition the design doc assumes can't happen. When a moderator later corrects SURVIVED to a good-faith CORRUPTED, bountyEntitlement is re-snapshotted from totalBonus, which is now missing whatever was already swept so the named whitehat's entitlement silently excludes the bonus, which sits with recoveryAddress instead.
Likelihood:
Occurs whenever a moderator's first-pass outcome call needs correcting an explicitly designed-for scenario (the re-flag window exists specifically for this), combined with riskWindowStart == 0, which happens routinely for a compromise that isn't observed by the pool during its brief UNDER_ATTACK window before flipping to CORRUPTED.
sweepUnclaimedBonus() is fully permissionless and repeat-callable, and the sponsor has a direct economic incentive to call it the instant any SURVIVED lands with riskWindowStart == 0 it costs nothing and functions as a race against a possible correction, not an edge case someone has to construct carefully.
Impact:
The good-faith whitehat's bounty entitlement, documented as "the whole pool: stake + bonus," silently drops to stake-only, with no revert or signal anywhere in the flow claimAttackerBounty() succeeds normally and simply pays out less.
recoveryAddress (sponsor-controlled) permanently captures value that the corrected, final, on-chain-recorded outcome designates for the attacker, a direct, deterministic fund misdirection once the sequence occurs, not a probabilistic or griefing-only outcome.
Run: forge test --match-contract ReflagBonusDivergencePoCTest -vvv — passes clean.
Note this reopens the narrower griefing concern the original comment was solving (a 1-wei donation could let anyone force claimsStarted = true and lock the re-flag window). A more complete fix pairs this change with a minimum-amount or minimum-delay gate on the first sweepUnclaimedBonus() call, so dust can't be used to force early finality while genuine sweeps still close the window as intended.
Impact – Medium Up to the entire bonus pool can be routed to the wrong party for good, with no on-chain way to unwind it, and in a stakerless pool the effect is total since bountyEntitlement computes to zero and claimAttackerBounty reverts outright. This impact is definitely not High: the pool stays solvent throughout with no principal ever at risk, and the money ends up at the sponsor's own recoveryAddress, which in most pools means a sponsor recovering a bonus they funded themselves. The whitehat's claim on that bonus also only exists because the moderator changed their mind after the fact. Likelihood – Low Four separate things have to coincide: nobody touches the pool for the whole active-risk window (or there are no stakers to begin with), the moderator flags SURVIVED and later reverses to CORRUPTED, that reversal is good-faith with a named attacker, and a sweep lands between the two flags. The first cuts against staker self-interest, since skipping the poke costs them their entire bonus share, and the second asks the moderator to overturn a scope judgement, which is a bigger deal than the typo fix DESIGN.md #4 offers the window for. The sweep itself I'd treat as near-certain once the rest holds, given it's permissionless and the sponsor has an obvious reason to make the call, but assembling the first three in one pool lifecycle is where this stays rare.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
View preliminary resultsAppeals are being carefully reviewed by our judges.
The contest is complete and the rewards are being distributed.