Root + Impact

Description

• Normal Behavior

  The protocol intentionally allows the moderator to re-flag a pool outcome before any participant has started claiming. This allows the moderator to fix an incorrect outcome or attacker address before funds move. The design document explicitly states that flagOutcome may be re-flagged before the first claim.

  Finality is tied to claimsStarted, not to the first OutcomeFlagged event. The design document describes claimsStarted as a value-movement finality latch.

  
  

• Specific Issue

  The OutcomeFlagged event does not indicate whether the emitted outcome is final or still re-flaggable. The event only includes:

  event OutcomeFlagged(address indexed moderator, PoolStates.Outcome outcome, bool goodFaith, address attacker);

Because flagOutcome() emits the same event for the first flag and for later re-flags, an off-chain consumer that treats the first event as the final settlement result can become permanently wrong unless it explicitly tracks all later OutcomeFlagged events and the claimsStarted finality condition.

The on-chain logic is not broken. The issue is that the event semantics are easy to misinterpret as final settlement when the protocol’s actual finality condition is separate.

The re-flag gate is based on claimsStarted, not on whether an outcome was already emitted.

The outcome fields are overwritten on every allowed flagOutcome() call.

The same OutcomeFlagged event is emitted each time.

The event interface itself has no isFinal, version, supersedes, or claimsStarted field.

Risk

Likelihood:

Likelihood: Medium

Reason 1 — Re-flagging is an intended moderator workflow

The design document explicitly permits re-flagging before the first claim so the moderator can fix a typo or incorrect result.

This is not an edge case or exploit-only path. It is a supported correction flow.

Reason 2 — The emitted event name looks settlement-like

The event is named OutcomeFlagged, and it includes the pool outcome, good-faith flag, and attacker address.

An off-chain system can reasonably treat this as the settlement signal unless it also understands the separate finality condition.

Reason 3 — Finality is not encoded in the event

The finality latch is claimsStarted, but OutcomeFlagged does not include claimsStarted or any equivalent finality field.

Impact:

• Impact: Medium / High integration risk

  Impact 1 — Incorrect settlement state in indexers/frontends

  An indexer that stores the first OutcomeFlagged event as final may show SURVIVED even after the moderator re-flags to CORRUPTED, or vice versa.

  The existing test suite proves that the outcome can move from SURVIVED to CORRUPTED before claims start.

  Impact 2 — Incorrect claim guidance

  A frontend may tell stakers to call claimSurvived() after observing a first SURVIVED event. If the moderator later re-flags to CORRUPTED before claims start, the pool no longer allows survived claims and funds follow the corrupted path instead.

  The code overwrites outcome, and claim functions depend on the current stored outcome.

  Impact 3 — Incorrect attacker/bounty indexing

  In good-faith corrupted cases, the moderator can correct the attacker address before the bounty is claimed. Existing tests show the attacker address can be changed from a wrong address to a right address before claim finality.

  An off-chain system that indexes the first attacker address as final can notify the wrong attacker or misrepresent bounty entitlement.

  Impact 4 — Incorrect risk dashboards / accounting

  Protocols, dashboards, or automated reporting tools that aggregate pool outcomes can count a pool under the wrong final result if they do not process later re-flags or check finality.

  
  

Proof of Concept

The existing test suite already contains a direct PoC for this behavior.

PoC 1 — Outcome changes from SURVIVED to CORRUPTED before claim finality

This test proves:

1. The first flagOutcome() succeeds with SURVIVED.

2. No claim has started after the first flag.

3. The moderator can then re-flag to CORRUPTED.

4. The final on-chain outcome() is now CORRUPTED, not SURVIVED.

PoC 2 — Attacker address changes before claim finality

This test proves:

1. A good-faith corrupted outcome can first be emitted with one attacker address.

2. Before the attacker claims, the moderator can re-flag with a different attacker address.

3. The current stored attacker is the second address, not the first.

Recommended Mitigation

Because the on-chain re-flag behavior is intentional, the goal should not necessarily be to remove re-flagging. The safer mitigation is to make event-level finality explicit.

Option A — Emit a separate finality event when claims start

Emit a dedicated OutcomeFinalized event the first time claimsStarted becomes true.

This should be added anywhere claimsStarted is first flipped to true, including:

• claimSurvived()

• claimCorrupted()

• claimAttackerBounty() when payout succeeds

• sweepUnclaimedCorrupted()

• claimExpired() mechanical resolution paths

Relevant current claimsStarted writes exist in multiple paths.

Option B — Include finality metadata in OutcomeFlagged

Add a monotonic outcomeVersion and emit it with every flag.

This helps indexers detect superseded outcomes.

Option C — Rename the event or add NatSpec warning

If storage/event changes are undesirable, add explicit interface-level warning documentation.

This is the lowest-risk mitigation but relies on integrators reading the interface comments.

Medium

This is best classified as Medium integration / UX-security risk.

The on-chain behavior is intentional and documented, so this is not an on-chain accounting or access-control bug. However, the emitted event can easily be consumed as a final settlement signal despite not being final until the claimsStarted latch is set.