Is WalletConnect Safe? Security Analysis for 2025

WalletConnect is pretty secure when it's set up right--and it’s only getting better as the protocol and network continue to develop. However, your level of risk really depends on a few key factors: the usability of your wallet, the permissions of the dapps you’re using, the integrity of the domains, and how you set up your sessions. This security analysis for 2025 dives into what’s actually well-protected, what’s a little more vulnerable, and lays out some solid measures that both startups and enterprises should be putting in place right now. You can check out more details here: (specs.walletconnect.com).

---

Summary (description)

A Fresh Look at WalletConnect Security in 2025

So, let’s dive into what’s new with WalletConnect and how it’s shaping up for security this year. We’ll cover encryption, the WalletConnect Network, the Verify API, and some emerging standards like EIP-5792 and CAIP-358. Plus, we'll talk about the key controls that decision-makers should get from their teams before they go live.

Encryption

Encryption is still a big deal. It keeps your data safe as it travels through the WalletConnect network. With advancements in cryptographic techniques, user information is more protected than ever.

WalletConnect Network

The WalletConnect Network itself has seen some enhancements. By improving its infrastructure, it aims to provide a more reliable and secure experience. This means fewer vulnerabilities and a more seamless connection for users.

Verify API

The Verify API is a game-changer. It lets apps verify user sessions and transactions securely, minimizing the risk of fraud. This means your users can enjoy peace of mind knowing their interactions are being checked and validated.

Emerging Standards: EIP-5792 and CAIP-358

There are also new standards to keep an eye on. EIP-5792 introduces fresh ways to manage wallet addresses, improving how identities are handled across decentralized systems. Meanwhile, CAIP-358 focuses on improving interoperability between various chains, which helps streamline user experiences and increase security.

Controls for Decision-Makers

Now, for those in charge, it’s crucial to have the right controls in place before rolling out any updates. Here are some must-haves:

1. Risk Assessment: Make sure to evaluate any new features for potential risks.
2. User Training: Educate your team on the latest security protocols.
3. Monitoring: Set up systems to monitor for unusual activity.
4. Compliance Checks: Regularly check that you're meeting all necessary compliance standards.

For more in-depth details, check out the official documentation: WalletConnect Network Docs.

With these insights in your toolkit, you're better equipped to navigate the evolving landscape of WalletConnect.

---

TL;DR for decision‑makers

• WalletConnect v2 is all about security, using some pretty modern cryptography techniques like Ed25519/X25519, HKDF, and ChaCha20‑Poly1305 to keep things private. With end-to-end encryption, even the relay can't peek at the messages. Just remember, this secures the transport, but not your app logic. You can read more about it here.
• Looking ahead to 2025, we've got some exciting new controls coming in. These include the Verify API, which features domain attestation plus scam checks; WalletConnect Certified with wallet/app/institution tiers; and a push for payments standardization (wallet_pay/CAIP‑358). If you actually turn these on and enforce them, you can significantly cut down on phishing attempts and those pesky user experience blunders when it comes to signing. Check it out here.
• However, we can't ignore the biggest lingering risks out there. Be on the lookout for social engineering scams, overly broad session permissions, and wallet UX issues (like those confusing EIP‑712 messages). Misconfigurations can also lead to trouble. It’s a good idea to enforce method and chain scoping, domain verification, and follow batch/intents patterns (EIP‑5792) to help keep things secure. More details can be found here.

---

What WalletConnect is--and isn’t--protecting

• We've got end-to-end encrypted transport between your wallet and the app. WalletConnect clients generate a shared symmetric key using X25519 + HKDF, and they encrypt payloads with ChaCha20-Poly1305. The relay service only handles the encrypted data, so it can't see any addresses, transactions, or KYC information. Check it out here: (specs.walletconnect.com)
• There's a cool publish/subscribe relay network that creates “mailboxes” for clients that aren’t online. Messages get cached with a time-to-live and are sent as soon as peers reconnect; they use hashed identifiers for topics. This makes things a lot more reliable, though it doesn’t check the business logic. More details here: (specs.walletconnect.com)
• For client authentication with the relay, we use a JWT linked to a did:key Ed25519 “client_id.” This approach helps prevent abuse and allows for account-level rate limiting and telemetry, all while keeping wallet secrets safe. Learn more here: (specs.walletconnect.com)

What It Doesn’t Protect:

• Natural Disasters: So, if a hurricane or earthquake hits, don’t expect coverage.
• Wear and Tear: Regular aging and depreciation of items? Not covered.
• Intentional Damage: Anything you break on purpose? That’s on you.
• Neglect: If you’re not taking care of your stuff, and it goes south, you won’t get a payout.
• Illegal Activities: Damages that happen while you’re up to no good? Yeah, those won’t be covered.
• Government Actions: If the government seizes your property, tough luck--no coverage there.

Make sure to double-check your policy for any other exclusions!

• Watch out for phishing attempts or malicious dapps trying to fool users into giving approvals or signatures. Be mindful of domain impersonation and wallet UIs that bury important details. These are real risks at the application layer that you need to handle. Make sure to use Verify, enforce strict session scoping, and adopt safer signing patterns. You can learn more about it here.

---

The WalletConnect Network in 2025: architecture and centralization realities

• Since early 2024, production traffic has been flowing through the WalletConnect Network. Right now, it’s running as a permissioned group of service nodes and gateways, managed by the WalletConnect Foundation and operated by Reown (the commercial arm that was formerly WalletConnect Inc.). The goal is to eventually make it open to everyone. (docs.walletconnect.network)
• Service nodes keep encrypted “mailboxes” using a cool system called rendezvous/consistent hashing, while gateways manage traffic flow. The neat part? The relay never gets to see any decrypted content. (docs.walletconnect.network)
• When it comes to decentralization and self-hosting, there were v1 community relays at one point, but the v2 “minimal relay” repo is now archived and isn’t a great choice for production use. The foundation’s plan includes a permissionless relayer program (you’ll stake WCT and get performance incentives) to help cut down on centralization risks. For now, just be ready for a federated setup. (github.com)

Compliance note: As of October 2023, WalletConnect decided to limit its services in Russia, following the guidance from OFAC. This is important info for businesses operating under regulations, and it's also a good reminder that network access is currently determined by policy. (theblock.co)

---

Verified: 2025 security features you should actually turn on

1) Verify API (anti‑phishing domain attestation)

• How it works: The app kicks things off by registering its origin through an enclave. From there, clients hash the message envelope to spin up an attestation ID. Wallets then resolve the origin and check the status, which can be: VALID, INVALID, UNKNOWN, or THREAT. This way, wallets can either warn users or block any sketchy sessions. (specs.walletconnect.com)
• Data Lake integration: This bit checks domains against upstream threat feeds (think Blockaid/Blowfish) and also allows for some manual overrides. It’s your first line of defense against those drainer sites we all want to avoid. (walletconnect.com)
• Caveat: Just a heads up, WalletConnect makes it clear that Verify isn’t “bulletproof.” It’s a tool to raise the cost for attackers, but don’t rely on it as your sole line of defense. (docs.walletconnect.network)

Practical Policy: Make sure that Verify is turned on in any wallet your users depend on. If a session comes through as INVALID or THREAT, just reject it. For sessions marked as UNKNOWN, pop up a message saying “proceed at your own risk.” (docs.walletconnect.network)

2) WalletConnect Certified (wallets, apps, institutions)

• The 2025 expansion isn’t just about certifying wallets; it’s also about verifying dapps and institutions based on standards for user experience, security, and integration (think Verify, batched transactions, payments). Consider this a helpful signal for procurement and allowlisting. (walletconnect.com)

3) Project ID allowlists and rate limits

• To access the network, you'll need to grab a Project ID from the Dashboard. Make sure to set up origin and bundle allowlists to keep your keys safe and prevent any misuse. Just think of the Project ID as a credential! Check out the details here: (docs.walletconnect.network)

---

What the incident data really says

• So far, there hasn’t been any public confirmation of protocol-level breaches since the 2022 Trail of Bits audit for WalletConnect v2. Good news: they found no critical issues! They did identify some medium-to-low level findings, but those have all been fixed, including enhancing replay protection and crypto security. Just a heads up though: there’s still some risk with localStorage exposure in browser wallets if XSS is lurking around--this is something you’ll need to keep an eye on for your app. (walletconnect.com)
• Watch out for the biggest threats: phishing scams and drainers pretending to be WalletConnect. For instance, a phony “WalletConnect” app on Google Play ended up swiping about $70K in 2024. Just a reminder: there’s no official “WalletConnect” wallet app; WalletConnect is just a transport protocol. (thehackernews.com)

---

Permissioning the session: where most teams go wrong

WalletConnect v2 is all about security from the ground up. Here’s how it works: a dapp suggests specific namespaces--think chains, methods, and events--and then the wallet gives the thumbs up to a session that’s limited to those scoped namespaces. You can think of it like API least-privilege. Check out the details here: (specs.walletconnect.com).

• Only ask for the request methods you actually need in your flow. A lot of folks tend to over-request methods like personal_sign and unrestricted eth_signTypedData, especially when a simple SIWE-only flow or just read-only access would do the trick. (specs.walletconnect.com)
• Be specific about your scope chains. If you're working on Base and Ethereum mainnet, there's no need to include testnets or unrelated Layer 2s. The wallet should provide at least one CAIP-10 account for each approved chain. (specs.walletconnect.com)
• Define your session lifetimes. The default session expiry is set to 7 days, but individual requests can timeout anywhere from 5 minutes to 7 days. For workflows that are regulated (like multi-party custody), be smart about using extended expiries and make sure to enforce re-authentication for any high-risk actions. (docs.walletconnect.network)

Example: A Simple, Secure Proposal for an EVM Swap DApp

When it comes to swapping tokens, making sure users feel safe and secure is super important. Here’s a straightforward approach that balances usability with security, perfect for an Ethereum Virtual Machine (EVM) swap DApp.

Key Features to Include

1. User-Friendly Interface
   A clean and intuitive design can really make a difference. Users should easily navigate the app without any hassle.
2. Multi-Chain Support
   Think about integrating various chains to enhance user flexibility. It’s all about giving users the option to swap across different networks!
3. Real-Time Price Data
   Displaying live price updates ensures users know they’re getting a fair deal. This can be achieved through APIs from popular exchanges.
4. Decentralized Control
   Keeping things decentralized means users will have full control over their tokens. This builds trust and aligns with the core values of blockchain.
5. Two-Factor Authentication
   Adding an extra layer of security through 2FA can help protect user accounts. It’s a small step that can prevent big issues down the road.

Security Measures

• Smart Contract Audits
  Regular audits by reputable firms can spot vulnerabilities before they become a problem. It’s a must for maintaining user trust.
• On-Chain Data Verification
  Using oracles to verify transactions can add an extra layer of security. This helps confirm that the data being used is accurate.
• Limit Swap Amounts
  Setting a cap on daily swaps can help mitigate risks and discourage bad actors. It’s all about finding that sweet balance between functionality and safety.

Tech Stack Recommendations

• Frontend: React or Vue.js for a responsive UI.
• Backend: Node.js with Express for server-side logic.
• Blockchain: Ethereum for smart contracts, paired with Web3.js to interact with the blockchain.
• Database: MongoDB or PostgreSQL for user data management.

Conclusion

Building a minimal and secure swap DApp for EVMs isn’t just about tech; it’s about prioritizing user experience and security. By focusing on these essentials, you can create a platform that users will love and trust.

Want to dive deeper? Check out more on [EVM DApps](https://example.com evm-dapps) for inspiration.

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

• Try to steer clear of using eth_sign whenever you can; it’s better to use typed data with clear summaries instead.
• If your process requires approvals, think about using batching with EIP‑5792 (check it out below) to help prevent signature fatigue and ensure smoother, atomic flows. (docs.walletconnect.network)

---

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

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

• You can bundle several on-chain calls, like approve and swap, into one signed request. Wallets have the option to declare atomicity and what they can do on each chain, while apps can check the status as needed. This is already live in production through WalletConnect, and more wallets are getting on board (like Safe, which is up and running now). Check it out here: (docs.walletconnect.network)

Basic 5792 Request (Sketch):

Here’s a quick sketch of what a basic 5792 request looks like:

• Request Type: POST
• Endpoint: /api/v1/request
• Headers:
  • Content-Type: application/json
  • Authorization: Bearer
• Body:

{
  "data": {
    "attribute1": "value1",
    "attribute2": "value2"
  }
}

• Response:

{
  "status": "success",
  "message": "Request processed successfully",
  "data": {
    "id": 12345,
    "attribute1": "value1",
    "attribute2": "value2"
  }
}

Feel free to tweak it as needed!

{
  "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: users can see the complete intent all at once; you get everything done at once; and with fewer popups, there's less chance to fool users between steps. (walletconnect.com)

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

• There's a cool, chain-agnostic JSON-RPC method for “connect-and-pay” that works in just one round trip. Merchants can lay out their options--like asset type, amount, recipient, and expiry--and then wallets choose the best fit before sending back a standard payment result. Keep an eye on this; it’s likely to be a must-have for procurement in 2026. If you handle payments, consider piloting it now! (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"] }
    ]
  }
}

• Quick tip: consider making wallet_pay an optional fallback for your current checkout process. Keep track of which wallets support this feature, and let that info guide your wallet allowlisting choices. Check it out in the WalletConnect documentation.

---

Mobile linking and latency vs. safety

• When it comes to deep linking versus universal links, it's best to go for deep links if you want a consistent user experience. Keep any redirect metadata only for deep-link situations, and steer clear of auto-redirects on QR scans. This helps you avoid those pesky cross-device hijacks. (docs.walletconnect.network)
• As for Link Mode, wallets can use One-Click Auth and session requests through universal links, which means less lag and even works offline! This is particularly awesome for native-to-native interactions, but don’t forget to pair it with Verify and stick to strict namespaces for added security. (docs.walletconnect.network)

---

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

1. Make Sure Verify is on Everywhere

• The wallet should always show the Verify status and block any THREAT right off the bat. Plus, the app needs to register and keep track of its verified domain metadata. Check it out here: (docs.walletconnect.network)

2) Principle of Least Privilege in Namespaces

• Go through each method that’s requested; no wildcards allowed. Make sure to limit access to production chains only. Plus, we need to ask for session re-approval anytime there's a change in the chain or method scope. Check it out here: (specs.walletconnect.com)

3) Session Lifetimes and Expiries

• By default, sessions last for a max of 7 days, and the expiry for each request is set to 5 minutes unless you have a solid reason to extend it (with custody sign-offs, you can stretch that to 7 days). Make sure to implement UI timers and have an auto-cancel state ready. You can find more details in the WalletConnect documentation.

1. Safer signing

• Go for EIP‑712 with easy-to-read summaries, and consider using EIP‑5792 for grouping intents. Let’s make sure to block raw eth_sign unless it’s an emergency. (eips.ethereum.org)

5) Keeping Your Project IDs Clean

• Make sure to use origin/bundle allowlists, switch up those IDs for different environments, and keep an eye out for any unusual usage. Think of the ID as you would an API key. Check out the details here: (docs.walletconnect.network)

1. Transport assumptions

• It's essential not to depend solely on relay secrecy. While the encrypts are pretty robust, always make sure to validate inputs on the server side. Log only hashed topics and non-PII information, and steer clear of saving decrypted payloads in your analytics. (docs.walletconnect.network)

7) Browser Hardening

• Get rid of XSS (use CSP and tight dependencies). The 2022 audit pointed out some risks with localStorage, so it's a good idea to keep sensitive data out of any JS-accessible storage. Instead, try using cookie/secure storage methods whenever you can. (walletconnect.com)

8) Wallet/Vendor Selection

• It's a good idea to go for WalletConnect Certified wallets. Check out the features like Verify, 5792, SIWE, risk scanning, a smooth pending-request user experience, and make sure they support Solana or Bitcoin if that's on your roadmap. You can find more info here.

1. Incident drills

• Get ready for a pre-bake drainer response: this means revoking approvals, putting up surface warnings in the app, and following the takedown playbook. It’s also super important to let users know that there’s no actual “WalletConnect app.” Check out this article for more details: financefeeds.com

---

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

• WalletConnect Inc. has officially changed its name to Reown, and with their January 2025 financing round, they've now raked in about $38 million. The WalletConnect Foundation is in charge of managing the Network and ensuring decentralization. This shift really helps businesses understand the difference between vendor and foundation roles and sets a clear path toward permissionless infrastructure. You can check out more details here.

---

Adoption metrics that matter

• Scale: As of 2024-2025, there are over 30 million users and more than 180 million lifetime connections! Monthly connections and active users have roughly doubled throughout 2024. This shows that the platform is maturing and gaining traction in terms of wallet support density. (walletconnect.com)

---

Worked examples your team can implement this quarter

1. Enable Verify in your wallet (or make it a requirement when you’re making purchases).

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)
})

Make sure your app registers the metadata.url and keeps the domains up to date. Check out the details in the WalletConnect documentation.

2) Add EIP‑5792 to Reduce Approvals from Two Popups to One

• Use wallet_getCapabilities for gate access; if it’s not supported, smoothly revert to the regular flows. Keep an eye on adoption rates to guide wallet allowlists. (docs.walletconnect.network)

1. Setting Up Expiries for Custody Workflows

• You can now set per-request expiry for up to 7 days! Plus, we’ve added pending-request dashboards to keep you in the loop. If a request expires, it’ll automatically return a code 4100 (“Request expired”). Check out the details here: (docs.walletconnect.network)

4) Project ID Allowlist

The Project ID allowlist helps manage access for different projects. Here’s how it works:

• Security: Only projects listed on the allowlist can interact with your resources. This adds an extra layer of security, ensuring that unauthorized projects can’t access sensitive data.
• Management: Keeping track of which Project IDs are allowed can simplify your workflow. It's easier to manage permissions when you have a clearly defined list.

To add a Project ID to the allowlist, you can use the following command:

gcloud projects add-iam-policy-binding your-project-id \
  --member='serviceAccount:service-account-email' \
  --role='roles/your-role'

Make sure to replace your-project-id, service-account-email, and roles/your-role with the specific details of your project.

By thoughtfully curating your allowlist, you can maintain control over who has access to your resources, which is always a good practice.

• In the Dashboard, make sure to limit the origins and bundle IDs. It's a good idea to have distinct IDs for production and staging environments. Also, set up alerts for any usage coming from unfamiliar origins. Check out the details here: (docs.walletconnect.network)

---

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

• Blind message attacks in Web3 authentication (SIWE misuse): Make sure your wallet shows a verified origin (hit that Verify button!) and provides clear summaries. Also, don't let SIWE be used outside your domains. Check it out here: (arxiv.org)
• Drainers via mobile store impersonation: It's super important to educate users. You might want to include this in your app: “WalletConnect is a connection protocol, not a wallet app.” Keep an eye out for any brand abuse and be ready to submit takedown requests quickly. Read more on this here: (thehackernews.com)
• Centralization and policy risk: Until relayers are permissionless, remember that policy controls (like sanctions) can impact how accessible your services are. So, it's a good idea to design a fallback user experience and keep tabs on decentralization proposals (like WCT-staked relayers). You can dive deeper into this here: (governance.walletconnect.network)

---

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

Absolutely--if you're following the 2025 playbook. The protocol has solid transport security that's been independently reviewed, and the Network is evolving and becoming more interconnected. Plus, with the new controls like Verify, Certified, EIP‑5792, and wallet_pay, you can really cut down on the everyday risks like phishing, signature fatigue, and user experience hiccups.

Your security will largely depend on how strictly you implement domain verification, method and chain scoping, expiration dates, and safer signing practices. Don't forget about being choosy when it comes to vendor selection, too. You can check out more about it on walletconnect.com.

---

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

• Make sure to turn on the Verify + block THREAT feature by default and don't forget to register your domains. You can find more info here.
• Keep your requested namespaces to a minimum. It’s best to avoid eth_sign and go for EIP‑712 and EIP‑5792 instead. Check out the details here.
• Aim for a session expiry of 7 days or less, and keep requests set to expire in 30 minutes for retail transactions. If you're dealing with custody, you can allow longer sessions, but make sure you have auditable logs in place. More on this can be found here.
• Set up Project ID allowlists and keep an eye on any unusual activity. And don't forget to separate your production and staging IDs! For more info, check this link.
• For crucial flows, make it mandatory to use WalletConnect Certified wallets or apps. You can learn more here.
• Don’t leave your users in the dark: remind them that “There is no WalletConnect app.” Make sure to link to your list of verified wallets or apps. More on that can be found here.

If you’re looking to roll this out with some safety nets in just weeks instead of months, we’ve got you covered! Our team can whip up reference implementations for Verify, EIP‑5792 batching, and wallet_pay pilots on both EVM and Solana. Plus, we’ll provide a signed threat model for your auditors.