Summary

sweepUnclaimedBonus() can transfer protocol-accounted bonus to recoveryAddress without setting claimsStarted. The moderator can then use the documented pre-claim correction window to reflag the same pool from SURVIVED to good-faith CORRUPTED, but the corrected snapshot is taken after totalBonus has already been reduced. The latest outcome says the named attacker is entitled to the good-faith CORRUPTED bounty, yet the bonus portion of that bounty is already held by recoveryAddress.

The issue is not a disagreement with the no-risk-window rule. In a final SURVIVED or EXPIRED outcome with riskWindowStart == 0, stakers are owed principal only and the bonus is sweepable. The break appears because the sweep is allowed while the correction window is still open. This path moves accounted bonus but leaves claimsStarted == false, so later accounting acts as if no final value movement occurred.

Finding Description

Affected function: ConfidencePool.sweepUnclaimedBonus().

Relevant behavior:

1. flagOutcome(SURVIVED) is allowed while the registry is CORRUPTED when the moderator judges the breach out of scope.

2. Before any claim, flagOutcome() intentionally permits a correction to good-faith CORRUPTED.

3. If no active-risk window was observed, _bonusShare() returns zero for SURVIVED/EXPIRED stakers, so sweepUnclaimedBonus() treats the tracked bonus as unreserved.

4. sweepUnclaimedBonus() transfers that tracked bonus to recoveryAddress, decrements totalBonus, and intentionally does not set claimsStarted.

5. A later good-faith CORRUPTED reflag snapshots snapshotTotalBonus = totalBonus, which is now zero.

6. claimAttackerBounty() pays only the remaining principal, even though a direct good-faith CORRUPTED flag over the same original pool pays principal plus bonus.

The sweeper does not need privileged access. The only privileged action is the moderator's documented pre-claim correction reflag, which is part of the intended protocol flow. The exploitable action is that any caller can move accounted bonus to recoveryAddress before that correction finalizes.

Impact Explanation

The corrected good-faith attacker bounty can be reduced by the full bonus balance. With stake plus bonus, the attacker receives only principal and recoveryAddress keeps the bonus. With a bonus-only pool, the entire good-faith bounty can be swept before correction and the named attacker has no remaining entitlement. A value-moving sweep of accounted protocol bonus must either finalize the current outcome or be impossible while the moderator correction window remains open. Otherwise, the pool can move funds according to one outcome while still allowing accounting to be resnapshotted under a different outcome.

The PoC uses 100e18 stake and 50e18 bonus. Direct good-faith CORRUPTED pays 150e18. The exploit sequence pays the attacker 100e18 and leaves 50e18 with recoveryAddress. The loss scales linearly with totalBonus.

Likelihood Explanation

The sequence is realistic during the protocol’s intended correction window. The moderator may initially flag SURVIVED for a registry-level CORRUPTED agreement when the breach appears out of scope, then correct to good-faith CORRUPTED after confirming the breach was in scope. A sponsor-controlled recovery address can watch the temporary SURVIVED flag and call sweepUnclaimedBonus() before the correction.

The path requires riskWindowStart == 0, which is also an intended and documented state: the registry can reach terminal CORRUPTED without the pool locally observing active risk, and moderator CORRUPTED remains allowed in that case.

Proof of Concept

Mainnet environment validation used BattleChain mainnet block 84. The exploit itself is deterministic against the local Foundry mocks.

PoC output:

Recommended Mitigation

Separate donation/dust sweeps from accounted-bonus sweeps while the reflag window is open. A pre-finality sweep may recover untracked donations, but it must not move tracked totalBonus unless the outcome has already been finalized by a claim or the sweep itself deliberately finalizes the outcome.

Minimal patch direction:

Blocking accounted-bonus sweeps before finality preserves the moderator correction window while still allowing donation-only sweeps.

Validation steps

Environment

Use the repository root:

Foundry is installed at:

The project .env contains:

The required hostname did not resolve from the validation machine. The exact required command fails before reaching JSON-RPC:

Expected observed output on the validation machine:

The reachable BattleChain mainnet endpoint verifies the expected chain id:

Expected output:

Reproduction

Run the PoC from the repository root while keeping the PoC under my-poc:

The PoC contains three tests. The exploit test performs the following sequence:

1. Alice stakes 100e18.

2. Carol contributes 50e18 bonus.

3. The registry mock is moved directly to CORRUPTED, leaving riskWindowStart == 0.

4. The moderator temporarily flags SURVIVED.

5. sweepUnclaimedBonus() is called before any claim.

6. The sweep transfers 50e18 to recoveryAddress, reduces totalBonus to zero, and leaves claimsStarted == false.

7. The moderator corrects the outcome to good-faith CORRUPTED and names attacker.

8. The corrected CORRUPTED snapshot has snapshotTotalBonus == 0.

9. attacker claims only 100e18.

10. The control path proves direct good-faith CORRUPTED would have paid 150e18.

Expected output:

Validation logic

The exploit is confirmed if all of the following are true:

1. pool.riskWindowStart() is zero when the temporary SURVIVED outcome is flagged.

2. The first snapshot records snapshotTotalBonus == 50e18.

3. sweepUnclaimedBonus() transfers 50e18 to recoveryAddress.

4. pool.claimsStarted() remains false immediately after that sweep.

5. A subsequent flagOutcome(CORRUPTED, true, attacker) succeeds.

6. The corrected snapshot records snapshotTotalBonus == 0.

7. pool.bountyEntitlement() is 100e18, not 150e18.

8. claimAttackerBounty() transfers only 100e18.

9. The direct-control path transfers 150e18 under good-faith CORRUPTED when the intermediate sweep is skipped.

The bonus-only test validates the maximum version of the same accounting break. With no stake and 50e18 bonus, a direct good-faith CORRUPTED outcome would make the bonus the entire bounty basis. The temporary SURVIVED sweep transfers that full 50e18 to recoveryAddress. The reflag then sets bountyEntitlement == 0, and claimAttackerBounty() reverts with BountyAlreadyClaimed.

Baseline tests

Run the non-fork test suite:

Expected summary:

Run fork tests against the reachable mainnet endpoint:

Expected summary:

Patch validation

Apply a patch that prevents sweepUnclaimedBonus() from moving tracked totalBonus while claimsStarted == false, while still allowing donation-only sweeps. After the patch:

1. The exploit test should revert at sweepUnclaimedBonus() before any tracked bonus leaves.

2. The direct-good-faith control should keep passing and pay 150e18.

3. Existing donation-only sweep tests should keep passing.

4. Existing dust sweep tests after all stakers claim should keep passing.

5. Existing no-risk principal-claim behavior should keep passing.

The invariant restored by the patch is:

If the implementation instead chooses to set claimsStarted = true when tracked bonus is swept, the exploit test should fail at the later reflag with OutcomeAlreadySet. That also prevents the false corrected outcome, but it lets a sweep finalize a temporary SURVIVED outcome. Blocking tracked-bonus sweeps before finality gives cleaner correction semantics.

BattleChain Confidence Pools State Machine

Registry-State Function Matrix

Pool-Local Latches

Confirmed Broken Assumption

docs/DESIGN.md describes claimsStarted as the value-movement finality latch: once value leaves, a corrective reflag cannot be honored without breaking balance accounting. A value-moving sweep of accounted protocol bonus must either finalize the current outcome or be impossible while the moderator correction window remains open. sweepUnclaimedBonus() violates that rule for accounted bonus. In a no-risk SURVIVED/EXPIRED snapshot, the function can sweep the tracked bonus to recoveryAddress, decrement totalBonus, and leave claimsStarted == false. A subsequent good-faith CORRUPTED reflag snapshots only the remaining principal, so the latest outcome says the attacker bounty is active while the bonus portion has already been moved to recovery.