Due release, due giorni. Il 2025-07-05 la v1.21.0 ha portato WalletConnect v2 — il protocollo oggi curato da Reown — e ha trasformato SSP in un wallet in grado di dialogare con migliaia di dApp: Uniswap, OpenSea, Aave e la lunga coda di frontend Web3 che già parlano WalletConnect. Il giorno dopo, il 2025-07-06, la v1.22.0 ha aggiunto una passata di UX su ogni modale che il nuovo connettore mostra. La cornice conta: WalletConnect non ha sostituito la multisig 2-su-2 di SSP. Ha solo dato a SSP un modo standard di ricevere richieste dalle dApp. Ogni azione richiesta da una dApp deve ancora passare per il wallet e per il telefono prima di essere firmata.
Collega SSP a migliaia di dApp
WalletConnect è nato come protocollo generico per "appaiare wallet e sito" e, negli ultimi anni, è diventato l'on-ramp di fatto verso le dApp Ethereum per i wallet non-MetaMask. Reown — il team un tempo noto come WalletConnect — distribuisce l'SDK v2 e un registro di app compatibili che si conta in migliaia. Con la v1.21.0, SSP entra in quel registro.
L'effetto pratico è che qualsiasi sito con un pulsante "Connect Wallet" che supporta WalletConnect può appaiarsi a SSP. Scambia su Uniswap. Fai un'offerta su OpenSea. Presta su Aave. Fai staking su Lido. Vota su Snapshot. Leggi un post di Mirror chiuso da un NFT. Con WalletConnect v2 in SSP, la via generica funziona.
È un tipo di integrazione diverso da SSP Connect, l'SDK first-party di SSP per le app partner che vogliono invocare azioni specifiche come pay. SSP Connect è la via profonda e in stile SSP. WalletConnect è la via standard, minimo comune denominatore. SSP ora le offre entrambe.
Come funziona il flusso di connessione
Il modello di appaiamento di WalletConnect è semplice e l'implementazione SSP lo segue senza sorprese. Una dApp produce una richiesta di connessione codificata come URI che inizia per wc: con un topic specifico per la sessione. L'utente la riceve in due modi: una stringa da copiare o un QR code da scansionare.
In SSP, l'utente apre la scheda WalletConnect, incolla l'URI nel campo di connessione WalletConnect (o scansiona il QR) e approva l'appaiamento. Da quel momento, la dApp può inviare richieste — firma questo messaggio, invia questa transazione, cambia su questa catena — al wallet tramite il relay WalletConnect. L'appaiamento dura finché una delle due parti non lo chiude. Se hai già usato WalletConnect con un altro wallet, la sensazione in SSP è la stessa, per scelta.
L'invariante multisig intatto
Ecco la parte facile da non vedere quando una release porta connettività dApp a un wallet multisig: WalletConnect non cambia il modello di sicurezza. È un trasporto, non un firmatario.
Quando Uniswap, via WalletConnect, chiede a SSP di firmare uno swap, la richiesta entra nella coda di approvazione di SSP Wallet. L'utente la rivede e la approva. Allora — e solo allora — SSP Wallet co-firma e inoltra la transazione metà-firmata a SSP Key sul telefono. Il telefono mostra lo stesso payload. L'utente lo approva anche lì. Solo dopo entrambe le approvazioni la transazione completamente firmata viene trasmessa.
Tre cose restano vere con WalletConnect in scena, ed erano già vere senza di esso:
- Due dispositivi, due approvazioni. Nessun dispositivo, nessun tasto sposta fondi da solo. WalletConnect non ha voto.
- La dApp non vede mai una chiave. Vede solo la firma sul payload che ha chiesto. Le chiavi vivono su SSP Wallet e SSP Key, come sempre.
- Il payload che firmi è il payload che la dApp ha inviato. Il wallet non muta la richiesta — stessi calldata, valore e chain ID.
WalletConnect allarga la superficie. Non indebolisce l'invariante.
Modali rifiniti il giorno dopo (v1.22.0)
La v1.22.0 è uscita in meno di 24 ore dopo la v1.21.0 ed è interamente sui quattro modali che il nuovo connettore apre. Il modale di richiesta connessione ha un layout più pulito: identità della dApp più chiara, ambito dei permessi più in evidenza, meno cromo. Il modale personal-sign — quello che compare quando un sito chiede di firmare un messaggio leggibile per autenticazione o consenso off-chain — è stato ridisegnato per mostrare il corpo del messaggio in modo più leggibile. Il modale di richiesta transazione ha un flusso più stretto: destinatario, valore, riepilogo del calldata e rete si leggono in un colpo. Il modale di cambio catena è stato semplificato per il caso comune di una dApp che chiede di passare tra Ethereum e Polygon.
Niente di tutto ciò cambia a cosa servono questi modali. Ognuno è una categoria specifica di richiesta dApp con una decisione di approvazione specifica. La v1.22.0 ha solo reso la decisione più facile da prendere a colpo d'occhio.
Cosa puoi fare oggi
Dopo l'aggiornamento a v1.21.0 (o, meglio, v1.22.0), quello che SSP non sapeva fare diventa routine. Scambia su un DEX. Fai un'offerta in un'asta NFT. Prendi a prestito con collaterale su Aave o Compound. Fornisci liquidità. Firma un voto Snapshot. Autenticati in un'app Web3 con Sign-In With Ethereum. Mintta da un launchpad. Ognuna di queste passa ora per lo stesso flusso incolla-URI-e-approva, con la stessa approvazione su due dispositivi alla fine.
Per gli sviluppatori, questo si affianca a l'API di SSP Wallet uscita prima nell'anno. Se stai costruendo un'app partner che vuole un'integrazione stretta e consapevole di SSP, l'API e SSP Connect restano la via giusta. Se stai lanciando una dApp generica e vuoi utenti SSP dal giorno uno, WalletConnect v2 è ora la risposta.
Ciò che non è cambiato è ciò che non doveva: la dApp parla al wallet, e il wallet parla all'utente — due volte, una su ciascun dispositivo, ogni volta.