WalletConnect 移动端集成
上一章你自己拿着私钥签名——这在很多产品里恰恰是你不想做的事:保管别人的私钥责任太重。更好的模式是把签名外包给用户已经信任的钱包 App(MetaMask、imToken、Rainbow…),你的 App 只负责"提出请求"。WalletConnect 就是连接这两个 App 的标准协议。这一章讲清它的会话模型和移动端签名流。
为什么需要它
两种截然不同的产品形态,决定你要不要 WalletConnect:
| 自管私钥(第 21 章 + 第 23 章) | WalletConnect(本章) | |
|---|---|---|
| 你的 App 拿私钥吗 | 拿(你就是钱包) | 不拿(用户的钱包 App 拿) |
| 责任 | 你要对私钥安全全权负责 | 责任在用户的钱包 |
| 适合 | 做一个钱包 App | 做一个需要用户签名的 dApp |
| 用户体验 | App 内直接签 | 跳到钱包 App 确认再跳回 |
如果你做的不是钱包本身,而是一个需要用户"用他自己的资产做点什么"的应用(游戏、市场、DeFi 前端),WalletConnect 几乎总是更明智的选择——你把最烫手的私钥保管责任完全推给了专业钱包。
这就是把认证委托给外部 App的经典模式,和"用微信/Google 登录"跳到对方 App 授权再跳回来,或系统级的 Intent 委托给另一个应用处理,思路完全一致。你的 App 说"我需要一个签名",系统/协议把请求送到钱包 App,用户在那边确认,结果通过 deep link 回到你这里。你从不接触凭证本身。
会话:一次配对,长期通信
WalletConnect 的核心是 session(会话)。建立过程:
- 你的 App 生成一个配对请求(桌面场景是二维码,移动场景是一个 deep link URI)。
- 用户的钱包 App 扫码 / 通过 deep link 接收,弹窗展示"某某 App 请求连接,权限范围是……"。
- 用户批准,双方通过一个中继服务器(内容端到端加密)建立持久会话。
- 此后你的 App 发出的签名/交易请求,都通过这条加密通道送到钱包,用户逐一确认。
用 Reown(WalletConnect)AppKit
官方 Android SDK 现在叫 Reown AppKit(WalletConnect 品牌升级后)。集成骨架大致如下:
// 需先在 cloud.reown.com 注册拿一个 projectId val connectionType = ConnectionType.AUTOMATIC val appMetaData = Core.Model.AppMetaData( name = "My dApp", description = "On-chain guestbook", url = "https://mydapp.example", icons = listOf("https://mydapp.example/icon.png"), redirect = "mydapp://request" // ★ deep link:钱包确认后跳回你的 App ) CoreClient.initialize(projectId, connectionType, application, appMetaData) AppKit.initialize(Modal.Params.Init(core = CoreClient))
// 发起 personal_sign(第 19 章)—— 请求经加密通道送到钱包 val request = Request( method = "personal_sign", params = """["0x...消息hex", "$userAddress"]""" ) AppKit.request(request, onSuccess = { /* 钱包返回签名,继续你的逻辑 */ }, onError = { /* 用户拒绝或超时 */ } ) // 触发后要主动 deep link 唤起钱包 App,让用户去确认
deep link:两个 App 之间的往返
移动端没有二维码可扫(你俩在同一台手机上),靠的是 deep link 互相唤起:你的 App 用钱包的 scheme 唤起钱包让用户确认,钱包处理完用你注册的 redirect scheme(上面的 mydapp://request)把用户送回来。你需要在 AndroidManifest.xml 里注册这个 scheme 的 intent-filter——这套你在做任何 deep link / OAuth 回调时都做过。
移动签名流的体验坑很多:用户切到钱包 App 后可能忘了切回来、钱包没装、deep link 没配好导致回不来。务必处理这些边界:检测钱包是否安装、请求超时、以及用户在钱包里拒绝的情况。另外——就算用了 WalletConnect,你仍要对"请求用户签什么"负道德责任(第 19 章):清楚地告诉用户这次签名会导致什么,别把一个危险授权包装得无害。
该选哪条路?
| 你要做的产品 | 推荐方案 |
|---|---|
| 一个钱包 App | 自管私钥(下一章重点) |
| 游戏 / 市场 / DeFi 前端 | WalletConnect,借用户已有钱包 |
| 想要"无感"链上体验的 C 端 App | 账户抽象 / 嵌入式钱包(第 26 章) |
WalletConnect 让你的 App 不碰私钥就能获得签名:通过一次配对建立加密会话,之后每个签名/交易请求经加密通道送到用户的钱包 App,用户确认后 deep link 跳回。心智模型 = "用第三方 App 登录/授权"那一套,你早就熟。做 dApp 优先选它;做钱包才需要自管私钥。而"自管私钥怎么存"——正是压轴的下一章,移动端安全的硬核所在。
本章小结
- 做 dApp(非钱包)优先用 WalletConnect:把私钥保管责任外包给用户的钱包 App。
- 核心是加密 session:一次配对后,签名/交易请求经中继通道送到钱包,用户逐一确认。
- 移动端靠 deep link 在你的 App 与钱包间往返;需注册 redirect scheme 并处理各种边界。
- 选型:钱包 App→自管私钥;dApp→WalletConnect;追求无感体验→账户抽象/嵌入式钱包(第 26 章)。