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

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

Support

FAQs

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

Give us feedback!