Verify is not just a warning badge. The docs position it as a security layer that lets wallets assess whether a request is coming from a matched, mismatched, unknown, or malicious domain before the user approves anything.
The verify-client spec reveals the lower layer: a request’s stringified JSON-RPC payload is hashed into an attestation_id, and the Verify Server maps that identifier to an origin. That means the trust surface sits in origin attestation and registry lookup, not just in front-end copy.
The spec also clarifies the privacy posture: the Verify Server only needs the payload-derived hash and the mapped origin, not plaintext relay contents.
The wallet docs make the UX contract explicit through verifyContext: wallets receive validation, origin, and isScam, then decide whether to proceed, warn, or block.
The four-state model is the analytically reusable part: VALID, UNKNOWN, INVALID, and scam-flagged requests are intentionally separated rather than collapsed into one binary trust bit.
WalletConnect’s docs explicitly say Verify is not bulletproof. That candor matters because it frames Verify as layered risk reduction and registry-backed origin mediation, not as a complete proof of app legitimacy.
The best-practices page elevates Verify into a recommended go-live checklist item for wallets, which is evidence that WalletConnect considers request-origin trust mediation part of production wallet infrastructure.
Specific source signals worth retaining
The attestation_id = sha256(stringify(json_rpc_payload)) line is the most important low-level mechanism clue.
The web docs’ example verifyContext.verified.validation, origin, and isScam fields are the clearest implementation-facing evidence of how Verify actually reaches wallet approval flows.
The docs’ domain-match / unverified / mismatch / threat taxonomy is more valuable than generic anti-phishing marketing because it exposes the actual decision surface wallets inherit.
The disclaimer that Verify is not bulletproof is worth keeping because it prevents over-reading the feature as a cryptographic identity guarantee.
Why this entry belongs in the corpus
It strengthens the wallet-auth-and-consent area with the request-origin trust layer that sits between transport/session protocols and final user approval.
It is a useful comparison class for browser PKI, wallet allow/blocklists, app-access-control screens, and other registry-mediated trust systems.
The reusable insight is that wallet security is not only about signature prompts or session scopes: it also depends on who runs the origin registry, how suspicious domains are classified, and how much override power the wallet gives the user when signals conflict.