walletconnect-verify

WalletConnect Verify API

• Name: WalletConnect Verify API
• URL: https://docs.walletconnect.network/wallet-sdk/features/verify
• Category: wallet-app domain-attestation layer / phishing-warning middleware / wallet-side trust registry interface
• Summary: WalletConnect Verify is a registry-mediated origin-trust layer that sits between a WalletConnect request and final user consent. The important part is not the badge. It is the classification path: who maps a request to an origin, how mismatches get labeled, and whether wallets treat the result as a warning or a stop.
• What it does:
  • Lets wallets retrieve a verifyContext for session proposals and auth requests so the wallet can display domain-risk information before approval
  • Derives an attestationId from the stringified JSON-RPC payload so both sides can reference the same origin attestation without exposing relay message contents to the server
  • Uses a Verify Server to map attestation identifiers to origins, then combines that with WalletConnect registry data and external security-tool inputs
  • Exposes four practically important states: domain match (VALID), unverified (UNKNOWN), mismatch (INVALID), and threat (isScam=true)
  • Returns origin and validation status while leaving final block / allow / warning UX policy to the wallet implementer
• Key claims:
  • The Verify Client spec says the client authenticates and verifies message origin by registering an attestation on a Verify Server, which is the clearest sign that this is a real trust layer rather than decoration
  • The attestation design matters because both sides hash the same decrypted JSON-RPC payload into the same attestationId while the server only needs the identifier-to-origin mapping
  • The web wallet docs make the policy surface explicit: wallets receive validation state, origin, and scam status, then decide whether to proceed, warn, or block
  • Official docs are candid that Verify is not bulletproof and is meant to make impersonation attacks harder rather than impossible
  • WalletConnect’s best-practices guidance treats Verify as a first-class wallet go-live requirement, which is strong evidence that the protocol owner sees origin trust mediation as core infrastructure
• Whitepaper: No standalone WalletConnect Verify whitepaper or litepaper surfaced in this pass. The clearest primary materials were the WalletConnect Verify docs, best-practices guidance, and the verify-client spec excerpt collected in ../whitepapers/walletconnect-verify-primary-sources-2026-05-12.md.
• Sources:
  • https://docs.walletconnect.network/wallet-sdk/features/verify
  • https://docs.walletconnect.network/wallet-sdk/web/verify
  • https://docs.walletconnect.network/wallet-sdk/best-practices
  • https://raw.githubusercontent.com/WalletConnect/walletconnect-specs/main/docs/specs/clients/core/verify/verify-client-api.md

Internal linkages

• Structural parent rail: walletconnect.
• Best upward risk-layer comparisons: blockaid and blowfish.

Control surface

• The power sits in origin mapping, registry policy, scam labeling, and wallet-side handling of UNKNOWN versus INVALID versus explicit scam flags.

• That is still offchain trust mediation even when the downstream action is an onchain signature or payment.

• Treat Verify as request-origin classification infrastructure, not as transport and not as settlement.

• Last reviewed: 2026-06-01 UTC