Deux versions, deux jours. Le 2025-07-05, la v1.21.0 a apporté WalletConnect v2 — le protocole désormais piloté par Reown — et fait de SSP un portefeuille capable de dialoguer avec des milliers de dApps : Uniswap, OpenSea, Aave et la longue traîne des frontends Web3 qui parlent déjà WalletConnect. Le lendemain, le 2025-07-06, la v1.22.0 a suivi avec une passe UX sur chaque modale que le nouveau connecteur affiche. Le cadrage compte : WalletConnect n'a pas remplacé la multisig 2-sur-2 de SSP. Il a juste donné à SSP une façon standard de recevoir des requêtes de dApps. Chaque action demandée par une dApp doit encore passer par votre portefeuille et votre téléphone avant d'être signée.
Connectez SSP à des milliers de dApps
WalletConnect a démarré comme un protocole générique d'« appairage portefeuille-site » et est devenu, ces dernières années, la rampe d'accès de fait aux dApps Ethereum pour les portefeuilles non-MetaMask. Reown — l'équipe anciennement connue sous le nom de WalletConnect — livre le SDK v2 et un registre d'apps compatibles qui se compte en milliers. Avec la v1.21.0, SSP rejoint ce registre.
L'effet pratique : tout site avec un bouton « Connect Wallet » qui supporte WalletConnect peut s'appairer avec SSP. Échangez sur Uniswap. Enchérissez sur OpenSea. Prêtez sur Aave. Stakez sur Lido. Votez sur Snapshot. Lisez un billet Mirror gardé par un NFT. Avec WalletConnect v2 dans SSP, le chemin générique fonctionne.
C'est une intégration d'un autre type que SSP Connect, le SDK maison de SSP pour les apps partenaires qui veulent invoquer des actions spécifiques comme pay. SSP Connect est le chemin profond, à la SSP. WalletConnect est le chemin standard, plus petit dénominateur commun. SSP propose désormais les deux.
Comment fonctionne le flux de connexion
Le modèle d'appairage de WalletConnect est simple, et l'implémentation SSP le suit sans surprise. Une dApp produit une demande de connexion encodée comme une URI commençant par wc: et un topic propre à la session. L'utilisateur la reçoit de deux manières : une chaîne à copier, ou un QR code à scanner.
Dans SSP, l'utilisateur ouvre l'onglet WalletConnect, colle l'URI dans le champ de connexion WalletConnect (ou scanne le QR) et approuve l'appairage. À partir de là, la dApp peut envoyer des requêtes — signe ce message, envoie cette transaction, bascule sur cette chaîne — au portefeuille via le relay WalletConnect. L'appairage dure jusqu'à ce qu'un des deux côtés y mette fin. Si vous avez déjà utilisé WalletConnect avec un autre portefeuille, la sensation dans SSP est la même, par choix.
L'invariant multisig préservé
Voici la partie qu'on rate facilement quand une version apporte la connectivité dApps à un portefeuille multisig : WalletConnect ne change pas le modèle de sécurité. C'est un transport, pas un signataire.
Quand Uniswap, via WalletConnect, demande à SSP de signer un swap, la requête tombe dans la file d'approbation de SSP Wallet. L'utilisateur la passe en revue et l'approuve. Alors — et seulement alors — SSP Wallet co-signe et transmet la transaction à moitié signée à SSP Key sur le téléphone. Le téléphone affiche le même payload. L'utilisateur l'approuve là aussi. Ce n'est qu'après les deux approbations que la transaction entièrement signée est diffusée.
Trois choses restent vraies avec WalletConnect dans l'image, et l'étaient déjà sans lui :
- Deux appareils, deux approbations. Aucun appareil, aucune touche ne déplace de fonds tout seul. WalletConnect n'a pas voix au chapitre.
- La dApp ne voit jamais de clé. Elle ne voit qu'une signature sur le payload qu'elle a demandé. Les clés vivent sur SSP Wallet et SSP Key, où elles ont toujours vécu.
- Le payload que vous signez est celui que la dApp a envoyé. Le portefeuille ne mute pas la requête — mêmes calldata, valeur et chain ID.
WalletConnect agrandit la surface. Il n'affaiblit pas l'invariant.
Modales peaufinées un jour plus tard (v1.22.0)
La v1.22.0 a été publiée moins de 24 heures après la v1.21.0 et porte uniquement sur les quatre modales que le nouveau connecteur affiche. La modale de demande de connexion a gagné une mise en page plus propre : identité de la dApp plus claire, périmètre des permissions plus saillant, moins d'enrobage. La modale de personal-sign — celle qu'un site déclenche quand il demande de signer un message lisible pour l'authentification ou un consentement off-chain — a été redessinée pour afficher le corps du message plus lisiblement. La modale de demande de transaction a un flux resserré : destinataire, valeur, résumé de calldata et réseau se lisent d'un coup. La modale de changement de chaîne a été épurée pour le cas commun o�� une dApp demande de basculer entre Ethereum et Polygon.
Rien de cela ne change à quoi ces modales servent. Chacune représente une catégorie spécifique de requête dApp, avec une décision d'approbation spécifique. La v1.22.0 a juste rendu la décision plus facile à prendre d'un coup d'œil.
Ce que vous pouvez faire aujourd'hui
Après la mise à jour vers la v1.21.0 (idéalement la v1.22.0), ce que SSP ne savait pas faire devient routine. Échangez sur un DEX. Enchérissez sur une vente NFT. Empruntez en collatéral sur Aave ou Compound. Apportez de la liquidité. Signez un vote Snapshot. Authentifiez-vous sur une app Web3 avec Sign-In With Ethereum. Mintez depuis un launchpad. Chaque action passe maintenant par le même flux coller-URI-et-approuver, avec la même approbation deux-appareils à la fin.
Côté développeurs, cela complète l'API SSP Wallet sortie plus tôt dans l'année. Si vous construisez une app partenaire qui veut une intégration serrée et consciente de SSP, l'API et SSP Connect restent la bonne voie. Si vous lancez une dApp générique et voulez des utilisateurs SSP dès le jour un, WalletConnect v2 est désormais la réponse.
Ce qui n'a pas changé est ce qui ne devrait pas changer : la dApp parle au portefeuille, et le portefeuille parle à l'utilisateur — deux fois, une fois sur chaque appareil, à chaque fois.