What Is WalletConnect and How It Works with SSP

If you have ever opened a decentralized exchange, an NFT marketplace, or a lending app and seen a "Connect Wallet" button with a QR code next to it, you have already met WalletConnect. It is the quiet plumbing that links self-custody wallets to the apps people actually use. For an SSP user the question is not just "what is WalletConnect" but "what changes about my security when I use it, and what stays the same?"

The short answer: WalletConnect is the door. Your keys, and SSP's 2-of-2 protection, stay exactly where they were.

What WalletConnect Actually Is

WalletConnect is an open protocol for moving signing requests between a decentralized application (a dApp) and a wallet. It is not a custodian. It does not hold funds. It does not see your seed phrase or private keys. When a wallet and a dApp connect over WalletConnect, the two endpoints establish an encrypted session through a relay network, and messages travel back and forth across that session. The relay sees encrypted blobs; only the two endpoints can read them.

It is used almost everywhere in the ecosystem, which is why one workflow at the wallet side carries you across hundreds of apps without learning a new flow each time. The protocol is documented openly at docs.walletconnect.com, and you can find a long catalogue of WalletConnect-compatible apps via ethereum.org/en/dapps.

The Basic Flow, Step by Step

The connection ritual is almost always the same, regardless of which dApp you are using.

1. The dApp shows a "Connect Wallet" option and presents a QR code, or — if you are on mobile — a deep link.
2. You open SSP, choose to connect to a dApp, and scan the QR code (or follow the link).
3. SSP shows you what the dApp is asking for: a session, your address, the chain you are connecting on.
4. You approve the session. An encrypted channel is now open between SSP and the dApp.
5. When you take any action on the dApp that requires a signature — a swap, a token approval, a deposit — the dApp sends a sign request through the channel. SSP shows you exactly what is being asked.
6. You decide. If you approve, the signing process runs in SSP and the signed transaction is returned to the dApp, which broadcasts it.
7. When you are done, you disconnect the session.

The important thing to notice: the dApp never asks for your private keys. It asks for signatures. Every signature is a separate decision you make in your wallet.

How the Signing Model Maps onto SSP

This is where SSP changes the picture in a way most wallets cannot. In a typical single-signature wallet, every sign request is a single approval in the wallet UI — fast, but also a single point of failure. If that one device is compromised or you tap "approve" on a hostile request, the signature happens.

SSP is a 2-of-2 multisig wallet. Key 1 lives in the SSP Wallet browser extension. Key 2 lives on your phone in the SSP Key mobile app. Every transaction needs both keys, every time. That model does not disappear when you use WalletConnect — it extends to it.

When a dApp sends a sign request through WalletConnect:

• The request first arrives at the SSP Wallet extension on your computer.
• You review what the dApp is asking you to sign — the contract, the amount, the chain, the calldata when you ask to see it.
• You approve it on the extension. The extension produces its share of the signature.
• The request is pushed to SSP Key on your phone for co-signing. You see the same details there.
• You approve it on your phone. SSP Key produces its share.
• The two shares combine into one valid signature, which is returned to the dApp.

On UTXO chains this happens as a BIP-48 multisig signature; on EVM chains (Ethereum, Polygon, Base, BNB Smart Chain, Avalanche) it is a Schnorr-aggregated 2-of-2 signature verified by an ERC-4337 smart account. Different cryptography, same property: two devices, two approvals, one transaction. If you want the deeper read on the EVM side, see SSP's account abstraction architecture, and for the foundational concept, what 2-of-2 multisig is.

A phishing dApp that tricks the extension still has to clear your phone. That is the whole point.

Security Implications You Should Know

WalletConnect does not weaken your security; it changes what you have to pay attention to. The risks below are not unique to WalletConnect, but a connected dApp is a common place to meet them.

Phishing dApps. Anyone can build a website that looks like a popular protocol and ask you to connect. The wallet has no way to know which one is real. Always confirm you are on the right domain before connecting. Bookmark the apps you use; don't navigate to them from search ads or chat links.

Malicious sign requests. Once a session is open, a dApp can ask for arbitrary signatures. A swap interface can hand you a token approval that gives a stranger contract permission to drain a token balance. Read what SSP shows you. If a sign request looks unfamiliar — a contract you don't recognize, an unlimited approval, a transfer to an address that isn't yours — reject it. The 2-of-2 review on your phone is your second chance to catch this.

Blind-signing. Sometimes the data being signed is opaque — a long hex string that doesn't decode into human-readable fields. Treat blind sign requests with suspicion. Prefer apps that show you the human-readable intent of what you're signing.

Link-vs-app confusion. WalletConnect is a protocol. Many wallets implement it. A site that says "Use WalletConnect" is not a specific brand of trust signal — it's a plumbing standard. Don't conflate "the dApp uses WalletConnect" with "the dApp is safe."

Scoped permissions. A session can be limited to specific chains and methods. When SSP shows you the session request, look at what is being asked. There is no harm in declining a session that asks for more than the app actually needs.

Stale sessions. A session you forgot about is still a session. If a dApp's frontend is later compromised, an active session is a foothold. Make a habit of disconnecting when you are done.

Concrete Habits That Make This Work

A few small disciplines keep your WalletConnect usage clean.

• Verify the dApp URL before scanning a connection QR. Type domain names rather than clicking links from chats or ads.
• Read every sign request. What contract is being called? What chain? What amount? An unlimited token approval is a different thing than a fixed-amount one — both can be legitimate, but you should know which you are signing.
• Use the phone confirmation as a second look. If the request looked fine on your computer but wrong on your phone, reject it. Two devices means two chances to notice.
• Disconnect sessions when you finish. SSP gives you the session list; treat it like a list of open doors.
• Prefer reputable apps with audit history. Bias toward protocols that have been around, that publish audits, and that don't require sign-in flows beyond a standard WalletConnect handshake.
• Keep your seed phrase out of any dApp flow. No legitimate dApp ever needs your seed phrase. Sign requests are how dApps talk to your wallet; anything that asks for a seed is a scam. See seed phrase best practices for the deeper read.
• If you are connecting on Ethereum, the same chain-specific rules apply about gas, nonces, and contract interactions — Ethereum in SSP covers the chain-side details.

Tying It Together

WalletConnect is the door between SSP and the dApp ecosystem. It is encrypted, open-source, and used by most of the wallets and protocols you will encounter. It does not change where your keys live, and it does not weaken SSP's 2-of-2 model. Every transaction a dApp asks for still has to clear both your browser extension and your phone — that is the security property you bought when you chose SSP, and it travels with you across every dApp you connect to.

The keys stay with you. The door is just open while you walk through it.