Is WalletConnect Safe? Security Analysis for 2025

WalletConnect is safe when implemented correctly—and getting safer as the protocol and network evolve—but your risk hinges on wallet UX, dapp permissions, domain integrity, and how you configure sessions. This 2025 security analysis explains what’s truly protected, what isn’t, and the concrete controls startups and enterprises should adopt right now. (specs.walletconnect.com)

Summary (description)

An expert, up-to-date security review of WalletConnect in 2025: how encryption, the WalletConnect Network, Verify API, and new standards like EIP-5792 and CAIP-358 affect risk—and the exact controls decision-makers should require from their teams before rollout. (docs.walletconnect.network)

TL;DR for decision‑makers

WalletConnect v2 uses modern cryptography (Ed25519/X25519 + HKDF + ChaCha20‑Poly1305) with end‑to‑end encryption; the relay cannot read messages. That protects the transport—not your app logic. (specs.walletconnect.com)
New 2025 controls: Verify API (domain attestation + scam checks), WalletConnect Certified (wallet/app/institution tiers), and payments standardization (wallet_pay/CAIP‑358) meaningfully reduce phishing and UX-driven signing mistakes—if you enable and enforce them. (docs.walletconnect.network)
Biggest residual risks are social‑engineering drainers, over‑broad session permissions, weak wallet UX (e.g., ambiguous EIP‑712 messages), and misconfigurations. Enforce method/chain scoping, domain verification, and batch/intents patterns (EIP‑5792). (specs.walletconnect.com)

What WalletConnect is—and isn’t—protecting

End‑to‑end encrypted transport between wallet and app. WalletConnect clients derive a shared symmetric key via X25519 + HKDF and encrypt payloads with ChaCha20‑Poly1305. The relay service only routes ciphertext and can’t see addresses, transactions, or KYC data. (specs.walletconnect.com)
A publish/subscribe relay network with “mailboxes” for offline clients. Messages are cached with TTL and delivered once peers reconnect; topics are hashed identifiers. This boosts reliability but doesn’t validate business logic. (specs.walletconnect.com)
Client authentication to the relay via a JWT bound to a did:key Ed25519 “client_id.” This deters abuse and enables account‑level rate limiting/telemetry without exposing wallet secrets. (specs.walletconnect.com)

What it does not protect:

Phishing or malicious dapps tricking users into approvals/signatures; domain impersonation; or wallet UIs that hide critical details. These are application‑layer risks you must mitigate with Verify, strict session scoping, and safer signing patterns. (docs.walletconnect.network)

The WalletConnect Network in 2025: architecture and centralization realities

Production traffic has run on the WalletConnect Network since early 2024. The network currently operates as a permissioned federation of service nodes and gateways, stewarded by the WalletConnect Foundation (with operations by Reown, the commercial entity formerly WalletConnect Inc.), with a roadmap toward permissionless participation. (docs.walletconnect.network)
Service nodes persist encrypted “mailboxes” using rendezvous/consistent hashing; gateways route traffic; the relay never sees decrypted content. (docs.walletconnect.network)
Decentralization and self‑hosting: v1 community relays existed, but the v2 “minimal relay” repo is archived and not recommended for production. The foundation’s roadmap includes a permissionless relayer program (staking WCT, performance incentives) to reduce centralization risk. Until then, plan for a federated dependency. (github.com)

Compliance note: in Oct 2023 WalletConnect restricted service in Russia following OFAC guidance—useful context for regulated enterprises, but also a reminder that network access is currently policy‑gated. (theblock.co)

Verified: 2025 security features you should actually turn on

1) Verify API (anti‑phishing domain attestation)

How it works: the app registers its origin via an enclave; clients hash the message envelope to create an attestation id; wallets resolve the origin and flag status: VALID, INVALID, UNKNOWN, THREAT. Wallets can warn or block risky sessions. (specs.walletconnect.com)
Data Lake integration: checks domains against upstream threat feeds (e.g., Blockaid/Blowfish) plus manual overrides. This is the first‑line control against drainer sites. (walletconnect.com)
Caveat: WalletConnect explicitly states Verify is “not bulletproof”—use it to raise attacker cost, not as your only defense. (docs.walletconnect.network)

Practical policy: Require Verify to be enabled in any wallet your users rely on; reject sessions with INVALID or THREAT; show “proceed at your own risk” for UNKNOWN. (docs.walletconnect.network)

2) WalletConnect Certified (wallets, apps, institutions)

2025 expansion certifies not just wallets but also dapps and institutions on UX, security, and integration standards (e.g., Verify, batched transactions, payments). Use this as a procurement and allowlisting signal. (walletconnect.com)

3) Project ID allowlists and rate limits

Require a Project ID via the Dashboard to use the network; configure origin/bundle allowlists to prevent key leakage and abuse. Treat the Project ID like a credential. (docs.walletconnect.network)

What the incident data really says

No protocol‑level breach has been publicly confirmed since the 2022 Trail of Bits audit of WalletConnect v2 (which found no critical issues; medium‑to‑info findings were remediated, including replay‑protection and crypto hardening). Residual risk: localStorage exposure in browser wallets if XSS is present—this is on your app to prevent. (walletconnect.com)
The most costly events are phishing/drainers masquerading as WalletConnect (e.g., a fake “WalletConnect” app on Google Play stole ~$70K in 2024). Remember: there is no official “WalletConnect” wallet app; WalletConnect is a transport protocol. (thehackernews.com)

Permissioning the session: where most teams go wrong

WalletConnect v2 forces a security mindset by design: a dapp proposes namespaces (chains + methods + events); the wallet approves a scoped session namespace. Treat this like API least‑privilege. (specs.walletconnect.com)

Only request methods you actually need for that flow. Commonly over‑requested methods include personal_sign and unrestricted eth_signTypedData when a SIWE‑only flow or read‑only access suffices. (specs.walletconnect.com)
Scope chains precisely. If you operate on Base and Ethereum mainnet, don’t include testnets or unrelated L2s. The wallet must supply at least one CAIP‑10 account per approved chain. (specs.walletconnect.com)
Set session lifetimes. Default session expiry is 7 days; explicit request/timeouts on individual requests are 5 minutes to 7 days. For regulated workflows (e.g., multi‑party custody), use extended expiries judiciously and enforce re‑auth on high‑risk actions. (docs.walletconnect.network)

Example: a minimal, safer proposal for an EVM swap dapp

{
  "requiredNamespaces": {
    "eip155": {
      "chains": ["eip155:1", "eip155:8453"],
      "methods": ["eth_sendTransaction", "eth_signTypedData"],
      "events": ["accountsChanged", "chainChanged"]
    }
  },
  "optionalNamespaces": {}
}

Avoid eth_sign where possible; prefer typed data with clear summaries.
If your flow needs approvals, consider batching with EIP‑5792 (below) to avoid signature fatigue and non‑atomic flows. (docs.walletconnect.network)

2025’s biggest uplift: intents, batching, and payments

EIP‑5792 (wallet_sendCalls): batch flows into one clear approval

Package multiple on‑chain calls (e.g., approve + swap) into one signed request; wallets can declare atomicity and capabilities per chain; apps can poll status. In production today via WalletConnect, with growing wallet support (e.g., Safe live now). (docs.walletconnect.network)

Basic 5792 request (sketch):

{
  "method": "wallet_sendCalls",
  "params": {
    "from": "0xYourUser",
    "chainId": "0x1",
    "atomicRequired": true,
    "calls": [
      {"to": "0xUSDC", "data": "0x095ea7b3...", "value": "0x0"},
      {"to": "0xRouter", "data": "0x...swapExactTokensForETH", "value": "0x0"}
    ]
  }
}

Why it’s safer: the user sees the full intent, once; you get all‑or‑nothing execution; fewer popups means fewer chances to trick users between steps. (walletconnect.com)

CAIP‑358 wallet_pay (draft): standardizing wallet‑native payments

A chain‑agnostic JSON‑RPC method for “connect‑and‑pay” in one round trip. Merchants specify options (asset, amount, recipient, expiry); wallets pick the best match and return a canonical pay result. Expect this to become a procurement checkbox in 2026; pilot now if you handle payments. (chainagnostic.org)

wallet_pay request (sketch):

{
  "method": "wallet_pay",
  "params": {
    "version": 1,
    "orderId": "c5c9c1a0-...",
    "expiry": 1734300000,
    "paymentOptions": [
      { "asset": "eip155:8453/erc20:0xA0b8...", "amount": "1000000", "recipient": "eip155:8453:0xMerchant", "types": ["transfer"] },
      { "asset": "eip155:1/erc20:0xA0b8...", "amount": "1000000", "recipient": "eip155:1:0xMerchant", "types": ["transfer"] }
    ]
  }
}

Policy tip: make wallet_pay optional fallback to your current checkout; log which wallets support it and use this in wallet allowlisting decisions. (docs.walletconnect.network)

Mobile linking and latency vs. safety

Deep linking vs. universal links: prefer deep links for predictable UX; restrict redirect metadata to deep‑link cases; avoid auto‑redirects on QR scans to prevent cross‑device hijacks. (docs.walletconnect.network)
Link Mode: wallets can transport One‑Click Auth and session requests over universal links (reduced latency, even offline). Great for native‑to‑native flows; still pair it with Verify and strict namespaces. (docs.walletconnect.network)

Practical safeguards to require in your build (copy/paste into your RFP)

Enforce Verify everywhere

Wallet must display Verify status and block THREAT by default; the app must register and maintain its verified domain metadata. (docs.walletconnect.network)

Principle of least privilege in namespaces

Review every requested method; forbid wildcards; restrict to production chains; require session re‑approval when chain/method scope changes. (specs.walletconnect.com)

Session lifetimes and expiries

Default 7‑day session max; per‑request expiry 5 minutes unless business‑justified (custody sign‑offs up to 7 days). Implement UI timers and auto‑cancel state. (docs.walletconnect.network)

Safer signing

Prefer EIP‑712 with human‑readable summaries; adopt EIP‑5792 for batched intents; block raw eth_sign unless break‑glass. (eips.ethereum.org)

Project ID hygiene

Use origin/bundle allowlists; rotate IDs for environments; monitor usage anomalies. Treat the ID like an API key. (docs.walletconnect.network)

Transport assumptions

Don’t rely on relay secrecy: encrypts are strong, but validate inputs server‑side; log only hashed topics/non‑PII; never store decrypted payloads in analytics. (docs.walletconnect.network)

Browser hardening

Eliminate XSS (CSP, tight dependencies). The 2022 audit flagged localStorage risk; keep secrets out of JS‑accessible storage and adopt cookie/secure storage patterns where applicable. (walletconnect.com)

Wallet/vendor selection

Prefer WalletConnect Certified wallets; verify features: Verify, 5792, SIWE, risk scanning, pending‑request UX, and support for Solana/Bitcoin if your roadmap requires it. (walletconnect.com)

Incident drills

Pre‑bake drainer response (revoke approvals, surface warnings in‑app, takedown playbook). Educate users that there is no “WalletConnect app.” (financefeeds.com)

Governance, rebrand, and who runs what (why it matters)

WalletConnect Inc. rebranded to Reown (Jan 2025 financing brings total raise to ~$38M). The WalletConnect Foundation stewards the Network and decentralization. For enterprises, this clarifies vendor vs. foundation roles and the path to permissionless infrastructure. (businesswire.com)

Adoption metrics that matter

Scale: 30M+ users and 180M+ lifetime connections as of 2024–2025; monthly connections and active users roughly doubled through 2024. Use this as a signal of maturity and wallet support density. (walletconnect.com)

Worked examples your team can implement this quarter

Turn on Verify in your wallet (or require it in procurement)

walletKit.on("auth_request", (req) => {
  const v = req.verifyContext.verified
  if (v.isScam || v.validation === "INVALID") {
    return showBlock("This site is unsafe.")
  }
  if (v.validation === "UNKNOWN") {
    return showWarn("Unverified site. Proceed?")
  }
  proceed(req)
})

Requires your app to register metadata.url and keep domains current. (docs.walletconnect.network)

Add EIP‑5792 to cut approvals from two popups to one

Gate with wallet_getCapabilities; if unsupported, gracefully fall back to standard flows. Track adoption to inform wallet allowlists. (docs.walletconnect.network)

Configure expiries for custody workflows

Set per‑request expiry up to 7 days; surface pending‑request dashboards; auto‑expire and return code 4100 (“Request expired”). (docs.walletconnect.network)

Project ID allowlist

In Dashboard, restrict origins/bundle IDs; keep separate IDs for prod/staging; alert on usage from unknown origins. (docs.walletconnect.network)

Emerging risks to keep on your radar (and what to do)

Blind message attacks in Web3 authentication (SIWE misuse): ensure the wallet displays verified origin (Verify) and clear summaries; disallow SIWE outside your domains. (arxiv.org)
Drainers via mobile store impersonation: educate users and add in‑app copy (“WalletConnect is a connection protocol, not a wallet app”). Monitor for brand abuse and submit takedowns quickly. (thehackernews.com)
Centralization and policy risk: until relayers are permissionless, assume policy controls (e.g., sanctions) can affect reachability; design fallback UX, and track decentralization proposals (WCT‑staked relayers). (governance.walletconnect.network)

Verdict: Is WalletConnect safe for startups and enterprises in 2025?

Yes—if you adopt the 2025 playbook. The protocol’s transport security is strong and independently assessed; the Network is maturing and federating; and new controls (Verify, Certified, EIP‑5792, wallet_pay) materially reduce the real‑world risks (phishing, signature fatigue, UX confusion). Your security posture will be determined by how rigorously you enforce domain verification, method/chain scoping, expiries, and safer signing patterns—plus vendor selection discipline. (walletconnect.com)

7Block Labs’ implementation checklist (cut‑paste into Jira)

Enable Verify + block THREAT by default; register your domains. (docs.walletconnect.network)
Reduce requested namespaces to minimum; forbid eth_sign; prefer EIP‑712 and EIP‑5792. (specs.walletconnect.com)
Set session expiry to ≤7 days; requests expire ≤30 minutes in retail flows, longer only for custody with auditable logs. (docs.walletconnect.network)
Configure Project ID allowlists and monitor anomalies; separate prod/stage IDs. (docs.walletconnect.network)
Require WalletConnect Certified wallets/apps for critical flows. (walletconnect.com)
Educate users: “There is no WalletConnect app.” Link to your verified wallet/app list. (financefeeds.com)

If you want this deployed with guardrails in weeks, not months, our team can deliver reference implementations for Verify, EIP‑5792 batching, and wallet_pay pilots across EVM and Solana, plus a signed threat model for your auditors.