BattleChain Confidence Pools
Cyfrin
FoundrySolidityLayer 2
7.25 ETH
View all submissions
Previous Next
Submission Details
Severity: low
Valid

`scopeLocked` State and `ScopeLocked` Event Rolled Back When `setPoolScope()` Is the First Observer

Author Revealed upon completion

Summary

When setPoolScope() is the first function to observe the registry moving past pre-attack staging, _observePoolState() sets scopeLocked = true and emits ScopeLocked. However, the immediately following if (scopeLocked) revert ScopePostLockImmutable() reverts the entire transaction, rolling back both the state change and the event. The scope is functionally immutable but scopeLocked stays false on-chain and no ScopeLocked event is recorded until another function commits _observePoolState().

Root Cause

function setPoolScope(address[] calldata accounts) external onlyOwner {
_observePoolState(); // scopeLocked = true + ScopeLocked emitted (pending)
if (scopeLocked) revert ScopePostLockImmutable(); // revert rolls EVERYTHING back
_replaceScope(accounts);
}
​
function _observePoolState() internal returns (IAttackRegistry.ContractState state) {
state = _getAgreementState();
if (
!scopeLocked && state != IAttackRegistry.ContractState.NOT_DEPLOYED
&& state != IAttackRegistry.ContractState.NEW_DEPLOYMENT
) {
scopeLocked = true; // rolled back on revert
emit ScopeLocked(block.timestamp); // rolled back on revert
}
}

State write and event are inside the same transaction that reverts -> both disappear.

Code Snppet-
https://github.com/CodeHawks-Contests/2026-07-bc-confidence-pools/blob/58e8ba4ce3f3277866e4926f3140e597f9554a1e/src/ConfidencePool.sol#L636

Impact

setPoolScope() never execute on that case. The state not handled appropriately there. Persists until another function (stake, withdraw, pokeRiskWindow) commits _observePoolState().

Mitigation

Check scope lock before observing, then re-check after:

function setPoolScope(address[] calldata accounts) external onlyOwner {
// Check existing lock state before observing
if (scopeLocked) revert ScopePostLockImmutable();
​
// Observe state — if this sets scopeLocked, tx still commits
_observePoolState();
​
// Re-check in case observation just locked scope
// scopeLocked = true is now committed even if we revert here
if (scopeLocked) revert ScopePostLockImmutable();
​
_replaceScope(accounts);
}
Updates

Lead Judging Commences

inallhonesty Lead Judge 2 days ago
Submission Judgement Published
Validated
Assigned finding tags:

Sponsor can atomically self-trigger ATTACK_REQUESTED and roll back scopeLocked via a reverting setPoolScope/pokeRiskWindow, reopening scope after a DAO rejection

Impact - Low Nothing moves when the scope is swapped, and the state afterward is pre-attack, so any staker who notices can withdraw in full. _replaceScope emits ScopeUpdated, which puts the change on-chain where it can be seen. Real loss needs a restarted attack cycle that breaches one of the substituted accounts with the original staker still in the pool, at which point their principal funds a CORRUPTED payout for coverage they never chose. Likelihood - Medium The step the sponsor cannot force is the moderator rejecting the attack request, though rejections are an ordinary registry operation. The rest they can arrange. Neither observation path can seal the lock in this state, and pausing the pool shuts the deposit routes, leaving only a full-exit withdraw to do it. So reaching the mutable-scope condition is not hard; what holds the severity down is how much has to go wrong afterward for anyone to actually lose money.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!