How to Use WalletConnect to Connect Wallets Securely

Core Protocol Architecture

1. WalletConnect operates through a relay-based messaging system where neither the DApp nor the wallet establishes direct peer-to-peer communication.

2. A WebSocket connection is initiated between the DApp frontend and the official WalletConnect relay server at wss://relay.walletconnect.com.

3. The DApp generates a unique topic and a temporary keypair, embedding them into a URI formatted per EIP-1328 specification.

4. This URI is rendered as a QR code visible on the DApp interface, containing encrypted session metadata including expiry timestamp and relay protocol identifier.

5. Upon scanning, the mobile wallet parses the URI, extracts the topic and symKey, and subscribes to the same relay channel using identical encryption parameters.

Wallet Integration Requirements

1. Wallets must implement the WalletConnect V2 client SDK, supporting EIP-155 namespace negotiation for multi-chain compatibility.

2. Each supported blockchain must be declared with its chain ID and requested methods, such as eth_sendTransaction or personal_sign.

3. The wallet enforces strict permission scoping: it never exposes private keys, only signs payloads using device-local cryptographic modules.

4. Session approval requires explicit user confirmation of DApp identity, requested chains, and functional permissions before establishing any RPC binding.

5. All subsequent messages—including transaction requests and signature prompts—are encrypted end-to-end using AES-256-GCM derived from the shared Diffie-Hellman secret.

Security Enforcement Mechanisms

1. Private keys remain fully isolated within the wallet’s secure execution environment—never transmitted, never exposed to memory accessible by web contexts.

2. The relay server cannot decrypt payloads; it only forwards ciphertext between endpoints without interpreting content.

3. Session expiry is enforced both client-side and relay-side, with default limits set to 7 days unless overridden during proposal.

4. Each session carries an immutable pairing identifier, enabling deterministic revocation via wallet-initiated disconnect commands.

5. No session persists across app restarts unless explicitly re-approved by the user—automatic reconnection is disabled by design.

Multi-Chain Namespace Handling

1. DApps declare required namespaces in their session proposal, specifying chains like eip155:1 (Ethereum Mainnet) and eip155:137 (Polygon).

2. Wallets respond with approved namespaces, which may differ based on user selection or wallet capability constraints.

3. Chain switching during active sessions triggers new permission prompts—no silent fallback or automatic authorization occurs.

4. RPC requests are routed exclusively to chains included in the approved namespace, preventing cross-chain leakage or misdirected transactions.

5. A single WalletConnect session can simultaneously maintain active contexts across multiple EVM-compatible chains without session duplication.

Session Lifecycle Management

1. Connection initiation begins with URI generation and QR rendering—no network handshake occurs until scan completion.

2. Once paired, the wallet stores session state locally using encrypted storage tied to device biometrics or PIN.

3. Users can view all active sessions inside wallet UI under “Connected Apps”, with real-time status indicators for each DApp.

4. Revoking a session terminates all associated subscriptions, invalidates the shared key, and purges cached signing context immediately.

5. Session metadata—including DApp origin, chain scope, and last interaction time—is never shared with third-party analytics or telemetry services.

Frequently Asked Questions

Q: Does WalletConnect store private keys on its relay servers?WalletConnect relay servers do not handle or store private keys. They only forward encrypted payloads without decryption capability.

Q: Can a malicious DApp trigger unauthorized transactions after connection?No. Every transaction request requires explicit user approval within the wallet interface. No operation executes without manual confirmation.

Q: Is it possible to connect the same wallet to two different DApps simultaneously?Yes. WalletConnect supports concurrent sessions. Each DApp receives an isolated session context with distinct permissions and chain scopes.

Q: What happens if the relay server goes offline during an active session?Active sessions continue functioning because message encryption and routing logic reside entirely within client-side implementations. Relay unavailability affects only new connection attempts.