Summary

The protocol explicitly allows the moderator to call flagOutcome() multiple times before any claims begin so that mistakes (such as an incorrect attacker address) can be corrected. However, when correcting a good-faith corruption by updating the attacker address, the associated corruptedClaimDeadline is not recalculated.

If the moderator initially flags the wrong attacker, becomes inactive for an extended period, and later corrects the mistake, the intended attacker may receive only a shortened claim window—or no usable claim window at all—despite the protocol permitting re-flagging for this exact purpose.

Finding Details

The documentation in flagOutcome() states:

When a good-faith corruption is flagged, the contract initializes the claim window:

https://github.com/CodeHawks-Contests/2026-07-bc-confidence-pools/blob/main/src/ConfidencePool.sol#L363-L372

Notice that _firstGoodFaithCorruptedAt is only assigned once.

Subsequent calls to flagOutcome() reuse the original timestamp:

The comments also explicitly state:

This behavior creates an edge case where the intended purpose of re-flagging (correcting moderator mistakes) conflicts with the fixed claim window.

Example Scenario

1. The moderator flags a good-faith corruption.

2. The moderator accidentally specifies the wrong attacker address.

3. The legitimate attacker cannot claim because they are not the recorded attacker.

4. The moderator becomes inactive for a significant period.

5. Before any claims occur, the moderator returns and corrects the attacker address using the permitted re-flag mechanism.

6. Since corruptedClaimDeadline is derived from the original timestamp, the deadline may have already expired or have very little time remaining.

7. The legitimate attacker may therefore lose the opportunity to claim the bounty, even though the incorrect address was successfully corrected.

   
   # Impact

   This issue does not affect protocol funds or enable theft.

   However, it can prevent the intended bounty recipient from exercising their claim due to an expired or substantially shortened claim window after a moderator correction.

   As a result:

   • the re-flag mechanism may not fully achieve its documented purpose of correcting moderator mistakes,

   • a legitimate attacker could lose their bounty solely because the correction occurred after the original deadline had largely elapsed,

   • the effective claim period becomes dependent on moderator responsiveness following an initial typo.

     
     # Recommendation

     If the protocol intends re-flagging to fully correct an incorrect attacker assignment, consider refreshing the claim window whenever the attacker address is modified before any claims have started.

     Alternatively, if preserving the original deadline is an intentional design decision to prevent deadline extensions, this limitation should be explicitly documented so that moderators understand that correcting an attacker address does not provide the corrected recipient with a fresh claim window.