WalletConnect

What Is WalletConnect?

WalletConnect is a protocol that bridges the gap between cryptocurrency wallets and decentralized applications (dApps). A user scans a QR code or taps a deep link, approves the connection in their wallet, and can then sign transactions or messages requested by the dApp. The wallet's private keys never leave the device.

Founded by Pedro Gomes in 2018 after receiving an Ethereum Foundation grant, WalletConnect emerged to solve a basic usability problem: how do you connect a mobile wallet to a desktop dApp? Browser extension wallets like MetaMask solved the desktop case by injecting a provider object into the page, but this approach did not work for mobile-only wallets or cross-device workflows. WalletConnect introduced a relay-based model that works across platforms, devices, and wallet implementations.

As of 2025, the WalletConnect network supports over 700 wallets and 85,000+ integrated applications, facilitating more than 55 million unique user connections per year. The parent company rebranded to Reown in 2024, while the WalletConnect protocol itself continues under the stewardship of the WalletConnect Foundation.

How It Works

WalletConnect uses relay servers as a transport layer for encrypted messages between two parties: a dApp (the proposer) and a wallet (the responder). The protocol separates into two phases: pairing and session management.

Pairing

The connection begins when the dApp generates a pairing URI following the EIP-1328 standard. This URI contains a topic identifier, a symmetric encryption key, the relay protocol to use, and an expiry timestamp (typically five minutes). The URI is presented as either a QR code (for desktop-to-mobile connections) or a deep link (for mobile-to-mobile).

wc:7f6e504bfad60b485450578e05678ed3e8e8c4751d3c6160be17160d63ec90f9@2
  ?symKey=587d5484ce2a2a6ee3ba1962fdd7e8588e06200c46823bd18fbd67def96ad303
  &methods=[wc_sessionPropose],[wc_authRequest]
  &relay-protocol=irn
  &expiryTimestamp=1705667684

When the wallet scans or opens this URI, both sides derive the same encryption keys from the symmetric key parameter. All subsequent messages are encrypted with AES-256-CBC before being sent through the relay. The relay forwards ciphertext without the ability to decrypt it.

Session Establishment

After pairing, the dApp proposes a session specifying which blockchain networks, JSON-RPC methods, and event types it needs access to. These are organized into namespaces:

// Example session proposal namespaces
{
  "requiredNamespaces": {
    "eip155": {
      "chains": ["eip155:1", "eip155:10"],
      "methods": ["eth_sendTransaction", "personal_sign"],
      "events": ["chainChanged", "accountsChanged"]
    }
  },
  "optionalNamespaces": {
    "solana": {
      "chains": ["solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ"],
      "methods": ["solana_signTransaction"],
      "events": []
    }
  }
}

The wallet displays the dApp's metadata (name, URL, icon) and the requested permissions to the user. If the user approves, the wallet returns the session response with the accounts and capabilities it grants. In v2, a single pairing can be reused for multiple sessions, eliminating the need to scan a new QR code each time.

Transaction Signing

Once a session is active, the signing flow works as follows:

1. The dApp sends an encrypted signing request through the relay
2. The wallet receives and decrypts the request
3. The user reviews transaction details in the wallet interface
4. If approved, the wallet signs using the local private key
5. The signed result is encrypted and returned through the relay to the dApp

At no point does the private key leave the wallet device. The relay only transports encrypted payloads, and the dApp only receives the signed output.

V1 vs. V2

WalletConnect v1 launched in 2018 and served the ecosystem for several years before v2 replaced it with significant architectural improvements. V1 was officially sunset, and all production traffic now runs on v2.

The multi-chain namespace system is the most consequential change. V1 assumed an EVM-only world and used a single chainId from EIP-155. V2 supports heterogeneous blockchain ecosystems: a wallet can approve access to Ethereum mainnet, Optimism, Solana, and Cosmos chains within a single session, each with distinct method permissions.

Comparison with Injected Providers and EIP-6963

WalletConnect is one of several approaches to connecting wallets with dApps, each solving different parts of the connectivity problem.

Injected Providers

Browser extension wallets like MetaMask inject a window.ethereum provider object into every web page (defined by EIP-1193). The dApp detects this object and interacts with it directly. This approach is simple but has a fundamental limitation: when multiple wallet extensions are installed, they overwrite each other's provider object. The last extension to load wins, and users cannot choose which wallet to use.

Injected providers also work only in desktop browsers. Mobile wallet users, hardware wallet users, and anyone working across devices cannot use this pattern.

EIP-6963: Multi Injected Provider Discovery

Approved in October 2023, EIP-6963 introduced an event-based discovery mechanism. Instead of a single window.ethereum object, each installed wallet emits an eip6963:announceProvider event with its provider and metadata (name, icon, unique identifier). The dApp listens for these events and presents all available wallets to the user.

EIP-6963 solves the wallet collision problem for browser extensions but remains limited to in-browser wallets. WalletConnect and EIP-6963 are complementary: libraries like Reown's AppKit (formerly Web3Modal) use EIP-6963 to discover installed browser wallets while simultaneously offering WalletConnect for mobile and cross-device connections.

Use Cases

DeFi and Trading

The most common use case is connecting a self-custodial wallet to a decentralized exchange or DeFi protocol. Users keep their private keys on a mobile wallet or MPC wallet and connect to swap interfaces, lending protocols, or yield platforms running in a desktop browser. WalletConnect handles the signing relay without the user needing to install a browser extension.

Mobile dApp Interaction

On mobile, where browser extensions are unavailable, WalletConnect deep links provide the primary connection method. A user browsing a dApp in their mobile browser taps a "Connect Wallet" button, which opens their wallet app via deep link, establishes the session, and returns to the browser. Subsequent signing requests switch to the wallet app automatically.

Multi-Chain Portfolio Management

With v2's namespace system, users can connect a single wallet to manage assets across multiple chains. A portfolio dashboard can request access to Ethereum, Polygon, and Arbitrum accounts in one session proposal rather than requiring separate connections for each network.

Payments

WalletConnect Pay, launched in early 2026, extends the protocol into point-of-sale, e-commerce, and fintech payment flows. Users can spend crypto and stablecoins directly from their wallets at merchants without converting to fiat first. This positions WalletConnect as both a signing protocol and a payment rail.

Bitcoin Wallet Connectivity: Nostr Wallet Connect

WalletConnect originated in the Ethereum ecosystem and remains primarily focused on EVM-compatible and smart-contract-enabled chains. For Bitcoin and Lightning, a parallel approach has emerged: Nostr Wallet Connect (NWC).

Created by the teams behind Alby and Amethyst, NWC uses the Nostr protocol as its relay layer instead of WalletConnect's dedicated network. When a user creates a connection, the app sends payment requests through a Nostr relay to the user's Lightning wallet. The wallet processes the payment via the Lightning Network and returns the result through the same relay.

NWC is narrower in scope than WalletConnect: it focuses specifically on Lightning payments rather than general-purpose transaction signing. Supported wallets include Alby, Umbrel, and Cashu.me. While WalletConnect serves the broader multi-chain ecosystem, NWC fills a complementary role as a standardized interface for Bitcoin-native applications.

Security Model

WalletConnect's security relies on end-to-end encryption and the principle that relay servers are untrusted intermediaries.

• All payloads are encrypted with AES-256-CBC using keys derived from the initial pairing handshake. Relay nodes forward ciphertext and cannot decrypt message contents.
• Private keys never leave the wallet device. The dApp sends unsigned transaction data, and the wallet returns only the signed output.
• Session permissions are explicit. The wallet user sees exactly which chains, methods, and events the dApp requests before approving.
• App verification metadata (domain, icon, description) is displayed during pairing, helping users identify legitimate dApps from phishing attempts.

The v2 protocol also supports Sign In With Ethereum (SIWE, EIP-4361) for authentication, including compatibility with smart contract wallets via EIP-1271 and EIP-6492 signature validation.

Why It Matters

WalletConnect addresses a fundamental tension in Web3: users want to control their own keys (self-custody), but they also need to interact with applications across devices and networks. Without a standardized connection protocol, every dApp would need custom integrations for every wallet, fragmenting the ecosystem.

For wallet builders, WalletConnect provides instant compatibility with thousands of dApps. For dApp developers, it eliminates the need to integrate each wallet individually. The protocol acts as a universal adapter layer, similar to how WebAuthn standardizes authentication across the traditional web.

As the ecosystem evolves toward embedded wallets and SDK-based wallet infrastructure, connection protocols remain critical for interoperability. Whether a user holds keys in a mobile app, a browser extension, or an MPC wallet, they need a way to authorize actions in applications running elsewhere. WalletConnect provides that bridge.

Risks and Considerations

Relay Dependency

All communication flows through relay servers. If the relay network goes down or becomes unreachable, wallets cannot communicate with dApps. While v2 introduced a decentralized network of relay nodes to reduce single points of failure, the protocol still depends on relay infrastructure being available and performant.

Phishing via Malicious dApps

WalletConnect itself does not validate what a dApp asks a user to sign. A malicious dApp can present a legitimate-looking interface while requesting approval for a transaction that drains the wallet. Users must carefully review every signing request in their wallet before approving. App verification metadata helps but does not eliminate the risk.

Session Persistence and Permissions

Active sessions persist until explicitly disconnected. A forgotten session with broad permissions could be exploited if the dApp is compromised. Users should regularly review and revoke active WalletConnect sessions, especially for dApps they no longer use.

QR Code Interception

The pairing URI contains the symmetric key used for encryption. If an attacker captures the QR code (for example, through a screen share or shoulder surfing), they could potentially intercept the pairing. The short expiry window (typically five minutes) limits this risk, but users should treat QR codes as sensitive and avoid sharing screens during pairing.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.