claimExpired both resolves an unresolved pool after expiry and can pay the calling staker on the PRODUCTION -> SURVIVED auto-resolve path. Once outcome is SURVIVED, the same function rejects every later call with InvalidOutcome remaining stakers must use claimSurvived instead.
A non-staker can finalize SURVIVED first , after which no staker can ever be paid via claimExpired. Integrators that only wire claimExpired after expiry see permanent reverts while funds remain claimable through the twin entrypoint.
Likelihood:
Post-expiry PRODUCTION auto-resolve is a normal path; the first caller (staker or non-staker) sets outcome = SURVIVED.
SDKs / bots that reuse claimExpired for every staker after the first resolve hit InvalidOutcome until they switch entrypoints.
Impact:
Remaining stakers appear stranded under a claimExpired-only integration even though principal + bonus are fully claimable via claimSurvived.
Non-staker finalize makes the wrong-entrypoint trap apply to the entire cohort.
Run:
Or document/SDK-enforce a hard route: after SURVIVED, only claimSurvived, with a dedicated error (e.g. UseClaimSurvived).
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.