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

Re-flag snapshots are live reads, not restorations of prior state

Author Revealed upon completion

Severity: Informational
Affected: ConfidencePool.flagOutcome at src/ConfidencePool.sol:357-358

TL;DR

flagOutcome re-reads totalEligibleStake and totalBonus live on every re-flag. If new stakes or bonus contributions occur between flags, the re-flag snapshots different values than the original flag. This behavior is undocumented.

Description

flagOutcome at lines 357-358 reads live pool state on every invocation:

snapshotTotalStaked = totalEligibleStake;
snapshotTotalBonus = totalBonus;

If stake() or contributeBonus() is called between two flagOutcome invocations, the re-flag snapshots include the new stake/bonus. This is correct behavior (the moderator is making a fresh decision with current state), but it means the original flag's snapshots are overwritten without documentation.

Example: Moderator flags SURVIVED with 100 staked + 50 bonus. Sponsor contributes another 50 bonus. Moderator re-flags CORRUPTED. bountyEntitlement = 100 + 100 = 200 instead of 100 + 50 = 150. The whitehat receives more than the original pool.

Scope Eligibility

ConfidencePool.sol is in contest scope. flagOutcome re-flag mechanics are documented in DESIGN.md §4, but the live-read behavior of snapshots on re-flag is not explicitly covered.

Severity Calibration

Informational. No exploitable loss. The moderator is trusted and can re-flag with awareness of changed state. A sponsor contributing bonus after a SURVIVED flag effectively donates to the eventual whitehat (if re-flagged CORRUPTED) or to recoveryAddress (if swept). Self-harm at worst.

Known-Issue Distinction

No prior audit reports flag the undocumented live-read behavior of re-flag snapshots. DESIGN.md §4 and §7 describe the re-flag window and snapshot mechanics but do not address inter-flag state changes.

Risk

Only when new stakes or bonus contributions occur between moderator flags. Requires the moderator to flag, then someone to stake/contribute, then the moderator to re-flag. Low frequency in practice.

No exploitable loss. The moderator is trusted. A sponsor who contributes bonus after a SURVIVED flag and before a CORRUPTED re-flag is voluntarily increasing the whitehat's bounty. This is self-harm, not an attack.

Proof of Concept

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

Moderator flags SURVIVED (100 staked + 50 bonus). Sponsor contributes 50 more bonus. Moderator re-flags CORRUPTED. bountyEntitlement = 100 + 100 = 200 instead of 150.

Recommended Mitigation

Document in DESIGN.md §4 that re-flag snapshots are live reads of current pool state, not restorations of the original flag's snapshots. No code change needed.

Support

FAQs

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

Give us feedback!