The constructor correctly validates the verifier address against address(0), but updateVerifier does not apply the same check, creating an inconsistency in input validation across the contract.
The owner could accidentally brick claim functionality by setting the verifier to address(0), requiring a follow-up updateVerifier call to recover.
Likelihood:
The missing zero address check is absent on every call to updateVerifier, meaning any invocation by the owner without explicit care can silently set the verifier to address(0).
The inconsistency with the constructor makes this easy to overlook during review or future modifications, as the protection exists in one path but not the other.
Impact:
The owner could accidentally brick claim functionality by setting the verifier to address(0), requiring a follow-up updateVerifier call to recover.
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.