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

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;
}
// ...
}

Support

FAQs

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

Give us feedback!