WalletConnect is a messaging protocol that carries encrypted messages between a dApp and a wallet, letting the dApp request signatures without ever touching your private key. Scanning its QR code creates a pairing; approving the dApp’s session proposal then creates a session listing the chains and methods it may request — permission to ask, not permission to act; every asset move still needs your signature. Disconnecting ends the session locally but does not revoke onchain token approvals. On WATS, sessions are approved in the WATS Mobile App.
What WalletConnect Actually Is (and What It Is Not)
WalletConnect is a messaging protocol. Its only job is to carry messages between a dApp and a wallet, so the two can talk without the dApp ever touching your private key. When a site shows a QR code and says connect wallet, that code is usually a WalletConnect pairing invitation.
It is not a wallet, a custodian, or a blockchain: it holds no funds and signs nothing. Nor is it a browser extension, which injects a provider straight into the page. It is most familiar for the cross-device case — as of 2026 still the most common way a phone wallet talks to a desktop dApp — but it is equally the standard same-device path, deep-linking a mobile-browser dApp into a wallet app on the same phone.
What Happens When You Scan That QR Code
The QR code encodes a pairing URI: a topic identifier, a relay protocol identifier and a symmetric key. That key is carried verbatim rather than derived by the wallet — which is why a leaked or screenshotted pairing URI is sensitive. Both sides then exchange encrypted messages on the pairing topic.
Pairing is only the handshake. The session that carries every signing request runs on a separate topic, under its own key that the dApp and wallet negotiate directly through an X25519 exchange expanded with HKDF. The pairing key protects pairing-level messages, never your transaction requests.
The relay is the part people misunderstand: it routes ciphertext and metadata only, and cannot read payloads, alter them, or sign on your behalf. If it goes down your session stops working, but your funds are untouched — your keys never left your device. The dApp then sends a session proposal and your wallet renders it as an approval screen; everything after that depends on what you approve. The click-by-click flow is in our guide on how to connect a wallet to a dApp.
Sessions, Namespaces and Permissions: What a dApp Can Ask For
A session proposal is structured, not free-form. It lists namespaces: the chains, methods and events the dApp wants — Ethereum mainnet, an L2 or Solana; transaction signing and typed-data signatures; chain-changed and accounts-changed events.
Mind the direction: the dApp requests chains, methods and events, while the accounts themselves are selected in your wallet and returned in the approval. The v2 split matters too. Required namespaces are all-or-nothing — satisfied in full or the proposal is rejected outright — but as of 2026 that is the legacy path, deprecated and discouraged in favour of optional namespaces, which a wallet can approve in part. A good wallet shows you both, so you know what is negotiable.
Approving a session does two things: it shares your public addresses for the approved chains, and it grants the dApp permission to send requests for the approved methods. Permission to ask is not permission to act.
Signing Requests: Why a Connection Is Not an Approval
Once a session exists, every meaningful action arrives as a separate request you must explicitly approve: a swap becomes a transaction request, a login a message-signing request, a marketplace listing a typed-data signature.
This is the security boundary that matters. A connected dApp cannot silently move your assets: that takes a signature, and a signature takes your device and your approval. What it can do is present a misleading request whose consequences are not obvious on screen.
Two categories deserve extra suspicion: a token approval, which grants a contract ongoing permission to spend a token long after the session ends, and an offchain signature — the kind with no gas cost — which can authorise an order or permit a contract redeems later. Neither looks dramatic.
Where WalletConnect Goes Wrong: Stale Sessions, Fake QR Codes and Blind Signing
Stale sessions. Sessions have an expiry, but people accumulate dozens of live connections to sites they used once. Each is a channel that can push a request to your wallet at any time — more surface for a misread approval.
Fake or swapped QR codes. An attacker who controls a page — a lookalike domain, a hijacked frontend — can show their pairing URI instead of the real one. You connect successfully, to them. That is the trap in our breakdown of how wallet drainers work: the connection succeeds, and the damage arrives in the signing request that follows.
Blind signing. If your wallet cannot decode a request and shows raw data instead, you are trusting the site’s description of its own transaction. Treat that as a reason to stop, not a formality.
How to Review and Revoke Active Sessions (and Why Approvals Are Separate)
Every WalletConnect-capable wallet keeps a list of active sessions, usually under connections or connected apps. Read it as an inventory: each entry names the dApp and the chains and accounts it can see.
Disconnecting costs nothing: your wallet publishes a session delete message over the relay and drops the session from its own state — no transaction, no gas, no onchain record. Treat teardown as best-effort, though: if the peer is offline or the relay unreachable, the dApp may keep treating the session as live until delivery or expiry.
The part that trips people up: disconnecting a session does not revoke a token approval. Session permissions live in your wallet’s local state; token approvals live onchain, granted by a transaction you signed. Ending the session stops new requests but leaves the allowance untouched — revoking it is a separate onchain step, covered in our walkthrough on revoking token approvals. Do both.
How WATS Handles dApp Connections
On WATS, WalletConnect sessions are handled by the WATS Mobile App: it scans the QR code and renders each proposal and signing request for approval on your phone. Custody works the same way across every WATS product, including the WATS Hot Wallet — you hold your keys and WATS never holds a key, so no connected dApp can move funds without your signature.
What differs is the fee layer. Every action — transfers, swaps, staking — is charged in a single token, ATS, instead of the chain’s native gas: on EVM through an ERC-4337 paymaster, on Solana and TON through an equivalent fee-payer/relayer. Because ATS is a LayerZero OFT, one balance covers all three ecosystems. Collected ATS is burned from 100,000,000 toward a 30,000,000 floor. WATS is the first and only wallet to combine ERC-4337 + OFT single-token fees, charged instead of native gas, with that burn.
Frequently asked questions
Does connecting a wallet via WalletConnect give a dApp access to my funds?
No. A session lets a dApp see your public addresses for the approved chains and send you requests. Any action that moves assets requires a signature you approve on your own device, so a connection alone cannot spend anything. On WATS, those proposals and signing requests are rendered for approval in the WATS Mobile App, and because WATS never holds a key, no connected dApp can move funds without your signature.
Does disconnecting a WalletConnect session revoke token approvals?
No, they are separate. A session lives in your wallet's local state and ends with no gas the moment you disconnect it there. A token approval lives in the token contract onchain and stays active until you send a revocation transaction.
Can the WalletConnect relay server read my transactions or steal my keys?
No. In WalletConnect v2 the session that carries your transaction and signature requests is encrypted under a key the dApp and your wallet negotiate directly with each other through an X25519 exchange — that key is never exposed to the relay. The symmetric key carried in the pairing URI only protects pairing-level messages. The relay routes ciphertext and metadata, and your private key never leaves your wallet at any point in the flow.