Cos'è WalletConnect? Come funzionano le sessioni wallet via QR code (e come revocarle)

WalletConnect è un protocollo di messaggistica che trasporta messaggi cifrati tra una dApp e un wallet, permettendo alla dApp di richiedere firme senza toccare mai la tua chiave privata. Scansionarne il QR code crea un pairing; approvare la proposta di sessione della dApp crea poi una sessione che elenca le chain e i metodi che può richiedere — il permesso di chiedere, non il permesso di agire; ogni movimento di asset richiede comunque la tua firma. Disconnettersi chiude la sessione a livello locale, ma non revoca le approvazioni dei token onchain. Su WATS, le sessioni si approvano nella WATS Mobile App.

Cos'è davvero WalletConnect (e cosa non è)

WalletConnect è un protocollo di messaggistica. Il suo unico compito è trasportare messaggi tra una dApp e un wallet, così che i due possano dialogare senza che la dApp tocchi mai la tua chiave privata. Quando un sito mostra un QR code e dice connect wallet, quel codice è di solito un invito di pairing WalletConnect.

Non è un wallet, né un custode, né una blockchain: non detiene fondi e non firma nulla. E non è nemmeno un'estensione browser, che inietta un provider direttamente nella pagina. È noto soprattutto per il caso cross-device — nel 2026 ancora il modo più diffuso in cui un wallet su smartphone parla con una dApp desktop — ma è altrettanto il percorso standard sullo stesso dispositivo, con un deep link che porta una dApp aperta nel browser mobile dentro l'app wallet sullo stesso telefono.

Cosa succede quando scansioni quel QR code

Il QR code codifica un URI di pairing: un identificatore di topic, un identificatore del protocollo di relay e una chiave simmetrica. Quella chiave viaggia in chiaro nell'URI invece di essere derivata dal wallet — ed è per questo che un URI di pairing trapelato o catturato in uno screenshot è un dato sensibile. Le due parti si scambiano poi messaggi cifrati sul topic di pairing.

Il pairing è solo l'handshake. La sessione che trasporta ogni richiesta di firma viaggia su un topic separato, sotto una propria chiave che dApp e wallet negoziano direttamente tramite uno scambio X25519 espanso con HKDF. La chiave di pairing protegge i messaggi a livello di pairing, mai le tue richieste di transazione.

Il relay è la parte che si tende a fraintendere: instrada solo ciphertext e metadati, e non può leggere i payload, alterarli o firmare al posto tuo. Se va offline la tua sessione smette di funzionare, ma i tuoi fondi restano intatti — le tue chiavi non hanno mai lasciato il tuo dispositivo. La dApp invia poi una proposta di sessione e il tuo wallet la mostra come schermata di approvazione; tutto ciò che segue dipende da cosa approvi. Il flusso passo per passo è nella nostra guida su come connettere un wallet a una dApp.

Sessioni, namespace e permessi: cosa può chiedere una dApp

Una proposta di sessione è strutturata, non libera. Elenca i namespace: le chain, i metodi e gli eventi che la dApp vuole — Ethereum mainnet, una L2 o Solana; firma di transazioni e firme di dati tipizzati; eventi chain-changed e accounts-changed.

Attenzione alla direzione: la dApp richiede chain, metodi ed eventi, mentre gli account veri e propri li selezioni nel tuo wallet e vengono restituiti nell'approvazione. Conta anche la distinzione introdotta con la v2. I namespace required sono tutto-o-niente — soddisfatti per intero o la proposta viene rifiutata in blocco — ma nel 2026 questo è il percorso legacy, deprecato e sconsigliato a favore dei namespace optional, che un wallet può approvare solo in parte. Un buon wallet te li mostra entrambi, così sai cosa è negoziabile.

Approvare una sessione fa due cose: condivide i tuoi indirizzi pubblici per le chain approvate e concede alla dApp il permesso di inviare richieste per i metodi approvati. Il permesso di chiedere non è il permesso di agire.

Richieste di firma: perché una connessione non è un'approvazione

Una volta che la sessione esiste, ogni azione rilevante arriva come richiesta separata che devi approvare esplicitamente: uno swap diventa una richiesta di transazione, un login una richiesta di firma di messaggio, una messa in vendita su un marketplace una firma di dati tipizzati.

È questo il confine di sicurezza che conta. Una dApp connessa non può spostare i tuoi asset in silenzio: serve una firma, e una firma richiede il tuo dispositivo e la tua approvazione. Quello che può fare è presentarti una richiesta ingannevole, le cui conseguenze non sono evidenti a schermo.

Due categorie meritano sospetto extra: l'approvazione di un token, che concede a un contratto il permesso continuativo di spendere quel token anche molto tempo dopo la fine della sessione, e una firma offchain — quella senza costo di gas — che può autorizzare un ordine o un permit che un contratto riscatta più tardi. Nessuna delle due sembra drammatica.

Dove WalletConnect va storto: sessioni dimenticate, QR code falsi e blind signing

Sessioni dimenticate. Le sessioni hanno una scadenza, ma le persone accumulano decine di connessioni attive verso siti usati una volta sola. Ognuna è un canale che può inviare una richiesta al tuo wallet in qualsiasi momento — più superficie per un'approvazione letta male.

QR code falsi o sostituiti. Un attaccante che controlla una pagina — un dominio sosia, un frontend compromesso — può mostrare il proprio URI di pairing al posto di quello vero. Ti connetti con successo, a lui. È la trappola descritta nella nostra analisi di come funzionano i wallet drainer: la connessione riesce, e il danno arriva con la richiesta di firma successiva.

Blind signing. Se il tuo wallet non riesce a decodificare una richiesta e mostra dati grezzi, ti stai fidando della descrizione che il sito dà della propria transazione. Consideralo un motivo per fermarti, non una formalità.

Come rivedere e revocare le sessioni attive (e perché le approvazioni sono un'altra cosa)

Ogni wallet compatibile con WalletConnect tiene una lista delle sessioni attive, di solito sotto connessioni o app connesse. Leggila come un inventario: ogni voce indica la dApp e le chain e gli account che può vedere.

Disconnettersi non costa nulla: il tuo wallet pubblica un messaggio di session delete sul relay ed elimina la sessione dal proprio stato — nessuna transazione, nessun gas, nessuna traccia onchain. Considera però la chiusura come best-effort: se il peer è offline o il relay irraggiungibile, la dApp può continuare a trattare la sessione come attiva fino alla consegna del messaggio o alla scadenza.

Il punto che confonde di più: disconnettere una sessione non revoca l'approvazione di un token. I permessi di sessione vivono nello stato locale del tuo wallet; le approvazioni dei token vivono onchain, concesse da una transazione che hai firmato tu. Chiudere la sessione ferma le nuove richieste ma lascia intatta l'allowance — revocarla è un passaggio onchain separato, spiegato nella nostra guida su come revocare le approvazioni dei token. Fai entrambe le cose.

Come WATS gestisce le connessioni alle dApp

Su WATS le sessioni WalletConnect sono gestite dalla WATS Mobile App: scansiona il QR code e mostra ogni proposta e ogni richiesta di firma da approvare sul telefono. La custodia funziona allo stesso modo su tutti i prodotti WATS, incluso l'Hot Wallet WATS — le chiavi le detieni tu e WATS non detiene mai una chiave, quindi nessuna dApp connessa può spostare fondi senza la tua firma.

Ciò che cambia è il livello delle commissioni. Ogni azione — trasferimenti, swap, staking — viene addebitata in un unico token, ATS, al posto del gas nativo della chain: su EVM tramite un paymaster ERC-4337, su Solana e TON tramite un equivalente fee-payer/relayer. Poiché ATS è un OFT LayerZero, un solo saldo copre tutti e tre gli ecosistemi. Gli ATS raccolti vengono bruciati partendo da 100.000.000 verso una soglia minima di 30.000.000. WATS è il primo e unico wallet a combinare commissioni ERC-4337 + OFT in un singolo token, addebitate al posto del gas nativo, con quel burn.