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

Re-flagging to CORRUPTED after bonus sweep permanently shortchanges the whitehat bounty

Author Revealed upon completion

Root + Impact

Description

The moderator may re-flag flagOutcome to correct a mistaken outcome or attacker address until the first value-moving claim sets claimsStarted = true. On good-faith CORRUPTED, bountyEntitlement is set to the full snapshotted pot (snapshotTotalStaked + snapshotTotalBonus), and the whitehat is expected to receive the entire pool per DESIGN 12.

When riskWindowStart == 0, sweepUnclaimedBonus correctly treats the bonus as unowed under SURVIVED and transfers it to recoveryAddress. However, this sweep intentionally does not set claimsStarted, so the moderator correction window stays open even after bonus tokens have left the contract. A subsequent re-flag to good-faith CORRUPTED re-snapshots bountyEntitlement from the depleted totalBonus, permanently shortchanging the whitehat by the already swept bonus amount.

function sweepUnclaimedBonus() external nonReentrant {
// ...
if (totalEligibleStake == 0 || riskWindowStart == 0) {
totalBonus -= amount <= totalBonus ? amount : totalBonus;
}
​
// @> Intentionally does NOT set claimsStarted — bonus value can leave the pool while
// @> flagOutcome re-flag remains allowed, hollowing bountyEntitlement on correction.
stakeToken.safeTransfer(recoveryAddress, amount);
}
​
function flagOutcome(...) external onlyModerator {
// @> Re-flag blocked only when claimsStarted; sweep does not flip this latch.
if (outcome != PoolStates.Outcome.UNRESOLVED && claimsStarted) revert OutcomeAlreadySet();
// ...
bountyEntitlement = willBeGoodFaithCorrupted ? snapshotTotalStaked + snapshotTotalBonus : 0;
}

Risk

Likelihood:

  • A moderator flags SURVIVED on a CORRUPTED registry when the breach is initially judged out-of-scope (riskWindowStart == 0), then corrects to good-faith CORRUPTED after learning the breach was in-scope.

  • Anyone calls sweepUnclaimedBonus between the SURVIVED flag and the corrective re-flag including the sponsor's recoveryAddress beneficiary because the sweep is permissionless and economically rational once bonus is unreserved.

Impact:

  • The whitehat receives bountyEntitlement based on depleted pool state (stake only), not the full pot promised by DESIGN 12.

  • The swept bonus remains permanently with recoveryAddress; the whitehat cannot recover it through claimAttackerBounty.

Proof of Concept

Run:

forge test --match-test test_PoC_sweepThenReflag_shortchangesWhitehat -vv
// test/unit/SweepUnclaimedBonus.t.sol
​
function test_PoC_sweepThenReflag_shortchangesWhitehat() external {
uint256 stakeAmt = 100 * ONE;
uint256 bonusAmt = 50 * ONE;
uint256 fullPot = stakeAmt + bonusAmt;
​
_stake(alice, stakeAmt);
_contributeBonus(carol, bonusAmt);
​
attackRegistry.setAgreementState(IAttackRegistry.ContractState.CORRUPTED);
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.SURVIVED, false, address(0));
​
assertEq(pool.riskWindowStart(), 0);
assertFalse(pool.claimsStarted());
​
pool.sweepUnclaimedBonus();
assertFalse(pool.claimsStarted()); // value moved, latch not set
​
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.CORRUPTED, true, attacker);
​
assertEq(pool.bountyEntitlement(), stakeAmt); // 100, not 150
assertEq(pool.snapshotTotalBonus(), 0);
​
vm.prank(attacker);
pool.claimAttackerBounty();
​
assertEq(token.balanceOf(attacker), stakeAmt); // whitehat: 100
assertEq(token.balanceOf(recovery), bonusAmt); // recovery keeps: 50
}

Recommended Mitigation

Latch claimsStarted when sweepUnclaimedBonus finalizes accounting bonus to recovery (i.e. when totalBonus is decremented). This preserves the donation-dust exception for sweeps that do not touch totalBonus, while closing the re-flag window once economically meaningful bonus value has left the pool.

if (totalEligibleStake == 0 || riskWindowStart == 0) {
totalBonus -= amount <= totalBonus ? amount : totalBonus;
+ if (!claimsStarted) claimsStarted = true;
}
​
// Intentionally does NOT set claimsStarted. A direct-transfer donation of as little as 1
// wei would otherwise let anyone flip the flag post-flagOutcome and block the moderator's
// documented pre-claim re-flag window. Genuine reliance only comes from claim entrypoints.
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.

Appeal created

Hawk 1 Submitter
about 5 hours ago

Support

FAQs

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

Give us feedback!