项目案例 · IT Solutions
WalletPro
已上线多链钱包，配有原生移动客户端与 Rust API，密钥和签名操作始终保留在设备上。
- 角色
- 开发
- 项目时间
- 2025–2026
- 成果
- 客户端签名，支持多链
05 · WalletPro
密钥留在设备上，技术栈清晰透明。
多链钱包，配有原生移动客户端与 Rust API，密钥和签名操作始终保留在设备上。
挑战
问题所在。
钱包用户需要明确的信任边界：哪些内容绝不离开设备，哪些内容允许网络看到。
产品必须在支持多条链的同时保持这一边界清晰，并避免让后端成为托管方。
方法
我们的应对方法。
01
密钥留在设备上
私钥与签名操作保留在客户端。API 提供数据并广播已签名交易。
02
清晰的多链支持
明确建模各条链的差异，使界面如实呈现功能与风险。
03
原生移动体验
Android 与 iOS 客户端承载钱包的主要操作流程。
04
Rust 后端 API
专注于数据、广播与运维事务的 API 层，不承担密钥托管。
05
经过测试的交付
在用户使用前，通过端到端测试与负载测试检验关键流程。
我们构建的内容
我们的交付成果。
Rust API
后端服务负责链数据、广播及钱包相关操作，不持有用户密钥。
Android 客户端
原生 Kotlin 钱包，支持设备端签名。
iOS 客户端
原生 Swift 钱包，采用相同的信任模型。
共享移动层
统一的移动端规范，确保两个平台在新增链时保持一致。
安全审查
面向审计的文档，说明信任边界与关键路径。
基础设施
容器化部署，并对 API 进行监控。
架构
系统概览。
原生客户端掌握密钥并执行签名。Rust API 提供链数据，转发已经签名的交易，使服务器不承担托管职责。
随着多链支持扩展，统一的移动端规范与自动化检查持续保护信任边界。
数据与事实
概览。
仅在设备上进行
签名
Android · iOS
客户端
Rust API
后端
多链
范围
我们的经验
带入后续工作的经验。
- 01
信任边界必须在产品中清楚可见，而不只存在于架构图里。
- 02
当链的特殊性影响共享界面的设计假设时，多链支持就会在不知不觉中出错，因此必须明确建模差异。
- 03
非托管后端的逻辑更易理解，也更容易向用户和审计人员解释。
下一步
下一步。
- 在保持相同设备端签名模型的前提下，支持更多链。
- 在应用内更清楚地说明权限与交易预览。
- 持续加固广播与监控路径。
继续交流