Root + Impact

Description

A confidence pool permanently commits to a local list of covered accounts. The design explicitly states that if the underlying agreement is later narrowed, the pool's locked scope remains the binding source of truth.

However, pool resolution is always gated by the registry state of the pool's original agreement address:

The moderator's off-chain scope judgment is therefore only usable when the original agreement itself is CORRUPTED. If an account in the pool's locked scope is removed from that agreement and rebound to another agreement, corruption under the new binding agreement cannot be reflected in the pool.

This is reachable through normal upstream functionality.

After an agreement's commitment period expires, its owner may remove accounts:

Removing a BattleChain account invokes the Attack Registry and deletes its binding:

The account can subsequently be registered under another agreement.

The Confidence Pool Factory does not require the underlying agreement's commitment period to cover the pool's expiry. It checks only that expiry is at least 30 days away, that the agreement is valid, and that the creator owns it:

There is no check equivalent to:

An account can therefore be detached and rebound while the pool still holds locked staker funds.

The attack path is:

1. Agreement A1 includes contracts X and Y.

2. A confidence pool is created against A1 with its local scope containing only X.

3. Stakers deposit.

4. A1 enters UNDER_ATTACK, permanently locking the pool scope and disabling withdrawals.

5. After A1's commitment period expires, the sponsor removes X from A1.

6. The Attack Registry deletes the X → A1 binding.

7. X is rebound to agreement A2.

8. X is successfully exploited and A2 becomes CORRUPTED.

9. The remaining contract Y survives, so A1 becomes PRODUCTION.

10. The pool moderator attempts to flag the pool as CORRUPTED because X, which remains in the pool's immutable scope, was the breach surface.

11. The call reverts because the pool reads A1 == PRODUCTION.

12. The pool must instead resolve as SURVIVED, returning principal and bonus to stakers.

The upstream interface expressly warns that membership in an agreement's scope does not prove that it is the account's binding agreement because multiple agreements may contain the same account.

The project design nevertheless states that a removed account remains covered by the pool's locked local commitment.

The implementation cannot enforce that commitment because it consults only the original agreement's registry state. :contentReference[oaicite:3]{index=3}

Risk

A sponsor can make an in-scope corruption unreportable by moving the covered account to another agreement before the pool expires.

The consequences are:

• stakers recover principal despite an in-scope contract being corrupted;

• stakers may also receive the complete bonus pool;

• the good-faith attacker cannot receive the pool bounty;

• the recovery address cannot receive principal under a bad-faith corruption;

• the moderator cannot correct the outcome because flagOutcome(CORRUPTED) always reverts;

• the mechanical expiry path also reads only the stale original agreement and resolves SURVIVED or EXPIRED.

The maximum incorrectly distributed value is the entire pool balance: all staked principal plus all contributed bonus.

The impact is High because the protocol's principal-at-risk mechanism can be bypassed completely.

The likelihood is Medium because no DAO compromise or registry corruption is required. The sponsor uses normal agreement-owner operations after the agreement commitment period expires. Upstream account removal deletes the existing Attack Registry binding.

Proof of Concept

Add the following test helper:

Add the following test to a contract inheriting BaseConfidencePoolTest:

Recommended Mitigation

The simplest robust mitigation is to ensure that the underlying agreement cannot remove any covered account during the pool's complete term.

At pool creation, require the agreement commitment period to cover the pool expiry:

The same condition must be enforced in setExpiry():

Additionally, when the scope locks, verify that every locally scoped account is currently bound to the pool's agreement:

Checking only at pool creation is insufficient because accounts may still be removed later. The agreement commitment must remain active through at least expiry.