updateVerifier() allows the owner to swap in a new verifier contract while the hunt is paused. Every call to claim() delegates proof validation to verifier.verify(); if verifier holds the zero address, that call will revert unconditionally, making it impossible for anyone to claim a reward.
Likelihood: Low
Requires the owner to pass address(0) — most likely an accidental copy-paste or scripting error during a verifier upgrade, rather than a deliberate act.
A compromised or phished owner key could use this as a targeted denial-of-service.
Impact: High
All future claim() calls revert with InvalidProof, permanently locking every unclaimed reward inside the contract.
Recovery requires calling updateVerifier() again with a valid address, which is only possible while the contract remains paused — the owner must notice the mistake before unpausing.
If the owner unpauses without noticing, claim() is broken for all users with no on-chain recovery path short of another pause-and-update cycle.
The issue is that `updateVerifier()` allows the owner to replace the verifier with an arbitrary address, including `address(0)`, even though the constructor explicitly treats a zero verifier as invalid and reverts with `InvalidVerifier()` during initial deployment. In other words, the contract establishes at deployment time that a null verifier address is not an acceptable configuration, but then fails to preserve that same invariant when the verifier is later updated through the admin recovery 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.