BattleChain Confidence Pools
Cyfrin
FoundrySolidityLayer 2
7.25 ETH
View all submissions
Previous Next
Submission Details
Impact: high
Likelihood: low

Sponsor can front-run the first active risk stake by extending expiry to the timestamp ceiling, causing a practically indefinite lock

Author Revealed upon completion

Root + Impact

Description

The sponsor can update expiry until the first successful stake sets expiryLocked. Deposits during UNDER_ATTACK are intentionally allowed, and that same staking call observes the active risk state and disables withdrawal through riskWindowStart.

A staker can inspect a pool, see a reasonable expiry, and submit the first stake. The sponsor can front-run that transaction with setExpiry(type(uint32).max) or another far future timestamp. The staker's transaction still succeeds, locks the new expiry, records riskWindowStart, and loses the withdrawal escape hatch.

The result is a practically indefinite lock of the first staker's principal unless the moderator resolves the pool or the unexpected new deadline finally arrives. A terminal registry state alone does not release funds: claimSurvived() requires the pool outcome to be set, and claimExpired() remains unavailable until the manipulated expiry.

The same root cause also lets the sponsor resurrect an expired but never-staked pool. setExpiry() only checks expiryLocked, the new minimum lead time, and the uint32 ceiling; it does not require the old expiry to still be in the future. That means a pool that looked expired and unusable can be made stakeable again before the first successful stake. This supports the first staker expiry mutation risk rather than creating a separate issue.

// src/ConfidencePool.sol
function stake(uint256 amount) external nonReentrant whenPoolNotPaused {
if (amount == 0) revert InvalidAmount();
if (amount < minStake) revert BelowMinStake();
if (outcome != PoolStates.Outcome.UNRESOLVED) revert OutcomeAlreadySet();
if (block.timestamp >= expiry) revert StakingClosed();
// @> In UNDER_ATTACK this records riskWindowStart and disables withdrawal.
_assertDepositsAllowed(_observePoolState());
​
if (!expiryLocked) {
// @> The first stake locks whatever expiry the sponsor just set.
expiryLocked = true;
}
...
}
​
function setExpiry(uint256 newExpiry) external onlyOwner {
// @> This only checks whether a stake has already succeeded.
if (expiryLocked) revert ExpiryLocked();
// @> It does not check whether the old expiry has already passed.
if (newExpiry < block.timestamp + _MIN_EXPIRY_LEAD) revert ExpiryTooSoon();
if (newExpiry > type(uint32).max) revert ExpiryTooFar();
​
expiry = uint32(newExpiry);
}
​
function withdraw() external nonReentrant {
IAttackRegistry.ContractState state = _observePoolState();
if (
// @> The first active-risk stake made this nonzero.
riskWindowStart != 0
|| (state != IAttackRegistry.ContractState.NOT_DEPLOYED
&& state != IAttackRegistry.ContractState.NEW_DEPLOYMENT
&& state != IAttackRegistry.ContractState.ATTACK_REQUESTED)
) {
revert WithdrawsDisabled();
}
...
}

Risk

Likelihood:

  • The victim is the first successful staker in the pool, before expiryLocked is set.

  • The pool is already in UNDER_ATTACK, so the first stake records riskWindowStart and disables withdrawal.

Impact:

  • The victim's principal can be locked until an unexpectedly distant deadline, potentially near the uint32 timestamp ceiling, unless the moderator resolves the pool first.

  • The victim cannot recover through withdraw() because the same stake that locked the changed expiry also sealed the risk window.

Proof of Concept

test/unit/ConfidencePool.branches.t.sol:ConfidencePoolBranchesTest.testFirstActiveRiskStakeLocksCurrentExpiry

function testFirstActiveRiskStakeLocksCurrentExpiry() external {
uint256 expectedExpiry = pool.expiry();
uint256 extendedExpiry = type(uint32).max;
​
attackRegistry.setAgreementState(IAttackRegistry.ContractState.UNDER_ATTACK);
pool.setExpiry(extendedExpiry);
​
token.mint(alice, 100 * ONE);
vm.startPrank(alice);
token.approve(address(pool), 100 * ONE);
pool.stake(100 * ONE);
​
assertEq(pool.expiry(), extendedExpiry);
assertTrue(pool.expiryLocked());
assertGt(pool.riskWindowStart(), 0);
​
vm.expectRevert(IConfidencePool.WithdrawsDisabled.selector);
pool.withdraw();
​
vm.warp(expectedExpiry);
vm.expectRevert(IConfidencePool.PoolNotExpired.selector);
pool.claimExpired();
vm.stopPrank();
}
// 1. Pool has no stake and displays expiry = block.timestamp + 30 days.
// 2. Registry state is UNDER_ATTACK.
// 3. Victim sends stake(100e18), expecting the 30-day deadline or relying on a pool that appeared expired.
// 4. Sponsor front-runs with setExpiry(type(uint32).max).
// 5. Victim stake executes and succeeds:
// - expiryLocked becomes true
// - riskWindowStart becomes nonzero
// - withdraw() is disabled
// 6. Even if the registry later reaches PRODUCTION, claimExpired() is unavailable until the far-future expiry.
// 7. Without a moderator flag, the staker remains unable to recover principal until that deadline.

Recommended Mitigation

Make staking check the expiry the staker accepted, or block expiry changes after the agreement has reached active risk.

- function stake(uint256 amount) external nonReentrant whenPoolNotPaused {
+ function stake(uint256 amount, uint32 expectedExpiry) external nonReentrant whenPoolNotPaused {
+ if (expiry != expectedExpiry) revert ExpiryChanged();
...
}

The sponsor should also be prevented from changing expiry after the registry is no longer in a safely withdrawable state.

function setExpiry(uint256 newExpiry) external onlyOwner {
if (expiryLocked) revert ExpiryLocked();
+ IAttackRegistry.ContractState state = _observePoolState();
+ if (
+ state != IAttackRegistry.ContractState.NOT_DEPLOYED
+ && state != IAttackRegistry.ContractState.NEW_DEPLOYMENT
+ && state != IAttackRegistry.ContractState.ATTACK_REQUESTED
+ ) revert ExpiryLocked();
...
}

Support

FAQs

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

Give us feedback!