BattleChain Confidence Pools

Summary

sweepUnclaimedBonus() can move accounted bonus to recoveryAddress while the moderator’s pre-claim re-flag window is still open. If the moderator later corrects SURVIVED to good-faith CORRUPTED, the new snapshot uses the already-reduced totalBonus, so the attacker bounty excludes bonus that was part of the pool before the correction.

Vulnerability Details

Vulnerable code:

• ConfidencePool.sol#L322-L363

• ConfidencePool.sol#L474-L506

flagOutcome() intentionally allows the moderator to re-flag before any claim starts:

The problem is that sweepUnclaimedBonus() can move real accounted bonus before that re-flag window is closed:

When riskWindowStart == 0, the function treats the bonus as sweepable, transfers it to recoveryAddress, and reduces totalBonus. But it does not set claimsStarted, so the moderator can still re-flag afterward. A later good-faith CORRUPTED flag snapshots the already-drained totalBonus, reducing the attacker’s bounty.

Why this is not intended

The code comments show that the moderator is allowed to fix an outcome only before users start relying on the current distribution.

sweepUnclaimedBonus() does not set claimsStarted because otherwise someone could send a tiny amount of tokens directly to the pool and use that donation to block the moderator from correcting a mistake. That part makes sense.

The problem is that the function does not separate a direct donation from the pool’s real recorded bonus.

In the second test, the pool has 100 tokens of stake, 50 tokens of bonus, and a 25-token direct donation. The sweep sends 75 tokens to recoveryAddress, which includes both the donation and the full 50-token bonus. Even after that, the moderator can still change the outcome. When the outcome is corrected to good-faith CORRUPTED, the attacker receives only the 100-token stake instead of 150 tokens.

The third test makes the issue even clearer because there is no donation at all. The pool has no stake and only a 50-token bonus. That bonus is fully swept, but the moderator can still correct the outcome afterward. Since the new snapshot sees zero stake and zero bonus, the attacker bounty becomes zero.

So this is not only about safely removing random tokens sent by outsiders. The same logic also lets the pool’s recorded bonus leave before the outcome is final. Once that bonus has been moved, a later correction should not be allowed to calculate the bounty from the reduced amount.

So the intended rule is not “re-flagging remains open after pool value moves.” The intended rule is that re-flagging stays open before claims lock in a distribution.
sweepUnclaimedBonus() avoids setting claimsStarted to prevent a tiny donation from griefing the moderator’s correction window:

That makes sense for dust or unaccounted donations. It does not cover the PoC case, where the swept amount is the real 50 * ONE bonus added through contributeBonus(). Once that accounted bonus leaves the pool, a later corrected snapshot should not silently lose it.

Likelihood: Medium

This requires a particular order of events: the moderator first flags the pool as SURVIVED or EXPIRED, someone calls sweepUnclaimedBonus() before any claim, and the moderator later corrects the result to good-faith CORRUPTED.

The sequence is specific, but every step is allowed by the current code. The sweep is permissionless, and it does not close the moderator’s correction window.

Impact: Medium

The attacker receives less than the bounty that would have been available before the bonus was swept.

In the second test, the attacker should receive the 100-token stake plus the 50-token bonus. Instead, the bonus is sent to recoveryAddress, and the attacker receives only 100 tokens. The attacker loses 50 tokens from the corrected bounty.

In the third test, the pool contains only a 50-token bonus and no stake. After the bonus is swept, the corrected CORRUPTED outcome gives the attacker nothing. The entire bounty is removed.

The tokens are not burned or stuck. They are sent to recoveryAddress. The issue is that they go to the wrong side of the final distribution, which reduces or completely removes the attacker’s bounty..

test/unit/AuditReflagSweepBonusTest.t.sol

Proof Of Concept

Tools Used

Manual review, Foundry test.

Recommendations

Close the re-flag window when sweepUnclaimedBonus() moves accounted bonus, while still allowing harmless dust/donation sweeps to avoid blocking moderator correction.

This keeps the intended donation/dust behavior intact, but once real accounted bonus leaves the pool, the outcome becomes final just like other value-moving paths