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

sweepUnclaimedBonus during the re-flag window reduces the good-faith attacker's bounty entitlement

Author Revealed upon completion

Root + Impact

Description

  • The protocol provides the moderator a pre-claim "re-flag window" to correct mistakes in the outcome. During this window, any unreserved bonus can be swept to the sponsor's recoveryAddress via sweepUnclaimedBonus(), which intentionally avoids locking the re-flag window (it doesn't set claimsStarted).

  • Because sweepUnclaimedBonus() decrements totalBonus, if the moderator flags a non-CORRUPTED outcome, the sponsor sweeps the bonus, and the moderator subsequently corrects the outcome to CORRUPTED, the flagOutcome function re-snapshots totalBonus at 0. This irreversibly lowers the attacker's bountyEntitlement, redirecting funds that rightfully belong to the attacker into the sponsor's wallet.

function sweepUnclaimedBonus() external nonReentrant {
// ...
// @> Root cause: totalBonus is decremented here, which understates the bountyEntitlement if a re-flag to CORRUPTED occurs later
if (amount > 0) {
totalBonus -= amount <= totalBonus ? amount : totalBonus;
}
​
// Intentionally does NOT set claimsStarted.
stakeToken.safeTransfer(recoveryAddress, amount);
​

Risk

Likelihood:

  • The moderator flags SURVIVED or EXPIRED (e.g., misjudging an incident as out-of-scope).

  • The sponsor (or any observer) calls sweepUnclaimedBonus() before any claims are made, sweeping the bonus to the recoveryAddress.

  • The moderator realizes the incident was actually an in-scope breach and re-flags to a good-faith CORRUPTED outcome.

Impact:

  • The good-faith whitehat attacker loses the entire bonus portion of their bounty.

  • The sponsor successfully extracts funds from the pool that should have gone to the attacker, breaking the core invariant that the attacker is entitled to the full pool (stake + bonus) in a good-faith scenario.

Proof of Concept

The following sequence demonstrates how the sponsor can extract the bonus while the moderator is investigating an outcome.

// t0: Pool has 100 stake and 50 bonus. Total balance = 150.
// Moderator mistakenly flags SURVIVED (believes breach is out of scope).
pool.flagOutcome(PoolStates.Outcome.SURVIVED, false, address(0));
​
// Sponsor immediately sweeps the unclaimed bonus to recoveryAddress.
// totalBonus drops from 50 to 0. Balance drops to 100.
pool.sweepUnclaimedBonus();
​
// t1: Moderator discovers breach was in-scope, corrects to CORRUPTED.
// flagOutcome re-snapshots: snapshotTotalBonus = totalBonus = 0.
// bountyEntitlement = snapshotTotalStaked (100) + snapshotTotalBonus (0) = 100.
pool.flagOutcome(PoolStates.Outcome.CORRUPTED, true, attacker);
​
// Attacker claims bounty but only receives 100 instead of 150.
// The sponsor effectively extracted 50 tokens from the attacker's rightful bounty.
​

Recommended Mitigation

To resolve this issue without breaking the donation-griefing protection inside sweepUnclaimedBonus (which explicitly avoids setting claimsStarted), flagOutcome should only snapshot the accounting variables on the first flag, preventing the swept bonus from corrupting a later correction.

- remove this code
+ add this code
​
bool public expiryLocked;
+ bool public hasFlagged;
​
// ... Inside flagOutcome()
​
outcome = newOutcome;
goodFaith = goodFaith_;
attacker = attacker_;
- snapshotTotalStaked = totalEligibleStake;
- snapshotTotalBonus = totalBonus;
- snapshotSumStakeTime = sumStakeTime;
- snapshotSumStakeTimeSq = sumStakeTimeSq;
+ if (!hasFlagged) {
+ snapshotTotalStaked = totalEligibleStake;
+ snapshotTotalBonus = totalBonus;
+ snapshotSumStakeTime = sumStakeTime;
+ snapshotSumStakeTimeSq = sumStakeTimeSq;
+ hasFlagged = true;
+ }
corruptedReserve = newOutcome == PoolStates.Outcome.CORRUPTED ? snapshotTotalStaked + snapshotTotalBonus : 0;
​
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!