BattleChain Confidence Pools

Description

• After a pool resolves SURVIVED or EXPIRED, sweepUnclaimedBonus() lets anyone recover bonus tokens nobody is owed — when riskWindowStart == 0, no staker earned any bonus, so the entire totalBonus is fair game to sweep to recoveryAddress. This function deliberately does not set claimsStarted, specifically so a 1-wei donation can't be used to grief-close the moderator's correction window.

• That same omission means sweepUnclaimedBonus() can move the entire live bonus pool — not just dust — while flagOutcome's re-flag window is still open, since that window's only gate is claimsStarted. A moderator's provisional SURVIVED flag (legal even when the registry reads CORRUPTED, as an out-of-scope judgment call) can be followed by a full bonus sweep, and then corrected to good-faith CORRUPTED — but the correction recomputes bountyEntitlement from the now-drained live totalBonus, permanently shorting the whitehat named in the correction.

Risk

Likelihood:

• A pool's risk window stays unobserved (riskWindowStart == 0) whenever the registry transitions to a terminal state without any pool interaction happening during UNDER_ATTACK/PROMOTION_REQUESTED — a normal outcome for a pool nobody happens to poke during that window, not a contrived edge case, and one the codebase's own design doc already acknowledges as reachable.

• A moderator facing a CORRUPTED registry read makes a provisional out-of-scope SURVIVED judgment, a permissionless caller sweeps the bonus in the same block or the next one, and the moderator then corrects to good-faith CORRUPTED once the in-scope determination is confirmed — this sequence follows the exact "fix a mistaken flag before anyone claims" workflow flagOutcome's re-flag window is built for, so the drain rides along an intended, everyday correction path rather than requiring an unusual sequence.

Impact:

• The named good-faith whitehat's bounty is permanently short by the entire swept bonus amount — not dust, the full totalBonus at sweep time — with the difference stuck at recoveryAddress instead of reaching the attacker docs/DESIGN.md says is owed "the entire pool."

• The shortfall is irreversible once claimAttackerBounty() pays out against the reduced bountyEntitlement; there is no later mechanism to top up the attacker's payment from the swept funds.

Proof of Concept

Run: forge test --match-path "SweepBonusReflagDrain.t.sol" -vvvv → PASS (gas: 591171)

Recommended Mitigation

Setting claimsStarted = true inside sweepUnclaimedBonus closes the re-flag window the moment value actually leaves the pool, mirroring every other payout/sweep function in the contract (claimSurvived, claimCorrupted, claimAttackerBounty, sweepUnclaimedCorrupted all already do this) — sweepUnclaimedBonus was the one exception.

Trade-off to weigh: the existing code comment explains this was deliberately omitted so a griefer couldn't donate 1 wei and immediately lock the moderator's correction window. This fix reintroduces that exact griefing vector — anyone can now force-close the re-flag window early with a trivial donation-plus-sweep. A more targeted fix would gate the lock on the swept amount being non-dust (e.g. only when totalEligibleStake != 0 or amount exceeds a minimum), preserving the original anti-griefing intent while still closing the drain for any economically meaningful sweep.