BattleChain Confidence Pools
Cyfrin
FoundrySolidityLayer 2
7.25 ETH
View all submissions
Previous Next
Submission Details
Impact: medium
Likelihood: medium

`sweepUnclaimedBonus()` can move funds while outcome correction remains open

Author Revealed upon completion

Root + Impact

Description

The protocol allows the moderator to correct a previously flagged outcome before finality is reached. That correction boundary is enforced through the claimsStarted latch.

However, sweepUnclaimedBonus() can transfer value out of the pool while claimsStarted is still false. This means funds can leave the contract even though the moderator correction window is still technically open.

As a result, bonus sweeping is not aligned with the same finality condition used by flagOutcome(), and economic state can change before outcome correction is fully closed.

function flagOutcome(PoolStates.Outcome newOutcome, bool goodFaith_, address attacker_) external onlyModerator {
if (outcome != PoolStates.Outcome.UNRESOLVED && claimsStarted) revert OutcomeAlreadySet();
...
}
​
function sweepUnclaimedBonus() external nonReentrant {
if (outcome != PoolStates.Outcome.SURVIVED && outcome != PoolStates.Outcome.EXPIRED) {
revert OutcomeNotEligibleForSweep();
}
​
...
uint256 amount = freeBalance > reserved ? freeBalance - reserved : 0;
if (amount == 0) revert NothingToSweep();
​
if (totalEligibleStake == 0 || riskWindowStart == 0) {
totalBonus -= amount <= totalBonus ? amount : totalBonus;
}
​
stakeToken.safeTransfer(recoveryAddress, amount);
}

flagOutcome() uses claimsStarted as the condition that closes re-flagging, but sweepUnclaimedBonus() can move value without requiring that condition to be true.

The issue is that sweeping is allowed before the same finality latch used for correction has been closed.

Risk

Likelihood:

  • The protocol explicitly permits moderator correction while claimsStarted == false.

  • sweepUnclaimedBonus() is permissionless and can be called during that same period.

Impact:

  • Funds can be moved out of the pool before outcome correction is fully finalized.

  • This creates a mismatch between outcome-correction state and value-movement finality.

Proof of Concept

This issue is reachable after the moderator has flagged SURVIVED, but before any claim has been made. At that point, claimsStarted is still false, so the contract still treats the correction window as open. Despite that, a third party can already call sweepUnclaimedBonus() and move sweepable value out of the contract.

function testSubmission_sweepUnclaimedBonusMovesFundsBeforeOutcomeCorrectionCloses() external {
_stake(alice, 100 * ONE);
_contributeBonus(carol, 50 * ONE);
​
attackRegistry.setAgreementState(IAttackRegistry.ContractState.CORRUPTED);
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.SURVIVED, false, address(0));
​
assertFalse(pool.claimsStarted(), "re-flag window still open before any claim");
​
uint256 recoveryBefore = token.balanceOf(recovery);
vm.prank(dave);
pool.sweepUnclaimedBonus();
​
assertEq(token.balanceOf(recovery) - recoveryBefore, 50 * ONE, "permissionless sweep moves bonus immediately");
assertFalse(pool.claimsStarted(), "sweep does not close the correction window");
assertEq(token.balanceOf(address(pool)), 100 * ONE, "only principal remains after sweep");
​
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.CORRUPTED, false, address(0));
​
assertEq(uint256(pool.outcome()), uint256(PoolStates.Outcome.CORRUPTED), "moderator can still re-flag");
assertEq(pool.snapshotTotalBonus(), 0, "re-flag snapshots after the sweep, not before it");
}

  1. Alice stakes and Carol contributes bonus.

  2. The registry is already CORRUPTED.

  3. The moderator flags SURVIVED.

  4. No claim has been made yet, so claimsStarted remains false.

  5. A third party calls sweepUnclaimedBonus().

  6. sweepUnclaimedBonus() transfers the sweepable bonus to recoveryAddress.

  7. The moderator can still re-flag the pool to CORRUPTED afterward because the formal correction window is still open.

  8. The later CORRUPTED snapshot now reflects snapshotTotalBonus == 0 because the value already moved before finality closed.

Result:
Value has already moved out of the contract even though the outcome correction window is still formally open.

Recommended Mitigation

The fix is to make bonus sweeping depend on the same finality condition that closes outcome correction. That keeps value movement and correction finality aligned.

function sweepUnclaimedBonus() external nonReentrant {
if (outcome != PoolStates.Outcome.SURVIVED && outcome != PoolStates.Outcome.EXPIRED) {
revert OutcomeNotEligibleForSweep();
}
​
+ if (!claimsStarted) revert OutcomeCorrectionWindowOpen();
​
uint256 reserved;
if (totalEligibleStake != 0) {
reserved = totalEligibleStake;
if (riskWindowStart != 0) {
reserved += snapshotTotalBonus - claimedBonus;
}
}
​
uint256 freeBalance = stakeToken.balanceOf(address(this));
uint256 amount = freeBalance > reserved ? freeBalance - reserved : 0;
if (amount == 0) revert NothingToSweep();
​
if (totalEligibleStake == 0 || riskWindowStart == 0) {
totalBonus -= amount <= totalBonus ? amount : totalBonus;
}
​
stakeToken.safeTransfer(recoveryAddress, amount);
}

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!