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

Whitehat's good-faith bounty can be underpaid because the bonus is swept out of the pool before the final CORRUPTED verdict

Author Revealed upon completion

Root + Impact

Description

  • Normally, when the moderator finally decides a pool is good-faith CORRUPTED, the named whitehat is owed the whole pool every staker's principal plus the entire bonus. The moderator is also allowed to correct a wrong verdict, but only until the first claim/sweep "locks" the outcome (claimstarted).

  • The problem is that sweepUnclaimedBonus() can send the entire accounted bonus out of the pool while the outcome is still SURVIVED, and it deliberately does not set claimStarted . So the correction window stays open even after the bonus is gone. When the moderator then corrects the verdict to good-faith CORRUPTED, flagOutcome re-reads the now-empty totalBonus, so the whitehat's bounty is recalculated as stake only.

  • The bonus is stranded at the recovery address and the whitehat is underpaid.

// sweepUnclaimedBonus() — the bonus leaves the pool but the outcome is NOT locked
if (totalEligibleStake == 0 || riskWindowStart == 0) {
@> totalBonus -= amount <= totalBonus ? amount : totalBonus; // bonus wiped from accounting
}
@> // Intentionally does NOT set claimsStarted -> correction window stays open
stakeToken.safeTransfer(recoveryAddress, amount); // bonus sent to recovery
​
// flagOutcome() — the later correction re-reads the already-drained bonus
snapshotTotalBonus = totalBonus; // now 0
@> bountyEntitlement = willBeGoodFaithCorrupted ? snapshotTotalStaked + snapshotTotalBonus : 0; // stake only
​

Risk

Likelihood:

  • Happens whenever the registry reaches CORRUPTED without any active-risk state being observed on-chain, so when riskWindowStart==0 which is normal, reachable sequence.

  • Happens whenever the moderator first flags SURVIVED and anyone calls the permissionless sweepUn claimedBonus before the moderator corrects the verdict. The sponsor is directly incentivized to trigger this, since the swept bonus lands at their own recovery address.

Impact:

  • The lost bonus is permanently stranded at the sponsor-controlled recovery address, so value is silently moved from the whitehat to the sponsor, breaking the documented "entire pool is the whitehat's bounty" guarantee.

Proof of Concept

function test_whitehatUnderpaidAfterPreVerdictBonusSweep() external {
// Alice stakes 100, sponsor adds a 400 bonus. The full pool (500) should be the bounty.
_stake(alice, 100 * ONE);
_contributeBonus(carol, 400 * ONE);
​
// Registry reaches CORRUPTED with no active-risk ever observed -> riskWindowStart == 0.
attackRegistry.setAgreementState(IAttackRegistry.ContractState.CORRUPTED);
assertEq(pool.riskWindowStart(), 0);
​
// Moderator's honest first call: thinks the breach was out-of-scope, flags SURVIVED.
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.SURVIVED, false, address(0));
​
// Anyone sweeps the "unowed" bonus to recovery. Outcome is NOT locked.
pool.sweepUnclaimedBonus();
assertEq(token.balanceOf(recovery), 400 * ONE);
assertFalse(pool.claimsStarted());
​
// Moderator gets better info: the breach WAS in-scope. Corrects to good-faith CORRUPTED.
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.CORRUPTED, true, attacker);
​
// Bounty is now only the stake (100), not the full pool (500).
assertEq(pool.bountyEntitlement(), 100 * ONE);
​
// Whitehat claims and receives 100 instead of 500. The 400 bonus is stranded at recovery.
vm.prank(attacker);
pool.claimAttackerBounty();
assertEq(token.balanceOf(attacker), 100 * ONE);
}

Recommended Mitigation

once sweepUnclaimedBonus() actually sends the counted bonus out of the pool, mark the outcome as final by setting claimsStarted = true. This closes the correction window at the moment the bonus leaves, so the moderator can no longer switch the verdict to good-faith CORRUPTED and hand the whitehat a bounty the pool can no longer pay
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!