The constructor correctly validates that the verifier address is not the zero address, reverting with InvalidVerifier() if it is. This prevents the contract from being deployed with a broken state.
However, the updateVerifier function does not perform the same validation. The owner can set the verifier to address(0), which will cause every subsequent claim call to revert when it attempts to call verify on the zero address, effectively breaking the treasure hunt.
Likelihood: Low
The owner calls updateVerifier with address(0) by mistake.
The function accepts it silently.
Impact: High
All claim calls revert because verifier.verify(...) targets the zero address, which has no code. No participant can claim any treasure until the owner notices and calls updateVerifier again with a valid address.
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.