Two releases, two days. On 2025-07-05 v1.21.0 shipped WalletConnect v2 — the protocol now stewarded by Reown — and turned SSP into a wallet that can talk to thousands of dApps: Uniswap, OpenSea, Aave, and the long tail of Web3 frontends that already speak WalletConnect. The next day, on 2025-07-06, v1.22.0 followed up with a UX pass on every modal the new connector raises. The framing matters: WalletConnect didn't replace SSP's 2-of-2 multisig. It just gave SSP a standard way to receive dApp requests. Every action a dApp asks for still has to clear both your wallet and your phone before it can sign.
Connect SSP to thousands of dApps
WalletConnect started as a generic "pair a wallet with a website" protocol and has, over the past few years, become the de-facto on-ramp for non-MetaMask wallets into Ethereum dApps. Reown — the team formerly known as WalletConnect — ships the v2 SDK and a registry of compatible apps that runs into the thousands. With v1.21.0, SSP joins that registry.
The practical effect is that any site with a "Connect Wallet" button that supports WalletConnect can pair with SSP. Swap on Uniswap. Bid on OpenSea. Lend on Aave. Stake on Lido. Vote on Snapshot. Read a Mirror post gated by NFT ownership. With WalletConnect v2 in SSP, the generic path works.
This is a different kind of integration than SSP Connect, SSP's own first-party SDK for partner apps that want to invoke specific actions like pay. SSP Connect is the deep, SSP-flavored path. WalletConnect is the lowest-common-denominator path. SSP now offers both.
How the connection flow works
WalletConnect's pairing model is simple, and the SSP implementation follows it without surprises. A dApp produces a connection request encoded as a URI that begins with wc: and a session-specific topic. The user gets it in one of two ways: as a string to copy, or as a QR code to scan.
In SSP, the user opens the WalletConnect tab, pastes the URI into the WalletConnect connection field (or scans the QR), and approves the pairing. From that point on, the dApp can send requests — please sign this message, please send this transaction, please switch to this chain — to the wallet through the WalletConnect relay. The pairing persists until either side ends it. If you have used WalletConnect with another wallet, the feel is the same in SSP, by design.
Multisig invariant intact
Here is the part that is easy to miss in a release that brings dApp connectivity to a multisig wallet: WalletConnect does not change the security model. It is a transport, not a signer.
When Uniswap, through WalletConnect, asks SSP to sign a swap, the request lands in SSP Wallet's approval queue. The user reviews and approves it. Then — and only then — SSP Wallet co-signs and forwards the half-signed transaction to SSP Key on the user's phone. The phone shows the same payload. The user approves it there too. Only after both approvals does the fully-signed transaction broadcast.
Three things stay true with WalletConnect in the picture that were already true without it:
- Two devices, two approvals. No single device, no single keystroke, can move funds. WalletConnect does not get a vote.
- The dApp never sees a key. All it ever sees is a signature on the payload it asked about. The keys live on SSP Wallet and SSP Key, where they always have.
- The payload you sign is the payload the dApp sent. The wallet doesn't mutate the request — same calldata, same value, same chain ID.
WalletConnect makes the surface bigger. It does not weaken the invariant.
Modals polished a day later (v1.22.0)
v1.22.0 shipped less than 24 hours after v1.21.0 and is purely about the four modals the new connector raises. The connection request modal got a cleaner layout: clearer identity for the dApp, more prominent permission scope, less chrome. The personal-sign modal — the one a site raises when it asks you to sign a human-readable message for authentication or off-chain consent — was redesigned to display the message body more legibly. The transaction request modal got a tighter flow: destination, value, calldata summary, and network are easier to scan in one pass. The chain switch modal was streamlined for the common case of a dApp asking you to flip from Ethereum to Polygon or back.
None of this changes what these modals are for. Each one is one specific category of dApp request with one specific approval decision attached. v1.22.0 just made the decision easier to make at a glance.
What you can do today
After updating to v1.21.0 (or, ideally, v1.22.0), the things SSP could not do before become routine. Swap on a DEX. Bid in an NFT auction. Borrow against collateral on Aave or Compound. Provide liquidity. Sign a Snapshot vote. Authenticate into a Web3 app with Sign-In With Ethereum. Mint from a launchpad. Each of these now works through the same paste-the-URI-and-approve flow, with the same two-device approval at the end.
For developers, this complements the SSP Wallet API released earlier in the year. If you are building a partner app that wants tight, SSP-aware integration, the API and SSP Connect are still the right path. If you are shipping a generic dApp and want SSP users on day one, WalletConnect v2 is now the answer.
What did not change is what shouldn't: the dApp talks to the wallet, and the wallet talks to the user — twice, once on each device, every time.