BattleChain Confidence Pools

Description

For a good-faith CORRUPTED resolution, the protocol guarantees the named whitehat attacker the whole pool — stake plus bonus (README: "up to snapshotTotalStaked + snapshotTotalBonus"; DESIGN.md §12: "the entire pool is the named attacker's bounty"; §5: the moderator may flag CORRUPTED "sweeping the pool whole, bonus included"). The re-flag correction window (DESIGN.md §4) exists so the moderator can fix a mis-flagged outcome "before any participant locks in the wrong distribution."

sweepUnclaimedBonus deliberately does not set the claimsStarted finality latch, specifically to keep the moderator's re-flag window open:

But the sweep itself irreversibly moves the bonus to recoveryAddress and decrements the live totalBonus, in the no-observed-risk branch:

When the registry is CORRUPTED with riskWindowStart == 0 (no active-risk state was ever observed), and the moderator first flags SURVIVED (an out-of-scope judgement, legal on a CORRUPTED registry), any account can call the permissionless sweepUnclaimedBonus and the bonus leaves to recoveryAddress. If the moderator then exercises the §4 correction window and re-flags good-faith CORRUPTED, flagOutcome re-snapshots the now-drained totalBonus:

The whitehat's bountyEntitlement is therefore short the entire bonus, which is already sitting at recoveryAddress (the sponsor-controlled address). The §4 guarantee that a pre-claim correction is honorable is broken by a value movement that §4's own reasoning did not account for — the sweep-comment's premise "genuine reliance only comes from claim entrypoints" is the oversight, because the sweep is itself an irreversible transfer.

Risk

Likelihood:

• Requires the registry in CORRUPTED with riskWindowStart == 0 (a real "no observable risk" state DESIGN.md §5 documents as reachable), the moderator flagging SURVIVED then correcting to good-faith CORRUPTED (a correction the §4 window explicitly supports), and one permissionless sweepUnclaimedBonus call interposed. The sweep is callable by anyone the moment the pool is in SURVIVED; it is not a tight race — the bonus stays sweepable until the moderator corrects.

• The beneficiary is the sponsor (recoveryAddress), giving an incentivized party a reason to interpose the sweep.

Impact:

• The entire bonus pool is permanently misdirected from the good-faith whitehat (the intended beneficiary of the whole pool) to recoveryAddress. Bonus liquidity is "economically required for rational staker participation," so the diverted amount can be the dominant part of the pool.

Proof of Concept

test/audit/BonusLeakReflag.audit.t.sol contains a baseline (correct behavior) and the bug, both passing under forge test.

• Baseline test_baseline_noSweep_whitehatGetsWholePool: the same SURVIVED → CORRUPTED moderator correction with no interposed sweep pays the whitehat the whole pool (100 principal + 500 bonus = 600) and leaks nothing to recovery.

• Bug test_bonusLeaksToRecovery_onSurvivedThenCorruptedReflag: with the sweep interposed, the whitehat receives only the 100 principal; the 500 bonus is at recoveryAddress; bountyEntitlement is 100.

Result: both tests PASS — the baseline proves the intended whole-pool payout, the bug proves the shortfall.

Recommended Mitigation

Reserve the bonus while the outcome can still be corrected to CORRUPTED, or lock the outcome once the bonus principal has moved. The bonus-releasing branch (riskWindowStart == 0 / totalEligibleStake == 0) is distinct from the donation/dust path the "do not set claimsStarted" comment worries about, so latching finality there does not reintroduce the 1-wei griefing concern:

Alternatively, gate sweepUnclaimedBonus so it can only release donations above the original snapshotTotalBonus until the CORRUPTED-correction window is closed.