Stakers underwrite a specific published scope (the BattleChain accounts the pool insures). DESIGN §8 promises "stakers' exposure is bounded by what they signed up for at deposit time." The pool already locks expiry on the first stake (expiryLocked) for exactly this staker-reliance reason.
Scope, however, locks only on the first observation of a non-pre-attack state, not on the first deposit. Because stake() is allowed throughout NOT_DEPLOYED / NEW_DEPLOYMENT and a deposit in those states does not set scopeLocked, the sponsor can call setPoolScope(...) after a staker has deposited and silently repoint the insured coverage. Exposure is therefore bounded at lock time, not deposit time, contradicting the documented guarantee stakers rely on.
Likelihood:
The sponsor (pool owner) can call setPoolScope at any time while the registry is in NOT_DEPLOYED / NEW_DEPLOYMENT, including after deposits. The trigger is a single owner call and needs no special registry state.
The DESIGN doc itself makes the contradictory "bounded at deposit time" promise, so stakers who deposit during pre-attack staging are actively encouraged to rely on coverage that is not yet fixed.
Impact:
A staker's insured coverage can change after they commit capital: a sponsor can narrow scope (dropping the account the staker cared about) or broaden it to include an account the sponsor expects to be breached (steering the pool toward a CORRUPTED outcome that sweeps the staker's principal to recoveryAddress).
Mitigated, hence Low: the staker can withdraw() for the entire pre-attack window and ScopeUpdated is emitted, so a monitoring staker can exit after a scope change. Harm requires an inattentive staker; there is no atomic trap.
Drop into test/audit/ and run forge test --match-contract ScopeMutableAfterDepositPoC -vv (passes against the unmodified contract).
Lock scope on the first stake, mirroring the existing expiryLocked latch (both protect the same deposit-time reliance):
Trade-off: the sponsor can no longer correct a scope typo after the first deposit, so scope must be finalized before staking opens. Alternatively, if pre-lock scope mutability is intended, correct DESIGN §8 to state that exposure is bounded at scope-lock time (not deposit time) so stakers do not rely on a guarantee the code does not provide.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.
The contest is complete and the rewards are being distributed.