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

Unprivileged race permanently drains tracked bonus before moderator's documented re-flag, breaking CORRUPTED accounting

Author Revealed upon completion

Root + Impact

Description

sweepUnclaimedBonus() allows anyone to sweep unowed bonus to recoveryAddress when riskWindowStart == 0, and the contract permits the moderator to re-flag the outcome as long as claimsStarted == false.

Because sweepUnclaimedBonus drains the live totalBonus to 0 when riskWindowStart == 0 but deliberately omits setting claimsStarted, an attacker can front-run a moderator's re-flag to CORRUPTED. This permanently snapshots snapshotTotalBonus as 0, shortchanging the named attacker's bounty, and recovery is impossible because contributeBonus() reverts post-resolution.

// ConfidencesPool.sol
function sweepUnclaimedBonus() external nonReentrant {
// ...
uint256 reserved;
if (totalEligibleStake != 0) {
reserved = totalEligibleStake;
@> if (riskWindowStart != 0) { // Bonus is only reserved if risk was observed
reserved += snapshotTotalBonus - claimedBonus;
}
}
// ...
@> if (totalEligibleStake == 0 || riskWindowStart == 0) {
@> totalBonus -= amount <= totalBonus ? amount : totalBonus; // Tracked bonus is drained to 0
}
​
@> // Missing: claimsStarted is deliberately not set here, leaving the re-flag window open
stakeToken.safeTransfer(recoveryAddress, amount);
// ...
}

Risk

Likelihood:

  • Occurs during the moderator's documented correction window when an agreement goes straight to PRODUCTION without observable active risk (riskWindowStart == 0), causing the bonus to be deemed unowed and sweepable.

  • Occurs when a searcher monitors the mempool for the moderator's re-flag transaction and front-runs it by calling sweepUnclaimedBonus().

Impact:

  • The named attacker's bountyEntitlement is permanently reduced by the swept bonus amount, causing a direct material loss to an identifiable victim.

  • Accounting corruption is permanent because contributeBonus() blocks any attempt to restore totalBonus post-resolution, meaning the protocol cannot manually fix the deficit before the re-flag snapshots the zero balance.

  • DoS survives manual recovery: Even if the owner manually transfers the swept tokens back to the contract to "fix" the balance, bountyEntitlement was already permanently snapshotted at snapshotTotalStaked + 0. The claimAttackerBounty() function strictly pays min(remaining, freeBalance), capping the attacker's payout at the snapshot amount. The attacker is permanently DoS'd from claiming the bonus, and the funds sit in the contract until swept back to recoveryAddress.

Proof of Concept

The following trace demonstrates how an unprivileged attacker exploits the gap between the moderator's initial flag and their corrected re-flag to permanently burn the tracked bonus:

// 1. Agreement goes straight to PRODUCTION (riskWindowStart remains 0).
// Stakers deposit 1000 tokens, and someone calls contributeBonus(100).
// State: totalBonus = 100, totalEligibleStake = 1000.
​
// 2. Moderator flags SURVIVED. claimsStarted remains false.
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.SURVIVED, false, address(0));
// State: snapshotTotalBonus = 100, claimsStarted = false
​
// 3. New evidence surfaces. Moderator submits a tx to re-flag to CORRUPTED.
// Attacker sees this in the mempool and front-runs it by sweeping unclaimed bonus.
pool.sweepUnclaimedBonus();
// Execution:
// - riskWindowStart == 0, so bonus is NOT reserved.
// - 100 tokens sent to recoveryAddress.
// - totalBonus decremented to 0.
// - claimsStarted is STILL false.
​
// 4. Moderator's re-flag tx executes, changing outcome to CORRUPTED (good-faith, naming attacker).
vm.prank(moderator);
pool.flagOutcome(PoolStates.Outcome.CORRUPTED, true, attacker);
// Execution:
// - Re-snapshots: snapshotTotalBonus = totalBonus = 0
// - bountyEntitlement = 1000 + 0 = 1000 (Missing the 100 bonus!)
​
// 5. Attacker claims bounty, permanently missing 100 tokens.
vm.prank(attacker);
pool.claimAttackerBounty();
// Attacker receives 1000 instead of 1100.
// Note: Recovery is impossible because calling contributeBonus() to restore
// totalBonus reverts with OutcomeAlreadySet().
​
// 6. Owner realizes the mistake and manually sends the 100 tokens back to the pool.
stakeToken.transfer(address(pool), 100);
// pool balanceOf is now 100.
// BUT bountyEntitlement is still snapshotted at 1000!
​
// 7. Attacker tries to claim again, or someone else tries to claim for them.
// claimAttackerBounty() calculates payout = min(remaining, freeBalance)
// remaining = bountyEntitlement (1000) - bountyClaimed (1000) = 0.
// The attacker can NEVER claim the returned 100 tokens.
// The funds are permanently stuck until the owner calls claimCorrupted() to sweep them back.

Recommended Mitigation

The fix ensures that while the moderator's re-flag window is open (claimsStarted == false), the unowed tracked totalBonus is treated as reserved and cannot be swept. This preserves the documented 1-wei donation griefing protection (by still allowing true excess dust to be swept) while preventing the accounting race that permanently corrupts the CORRUPTED bounty snapshot.

function sweepUnclaimedBonus() external nonReentrant {
// ...
uint256 reserved;
if (totalEligibleStake != 0) {
reserved = totalEligibleStake;
if (riskWindowStart != 0) {
reserved += snapshotTotalBonus - claimedBonus;
+ } else if (!claimsStarted) {
+ // Protect the unowed tracked bonus from being swept while the
+ // moderator's pre-claim re-flag window is still open.
+ reserved += totalBonus;
}
}
// ...
- if (totalEligibleStake == 0 || riskWindowStart == 0) {
+ if ((totalEligibleStake == 0 || riskWindowStart == 0) && claimsStarted) {
totalBonus -= amount <= totalBonus ? amount : totalBonus;
}
// ...
}
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!