Zwei Releases, zwei Tage. Am 2025-07-05 brachte v1.21.0 WalletConnect v2 — das heute von Reown betreute Protokoll — und machte SSP zu einer Wallet, die mit tausenden dApps sprechen kann: Uniswap, OpenSea, Aave und der Long Tail der Web3-Frontends, die WalletConnect bereits beherrschen. Am Tag darauf, am 2025-07-06, folgte v1.22.0 mit einem UX-Durchgang über jede Modale, die der neue Connector öffnet. Der Rahmen ist wichtig: WalletConnect hat SSPs 2-aus-2-Multisig nicht ersetzt. Es hat SSP nur einen standardisierten Weg gegeben, dApp-Anfragen entgegenzunehmen. Jede Aktion, die eine dApp anfordert, muss immer noch durch deine Wallet und dein Telefon, bevor sie signiert wird.
SSP mit tausenden dApps verbinden
WalletConnect begann als generisches Protokoll für „Wallet mit Webseite koppeln" und ist in den letzten Jahren zum De-facto-Onramp für Nicht-MetaMask-Wallets ins Ethereum-dApp-Ökosystem geworden. Reown — das Team, früher unter dem Namen WalletConnect bekannt — liefert das v2-SDK und ein Register kompatibler Apps, das in die Tausenden geht. Mit v1.21.0 ist SSP in diesem Register.
Der praktische Effekt: Jede Seite mit einem „Connect Wallet"-Button, die WalletConnect unterstützt, kann sich mit SSP koppeln. Tausche auf Uniswap. Biete auf OpenSea. Verleihe auf Aave. Stake auf Lido. Stimme auf Snapshot ab. Lies einen Mirror-Beitrag, der durch ein NFT geschützt ist. Mit WalletConnect v2 in SSP funktioniert der generische Weg.
Das ist eine andere Art von Integration als SSP Connect, SSPs eigenes First-Party-SDK für Partner-Apps, die bestimmte Aktionen wie pay aufrufen wollen. SSP Connect ist der tiefe, SSP-eigene Weg. WalletConnect ist der Standardweg, der kleinste gemeinsame Nenner. SSP bietet jetzt beides.
Wie der Verbindungs-Flow funktioniert
Das Pairing-Modell von WalletConnect ist einfach, und die SSP-Implementierung folgt ihm ohne Überraschungen. Eine dApp erzeugt eine Verbindungsanfrage, kodiert als URI, die mit wc: und einem sitzungsspezifischen Topic beginnt. Der Nutzer erhält sie auf zwei Wegen: als String zum Kopieren oder als QR-Code zum Scannen.
In SSP öffnet der Nutzer den WalletConnect-Tab, fügt die URI in das WalletConnect-Verbindungsfeld ein (oder scannt den QR) und bestätigt das Pairing. Ab da kann die dApp Anfragen senden — signiere diese Nachricht, sende diese Transaktion, wechsle auf diese Kette — über das WalletConnect-Relay an die Wallet. Das Pairing besteht, bis eine Seite es beendet. Wer WalletConnect schon mit einer anderen Wallet benutzt hat, kennt das Gefühl: in SSP ist es dasselbe, mit Absicht.
Die Multisig-Invariante bleibt
Hier ist der Teil, den man bei einem Release, das einer Multisig-Wallet dApp-Konnektivität bringt, leicht übersieht: WalletConnect ändert das Sicherheitsmodell nicht. Es ist ein Transport, kein Signierer.
Wenn Uniswap via WalletConnect SSP bittet, einen Swap zu signieren, landet die Anfrage in der Approval-Queue von SSP Wallet. Der Nutzer prüft und bestätigt. Dann — und erst dann — co-signiert SSP Wallet und reicht die halb signierte Transaktion an SSP Key auf dem Telefon weiter. Das Telefon zeigt denselben Payload. Der Nutzer bestätigt auch dort. Erst nach beiden Bestätigungen wird die vollständig signierte Transaktion gesendet.
Drei Dinge bleiben mit WalletConnect im Bild wahr und waren es schon davor:
- Zwei Geräte, zwei Bestätigungen. Kein einzelnes Gerät, kein einzelner Tastendruck bewegt Mittel. WalletConnect hat keine Stimme.
- Die dApp sieht nie einen Schlüssel. Sie sieht nur die Signatur auf dem Payload, nach dem sie gefragt hat. Die Schlüssel liegen auf SSP Wallet und SSP Key, wie immer.
- Der Payload, den du signierst, ist der Payload, den die dApp gesendet hat. Die Wallet mutiert die Anfrage nicht — gleiche Calldata, gleicher Wert, gleiche Chain-ID.
WalletConnect vergrößert die Oberfläche. Es schwächt die Invariante nicht.
Modale einen Tag später poliert (v1.22.0)
v1.22.0 erschien in weniger als 24 Stunden nach v1.21.0 und betrifft ausschließlich die vier Modalen, die der neue Connector öffnet. Die Modale für Verbindungsanfragen hat ein saubereres Layout: klarere Identität für die dApp, prominenterer Berechtigungsumfang, weniger Beiwerk. Die Personal-Sign-Modale — die ein Site auslöst, wenn er um die Signatur einer menschenlesbaren Nachricht für Authentifizierung oder Off-Chain-Consent bittet — wurde überarbeitet, sodass der Nachrichtentext besser lesbar ist. Die Modale für Transaktionsanfragen hat einen kompakteren Flow: Ziel, Betrag, Calldata-Zusammenfassung und Netzwerk lassen sich auf einen Blick erfassen. Die Modale für Kettenwechsel wurde für den häufigen Fall vereinfacht, dass eine dApp das Umschalten zwischen Ethereum und Polygon erbittet.
Nichts davon ändert, wofür diese Modalen da sind. Jede ist eine spezifische Kategorie von dApp-Anfrage mit einer spezifischen Approval-Entscheidung. v1.22.0 hat die Entscheidung nur leichter auf einen Blick fällbar gemacht.
Was du heute tun kannst
Nach dem Update auf v1.21.0 (oder besser v1.22.0) wird Routine, was SSP vorher nicht konnte. Tausche auf einer DEX. Biete in einer NFT-Auktion. Leihe gegen Collateral auf Aave oder Compound. Stelle Liquidität bereit. Signiere eine Snapshot-Abstimmung. Logge dich in eine Web3-App mit Sign-In With Ethereum ein. Minte aus einem Launchpad. Jede dieser Aktionen läuft jetzt über denselben URI-einfügen-und-bestätigen-Flow, mit derselben Zwei-Geräte-Bestätigung am Ende.
Für Entwickler ergänzt das die SSP-Wallet-API, die früher im Jahr erschien. Wenn du eine Partner-App baust, die enge, SSP-bewusste Integration will, sind API und SSP Connect weiterhin der richtige Weg. Wenn du eine generische dApp lieferst und SSP-Nutzer vom ersten Tag haben willst, ist WalletConnect v2 jetzt die Antwort.
Was sich nicht geändert hat, ist genau das, was sich nicht ändern sollte: die dApp spricht mit der Wallet, und die Wallet spricht mit dem Nutzer — zweimal, je einmal pro Gerät, jedes Mal.