两个版本,两天时间。2025-07-05,v1.21.0 把 WalletConnect v2 —— 如今由 Reown 维护的协议 —— 带进 SSP,让 SSP 变成一个能与数千 dApp 对话的钱包:Uniswap、OpenSea、Aave 以及已经在讲 WalletConnect 的 Web3 前端长尾。第二天,2025-07-06,v1.22.0 紧随其后,对新连接器打开的每一个弹窗做了一次 UX 修整。框架很关键:WalletConnect 并没有替换 SSP 的 2/2 多签,它只是给了 SSP 一种标准方式来接收 dApp 请求。任何 dApp 请求的动作,仍然要先过你的钱包再过你的手机,才能签名。
把 SSP 连到数千 dApp
WalletConnect 起步于一个通用的「把钱包和网站配对」协议,过去几年里成了非 MetaMask 钱包进入以太坊 dApp 生态的事实入口。Reown —— 前身名为 WalletConnect 的团队 —— 提供 v2 SDK,以及一个数以千计的兼容应用注册表。v1.21.0 起,SSP 也加入了这个注册表。
实际效果是:任何带「Connect Wallet」按钮且支持 WalletConnect 的网站,都能与 SSP 配对。在 Uniswap 兑换。在 OpenSea 出价。在 Aave 借贷。在 Lido 质押。在 Snapshot 投票。读一篇用 NFT 门禁的 Mirror 文章。在 SSP 里有了 WalletConnect v2,通用路径就跑通了。
这是一种不同于 SSP Connect 的集成。SSP Connect 是 SSP 自家的第一方 SDK,面向想要调用 pay 等具体动作的合作伙伴应用。SSP Connect 是深度、有 SSP 味的路径。WalletConnect 是标准、最小公分母的路径。SSP 现在两条都提供。
连接流程怎么走
WalletConnect 的配对模型很简单,SSP 的实现也没有意外。dApp 产生一条连接请求,被编码为以 wc: 开头并带有会话级 topic 的 URI。用户拿到它有两种方式:可以复制的字符串,或可以扫的二维码。
在 SSP 里,用户打开 WalletConnect 标签页,把 URI 粘贴到 WalletConnect 连接输入框(或扫二维码),然后批准配对。从那一刻起,dApp 可以通过 WalletConnect relay 向钱包发送请求 —— 请签这条消息、请发这笔交易、请切换到这条链。配对一直存在,直到一方结束。如果你用别的钱包试过 WalletConnect,那种感觉在 SSP 里是一样的,这是有意为之。
多签不变量原样保留
在一个把 dApp 接入能力带给多签钱包的版本里,最容易被忽略的部分是:WalletConnect 并没有改变安全模型。它是传输,不是签名者。
当 Uniswap 通过 WalletConnect 请求 SSP 给一次 swap 签名时,请求落到 SSP Wallet 的审批队列。用户审阅、批准。然后 —— 而且只在那时 —— SSP Wallet 协同签名,并把半签的交易转给手机上的 SSP Key。手机展示同一个 payload。用户在那里也批准一次。只有在两次批准之后,完整签名的交易才会广播。
三件事在 WalletConnect 加入画面之后依旧成立 —— 而且在没有它的时候本来就成立:
- 两台设备,两次批准。 没有任何一台设备、任何一次按键能单独动用资金。WalletConnect 没有投票权。
- dApp 永远看不到密钥。 它看到的只是它问过的 payload 上的签名。密钥还在 SSP Wallet 和 SSP Key 上,从来如此。
- 你签的 payload 就是 dApp 发的 payload。 钱包不改请求 —— 同样的 calldata、同样的 value、同样的 chain ID。
WalletConnect 把 表面 做大了,但没有削弱 不变量。
弹窗在一天后被打磨(v1.22.0)
v1.22.0 在 v1.21.0 后不到 24 小时发布,完全围绕新连接器打开的四个弹窗。连接请求弹窗有了更干净的布局:dApp 的身份更清楚,权限范围更显眼,装饰更少。Personal-sign 弹窗 —— 当站点请求你签一条人类可读消息用于身份认证或链下同意时弹出的那个 —— 经过重新设计,让消息正文更易读。交易请求弹窗的流程更紧凑:目的地、金额、calldata 摘要和网络,一眼能看完。链切换弹窗为常见的「dApp 让你在以太坊和 Polygon 之间切换」做了简化。
这些都没有改变这些弹窗是用来 做什么 的。每个都是一种特定类别的 dApp 请求,带着一种特定的批准决定。v1.22.0 只是让那个决定更容易一眼做出。
今天你可以做的事
升到 v1.21.0(或更理想的 v1.22.0)之后,SSP 此前做不到的事变得日常。在 DEX 上兑换。在 NFT 拍卖里出价。在 Aave 或 Compound 抵押借款。提供流动性。签一次 Snapshot 投票。用 Sign-In With Ethereum 登入 Web3 应用。在 launchpad 上 mint。每一项都走同一个粘贴 URI 然后批准的流程,最后是同一道双设备审批。
对开发者而言,这与今年早些时候发布的 SSP Wallet API 形成互补。如果你在做一款想要紧密、SSP-感知集成的合作伙伴应用,API 和 SSP Connect 依然是正路。如果你只是发一款通用 dApp 并希望第一天就有 SSP 用户,WalletConnect v2 现在就是答案。
没变的恰恰是该不变的:dApp 跟钱包说话,钱包跟用户说话 —— 两次,每台设备一次,每次都如此。