The protocol is designed to allow a pool sponsor to control and mutate the expiry configuration of a confidence pool only until the first stake deposit lands, at which point the parameter is locked permanently. However, the current implementation of the stake function lacks any validation check or slippage protection concerning the pool's expected expiry time.
A malicious or compromised pool sponsor can monitor the public mempool for a pending first `stake()` transaction. The sponsor can then broadcast a transaction calling `setExpiry(type(uint32).max)` with a higher gas fee to front-run the staker. The sponsor's transaction will modify the expiry to the year 2106 right before the user's deposit executes.
Likelihood:
Reason 1: This attack occurs specifically during the open interval when a pool has been initialized but has not yet accepted its very first user deposit
Reason 2: It is easily operationalized using a standard mempool monitoring bot to track incoming calls targeting the [stake] entrypoint
Impact:
Impact 1: Once the first stake transaction processes, the [expiryLocked] latch turns true, permanently sealing the maxed-out expiry time.
Impact 2: underlying registry state subsequently moves past pre-attack staging into an active-risk phase like [UNDER_ATTACK], the [withdraw()] function is disabled permanently via the[riskWindowStart !=0] latch. The user's principal remains frozen inside the contract for decades with no mechanical escape path.
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.