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

Tracked bonus can leave during the re-flag window, making corrected bounty recipients order-dependent

Author Revealed upon completion

Root + Impact

Description

flagOutcome() allows the immutable pool moderator to correct an already-flagged outcome until the first claim begins. This correction mechanism is intended to preserve the moderator’s ability to fix an incorrect outcome or attacker address before participants rely on the distribution.

sweepUnclaimedBonus() may nevertheless transfer tracked totalBonus to recoveryAddress without setting claimsStarted. Because totalBonus is later used by flagOutcome() when calculating a corrected good-faith CORRUPTED bounty, calling the sweep before the correction changes the final beneficiary of the tracked bonus while leaving the correction valid.

Consequently, two valid transaction orderings from identical pool and registry state produce different recipients:

Correction → claim:
whitehat receives principal + tracked bonus
​
Sweep → correction → claim:
recoveryAddress receives tracked bonus
whitehat receives principal only

Both orderings remain solvent. The issue is that a permissionless value-moving operation can modify tracked economic state during the documented correction window, making the result of a valid moderator correction transaction-order dependent.

function sweepUnclaimedBonus() external nonReentrant {
// The pool determines the amount currently considered unreserved.
uint256 amount = stakeToken.balanceOf(address(this)) - reservedAmount;
​
// @> The sweep can remove value represented by the tracked totalBonus.
// @> This is not limited to untracked donations or rounding excess.
totalBonus -= amount <= totalBonus ? amount : totalBonus;
​
// @> Tokens leave the pool and are transferred to the recovery beneficiary.
stakeToken.safeTransfer(recoveryAddress, amount);
​
// @> claimsStarted is deliberately not set, so the moderator may still
// @> re-flag the outcome after tracked economic value has moved.
}
​
function flagOutcome(
PoolStates.Outcome newOutcome,
bool goodFaith,
address attacker
) external onlyModerator {
if (claimsStarted) revert ClaimsAlreadyStarted();
​
// @> A later correction snapshots the already-reduced tracked bonus.
snapshotTotalStaked = totalEligibleStake;
snapshotTotalBonus = totalBonus;
​
if (
newOutcome == PoolStates.Outcome.CORRUPTED
&& goodFaith
) {
// @> The corrected whitehat bounty now depends on whether the
// @> permissionless sweep executed before this transaction.
bountyEntitlement =
snapshotTotalStaked + snapshotTotalBonus;
}
}

Risk

Likelihood:

  • This occurs when the moderator initially flags SURVIVED, no claimant has started the distribution, and the moderator subsequently corrects the outcome to good-faith CORRUPTED.

  • This occurs when tracked bonus is considered sweepable under the initial outcome, including pools with riskWindowStart == 0, and any account executes sweepUnclaimedBonus() before the moderator’s correction transaction.

Impact:

  • Up to the entire tracked bonus is transferred to recoveryAddress instead of being included in the corrected whitehat bounty.

  • The final recipient of tracked pool value becomes dependent on permissionless transaction ordering during the moderator’s documented correction window.

No staker principal is lost, and the pool remains solvent. The impact is limited to tracked bonus and recipient integrity, making the appropriate severity Low.

Proof of Concept

// SPDX-License-Identifier: MIT
pragma solidity 0.8.26;
​
import {
IAttackRegistry
} from "@battlechain/interface/IAttackRegistry.sol";
import {PoolStates} from "src/libraries/PoolStates.sol";
import {ConfidencePool} from "src/ConfidencePool.sol";
import {
BaseConfidencePoolTest
} from "test/helpers/BaseConfidencePoolTest.sol";
​
contract POC_TrackedBonusReflagOrdering is
BaseConfidencePoolTest
{
function _stakeOn(
ConfidencePool target,
address user,
uint256 amount
) internal {
token.mint(user, amount);
​
vm.startPrank(user);
token.approve(address(target), amount);
target.stake(amount);
vm.stopPrank();
}
​
function _bonusOn(
ConfidencePool target,
address contributor,
uint256 amount
) internal {
token.mint(contributor, amount);
​
vm.startPrank(contributor);
token.approve(address(target), amount);
target.contributeBonus(amount);
vm.stopPrank();
}
​
function test_LOW_sweepBeforeCorrectionChangesTrackedBonusRecipient()
external
{
ConfidencePool correctionFirst = pool;
ConfidencePool sweepFirst = _deployPool();
​
_stakeOn(correctionFirst, alice, 100 * ONE);
_stakeOn(sweepFirst, alice, 100 * ONE);
​
_bonusOn(correctionFirst, carol, 50 * ONE);
_bonusOn(sweepFirst, carol, 50 * ONE);
​
/*
* The Agreement becomes CORRUPTED without either pool observing
* an active-risk interval. Risk observation is lazy, therefore
* riskWindowStart remains zero in both pools.
*/
attackRegistry.setAgreementState(
IAttackRegistry.ContractState.CORRUPTED
);
​
/*
* The moderator initially determines that the Agreement-level
* corruption does not affect the pool's committed scope.
*/
vm.prank(moderator);
correctionFirst.flagOutcome(
PoolStates.Outcome.SURVIVED,
false,
address(0)
);
​
vm.prank(moderator);
sweepFirst.flagOutcome(
PoolStates.Outcome.SURVIVED,
false,
address(0)
);
​
assertEq(correctionFirst.riskWindowStart(), 0);
assertEq(sweepFirst.riskWindowStart(), 0);
assertFalse(correctionFirst.claimsStarted());
assertFalse(sweepFirst.claimsStarted());
​
/*
* Path A:
* The moderator correction executes before the sweep.
*/
vm.prank(moderator);
correctionFirst.flagOutcome(
PoolStates.Outcome.CORRUPTED,
true,
attacker
);
​
assertEq(
correctionFirst.snapshotTotalStaked(),
100 * ONE
);
assertEq(
correctionFirst.snapshotTotalBonus(),
50 * ONE
);
assertEq(
correctionFirst.bountyEntitlement(),
150 * ONE
);
​
uint256 attackerBefore =
token.balanceOf(attacker);
​
vm.prank(attacker);
correctionFirst.claimAttackerBounty();
​
uint256 correctionFirstWhitehat =
token.balanceOf(attacker) - attackerBefore;
​
/*
* Path B:
* An arbitrary account executes the permissionless sweep before
* the same moderator correction.
*/
uint256 recoveryBefore =
token.balanceOf(recovery);
​
vm.prank(bob);
sweepFirst.sweepUnclaimedBonus();
​
uint256 sweepFirstRecovery =
token.balanceOf(recovery) - recoveryBefore;
​
assertEq(
sweepFirstRecovery,
50 * ONE,
"recovery receives tracked bonus"
);
assertEq(
sweepFirst.totalBonus(),
0,
"tracked bonus is removed"
);
assertFalse(
sweepFirst.claimsStarted(),
"value moved without closing correction window"
);
​
/*
* The moderator may still execute the same correction, but the
* bounty snapshot now excludes the swept tracked bonus.
*/
vm.prank(moderator);
sweepFirst.flagOutcome(
PoolStates.Outcome.CORRUPTED,
true,
attacker
);
​
assertEq(
sweepFirst.snapshotTotalStaked(),
100 * ONE
);
assertEq(
sweepFirst.snapshotTotalBonus(),
0
);
assertEq(
sweepFirst.bountyEntitlement(),
100 * ONE
);
​
attackerBefore = token.balanceOf(attacker);
​
vm.prank(attacker);
sweepFirst.claimAttackerBounty();
​
uint256 sweepFirstWhitehat =
token.balanceOf(attacker) - attackerBefore;
​
/*
* Identical initial state, but different recipients depending
* only on the ordering of two valid calls.
*/
assertEq(correctionFirstWhitehat, 150 * ONE);
assertEq(sweepFirstWhitehat, 100 * ONE);
assertEq(sweepFirstRecovery, 50 * ONE);
​
assertEq(
correctionFirstWhitehat,
sweepFirstWhitehat + sweepFirstRecovery,
"same total assets, different beneficiaries"
);
​
emit log_named_uint(
"correction-first whitehat",
correctionFirstWhitehat
);
emit log_named_uint(
"sweep-first whitehat",
sweepFirstWhitehat
);
emit log_named_uint(
"sweep-first recovery",
sweepFirstRecovery
);
}
}

Run the proof of concept with:

forge test \
--match-contract POC_TrackedBonusReflagOrdering \
-vvvv

Observed result:

Suite result: ok. 1 passed; 0 failed; 0 skipped
​
correction-first whitehat: 150e18
sweep-first whitehat: 100e18
sweep-first recovery: 50e18

Recommended Mitigation

Distinguish genuinely untracked excess from tracked totalBonus while the outcome remains correctable.

Before correction finality, only untracked donations or rounding excess should be sweepable without setting claimsStarted. Tracked bonus should remain reserved until the current distribution becomes final through the first claim, an explicit finalization action, or a defined correction deadline.

function sweepUnclaimedBonus() external nonReentrant {
uint256 balance =
stakeToken.balanceOf(address(this));
​
uint256 principalReserve =
_outstandingPrincipalLiability();
​
- uint256 reservedAmount = principalReserve;
+ uint256 reservedAmount = principalReserve;
​
+ // While re-flagging remains possible, tracked bonus is part of the
+ // economic state of a potential corrected outcome and must remain
+ // reserved. Only genuinely untracked excess may be swept.
+ if (!claimsStarted) {
+ reservedAmount += totalBonus;
+ }
​
if (balance <= reservedAmount) {
revert NothingToSweep();
}
​
uint256 amount = balance - reservedAmount;
​
- totalBonus -= amount <= totalBonus
- ? amount
- : totalBonus;
-
stakeToken.safeTransfer(
recoveryAddress,
amount
);
}

Alternatively, introduce an explicit outcome-finalization mechanism or correction deadline. Once correction is no longer possible, tracked bonus that is not reserved for the finalized outcome may safely become sweepable.

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
1 day ago

Support

FAQs

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

Give us feedback!