非託管錢包基礎設施

自託管錢包。不持有密鑰。

Signatorie 是面向工程團隊的 SDK 與 API，用於把自託管錢包嵌入你的平台。你的公司在結構上無法動用用戶資產——並非出於政策承諾，而是由架構決定。非託管屬性由架構強制執行，並可在密碼學上驗證。

為 K-VASP、MiCA、DTSP、FSA、SFC 而建。

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 制度要求三十億韓圜以上的資本門檻、ISMS 認證以及實名銀行對接；歐盟 MiCA 自 2024 年 12 月起全面生效，強制執行 CASP 授權。對絕大多數平台而言，跨入託管邊界並非一份文書工作，而是一項重塑商業模式的資本與組織承諾。

這些義務只附着於託管行為本身。一家真正從不持有用戶密鑰——並能對此加以證明——的公司，運作於這道邊界之外。長期以來的關鍵障礙在於「能加以證明」這幾個字：在此之前，要實現真正的非託管，要麼從零開始自行構建門限密碼學，要麼接受用戶根本不會使用的產品體驗。Signatorie 把這個取捨折疊掉了。可被驗證的非託管屬性，連同一份工程團隊可在數天內對接完成的整合介面，一併交付。

  • SFC

    香港 VASP 制度

  • DTSP

    新加坡 MAS 數字代幣服務制度

  • FSA

    日本 VASP 註冊

  • K-VASP

    資本門檻 30 億韓圜以上，ISMS 認證

  • MiCA

    CASP 授權，2024 年 12 月起生效

運作方式

門限簽名，由架構決定

Signatorie 的簽名系統建基於門限簽名 (threshold signature scheme)——這是一種密碼學原語：用戶的簽名密鑰被切分為多份密鑰分片，分發給多方持有；要產生一個簽名，必須有至少一個最低數量 (即「閾值」) 的分片共同協作運行協議。Signatorie 服務器持有的分片數量，被嚴格設定為少於這個閾值。算術上的後果是直接的：服務器單獨無法生成簽名，這是數學構造決定的。這並非 Signatorie 選擇遵守的一項政策，而是系統的結構屬性。即便 Signatorie 的每一台服務器、每一個數據庫、每一份備份在同一時刻全部失陷，攻擊者所掌握的分片數量仍然不足以組成一個可簽名的集合。

保存在用戶側的分片，由用戶自己的認證因子加密。密碼以 PAKE (password-authenticated key exchange，密碼認證密鑰交換) 處理——這個協議在客戶端推導出密碼學素材，而密碼本身、或任何能還原密碼的信息，從不以可被利用的形式送到服務器。Passkey 則透過 WebAuthn PRF 處理——PRF 是 passkey 標準的一項擴展，讓用戶硬件 (手機、安全密鑰、操作系統密鑰庫) 產生一段只有該硬件才能產生的確定性秘密。分片以加密形式存放於數據庫——Signatorie 的，或客戶你自己的——不依賴 iCloud、Google Drive 等消費級雲端帳戶，那類帳戶的恢復流程處於你的控制範圍之外。Signatorie 無法使用它所持有的分片。簽名時，用戶完成認證，客戶端解密用戶的分片，門限簽名協議隨即運行。

門限簽名架構Signatorie 門限簽名流程的架構圖。左側為用戶設備，持有兩個認證因子保護的客戶端密鑰分片：以 PAKE 保護的密碼 (零知識密碼交換，密碼從不以可被利用的形式到達服務器)，以及以 WebAuthn PRF 保護的 passkey (綁定於硬件、只有該設備才能產生的秘密)。右側為 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 側信道研究、更簡潔的安全審查。

整合

十五行以內完成一個錢包

三個步驟，每一段都可一眼讀懂：初始化客戶端、為一個用戶 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 框架的架構文檔可按需提供。
DTSP — 新加坡
新加坡金融管理局 (MAS) 的 DTSP 制度，將牌照義務施加於提供數字代幣服務的營運者。非託管基礎設施置身於主要託管牌照要求之外。Signatorie 提供格式適合提交予 MAS 審閱的架構文檔。
FSA · MiCA · K-VASP
在日本金融廳 (FSA) 的 VASP 註冊制度、歐盟 MiCA 的 CASP 授權制度、以及韓國 K-VASP 制度下，均有等效的對映立場，已備有文檔，按需提供。

準備好評估了嗎？

加入候補名單以取得早期訪問權限，或索取技術文檔，按你自己的節奏審閱架構。

Signatorie — 非託管錢包基礎設施