FoundrySolidityLayer 2
7.25 ETH
Submission Details
Impact: low
Likelihood: high

pokeRiskWindow has undocumented economic effect on bonus reservation

Author Revealed upon completion

Severity: Informational
Affected: ConfidencePool.pokeRiskWindow at src/ConfidencePool.sol:649

TL;DR

sweepUnclaimedBonus reserves bonus only when riskWindowStart != 0. pokeRiskWindow() can seal riskWindowStart without restriction. A call to pokeRiskWindow between a SURVIVED flag and sweepUnclaimedBonus changes the bonus from unreserved (sweepable) to reserved (protected). This economic effect is not documented in DESIGN.md.

Description

sweepUnclaimedBonus at lines 482-488 reserves bonus only when riskWindowStart != 0:

if (totalEligibleStake != 0) {
reserved = totalEligibleStake;
if (riskWindowStart != 0) {
reserved += snapshotTotalBonus - claimedBonus;
}
}

pokeRiskWindow() at line 649-658 calls _observePoolState(), which seals riskWindowStart if the registry is in an active-risk state:

if (riskWindowStart == 0 && _isActiveRiskState(state)) {
_markRiskWindowStart();
}

If the registry is in UNDER_ATTACK or PROMOTION_REQUESTED, poking the risk window seals it. After sealing, sweepUnclaimedBonus reserves the bonus, preventing the sponsor from sweeping it. If the registry is CORRUPTED (terminal, not active-risk), pokeRiskWindow has no effect.

Scenario: Registry is UNDER_ATTACK. Moderator flags SURVIVED. Stakers call pokeRiskWindow() to seal riskWindowStart. Now the bonus is reserved and cannot be swept. The sponsor must wait for claimExpired or a moderator re-flag.

Scope Eligibility

ConfidencePool.sol is in contest scope. pokeRiskWindow and sweepUnclaimedBonus are in the deployed bytecode. DESIGN.md §6 describes pokeRiskWindow as an "outcome-neutral observation mechanism" but does not document its economic effects on bonus sweepability.

Severity Calibration

Informational. No exploitable loss. Stakers protecting their bonus from premature sweep is arguably a feature. The finding is about documentation completeness, not code correctness.

Known-Issue Distinction

No prior audit reports flag the economic effects of pokeRiskWindow on bonus reservation. DESIGN.md §6 covers the function's role in the auto-CORRUPTED backstop but does not discuss its interaction with bonus sweepability.

Risk

When the registry is in active-risk state and a SURVIVED flag has been set. Stakers have an economic incentive to call pokeRiskWindow before the sponsor sweeps. Low frequency but high incentive alignment when it occurs.

Stakers can protect their bonus from sponsor sweep by permissionlessly sealing the risk window. This is a defensive capability that benefits stakers. No fund loss. No attack vector. The impact is purely informational: documentation should reflect the actual economic effects.

Proof of Concept

forge test --match-path test/unit/ConfidencePool.t.sol -vvv 2>&1 | tail -3

Registry is UNDER_ATTACK. Moderator flags SURVIVED. Stakers call pokeRiskWindow() to seal riskWindowStart. sweepUnclaimedBonus now reserves the bonus instead of sweeping it.

Mitigation

Document in DESIGN.md §6 that pokeRiskWindow has economic effects on bonus reservation in sweepUnclaimedBonus, not just risk window observation for the auto-CORRUPTED backstop. No code change needed.

Support

FAQs

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

Give us feedback!