[{"data":1,"prerenderedAt":19},["ShallowReactive",2],{"blog-content-en-what-is-walletconnect":3},{"slug":4,"title":5,"excerpt":6,"description":7,"bodyHtml":8,"faqItems":9},"what-is-walletconnect","What Is WalletConnect? How QR-Code Wallet Sessions Work (and How to Revoke Them)","WalletConnect is the protocol behind the QR code you scan to link a wallet to a dApp. Here is what that scan actually creates, what a session can and cannot do, and how to review and end sessions safely.","A plain-English explanation of how WalletConnect sessions work: what the QR code encodes, what permissions a dApp requests, and how to review and revoke active connections.","\u003Cblockquote>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.\u003C\u002Fblockquote>\u003Ch2>What WalletConnect Actually Is (and What It Is Not)\u003C\u002Fh2>\u003Cp>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 \u003Cem>connect wallet\u003C\u002Fem>, that code is usually a WalletConnect pairing invitation.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Ch2>What Happens When You Scan That QR Code\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cp>Pairing is only the handshake. The session that carries every signing request runs on a \u003Cem>separate\u003C\u002Fem> 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.\u003C\u002Fp>\u003Cp>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 \u003Ca href=\"\u002Fblog\u002Fhow-to-connect-wallet-to-dapp\">how to connect a wallet to a dApp\u003C\u002Fa>.\u003C\u002Fp>\u003Ch2>Sessions, Namespaces and Permissions: What a dApp Can Ask For\u003C\u002Fh2>\u003Cp>A session proposal is structured, not free-form. It lists \u003Cem>namespaces\u003C\u002Fem>: 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.\u003C\u002Fp>\u003Cp>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. \u003Cem>Required\u003C\u002Fem> 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 \u003Cem>optional\u003C\u002Fem> namespaces, which a wallet can approve in part. A good wallet shows you both, so you know what is negotiable.\u003C\u002Fp>\u003Cp>Approving a session does two things: it shares your public addresses for the approved chains, and it grants the dApp permission to \u003Cstrong>send requests\u003C\u002Fstrong> for the approved methods. Permission to ask is not permission to act.\u003C\u002Fp>\u003Ch2>Signing Requests: Why a Connection Is Not an Approval\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cp>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 \u003Cem>can\u003C\u002Fem> do is present a misleading request whose consequences are not obvious on screen.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Ch2>Where WalletConnect Goes Wrong: Stale Sessions, Fake QR Codes and Blind Signing\u003C\u002Fh2>\u003Cp>\u003Cstrong>Stale sessions.\u003C\u002Fstrong> 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.\u003C\u002Fp>\u003Cp>\u003Cstrong>Fake or swapped QR codes.\u003C\u002Fstrong> 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 \u003Ca href=\"\u002Fblog\u002Fwhat-is-a-wallet-drainer\">how wallet drainers work\u003C\u002Fa>: the connection succeeds, and the damage arrives in the signing request that follows.\u003C\u002Fp>\u003Cp>\u003Cstrong>Blind signing.\u003C\u002Fstrong> 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.\u003C\u002Fp>\u003Ch2>How to Review and Revoke Active Sessions (and Why Approvals Are Separate)\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>The part that trips people up: \u003Cem>disconnecting a session does not revoke a token approval\u003C\u002Fem>. 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 \u003Ca href=\"\u002Fblog\u002Fhow-to-revoke-token-approvals\">revoking token approvals\u003C\u002Fa>. Do both.\u003C\u002Fp>\u003Ch2>How WATS Handles dApp Connections\u003C\u002Fh2>\u003Cp>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 \u003Ca href=\"\u002Fhot-wallet\">WATS Hot Wallet\u003C\u002Fa> — you hold your keys and WATS never holds a key, so no connected dApp can move funds without your signature.\u003C\u002Fp>\u003Cp>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\u002Frelayer. 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.\u003C\u002Fp>",[10,13,16],{"q":11,"a":12},"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.",{"q":14,"a":15},"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.",{"q":17,"a":18},"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.",1786059318684]