recoveryAddress is the sweep destination for all CORRUPTED-path transfers. DESIGN.md §10 documents it as a pool parameter stakers should verify before depositing; once the registry reaches UNDER_ATTACK, withdraw is permanently disabled and stakers are locked in.
setRecoveryAddress has no resolution-state guard and succeeds in any outcome phase. Both sweep functions read recoveryAddress live at execution time, so a post-flag redirect takes effect immediately — after stakers can no longer exit.
Likelihood:
A sponsor calls setRecoveryAddress between flagOutcome(CORRUPTED, ...) and the sweep — on a sequenced L2 all three fit in one block, making the redirect unobservable before funds move.
The sponsor is a documented trusted role, but their trust surface is pre-deposit parameter setting. A malicious address set from day one would never attract stakers; the harm is specifically the ability to switch after stakers are locked in.
Impact:
The entire pool balance sweeps to the attacker-controlled address in the bad-faith CORRUPTED path — 100% loss of staker principal and bonus.
Stakers have no recourse: claimSurvived and claimExpired both revert on a CORRUPTED outcome.
Save as test/unit/POC_RecoveryAddressRedirect.t.sol and run:
Lock setRecoveryAddress once the outcome is set, mirroring the expiryLocked and scopeLocked patterns already used in the contract. This ensures the sweep destination observed by stakers at deposit time cannot change after they are locked in.
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.