Root + Impact

Description

The protocol permits the moderator to re-flag an outcome before the first claim. The docs explicitly describe this as a mechanism for correcting mistakes:

“flagOutcome may be re-flagged pre-claim so the moderator can fix a typo'd outcome/attacker before any participant locks in the wrong distribution.”

The design further states:

“A claim is the distribution-locking event. Once value has left the contract, a corrective re-flag cannot be honored without breaking balance accounting.”

This is implemented by allowing flagOutcome() to overwrite an existing outcome while claimsStarted remains false:

However, claims are enabled immediately after the outcome is flagged. There is no protected period in which the moderator can exercise the documented correction mechanism.

Consider an incident involving multiple attackers, A and B. The moderator decides that attacker A should receive the good-faith bounty but accidentally submits attacker B’s address.

Because attacker B controls the selected address, B can immediately call claimAttackerBounty():

For a good-faith CORRUPTED outcome, the bounty consists of the complete snapshot of staked principal and contributed bonus. Attacker B can therefore receive the entire pool in one transaction.

Once the claim succeeds, claimsStarted becomes true. The moderator’s attempt to replace attacker B with the intended attacker A then reverts with OutcomeAlreadySet.

The mechanism assumes that the first claimant is exercising a correct outcome. That assumption is invalid when the correction feature is needed: the incorrectly advantaged attacker has a direct incentive to claim immediately and eliminate the correction opportunity.

Risk

Likelihood:

The moderator must select an incorrect but controlled address, such as another participant in a multi-attacker incident. That address must claim before the moderator submits the correction.

Impact:

The mistakenly named attacker receives all staked principal and bonus. The intended attacker receives nothing, and the transfer cannot be corrected or recovered.

Proof of Concept

Add the following test to test/unit/AttackerCorrectionRace.t.sol and run:

The test passes, showing that attacker B drains the complete pool and permanently prevents correction.

Recommended Mitigation

Wire _assertClaimsOpen() into claimSurvived / claimAttackerBounty / claimCorrupted / sweeps. Drop the claimsStarted latch for re-flag gating (or keep it only as a post-window safety check). The fix may look like: