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

sweepUnclaimedBonus allows for a later CORRUPTED re-flag to exclude the swept bonus from the whitehat bounty

Author Revealed upon completion

Root + Impact

Summary

sweepUnclaimedBonus() sends the entire accounted bonus to recoveryAddress without setting claimsStarted. The moderator consequently re-flag SURVIVED as good-faith CORRUPTED, but the whitehat’s bounty is calculated from the depleted totalBonus, excluding the swept bonus.

Description

The protocol permits the moderator to correct an outcome while claimsStarted == false. This allows mistakes involving the outcome, good-faith status, or attacker address to be corrected before anyone relies upon the original distribution.

For a SURVIVED outcome where riskWindowStart == 0, stakers are not entitled to bonus rewards. Therefore, sweepUnclaimedBonus() correctly considers the entire bonus pool unreserved and transfers it to recoveryAddress. The problem is that this sweep moves real, accounted value without closing the outcome correction window.

Root cause

Outcome correction is blocked only when claimsStarted is true:

if (outcome != PoolStates.Outcome.UNRESOLVED && claimsStarted) {
revert OutcomeAlreadySet();
}

Claims correctly set this finality latch after transferring value. However, sweepUnclaimedBonus() explicitly does not.

// Intentionally does NOT set claimsStarted.
stakeToken.safeTransfer(recoveryAddress, amount);

Avoiding the latch is appropriate for donation-only sweeps. Otherwise, an attacker could directly transfer one wei into the pool, sweep it, and prematurely close the moderator’s correction window.

The issue here is applying that exception to every sweep, including sweeps that remove accounted bonus. When there are no remaining stakers or no locally observed risk window, the function reduces totalBonus by the swept amount.

if (totalEligibleStake == 0 || riskWindowStart == 0) {
totalBonus -= amount <= totalBonus ? amount : totalBonus;
}

This is not merely removing an unsolicited donation. With riskWindowStart == 0, it can remove the entire genuine bonus pool while leaving the outcome mutable.

A subsequent good-faith CORRUPTED flag snapshots the depleted accounting in `` function.

snapshotTotalStaked = totalEligibleStake;
snapshotTotalBonus = totalBonus;
​
corruptedReserve =
snapshotTotalStaked + snapshotTotalBonus;
​
bountyEntitlement =
snapshotTotalStaked + snapshotTotalBonus;

Because totalBonus was reduced during the earlier sweep, snapshotTotalBonus silently excludes the bonus transferred to recovery.

The broken state transition control flow is therefore:

Accounted bonus leaves pool
↓
totalBonus decreases
↓
claimsStarted remains false
↓
Outcome remains mutable
↓
CORRUPTED snapshots depleted bonus
↓
Whitehat bounty excludes swept value

The contract treats the sweep as final for token accounting but non-final for outcome correction. Those two decisions are incompatible.

Risk

Likelihood:

  • When a pool's active-risk interval passes without anyone interacting with it, riskWindowStart stays 0 and the agreement then settles to CORRUPTED.

  • When the moderator first flags SURVIVED on an out-of-scope judgment and later corrects it to good-faith CORRUPTED and sweepUnclaimedBonus() is called in the gap between those two actions. The call is permissionless, and the sponsor (who owns recoveryAddress) is directly incentivized to make it, since the sweep locks the bonus into their own address before the moderator can redirect it to the whitehat.

Impact:
The whitehat loses its entire bonus allocation: the tokens are irreversibly transferred to recoveryAddress before the corrected CORRUPTED outcome snapshots balances, so they are never part of bountyEntitlement. Principal remains claimable, but bounty funds reach the wrong recipient.

Proof of Concept

// SPDX-License-Identifier: MIT
pragma solidity 0.8.26;
​
import {IAttackRegistry} from "@battlechain/interface/IAttackRegistry.sol";
import {PoolStates} from "src/libraries/PoolStates.sol";
import {BaseConfidencePoolTest} from "test/helpers/BaseConfidencePoolTest.sol";
​
/// @notice Hunt PoCs for the CORRUPTED resolution / bounty accounting path.
contract CorruptedBountyHuntTest is BaseConfidencePoolTest {
// EXPLOIT: 100 principal + 50 bonus. Whitehat ends with 100; 50 stranded at recovery.
function testPoC_SweepUnclaimedBonusThenReflagCorrupted_ShortsWhitehat() external {
uint256 principal = 100 * ONE;
uint256 bonus = 50 * ONE;
​
// Stake + bonus contributed while in a pre-attack state, so the pool
// never observes an active-risk state => riskWindowStart stays 0.
_stake(alice, principal);
_contributeBonus(carol, bonus);
assertEq(pool.riskWindowStart(), 0, "no risk window observed");
​
// Agreement goes terminal-CORRUPTED without the pool ever observing an
// active-risk window (nobody poked during UNDER_ATTACK). This is a
// legitimate on-chain reachable state.
attackRegistry.setAgreementState(IAttackRegistry.ContractState.CORRUPTED);
​
// Step 1: moderator initially judges the breach OUT of this pool's scope
// and flags SURVIVED (valid: CORRUPTED is accepted for SURVIVED).
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.SURVIVED, false, address(0));
assertEq(uint256(pool.outcome()), uint256(PoolStates.Outcome.SURVIVED), "survived flagged");
assertEq(pool.riskWindowStart(), 0, "still no risk window");
​
// Step 2: ANYONE permissionlessly sweeps the "unowed" bonus. Because
// riskWindowStart == 0, _bonusShare pays zero, so the whole bonus is
// deemed sweepable and sent to recovery. This does NOT latch claimsStarted.
uint256 recoveryBefore = token.balanceOf(recovery);
pool.sweepUnclaimedBonus();
uint256 recoveryGotBonus = token.balanceOf(recovery) - recoveryBefore;
assertEq(recoveryGotBonus, bonus, "bonus swept to recovery");
assertEq(pool.claimsStarted(), false, "sweep did NOT latch claimsStarted -> reflag still open");
assertEq(pool.totalBonus(), 0, "totalBonus zeroed by sweep");
​
// Step 3: moderator gets better information: the breach was actually
// IN scope. It corrects the outcome to good-faith CORRUPTED naming the
// whitehat. The re-flag is permitted precisely because no claim latched.
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.CORRUPTED, true, attacker);
​
// The whole pool (principal + bonus = 150) should be owed to the whitehat.
// But bountyEntitlement was computed from the depleted totalBonus.
uint256 entitlement = pool.bountyEntitlement();
assertEq(entitlement, principal, "BUG: entitlement excludes the swept bonus");
assertLt(entitlement, principal + bonus, "BUG: whitehat entitlement short by the bonus");
​
// Step 4: whitehat claims the full remaining entitlement.
uint256 attackerBefore = token.balanceOf(attacker);
vm.prank(attacker);
pool.claimAttackerBounty();
uint256 attackerGot = token.balanceOf(attacker) - attackerBefore;
​
// Whitehat received only the principal; the 50-token bonus is stranded
// at recovery. In a fresh good-faith CORRUPTED they would have received 150.
assertEq(attackerGot, principal, "whitehat received only principal");
assertLt(attackerGot, principal + bonus, "LOSS: whitehat short-changed by the bonus");
​
// Conservation check: bonus was routed to the WRONG party (recovery),
// not the whitehat the good-faith CORRUPTED outcome designates.
assertEq(token.balanceOf(recovery) - recoveryBefore, bonus, "bonus permanently at recovery");
}
​
// -------------------------------------------------------------------------
// CONTROL: a fresh good-faith CORRUPTED (no interim SURVIVED + sweep) pays
// the whitehat the ENTIRE pool including bonus. Confirms the value the above
// sequence loses.
// -------------------------------------------------------------------------
function testPoC_Control_FreshGoodFaithCorruptedPaysWholePool() external {
uint256 principal = 100 * ONE;
uint256 bonus = 50 * ONE;
​
_stake(alice, principal);
_contributeBonus(carol, bonus);
​
attackRegistry.setAgreementState(IAttackRegistry.ContractState.CORRUPTED);
​
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.CORRUPTED, true, attacker);
​
assertEq(pool.bountyEntitlement(), principal + bonus, "fresh: whole pool owed to whitehat");
​
uint256 attackerBefore = token.balanceOf(attacker);
vm.prank(attacker);
pool.claimAttackerBounty();
assertEq(token.balanceOf(attacker) - attackerBefore, principal + bonus, "fresh: whitehat gets whole pool");
}
}
[PASS] testPoC_SweepUnclaimedBonusThenReflagCorrupted_ShortsWhitehat()
[PASS] testPoC_Control_FreshGoodFaithCorruptedPaysWholePool()

Recommended Mitigation

Set the finality latch on any sweep that removes accounted value, while preserving the
donation-only exemption the existing comment protects. The totalBonus decrement already identifies
the accounted-value case exactly:

// sweepUnclaimedBonus, replacing lines 498-505
if (totalEligibleStake == 0 || riskWindowStart == 0) {
-- totalBonus -= amount <= totalBonus ? amount : totalBonus;
++ uint256 dec = amount <= totalBonus ? amount : totalBonus;
++ totalBonus -= dec;
// Removing genuinely-accounted bonus is a reliance event. close the correction window so a
// later good-faith CORRUPTED re-flag cannot snapshot the now-depleted totalBonus. A
// donation-only sweep (dec == 0) still leaves the window open, preserving the anti-grief
// property the original comment protects.
++ if (dec != 0 && !claimsStarted) claimsStarted = true;
}
​
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!