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

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.

Updates

Lead Judging Commences

inallhonesty Lead Judge
8 days ago
inallhonesty Lead Judge 2 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
inallhonesty Lead Judge 2 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

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

Give us feedback!