BattleChain Confidence Pools
Cyfrin
FoundrySolidityLayer 2
7.25 ETH
View all submissions
Previous Next
Submission Details
Severity: low
Valid

`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);
}
Updates

Lead Judging Commences

inallhonesty Lead Judge 2 days ago
Submission Judgement Published
Validated
Assigned finding tags:

sweepUnclaimedBonus() omits claimsStarted latch, letting a moderator re-flag re-snapshot a drained totalBonus and short the CORRUPTED bounty

Impact – Medium Up to the entire bonus pool can be routed to the wrong party for good, with no on-chain way to unwind it, and in a stakerless pool the effect is total since bountyEntitlement computes to zero and claimAttackerBounty reverts outright. This impact is definitely not High: the pool stays solvent throughout with no principal ever at risk, and the money ends up at the sponsor's own recoveryAddress, which in most pools means a sponsor recovering a bonus they funded themselves. The whitehat's claim on that bonus also only exists because the moderator changed their mind after the fact. Likelihood – Low Four separate things have to coincide: nobody touches the pool for the whole active-risk window (or there are no stakers to begin with), the moderator flags SURVIVED and later reverses to CORRUPTED, that reversal is good-faith with a named attacker, and a sweep lands between the two flags. The first cuts against staker self-interest, since skipping the poke costs them their entire bonus share, and the second asks the moderator to overturn a scope judgement, which is a bigger deal than the typo fix DESIGN.md #4 offers the window for. The sweep itself I'd treat as near-certain once the rest holds, given it's permissionless and the sponsor has an obvious reason to make the call, but assembling the first three in one pool lifecycle is where this stays rare.

Support

FAQs

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

Give us feedback!