非托管钱包基础设施

自托管钱包,平台不持有密钥

Signatorie 是一套面向工程师的 SDK 与 API,让你的平台直接嵌入自托管钱包。你的公司无法动用用户资金——这并非来自内部政策,而是由系统架构本身决定。非托管属性在结构上被强制,且在密码学上可验证。

为 SFC、DTSP、FSA、K-VASP 与 MiCA 而构建。

quickstart.ts
import { Signatorie } from '@signatorie/sdk'; const sig = new Signatorie({  apiKey: process.env.SIGNATORIE_API_KEY,  chain: 'ethereum',}); // Non-custodial wallet, threshold-signedconst wallet = await sig.wallets.create({  userId: 'user_abc123',});

问题所在

托管代价沉重,非托管又有隐忧

在亚洲与欧洲五大主要加密监管框架之下,「托管」是触发最重义务的那条红线。香港证监会 (SFC) 的 VASP 制度要求持牌、设有合资格保管人、并满足资本与内控要求;新加坡金融管理局 (MAS) 的 DTSP 框架对在新加坡境外提供数字代币服务的本地实体设有发牌义务;日本金融厅 (FSA) 要求加密资产交换业者完成 VASP 注册并接受持续审计;韩国《特定金融信息法》下的 K-VASP 制度要求 30 亿韩元以上的资本下限、ISMS 信息安全管理体系认证以及实名银行账户对接;欧盟 MiCA 自 2024 年 12 月全面生效,要求 CASP 牌照。对多数平台而言,跨入托管边界并非文件工作,而是一笔重塑业务结构的资本与组织投入。

上述义务只附着于「托管」这一行为。一家真正从不持有用户密钥——并且能够证明这一点——的公司,本身就位于监管边界之外。难点一直在于「证明」二字:在过去,真正意义上的非托管要么意味着从零搭建门限密码学,要么意味着用户体验差到无人愿用。Signatorie 收敛了这道取舍。可证明的非托管属性,配合一套工程团队几天内就能交付的集成接口。

  • SFC

    香港证监会 VASP 持牌制度

  • DTSP

    新加坡金管局 DTSP 框架

  • FSA

    日本金融厅 VASP 注册

  • K-VASP

    资本下限 30 亿韩元以上,ISMS 认证

  • MiCA

    CASP 牌照,2024 年 12 月起全面生效

工作原理

门限签名,由结构决定

Signatorie 的签名系统建立在「门限签名」之上——这是一种密码学原语,用户的签名密钥被切分为多份「密钥分片」(share),任何一次签名都必须凑齐预设的最低分片数(即「阈值」)才能完成协议。Signatorie 的服务器所持有的分片数量,严格少于签名所需的阈值。由此得到一个直接的算术结论:服务器单独无法生成签名,这是数学构造决定的。这不是 Signatorie 选择不签,而是系统在结构上根本无法签。即便所有 Signatorie 服务器、数据库与备份在同一时刻被完全攻陷,攻击者拿到的分片数量在数学上仍不足以拼出一个签名。

落在用户一侧的分片,则使用用户自身的认证因子加以加密。密码走的是 PAKE(password-authenticated key exchange,密码认证密钥交换——一种在客户端基于密码派生密钥材料、而密码本身从不以可用形式抵达服务器的协议)。通行密钥走的是 WebAuthn PRF(PRF 是 WebAuthn 通行密钥标准的扩展,让用户手上的硬件设备产出一段只有该硬件才能产出的确定性秘密值)。分片以加密形式存放于数据库中——Signatorie 这边、或客户这边——而不依赖 iCloud、Google Drive 等消费级云盘账户,避免继承平台无法掌控的账户恢复流程。Signatorie 无法使用它所持有的分片。一次签名的流程是:用户在客户端完成认证 → 客户端解密用户分片 → 门限签名协议在多方之间运行。

门限签名架构Signatorie 门限签名架构示意图。图左为用户设备,持有受双因子保护的客户端密钥分片:一组分片由密码加 PAKE 加密(密码以零知识方式参与交换,永远不会以可用形式发往服务器),另一组由通行密钥加 WebAuthn PRF 加密(与硬件绑定、只有该设备本身才能产出的秘密值)。图右为 Signatorie 服务器,将加密后的分片保存在数据库中——不依赖 iCloud 或 Google Drive——所持有的分片数量在设计上严格少于签名阈值,因此服务器无法独自生成签名。图中央是 t-of-n 门限协议:必须凑齐解密后的用户分片,并按需配合服务器持有的那一份,才能完成签名。无论平台一侧还是 Signatorie 一侧,都无法单独产生一个有效签名。User devicepassword · ZKP PAKEpasskey · WebAuthn PRFclient key sharesauthenticates · decrypts sharesThreshold signingrequires t-of-n sharesruns across user + serverSignatorie serverencrypted shares in DBno iCloud / Drive neededholds < thresholdcannot sign alonesignature

能力

为工程团队而设

  • 多链支持

    Solana、Ethereum 及兼容 EVM 的链、Bitcoin、Cosmos、Polkadot、Aptos、Sui。一次集成,覆盖多条网络。

  • 面向工程师的 SDK

    覆盖主流后端与前端语言的 SDK,另有 REST API 适配任意技术栈。多数团队的集成工作以「天」计。

  • 不依赖消费级云盘

    分片以加密形式保存在数据库中——Signatorie 这边或客户这边——从不进入用户的 iCloud 或 Google Drive。Signatorie 无法使用它所持有的分片。

  • 密码学非托管

    服务器一侧持有的分片数量,由数学约束严格少于签名阈值。这是一项可审计的事实,而非营销说辞。

  • 纯用户端签名模式

    可选配置:服务器持有零份密钥材料,只作为加密存储而存在——这是本架构所能给出的最严格的非托管姿态。

  • 不强依赖 TEE

    签名安全性不依赖于 TEE(可信执行环境)。更少的硬件依赖、无需追踪 TEE 侧信道研究进展、安全评审范围也更小。

集成

十五行以内接入一个钱包

三个步骤,每一步都能一眼看懂:初始化客户端、为某个用户 ID 创建非托管钱包、签署一笔交易。用户认证完全在客户端完成。

create-and-sign.ts
import { Signatorie } from '@signatorie/sdk'; const signatorie = new Signatorie({  apiKey: process.env.SIGNATORIE_API_KEY,  chain: 'ethereum',}); // Create a non-custodial wallet for a new userconst wallet = await signatorie.wallets.create({  userId: 'user_abc123',  authFactors: ['password', 'passkey'],}); // Sign a transaction (user authentication happens client-side)const signedTx = await wallet.sign(transaction);

监管

架构如何对应到法规条文

Signatorie 在设计上确保你的平台不会跨入托管状态。可提交监管机构查阅的架构说明文档,按各框架分别准备,可索取。

SFC — 香港
香港证监会下的 VASP 持牌制度,将受规管虚拟资产服务的发牌义务集中于「为客户保管虚拟资产」的运营者,并要求合资格保管人、资本与内控等一整套条件。Signatorie 的门限架构在设计上让客户平台不进入托管状态,从而显著降低附着于托管之上的发牌门槛与持续义务。可提供针对 SFC VASP 框架的架构对应文档供监管查阅。
DTSP — 新加坡
新加坡金融管理局 (MAS) 的 DTSP 框架要求向境外客户提供数字代币服务的本地实体取得 DTSP 牌照,并满足资本、AML 与运营要求。非托管基础设施位于该框架的发牌核心之外。Signatorie 可提供架构对应文档,格式适合提交予 MAS 审阅。
FSA · K-VASP · MiCA
在日本金融厅 (FSA) 加密资产交换业 VASP 注册、韩国《特定金融信息法》K-VASP 制度(资本下限 30 亿韩元以上、ISMS 认证、实名银行对接),以及欧盟 MiCA(2024 年 12 月起 CASP 牌照全面生效)之下,Signatorie 的定位一致,相关架构文档已备妥,可索取。

准备做技术评估?

加入候补名单以获取早期访问,或索取技术文档,按你自己的节奏审阅架构。

Signatorie — 非托管钱包基础设施