BattleChain Confidence Pools

Description

The protocol documents the pool's locked scope as a fixed commitment that is isolated from subsequent changes to the underlying agreement. According to the two protocol documentation references:

1. Excerpt from protocol-readme.md Trust Assumptions

   **Scope lock isolates stakers from agreement-level changes.** Once the registry leaves pre-attack staging, sponsor changes to the underlying agreement — adding accounts, **narrowing scope**, swapping the agreement's recovery address — don't alter what this pool covers. Stakers are exposed to exactly what they signed up for at deposit time.

2. Excerpt from DESIGN.md point 8

   **Residual trade-off:** if the sponsor *narrows* the agreement, the pool's locked scope may

   reference accounts no longer in the agreement — but the pool's own commitment to stakers remains

   the binding source of truth.

It is clear that if a scope (after scope lock) of an agreement is narrowed, it does not alter what the pool covers. The pool's scope commitment remains the binding source of truth. Stakers are exposed to exactly what they signed up for at deposit time. This scope changes after a scope-lock is therefore the reason the final outcome for a pool is completely dependent on the moderator's off-chain judgement based on the committed scope and can decouple from the registry outcome as explained in the DESIGN docs point 8. But that is not the case under certain scenarios (Refer to the PoC comments for a more detailed explanation).

This commitment is stored independently in _scopeAccounts and isAccountInScope. However, the scope is only validated against the agreement when it is initially set or replaced. It is not used to determine whether the moderator is authorized to report a later CORRUPTED outcome. Instead, the pool stores one immutable agreement address and _getAgreementState() always returns the state of that original agreement:

flagOutcome() then requires this specific agreement to be CORRUPTED before the trusted moderator can flag the pool as CORRUPTED:

This requirement breaks the fixed-scope commitment when an account is removed from the original agreement and rebound to another agreement. There is one global AttackRegistry, but it maintains independent state for each agreement and a current contract => agreement binding. Consider a pool tied to Agreement A whose locked scope contains Account X:

1. The pool accepts stake and permanently locks Account X in its local scope.

2. Agreement A removes X. This updates A's scope and unregisters X from A in the AttackRegistry, but it does not remove X from the pool's locked scope as intended by the design.

3. X is subsequently added and registered under Agreement B.

4. X is successfully breached while operating under B, causing Agreement B to become CORRUPTED.

5. Agreement A remains nonterminal or reaches PRODUCTION, because the breached account is no longer part of A's scope.

At that point, the moderator cannot resolve the pool as CORRUPTED, despite the breach occurring in a contract that remains inside the pool’s locked commitment. The moderator's attempt to call flagOutcome(CORRUPTED, ...) reverts with InvalidOutcome whenever A is nonterminal or PRODUCTION.

The final pool result depends exclusively on A:

Both results return principal and the applicable bonus to stakers even though the breached account was part of the scope against which they staked.

The reverse disagreement is explicitly supported: if Agreement A becomes CORRUPTED because an account outside the pool's locked subset was breached, the moderator can flag the pool as SURVIVED. The implementation therefore supports an agreement-level corruption being downgraded based on the pool's narrower scope, but it does not support an agreement-level survival or nonterminal state being upgraded to CORRUPTED when an account preserved by the pool's locked scope is breached after rebinding. The moderator is trusted to identify the breach surface, but the original-agreement state gate prevents the moderator from applying that judgement in this direction going against what the protocol promises during commitment.

Impact

Stakers recover their principal and may receive the sponsor-funded bonus despite a successful breach of an account that remains inside the pool's documented locked coverage. A good-faith attacker cannot be named for the pool's attacker bounty, and a bad-faith corruption cannot transfer the pool's stake and bonus to the recovery address. Later agreement-scope changes therefore alter the economic exposure that the protocol promises will remain fixed after scope lock as per the docs.

Likelihood is also High, the AttackRegistry offers functionality for Agreements to change their scope actively while they are under attack.

Root Cause

The pool preserves its committed account list but does not use that commitment as an independent input to resolution. _getAgreementState() reads only the immutable original agreement, and flagOutcome(CORRUPTED, ...) requires that agreement itself to be CORRUPTED. The pool never considers the current agreement binding or terminal state of accounts retained in its locked scope, leaving the trusted moderator unable to report an in-scope breach after one of those accounts is removed and rebound.

Recommended Mitigation

The code-level mitigation is non trivial, the flag outcome and expiry claim logic needs to be changed to account for such scenarios.

I think the most trivial way to counter this would be flagOutcome for a moderator must not be dependent on the linked registry state, and claimExpired should be permisson gated and non-dependent on the linked registry state as well. It should allow a moderator to decide the final outcome after expiry. Since moderator is considered trusted.

Or if this is intended then, which is clear is not from the wording of docs regarding narrowed scope, change the Docs to specify this clearly.

PoC

Setup

Since the test uses all actual contract implementation we need to do the following:

• ConfidencePool is pinned to Solidity 0.8.26.

• The vendored Safe Harbor implementations are pinned to Solidity 0.8.34.

Solidity cannot import contracts pinned to both exact compiler versions into one compilation unit. The test therefore deploys the real Safe Harbor contracts from their Solidity 0.8.34 build artifacts and interacts with them through the vendored interfaces. ConfidencePool compiles normally under Solidity 0.8.26.

foundry.toml was updated to grant the test read-only access to the Safe Harbor build artifacts:

Run

PoC Code

Save the following file as test/poc/LockedScopeRebinding.t.sol:

What the attack does:

• Create two agreements with scope [1, 2] and [3, 4] respectively, register them to their seperate pools with Pool A for Agreement A scope as [2] and Pool B for Agreement B scope as [3, 4].

• Start stake for both pools which lock the scope.

• later Remove 2 from Agreement A and add to B, while pool scopes are locked. Then hack 2 marking Agreement B as corrupted but it allows the pool moderator to mark PoolB as survived because 2 was breached as out-of-commitment scope which is correct. But the opposite, pool A cannot be marked as corrupted even tho the breached account was the only in-commitment-scope for the pool. Going against the protocol docs promise of narrowing scope does not alterr what this pool covers.