BattleChain Confidence Pools

Summary

The protocol intentionally allows the moderator to correct an outcome before the first value-moving claim. In a good-faith CORRUPTED correction, the named attacker should receive a bounty equal to the snapshotted stake plus bonus. The bug is that sweepUnclaimedBonus() can move accounted bonus to recoveryAddress during that same correction window without setting claimsStarted.

This is a payout-integrity issue. When the first outcome is SURVIVED and riskWindowStart == 0, sweepUnclaimedBonus() treats the tracked bonus as sweepable, transfers it to recovery, and decrements totalBonus. The moderator can still re-flag to good-faith CORRUPTED afterward, but the new bounty snapshot excludes the swept bonus.

Affected Contract

File: src/ConfidencePool.sol

Lines: 322-379

Function/Type: flagOutcome(PoolStates.Outcome,bool,address)

File: src/ConfidencePool.sol

Lines: 432-453

Function/Type: claimAttackerBounty()

File: src/ConfidencePool.sol

Lines: 474-509

Function/Type: sweepUnclaimedBonus()

Vulnerability Details

flagOutcome() allows re-flagging as long as claimsStarted is false. This is meant to let the moderator correct an incorrect outcome before participants rely on it through a claim.

However, sweepUnclaimedBonus() can transfer real pool value without setting claimsStarted. In the no-risk-window case, the function reserves only outstanding principal and treats the entire bonus as free balance. It then decrements totalBonus and transfers the amount to recoveryAddress.

Because claimsStarted remains false, the moderator can still correct the outcome to good-faith CORRUPTED. During that correction, flagOutcome() snapshots the already-decremented totalBonus, so bountyEntitlement = snapshotTotalStaked + snapshotTotalBonus excludes the swept bonus. The whitehat receives principal only, while recovery keeps the bonus.

Root Cause

The root cause is that sweepUnclaimedBonus() performs value movement and accounting reduction without closing the re-flag correction window, allowing a later good-faith CORRUPTED snapshot to use the reduced bonus value.

Attack Vectors

Attack Vector 1: Sweep between incorrect flag and correction

Step 1 The registry is CORRUPTED, but no active-risk observation has set riskWindowStart.
Step 2 The moderator first flags SURVIVED and intends to correct it before any claim.
Step 3 Any caller invokes sweepUnclaimedBonus() while claimsStarted == false.
Result: The bonus is transferred to recoveryAddress, totalBonus is decremented, and the correction window remains open.

Attack Vector 2: Front-run moderator correction

Step 1 A SURVIVED flag is visible on-chain with riskWindowStart == 0.
Step 2 A moderator correction to good-faith CORRUPTED is expected or submitted.
Step 3 A caller submits sweepUnclaimedBonus() before the correction is finalized.
Step 4 The moderator correction still succeeds, but snapshots the reduced totalBonus.
Result: The whitehat bounty excludes the swept bonus and pays only the remaining principal.

Execution Flow

• The pool holds staked principal and contributed bonus.

• The registry is terminal CORRUPTED, but riskWindowStart remains zero.

• The moderator flags SURVIVED.

• claimsStarted remains false because no claim has occurred.

• A caller executes sweepUnclaimedBonus().

• The function reserves principal only, transfers the tracked bonus to recovery, and decrements totalBonus.

• The moderator re-flags to good-faith CORRUPTED.

• flagOutcome() snapshots the reduced totalBonus.

• claimAttackerBounty() pays the attacker only snapshotTotalStaked + snapshotTotalBonus, excluding the swept bonus.

Impact

This is a Medium severity value-redirection issue. The named good-faith attacker can lose the entire bonus portion of the bounty even though the moderator correction is accepted. The recovery address keeps funds that should have been reserved for the whitehat under the corrected CORRUPTED outcome.

The attacker cost is only the gas cost to call a permissionless sweep during the correction window. The protocol impact is a broken final distribution: the correction mechanism remains open, but the economic state being corrected has already been changed by a sweep.

Validation steps

Standalone Validation

Framework used: Foundry / forge

Validation Test File

File 1: test/poc/ConfidencePoolReflagSweepPoC.t.sol

How to Run

Captured Test Output

Log-to-Impact Walkthrough

The passing PoC shows that sweepUnclaimedBonus() transfers 50 * ONE to recovery while claimsStarted remains false. The moderator then re-flags to good-faith CORRUPTED, but bountyEntitlement() is only 100 * ONE, proving the bonus was removed from the whitehat bounty.

Key Assertions Proven

assertFalse(pool.claimsStarted()) after the sweep -> proves the correction window remains open after value movement -> PASS
assertEq(pool.totalBonus(), 0) -> proves the tracked bonus is removed before the corrected snapshot -> PASS
assertEq(pool.bountyEntitlement(), 100 * ONE) -> proves the good-faith bounty excludes the swept 50 * ONE bonus -> PASS

Recommended Fix

Do not allow accounted bonus to be swept while the moderator correction window is still open. Either reserve totalBonus until a genuine claim closes the window, or make tracked-bonus sweeping close the correction window before value leaves the pool.