AWS FSI · 闭门技术交流 · 2026-08
机构钱包安全
MPC 多签 + Safe 链上多签 + Maker-Checker 审批
→ 下一页F 全屏P 导出 PDF
幕 0/11 · 北极星
其他都是手段，钱包才是目的everything else is a means; the wallet is the goal
「其他都是小打小闹，到不了太多钱，就是为了搞你钱包，然后一波带走 。你前面绕一圈，最多是手段 ，但不是目的，目的就是你的钱包 。」
$3.4B+
2025 全年被盗（Chainalysis，2025-12 定稿）
≈76%
2026 H1 损失金额 来自基建/操作型攻击（仅占事件数 ≈15%）· TRM
$1.46B
Bybit 单笔 / 401,347 ETH（2025-02-21）
攻击正从「广撒网」收敛为「少次数、单笔巨额、直取钱包 」。防护做得再全，落点还是钱包。
安全体系的最后一米，永远是钱包的签名那一下。
Agenda · 今天的路线
一条主线：三层组合，且改配置也要过多签three orthogonal layers — reconfiguring them also needs multisig
🎯
幕 1-2 · 威胁与正本清源 钱包为何是终局 · 六大复盘 · 多签是三类技术，不是一种方式
🔑
幕 3 · 第一层 MPC/TSS 协议谱系 · CVE · presign 雷区 · DKG 与 reshare
⛓️
幕 4 · 第二层 Safe delegatecall 攻击面 · Guard · Safenet · 反盲签
⭐
幕 5 · 组合（核心） MPC×Safe 叠加 · t 与 k · 三层正交
✅
幕 6-7 · 审批与资金架构 t-of-n ≠ 四眼 · 策略引擎 · 蓄水池
☁️
幕 8 · AWS 落地 Nitro+KMS 替 HSM 的边界 · 设备身份 · 账
🔀
幕 9-10 · 合并 · TCO · 合规 六件事 · 临界点 · 25EC44
🔮
幕 11 · 前沿与落地 量子 · AI Agent 投毒 · 可选路径
如果全场只记一句：别把 t-of-n 当成四眼——它们防的是完全不同的攻击。
幕 1/11 · 威胁全景 · 数据
先把数据口径对齐get the numbers right first
$2.2B
2024 全年（+21% YoY，Chainalysis）
$3.4B+
2025 全年（Chainalysis，2025-12）
$2.02B
DPRK 2025（+51%）· 累计 $6.75B · 占服务型被攻破 76%
✔ 当前定稿口径
Bybit = $1.46B / 401,347 ETH （Chainalysis 摘要与 FBI 均取整为 $1.5B）
WazirX 2024 = ≈$234.9M （早期估值曾作 $233M）
DPRK 洗钱 约 45 天三波 ；>60% 单笔 <$500K —— 这条可直接落成出金风控规则
✘ 三个最容易被引错的数
「$233M 」不是 Bybit 总额（两个候选来源：WazirX ≈$234.9M / Bybit 的 stETH 分项 $253.16M，不宜断言）
「$3.7–3.8B 」属 2022 年 ，不是 2024
「私钥泄露 43.8% 」是 Chainalysis 2024 全年 一手口径；跨年混用才是错 ——讲当代请用 TRM 76% / Hacken 88.3%
数字的口径本身，就是尽调能力的一部分。
幕 1/11 · 威胁全景 · 复盘
六大事件：失守的到底是哪一环what actually failed
事件 损失 根因（一句话） 失守的一环 Bybit 2025-02$1.46B 前端 JS 被换；签名者在 Ledger 看到的是对的，Safe UI 显示的被改；operation 0→1 签名者看到的 ≠ 他签的+ v1.1.1 装不了 Guard Radiant 2024-10~$50M 至少 3 名 签名人设备被控（确切数目官方未定）；Safe UI 与 Tenderly 模拟均无异常；"重试"被武器化三条校验路径同构 WazirX 2024-07≈$234.9M Safe 4-of-6，第 6 把 key 在第三方；UI 与实际 payload 不一致 同上 + 第三方持钥 Drift 2026-04≈$285M 社工长达 6 个月 →盲签 durable nonce 预签名；刚迁到零 timelock 的 2/5 多签 签名意图 + 无冷静期 Upbit 2025-11$30-37M Solana 热钱包；管理员凭证被劫持；官方承认签名基建有缺陷 热钱包签名基建 Coldcard 2026-07≈$116M* 2021 固件构建错误→熵 128→最低 40 bit，无需物理接触 可暴破 密钥生成/熵源
共性：前四起失守点都不是密码学，而是"签名者看到的内容" ——密钥根本没被偷。Radiant 尤其值得看：多人复核、模拟工具都做了，但三条校验路径读的是同一条渲染管线。
* Coldcard 为截至 2026-08-05 的滚动计数（Galaxy Research 计数，TRM 标 preliminary）；同一事件另有 1,367 BTC / 1,196 地址等不同时点快照，勿混引。
大部分「多签被攻破」，是签名意图被骗，不是密码学被破。
幕 1/11 · 威胁全景 · Bybit 机理
一个 uint8，一笔 delegatecall，$1.46Bhow a single storage slot fell
2/04 开发者 Mac 被社工 2/19 恶意 JS 注入 S3 前端 2/21 3 owner 在 Ledger 看到对的 Safe UI 显示的被换 2/21 operation 0→1 delegatecall 14:15 资源被修改（约 2 分钟后） Sygnia 判断为掩痕 三个合法签名 + 链上校验全对 —— 失守点只在 operation 这一个 uint8 三个合法 owner 用真硬件钱包签了真签名，链上校验完全正确。失守点：operation 0→1 这一个 uint8 + 一个架构上装不了 Guard 的 v1.1.1 实现。
Guard 是 v1.3.0 才引入的——停留在 v1.1.1 的 Safe，想拦也拦不了。
幕 1/11 · 威胁全景 · 范式转移
攻击面从「合约/密钥」转向「签名意图 + 人 + 供应链」the attack surface has moved
旧范式（守得住） 🔒 智能合约漏洞 🔑 私钥被盗 🌐 网络/主机入侵 新范式（2026 H1 · 占损失 76%） 🎭 签名意图被骗（盲签） 👤 人 · 社工 · 内鬼 📦 供应链 / 前端 / 第三方 转移 2026 H1：基础设施与操作型入侵只占事件数约 15% ，却占损失金额约 76% （TRM）。攻击者越来越不偷私钥，而是让合法签名者签下他看不懂的东西 。
防御主轴要从「守密钥」升级到「验签名意图 + 保审批路径独立」。
幕 2/11 · 正本清源
多签不是「一种方式」，是三类实现技术multisig is three technologies, not one method
「多签」这个词在行业里常被当成一种方式来用，但它其实是三类不同的实现技术 ——混着说，是最常见的口径分歧来源。
🔑
MPC 多签 私钥分片，密码学阈值签名（TSS）。产出的是一个签名 。链上只见一个普通 EOA 签名。
⛓️
链上合约多签 Safe 为代表，多 owner 达阈值合约放行。多个独立签名 过阈值。链上全可查。
✅
审批流 Maker-Checker，业务语义的四眼/多级审批。对「这笔业务对不对」 负责。
三者可以叠加 ——这就是「三层组合架构」的来源。它们分别防：私钥单点、被骗执行、业务欺诈。
先把这三个词分清楚，后面所有讨论才不会各说各话。
幕 2/11 · 正本清源 · MPC
MPC 产出的是「签名」，f(0) 永不重构it produces a signature, never the key
分片1 分片2 分片3 分片4 分片5 secret = f(0)（从不被重构） 够阈值的各方各自算出部分签名并合成 —— f(0) 全程不出现在任何一台机器上 （Shamir 秘密分享 · 门限 3/5：3 个绿点足以完成签名） 以 3-of-5 为例，基于 Shamir 秘密分享 ：各方持有曲线上的点，够阈值的各方各自算出部分签名再合成 ——完整私钥 f(0) 不出现在任何一台机器上，也不给对方看。
一句话记差别：MPC 拼的是签名 ，Safe 拼的是多个独立签名 。
幕 2/11 · 正本清源 · Safe
Safe：多个 owner 各自签，合约达阈值放行independent signers, on-chain threshold
owner₁ EOA-A（硬件钱包） owner₂ EOA-B（硬件钱包） owner₃ EOA-C（硬件钱包） Safe 合约 2-of-3 达阈值放行 链上执行 · owners/threshold 全可查 与 MPC 不同：Safe 的每个 owner 是独立的 EOA 地址 ，各自用完整私钥签名，合约收集到 ≥ 阈值个签名才执行 。owners / threshold / 每笔执行结果全部链上可查、可举证到人 。
Safe 的结构性优势是链上可验证与不可否认——出事能 ecrecover 出谁签的。
幕 2/11 · 正本清源 · 对比
MPC vs Safe：不是二选一，是防不同攻击阶段they defend different stages
MPC / TSS
链上只见一个普通签名 ，门限与参与方链下无痕
同一套 MPC 平台可覆盖多链，但不同曲线需不同协议与不同密钥 （ECDSA ↔ EdDSA 不通用）
gas 便宜（就是一笔普通 EOA 交易）
风险在密码学与实现层 （CVE-2023-33241 等）+ 分片运维
解决：私钥不落单点
Safe 合约多签
owners / threshold / 每笔链上可查、可举证到人
仅 EVM；跨链需逐链部署与逐链维护（整合场景的痛点）
gas 有结构性开销（ecrecover 3000 gas/签名）
风险在合约层 （delegatecall / module / 版本漂移）
解决：被骗取的签名不能被执行 ——前提是装了 Guard
正确表述：MPC 管密钥、Safe/Guard 管执行策略 。Bybit 失守的是后者——只买 MPC 不装 Guard，同样的攻击可以再来一次 。
别问「MPC 还是 Safe」，问「这个攻击阶段谁在防」。
幕 3/11 · 第一层 MPC · 协议谱系
选错协议 = 继承它的漏洞pick the wrong protocol, inherit its bugs
GG18 2018 ❌ GG20 2020 ⚠️ CGGMP21 2021 ⚠️ DKLs23 2023 ✅✅ FROST RFC 2024-06 ✅✅ CGGMP24 2024 ✅* ❌ GG18：CVE-2023-33241 / TSSHOCK 打穿，且无 identifiable abort ⚠️ 2026-05-15 THORChain GG20 事故 $10.7M：上游修复分散多版本、下游 fork 只跟 CVE → zero-day ✅* CGGMP24 实现侧目前仅 alpha（0.7.0-alpha.3）；FROST 有实现层 CVE-2025-58359（refresh 语义）
协议 在线轮数 已知问题 2026 取向（自建） GG18 9 CVE-2023-33241；TSSHOCK；无 identifiable abort ❌ 不做新部署 GG20 6-7 同族漏洞；但论文标题即含 with Identifiable Abort ⚠️ 仅存量维护 CMP / CGGMP21 1 CVE-2025-66016 / 66017（2025-11） ⚠️ 须 CGGMP24；实现侧仅 alpha DKLs23 3 无协议级 CVE（无 Paillier）；规格本身不含 IA ✅ 候选之一 FROST （Schnorr/EdDSA）2 无协议级 CVE；实现层 CVE-2025-58359 （refresh 语义） ✅ Ed25519/Solana 取向
来源：Fireblocks Research（CVE-2023-33241，发现者，一手）· Verichains TSSHOCK（一手）· DFNS/RustSec（2025-11，一手）· dkls.info（作者维护，2026-07）· RFC 9591（IRTF/CFRG **Informational，非 IETF 标准**）
存量 MPC 库的 fork 必须与上游逐 commit 对齐审计——"上游改了但没标 critical"恰恰最危险。
幕 3/11 · 第一层 MPC · CVE-2023-33241
BitForge ≠ TSSHOCK：两组独立漏洞two independent vulnerability classes
BitForge（Fireblocks 命名）
CVE-2023-33241 + CVE-2023-33242
根因：不检查对手方 Paillier 模数是否为 biprime
≥16 次签名 + 中国剩余定理 即恢复完整私钥，与参与方数量无关波及 15+ 厂商/库，Binance Custody 被点名在列
TSSHOCK（Verichains 命名）
攻击 DLN proof 编码/挑战空间（α-shuffle / c-guess / c-split）
最少 1 次签名 提取完整私钥，不需要 abort、无痕继续 额外波及 CGGMP21 的实现（如 Taurus）
THORChain 收到 PoC 后全网停机
一个值得记住的教训：tss-lib 的哈希编码歧义 2019 年就被审计报过、评为 Low、"已修复" ，四年后被 TSSHOCK 打穿。"审计过"≠"安全"，"已修复"≠"根因已消除" 。
一条常见误传：Fireblocks 不是 tss-lib 的 fork——它用 MPC-CMP/CGGMP，且 CVE-2023-33241 正是 Fireblocks 自己披露的。但要说准：CMP/CGGMP 谱系源自 GG18、同样依赖 Paillier ——"换协议族就免疫"并不成立。
技术尽调要问的是「审的哪个 commit、根因消除没、之后有无新审计」。
幕 3/11 · 第一层 MPC · presign 预签名
presign 买到的是延迟，代价是更严的运维纪律presign buys latency; the price is discipline
presign 是纯密码学预处理 （预备一个随机 nonce 的分享），不承载任何业务授权含义 ——presign 的那一刻消息还不存在，什么都没批准。
⚠️
雷区一 presignature 重用 = nonce 重用 = 私钥立即泄漏 。防御：消费与删除放在同一数据库事务。
💥
雷区二 备份/恢复会复活已消费的 presignature ——一次 DR 演练或数据库回滚 = 私钥泄漏。必须进 runbook 与变更审批。
🎭
雷区三 presign × raw signing = 签名伪造（CVE-2025-66017） ；再叠加 HD 派生，强度 128 → 85 bit。
取舍：冷钱包（低频大额）不建议启用 presign；热钱包出金（高频、要求亚秒）才是它的战场 。冷侧真正需要的"签名人不在线也能参与"，靠 proactive refresh with offline devices 解决，不靠 presign。
把「已 presign」当成「已批准这笔转账」——是最危险的一种误解。
幕 3/11 · 第一层 MPC · DKG 工程现实
三件事经常被混：refresh / reshare / rotationthe three things people conflate
Key refresh 份额随机化，t 与 n 不变、地址不变 。目的：让不同时间窃取的份额无法拼合。
Re-share 改 n（换人）或 t（换阈值），地址不变 。整合与换人本质上就是它。
Key rotation 换公钥 → 换地址 → 需要真实链上转账迁移资产。
最强的一手证据就在实现层：CVE-2025-58359 （ZF FROST 2.0.0–2.1.0，2.2.0 修复）——keys::refresh 传入更小的 min_signers 会让人以为阈值降了、其实没降，且旧阈值仍能签 。最成熟的 FROST 实现自己就把这两件事混在一个 API 里。
identifiable abort 要单独落实 没有它，出问题时只有两个选择——怪罪所有人 （资金锁死）或谁都不怪 （资金被偷）。GG20 论文标题即含 IA，CGGMP21/24、2PC-MPC 也有；DKLs23 规格本身不提供 （有实现方付费定制）。→ 「选 DKLs23」与「要 IA」是两个必须分别落实 的要求。
广播 ≠ N 次单播 若"广播"是拿 N 次单播凑的，reshare 就可能被 equivocate（对不同人说不同话）。旧份额已删、新份额视图不一致 = 永久锁币 。
整合 = 换人 = reshare = 全流程风险最高的一步，先在测试网走通灾备恢复。
幕 3/11 · 第一层 MPC · 抗量子
量子与标准争议：2026 该不该动？quantum & the parameter-provenance debate
两类算法风险
量子 ：Google Quantum AI 白皮书给的是两个可互换资源点 ——≤1,200 逻辑量子比特 + ≤9,000 万 Toffoli，或 ≤1,450 + ≤7,000 万；并给出 <50 万物理比特、分钟级 。NIST 预期 2030 弃用 / 2035 禁止 ECDSA 参数来源争议 ：NIST P-256 的参数由种子生成，长期存在公开讨论；而 secp256k1 未进 NIST 标准 ，不受该讨论影响 2026 该做的 4 件事（低成本高价值）
建密码学资产清单（哪条链、哪个地址、什么曲线、谁在签）
要求「签名敏捷性」——换算法不重写业务
盯 NIST IR 8214C 的门限 PQC 征集
现在不要为抗量子更换 MPC 协议
2029–2035 之前真正会让你损失资金的，是实现层与运维层缺陷 ，不是量子。AWS 侧 KMS 已支持 ML-DSA（2025-06），可先用于内部证据链与代码签名。
量子是 5 年后的事；presign 复活、盲签、reshare 锁币是今天的事。
幕 4/11 · 第二层 Safe · 架构
根因是「delegatecall 到任意目标 + 无 Guard」the real root cause
slot 0 singleton = 实现合约指针 ← delegatecall 可写它（也可写任意 slot） slot 2 owners（链表） slot 4 threshold 门限 m slot 5 nonce 单调递增 ← 先自增再算哈希 根因是「允许 delegatecall 到任意目标 + v1.1.1 无法装 Guard」——改成 EIP-1967 也拦不住 Safe 的 singleton 指针存在 裸 slot 0 （非 EIP-1967），这只是把伪装成本压到最低 ——恶意合约写自己第一个状态变量就长得像 transfer()。真正的根因是「允许 delegatecall 到任意目标」+「v1.1.1 架构上装不了 Guard」 ；改成 EIP-1967 也拦不住 ，因为 delegatecall 可写任意 slot。
nonce 先自增再算哈希——失败交易也消耗 nonce，运维脚本别假设"失败=nonce 不变"。
幕 4/11 · 第二层 Safe · 签名类型
让云端密钥成为 Safe owner：今天怎么做making a KMS key a Safe owner — today
v 值 类型 语义与风险 0 EIP-1271 合约签名 owner 是合约（passkey 模块走这条）。注：更严格的 32 字节返回校验在尚未发布 的分支上，当前发布版仍是宽容解码 1 approved hash ⚠️ 执行者若本身是 owner，可为任意哈希免签贡献一票 = 等效门限 −1 （源码级 ⚠️⚠️⚠️ 标注）→ 执行者与签名者必须角色分离>30 eth_sign 签名者只看到一串裸哈希——盲签最典型入口。机构应在流程上禁用，只允许 EIP-712
今天可交付的路径 ：用 Safe 官方 passkey 模块 （SafeWebAuthnSignerFactory，README 明写兼容 1.3.0+ ，走 ERC-1271，含 Certora 规格）——不必自写验证合约。落地 4 步：Enclave 内构造 WebAuthn 消息并把 challenge 绑定 safeTxHash → KMS ECDSA_SHA_256 签 → DER→(r,s) → 自行 low-s 归一 。它验的是 WebAuthn 断言结构 ，不是裸 P-256 over safeTxHash。
链侧前提已就绪：EIP-7951（P256VERIFY）status = Final ，随 Fusaka 于 2025-12-03 主网可用；成本 L1 6,900 gas（≈ecrecover 的 2.3×）。EIP 明确不要求 non-malleable → 应用层须做 low-s + 重放去重。原生 v=2 属下一个发布版 的路线图。
今天就想把云端/HSM 密钥接进链上多签：走官方 passkey signer + ERC-1271，不必等原生分支。
幕 4/11 · 第二层 Safe · delegatecall
一笔交易完成"代理升级"，多签从此消失delegatecall rewrites slot 0 → multisig gone
正常：slot 0 = 0x34Cf…（Safe 1.1.1 实现） 多签保护生效 delegatecall 到攻击者合约，其 transfer() 写 stor0 被改：slot 0 = 0xbDd0…（恶意实现） 签名校验逻辑本身被换掉 攻击者直接调 sweepETH() 不再走 execTransaction · 多签已消失 冷钱包 Safe 应只允许 operation=0（NoDelegatecallGuard，v1.3.0+ 才能装） 篡改的 JS 把 operation 从 0 翻成 1，data 伪装成 ERC-20 transfer(0xa9059cbb…)；因为是 delegatecall，被调合约的 transfer() 把值写进 SafeProxy 自己的 slot 0 → 实现地址被换。此后攻击者直接调新实现的 sweepETH()，签名校验逻辑本身已经被换掉 。
冷钱包 Safe 应只允许 operation=0；一条 NoDelegatecallGuard 就能挡住这一类——但它需要 v1.3.0+。
幕 4/11 · 第二层 Safe · 扩展点
每个扩展点都是攻击面every extension is an attack surface
扩展点 是否绕过 threshold 真实事故 加固 Module 完全绕过（无签名 / 无 threshold / 无 nonce） SquidRouterModule 2026-05（86 个 Safe / ≈$3.2M；另有 88 / $3.98M 口径）；Zodiac 2026-06（$1.5M） 白名单化 + v1.5.0 的 ModuleGuard + 定期 getModulesPaginated 对账 operation = DelegateCall 不绕过签名，但一次通过后永久摘除多签 Bybit $1.46B NoDelegatecallGuard；冷钱包只允许 op=0 approvedHashes (v=1) 等效门限 −1 源码级警告 执行者与签名者角色分离（用非 owner 的 relayer 提交） Fallback Handler 不直接绕过，但可伪造 isValidSignature — 仅用官方 handler，变更纳入变更管理
Safe 官方文档原文（2026-08 更新）："A malicious module can take over a Safe." 启用一个 module = 给它一把无门限的万能钥匙 。
整合场景的第一个 deliverable：盘点全部历史 Safe 的 singleton 版本 （读 slot 0 比对官方部署地址表），把 <1.3.0 的迁移到 1.4.1 / 1.5.0 ——Guard 是 v1.3.0 才有的，ModuleGuard 是 v1.5.0 才有的。
先出「全部 Safe 的 slot0 版本清单 + 迁移路线图」，再谈别的加固。
幕 4/11 · 第二层 Safe · Bybit 之后
对抗盲签：从 UI 告警升级到链上强制from UI alerts to on-chain enforcement
防线 A · 独立重算哈希 OpenZeppelin Safe Utils / Cyfrin safe-hash-rs——UI 完全被控时唯一仍有效 的手段。Lido 治理已把它制度化为两阶段验证。
防线 B · Clear Signing ERC-7730 ：v2 于 2026-04 发布，2026-05-12 治理移交 Ethereum Foundation （registry 由 EF 托管）。注：该 ERC 目前仍为 Draft 状态，但已有生产实现
防线 C · 链上强制 Safenet ：validator 产出 attestation → Safe 上的 Guard 在链上 验证后才放行。BFT 容忍 ≤1/3 作恶。Beta 阶段，不建议单独依赖。
完整阶梯还包含"交易模拟"与"意图/风险引擎"两级（Tenderly / Blockaid / Hypernative），此处只挑了三条与本场主线最相关的。
Ledger 引 Chainalysis 的一句判词，值得刻墙上：「最薄弱的一环不再是密钥存储，而是展示层。」
规模侧的反证（防止过度叙事）：Bybit 之后 Safe 的交易数与账户数 持续创纪录（Q2 2026 ≈130M 笔/季、63.4M 累计账户）；商业化上 2025 全年 ARR 由 $2M 增至 >$10M（2026-02 披露），Q2 2026 revenue $1.98M/+42% YoY。但同期受保护资产 QoQ −23% ——所以"创纪录"只对交易/账户口径成立。
最省钱、收益最大的一条：签名前端自托管 + 把"前端资产哈希变更"做成 P1 告警。
幕 5/11 · 组合的艺术 · 核心
把 MPC 输出，作为 Safe 的一个 ownerthe MPC output becomes one Safe owner
MPC 分片1 MPC 分片2 MPC 分片3 MPC 签出 1 个签名 （f(0) 不重构） owner₁ = MPC 输出 owner₂ = EOA owner₃ = EOA Safe 2-of-3 module 走小额 DeFi 两层的失效模式不重叠：MPC 层失守仍需凑够链上票数；链上被骗仍需 Enclave 内策略放行 机制很干净：MPC 那组分片跑完 TSS，产出一个标准签名、对应一个普通 EOA 地址 ；这个地址在 Safe 合约眼里跟任何硬件钱包地址没有区别，就是 owners 里的一项。Safe 完全不需要知道它背后是 3-of-5。
但要说准前提：叠加只在「Enclave 内固化了白名单/意图校验」时才成立 （见幕 7）。若 MPC 侧只是无条件对收到的 payload 签名，那它只是把同一份恶意 payload 又签了一遍——Bybit 若把 owner₁ 换成 MPC，结局不变 。
叠加的价值不是"多一层"，而是多一条不共享渲染管线的校验 ——这才是能挡住 Bybit 的那一层。
幕 5/11 · 组合的艺术 · 全片核心
三层组合架构：MPC + Safe + Maker-Checkerthe three-layer combined architecture
第三层 · Maker-Checker 审批 业务语义四眼 · 小额自动 / 超额多级审批 · 改配置也要过多签 第二层 · Safe 链上多签 多 owner 2-of-3 · MPC 输出作 owner₁ · Guard 拦 delegatecall · 链上可举证 第一层 · MPC / TSS 分片 私钥分片阈值签名 · Enclave 内运算 · KMS+PCR0 门控 · DKLs23/CGGMP24 攻击者需同时攻破 密码学 + 链上 + 人 · 三层组合业界尚未大规模落地 一个观察：主流钱包服务商普遍做到 MPC + 电子流审批两层 ，三层组合尚未见大规模落地——这既是差异化空间，也意味着没有现成的踩坑经验可抄 。小额高频自动执行，超额触发对应层级审批。
三层只有在信息路径彼此独立 时才真的等于三层——下一页把它量化。
幕 5/11 · 组合的艺术 · 关键洞见
t 与 k 是两个正交指标key independence vs cognitive independence
签名人1 真硬件钱包 · 真签名 签名人2 真硬件钱包 · 真签名 签名人3 真硬件钱包 · 真签名 同一条渲染管线 k = 1 t 与 k 是两个正交指标 t=3 密钥独立 · k=1 认知独立 攻击成本塌缩到「攻破 1 条管线」 t 仍是 3（攻击者确实取得 3 个真签名）；塌缩的是攻击成本，不是密码学门限 t = 密码学门限（密钥独立性）；k = 独立信息路径数（认知独立性——"签名者判断这笔交易是什么"的相互独立来源有几条）。Bybit 的 t 确实是 3（攻击者拿到 3 个真签名）；塌缩的是「攻击成本」——攻破 1 条渲染管线即可换到 3 个签名 。Radiant 是另一种形态：三台设备各自被攻破，但校验管线同构，效果相同。
推论（反直觉但有用）：k=1 时，加更多审批人、加更多模拟工具，边际收益接近零 。3/5 提到 5/7，攻击成本没变。所以钱包设计的核心 KPI 之一应当是提升 k ，而不只是提升 n。
这是本材料提出的分析框架，非既成业界定义；提出它是为了让"多签被攻破"这类事故可比较、可预算。
花在第 6 个审批人身上的钱，不如花在第 2 条独立信息路径上。
幕 5/11 · 组合的艺术 · 分析框架
三层正交：密码学 / 流程 / 呈现three orthogonal layers, none replaces another
呈现层（WYSIWYS） 每个签名人看到的，是否真的是他要签的？ 独立设备解码 · clear-signing · 第二渠道 流程层 这笔业务是否经独立复核与授权？ maker/checker · 角色互斥 · 冷静期 密码学层 密钥是否得到足够持份者授权？ MPC/TSS t-of-n · Safe 多签 · HSM 双人卡 三层正交，任一缺失另两层不能补偿（本文分析框架，非既成业界定义） 密码学层（t-of-n）+ 流程层（maker/checker）+ 呈现层（WYSIWYS，签名者看到的=他签的）必须同时成立 。Radiant 是"密码学有、流程有、呈现无"的教科书案例——多人复核与模拟都做了，但所有人读的是同一条管线。
与前面「第一层 MPC / 第二层 Safe / 第三层审批」是两套不同的切法：前者按技术组件 分，这里按失效维度 分。同一个 Safe 既属"第二层组件"，也承担"呈现层"的责任。
呈现层的独立性无法被密码学或流程补偿——这是 Bybit / Radiant 的共同解药。
幕 6/11 · 第三层 审批 · 金融本源
四眼原则：有判例支撑的控制族not "add an approval" — a control family
SWIFT CSCF v2026（可引用的合规锚点） Control 5.1 点名必须分离：Transaction submission ≠ approval ；且"改权限的权限也要分"以防管理员自己把四眼关掉；break-glass 必须成文、每次使用留记录、用后必须改密码 。Control 2.9 的五类交易业务控制，是钱包策略引擎的原始蓝图。
ISO/IEC 27001:2022 A.5.3 SoD 要求使单人无法同时执行并控制同一活动；"用不同设备执行不同职责"在 ISO 语境下是正统实现手段之一 ——这正好是呈现层独立性的合规依据。
CSCF 2.9 的原文是 *"any or a combination of the following"*，且 SWIFT 自述实施指引 *"should never be considered as an audit checklist"* → gap 分析应按 outcome / 等效控制 来论证，而不是逐条打勾。
我方建议 ：加密钱包的大额提币直接对标"六眼"（比四眼更高一档）。（SWIFT 原文只在举例中承认存在高于四眼的档位，并未给出定义条目。）
向监管解释审批流时，引 CSCF 5.1/2.9 与 ISO 27001 A.5.3，比引任何厂商白皮书都硬。
幕 6/11 · 第三层 审批 · 关键论证
门限 t-of-n ≠ maker/checker（三条独立论证）why a cryptographic threshold isn't four-eyes
📄
① 对内容不可知 t-of-n 只证明"有 t 份材料签了某个 32 字节 digest"，不对 digest 的语义作任何断言 。maker/checker 恰恰只处理语义（收款方 / 金额 / 是不是 transferOwnership）。两者定义域不重叠。
🔀
② n 是密钥独立性，不是信息独立性 门限被完整满足，但所有签名者读同一条渲染管线时，攻击成本塌缩到"攻破一条管线"。
👤
③ 管不了"谁发起" 若同一人既是发起者又是审批者，t-of-n 依然满足。所以厂商必须显式 提供 SoD 开关。
这就是为什么密码学门限与业务审批是两个正交层，必须叠加 ——只做前者，会出现"人批了，但看错了东西"。
四眼原则被写进代码，就是那个布尔开关：不允许发起人自批。
幕 6/11 · 第三层 审批 · 闭环
改配置本身，也要过多签reconfiguring the wallet also needs multisig
改 MPC 分片 reshare ceremony 需原阈值签名 改 Safe owner swapOwner 需现有阈值批准 改风控规则 走 Maker-Checker 多级审批 改 KMS 授权 / Guard 高权限操作 实时监控告警 前提：Guard 已封住 delegatecall（否则可绕过 owner 变更流程直接改 storage） 闭环成立后，内鬼即便拿到 admin 也难以单点全端 回应一个常见的攻击设想（"内鬼把人踢掉"）：改 MPC 分片需 reshare ceremony（原阈值签名） ；改 Safe owner 只能通过 Safe 交易（现有阈值批准） ；改风控规则走 Maker-Checker ；高权限操作（KMS 授权 / Guard 变更）配实时监控告警。
前提必须说清：这个闭环成立的条件是 Guard 已封住 delegatecall 。否则攻击者不必走 swapOwner 流程——一笔 delegatecall 就能直接改写 owners 所在的 storage，把整个闭环绕过去。先有 Guard，才有闭环。
闭环成立后，内鬼即便拿到 admin 也难以单点全端；但闭环的地基是 Guard。
幕 6/11 · 第三层 审批 · 策略引擎
策略引擎的默认态陷阱the default-state traps
厂商 求值语义 最危险的默认 SoD 开关 Fireblocks 规则顺序匹配 需显式建规则 授权组内含"发起人可否兼审批"的开关 Fordefi first-match-wins ⚠️ 出厂默认策略不要求审批 Admin Quorum 管策略变更 Turnkey 全量求值，DENY 恒胜 默认隐式 DENY（最安全） consensus 表达式（人数 + 角色） Dfns 全量求值，Block 恒胜 ⚠️ 默认全允许，且无 Allow 动作可反悔 initiatorCanApprove 默认 falseCobo 按 priority 命中即停 预置一套默认策略 手册明文禁"同角色既提币又审批" BitGo 交易发起时全量校验 含客户不可移除的强制策略 最佳实践明文要求发起/审批分离
越权升级路径必须无缝且单调 ：first-match-wins 的引擎最常见的致命错配是规则顺序颠倒——把宽松的 ALLOW 放在严格的"需审批"之前，则大额交易命中第一条即放行。把策略当代码测：property-based 断言"金额单调递增 → 所需审批数单调不减"，任何反例都是一个可套利的缝。
各厂商具体字段名与语义以官方样例 + 推断为准，建议在客户自己的工作区实测确认 （部分字段的语义在官方文档中未给出定义条目）。
审计第一步：把策略导出成 JSON，grep 那个"允许发起人兼审批"的开关。
幕 6/11 · 第三层 审批 · AWS 落地
Step Functions 审批控制平面the approval control plane on AWS
maker 发起 运营门户 Step Functions（.waitForTaskToken） ① 白名单 + 冷静期 ② AML 筛查（降级须留痕） ③ Travel Rule（签名前完成） ④ 金额/资产分级路由 ⑤ 人工审批（maker 被排除） 签名面（最小面） Nitro Enclave + KMS task token 只能同账号主体回传 · 全程 CloudTrail + S3 Object Lock（连 root 都删不掉） Step Functions Standard + .waitForTaskToken ：可暂停至执行时长配额（1 年），task token 只能由同账号主体回传 （跨账号伪造无效）。S3 Object Lock Compliance 模式 ：保留期内连 root 都删不掉——审计证据桶必须用 Compliance 而非 Governance。
AML「Skip on failure」是个静默降级陷阱：提供方宕机时放行，必须①打独立标记（SKIPPED_PROVIDER_UNAVAILABLE，绝不复用 PASSED ）②降级期自动收紧 审批档位 ③窗口关闭后批量回溯筛查。否则"没查过"和"查过没事"在下游长得一模一样。
审批 App 必须是独立的第二条信息路径——这是把 k 从 1 提到 2 最省钱的做法。
幕 7/11 · 资金架构 · 蓄水池
三层出入金蓄水池架构the reservoir model
① 对外接入层 每客户独立地址 · KYT/AML 分批 Sweep（选 Gas 低谷） ② 蓄水池主池 核心资金池 · 重中之重 ③ 出金小池（热钱包） 小额直出 · 大额从主池调拨 ④ DeFi / 质押 MPC 管不了合约钱包 → 叠 Safe 最高频、最高风险 = 主池 + DeFi 蓄水池有两个出发点：①反洗钱 ——入金先到每客户独立地址过 KYT/AML，命中制裁名单就弃用该地址，不污染主池；②客户资金隔离 便于管理。出金不从主池直出，而是主池调拨到出金小池（热钱包属性）。DeFi/质押场景 MPC 管不了智能合约钱包，需叠加 Safe。
最高频、最高风险的两层是蓄水池主池 与DeFi ——加固预算应该按这个顺序排。
幕 7/11 · 资金架构 · 风控落点
风控规则可以落在三个地方where the rules actually live
🔒
① 固化进 Enclave 镜像 写进 EIF 。改代码 → PCR0 变 → KMS 拒绝解密。最强，但每次改规则都要走发布流程。 这也是幕 5 那个"叠加前提"的落点。
🗄️
② 加密存 DynamoDB KMS 加密，解密权限只给特定 PCR0 的 enclave。可改但受门控，改需授权。灵活性与强度的折中点。
⛓️
③ 链上（Guard / 合约） 链上规则，可改但链上可见 ——配监控，admin 一动就看得到。
一个需要显式披露的取舍 ：若把两个 MPC 分片放在同一台宿主机 的不同 Enclave（常见的简版起步形态），密码学门限虽在，但宿主机与其运维人员成为单一失效点 ——它是"先跑通流程"的合理起点，不是目标形态 。目标形态：分片跨账号 / 跨可用区 / 跨主体分布。
技术上锁死越彻底，运维越重；务实做法是技术保底 + 管理跟上 + 高权限操作全监控。
幕 8/11 · AWS 落地 · 边界
Nitro Enclave + KMS 替 HSM：热可以，客户冷不行hot yes, client cold no
✔ 能做（已有一手生产先例）
热钱包在线签名 ——Turnkey / Privy / Fireblocks cosigner / ACINQ / Crypto.comMPC/TSS 分片运算、validator 远程签名、策略引擎、暖钱包
密钥不可导出、只有被度量的代码能用、每次使用有 CloudTrail 密码学证据
✘ 不能做
客户冷钱包（HK ≥98% 那部分） ——Nitro Enclaves 没有任何 CMVP 证书 SFC 通函引述《VATP 指引》para 10.8：在可行情况下应 离线生成并存于具适当认证的 HSM——"appropriate certification" 是硬门槛，Nitro 拿不出
同一份通函还要求冷钱包避免使用公链智能合约 → Safe 类合约多签不能顶替冷库
所以我们把边界说清：热层可以论证；客户冷钱包这一层，AWS 今天做不到 ；暖 / 自营 / validator 是 Nitro 性价比最高的地带。
把做不到的部分讲在前面，剩下的论证才有分量。
幕 8/11 · AWS 落地 · 门控机制
改一行代码 → PCR0 变 → KMS 拒绝解密the core mechanism that replaces the HSM
Nitro Enclave 无网络 · 无持久化 · 无 SSH attestation doc（含 PCR0） 改一行代码 → PCR0 变 attested AWS KMS 校验 PCR0 = ImageSha384 门控 5 操作（分属三套配额） GenerateDataKeyPair secp256k1 仅 100 rps PCR0 不匹配 → 拒绝解密 正解：种子在 enclave 内解密一次后常驻内存，用 BIP-32/44 派生 —— 不要每笔打 KMS 私钥以"被 KMS 加密的密文"存放（S3/DynamoDB），只有 PCR0 匹配 的 enclave 镜像能解出来。attestation 门控 5 个操作 ：Decrypt / DeriveSharedSecret / GenerateDataKey / GenerateDataKeyPair / GenerateRandom。每次解密写入 CloudTrail （含 PCR 记录）——正好对应通函对代码治理与审计留痕的要求。
架构评审级约束 ：这 5 个操作分属三套配额——Decrypt/GenerateDataKey/GenerateRandom 走对称共享配额（香港区 10,000 rps）；DeriveSharedSecret 走 ECC 共享 1,000 rps；GenerateDataKeyPair 按 key spec 独立配额，secp256k1 与各 NIST 曲线仅 100 rps 。若设计成"每个用户钱包现场 GenerateDataKeyPair"，天花板就是 100 rps。 正解：种子在 enclave 内解密一次后常驻内存，用 BIP-32/44 派生。
代码的哈希，就是解密的钥匙——但别把 KMS 放在每笔交易的热路径上。
幕 8/11 · AWS 落地 · 2026 增量
两条新路径：降门槛 + 覆盖多链two 2026 upgrades
🖥️
EC2 Instance Attestation（2025-09-23 GA） NitroTPM + Attestable AMI，把整台 EC2 实例 做密码学度量并与 KMS 集成（条件键 NitroTPMPCR 4/7/12，门控同样那 5 个操作）。对"不想把签名服务重构成 enclave"的团队是实质性降门槛。
🔑
KMS 原生 Ed25519（2025-11）+ ML-DSA（2025-06） KMS 曲线全集：P-256/384/521 / secp256k1 / Ed25519 。Solana / Sui / Aptos / NEAR / Stellar / TON 可原生用 KMS 签名 ，不必自建 Ed25519 签名器。ML-DSA 为抗量子留好接口。
两条可证明执行环境的路径并存：Nitro Enclaves （隔离最强，需拆分应用）vs EC2 Instance Attestation （整机度量，改造小）。选型看你愿意为隔离付多少改造成本。
2026 之后，不必为了签名把整个服务塞进 enclave——整机 attestation 是新选项。
幕 8/11 · AWS 落地 · 设计评审
"用了 Enclave + KMS" ≠ 安全Trail of Bits, 2026-08-05
被动攻击 checklist（宿主机为敌）
Encrypt / ReEncrypt 不受 attestation 保护 → CMK 只做信封 data key，不直接做业务加密attestation 时间戳只校验"≤5 分钟"且未与请求内容绑定 → 存在 5 分钟重放窗口
user_data / nonce 被 KMS 完全忽略 → 请求级绑定只能靠 enclave 内自建 TLS所有请求都带 Recipient；用 encryption context
主动攻击 checklist + 运营建议
CMK 全 ARN 硬编码进 EIF （因而被 PCR0 度量），显式传 keyId 并校验响应，禁用 alias 把 enclave 的 IAM role 也纳入度量 ，运行时 sts:GetCallerIdentity 自校验
enclave 内自建 TLS 并把 CA 打包进 EIF（因而被度量）
诚实告知：KMS key policy 可被 AWS Support 恢复默认 —— 要真正端到端可验证，须走"主密钥不托 KMS"的路线
⚠️ 一个现实提醒：AWS 官方钱包参考实现仍依赖 ToB 建议弃用的 aws-nitro-enclaves-sdk-c——照抄参考实现需自行做这项风险评估。
把这两张 checklist 当设计评审表；缺了它，方案在"宿主机为敌"的威胁模型下不成立。
幕 8/11 · AWS 落地 · 设备与通道身份
把签名设备 / 审批终端，当"设备"来管device identity for signers & approvers
签名设备 / 审批终端 X.509 短命证书 TPM/SE + 可信显示 IoT Core / Roles Anywhere 证书 → STS 临时凭证(900s) 无长期 AK/SK KMS / Nitro Enclave PCR0 门控签名 Fleet Provisioning claim 证书 5 分钟过期 IDC 零迁移接入：Roles Anywhere 当天消掉长期密钥（信任边界是账户级，须写 trust policy 条件） IAM Roles Anywhere ：IDC 未上云场景的零迁移第一步——X.509 证书换 STS 临时凭证，当天可做、消掉 IDC 里全部长期 AK/SK 。⚠️ 信任边界是账户级 ：不在 role trust policy 里写证书条件，一个 trust anchor 就能假设账户内任意角色。Fleet Provisioning by trusted user ：临时 claim 证书 5 分钟过期 = 天然的"双人在场发卡仪式"，把调用权做成 maker/checker 即得到可 CloudTrail 审计的密钥仪式。
事实 ：AWS IoT Device Defender 的 Detect 功能自 2026-08-31 起不再对新客户开放 （Audit 不受影响，官方文档一手）。我方推断（非 AWS 承诺） ：可在此前启用一个最小 security profile 争取"既有客户"资格——AWS 并未定义该资格的判定口径，须由 account team 书面确认 。因此把自建行为检测 pipeline 列为主路径 更稳。
FIDO2 的"物理在场"限制需说准：AWS 官方限定 passkey/安全密钥仅在 Management Console 支持 ，CLI/API 与 MFA-protected API 不支持 → 它排除的是"通过 VDI/远程桌面登录控制台"，不能用来门控自建签名 API ；防盲签仍要靠可信显示类设备。另：用 IoT 设备身份框架管钱包签名设备无公开先例 ，这是本材料的原创架构提案（强邻证：Ledger PSD、支付业 TR-34 远程密钥注入）。
先做 Roles Anywhere（当天见效），再谈设备控制面——顺序反了会卡在改造上。
幕 8/11 · AWS 落地 · 账
FIPS 等级与成本：量级差约 5 倍the numbers behind "replace HSM"
方案 认证（含时效） 香港区 HA 双份月成本 适用 Nitro Enclave + KMS Enclave 无 CMVP ；enclave 内可跑 FIPS 140-3 L1 软模块；底层 KMS HSM 为 140-3 L3（#4884，Interim validation，sunset 2026-11-17 ） ≈$640/月（2× c6i.2xlarge + KMS） 热 / 暖 / validator CloudHSM hsm2m.medium FIPS 140-3 L3，CMVP #4703，sunset 2029-06-05 ≥$3,168/月（2 HSM × $2.17/h） 需"certified HSM"字样；冷根仪式（按需启停 可压到 $2–4k/年） 外部 HSM（自建 / colo） 通常 L3 / CC（逐型号核 CMVP） 数万美元级 capex + opex 监管强制物理主权
两条必须主动说出来的话：①用 KMS 签 secp256k1 属 CMVP 的 allowed 而非 approved ——#4884 明文限定 "secp256k1 may only be used in block-chain related applications"（反过来也是个故事：CMVP 已为区块链开了具名口子）；②KMS HSM 的几张 Active 证书 sunset 集中在 2026-09 与 2026-11 ，后继仅在 IUT 阶段 → 建议把这两个日期写进客户风险登记册。
成本口径：两侧均为下界 （未含 NLB / NAT / EBS / 跨 AZ 传输 / 人力；CloudHSM 侧未含客户端实例）→ "5 倍"是量级结论，不是报价 （实算 4.98×）。旧 hsm1.medium 按 AWS 公示计划已于 2026-03-31 EOS；AWS 只承诺"开始自动迁移"，未公布完成状态。⚠️ AWS Payment Cryptography 不能 做区块链签名（无 secp256k1/Ed25519，KeyUsage 为 TR-31 支付语义）。
Nitro 零附加费 + CloudHSM 按需启停，是"替 HSM 降本"的两把钥匙。
幕 9/11 · 合并上云 · 六件事
"找个新地址转进来"只覆盖六分之一"merging wallets" is six independent things
工程难度 / 不可回滚性 → 失败后果 ↑ 资产归集 热钱包资产 风控/审批流合并 签名人名册 密钥体系统一 用户历史充值地址 「找个新地址转进来」只覆盖左下角最容易的一件；右上角三件才是真正的成本与风险 成本分布是倒过来的：资产归集 最容易且可回滚（钱还在自己手里）；而用户历史充值地址处置 技术上最简单、业务上最致命——用户可能在合并完成 18 个月后还往旧地址打钱；密钥体系统一 则涉及密码学层面的硬约束（下一页）。
合并钱包不是一个动作，是六件难度、可回滚性完全不同的事——先排序，再动手。
幕 9/11 · 合并上云 · 密钥路径
密钥体系统一：四条路径，代价各不同four paths, very different costs
P1 新建 + 迁移 新 DKG + 链上迁资产，地址变 。跨厂商的默认 选择，总是可行。
P2 Key copy（同厂商） 把同一把密钥重新分享给新参与方 + 新阈值，地址不变、资产不上链移动 ，可把旧签名人整组换掉。尽调第一个问题：双方是否同一 MPC 平台。
P3 双体系并存 + 统一编排 过渡期必选，也是 sunset 旧充值地址期间的唯一办法。
P4 主密钥导入 部分平台支持 ImportKey（含 raw secp256k1 + BIP32 chain code）→ 导入对方 BIP32 主密钥后即可接管全部历史充值地址 ，sunset/sweeper/强制换址都不再必要。代价：私钥必然明文 materialize 一次 。
P4 的代价必须讲透：需气隙 ceremony + 双人控制 + 全程留证；而且"对方的密钥能被导出"这件事本身就是尽调红旗 ——它同时说明对方过去也能导出。数学上那句仍然成立：不能把两把独立私钥合成一把、还让原有两组地址都继续有效 。
最重要的战术建议：「新建+迁移」与「IDC 密钥上云」在密码学上同构（非导出密钥只能换密钥）→ 把整合与上云合并成同一次密钥切换 ：一次 ceremony、一次迁移、一次公告、一次审计。分两次做成本翻倍、风险不减半。（补一条准确归因：AWS KMS/CloudHSM 本身支持非对称密钥导入，阻断点在源侧 CKA_EXTRACTABLE=false 与治理代价。）
reshare 三坑：删光 presignature / 与签名并发会报 epoch 错（当天须冻签）/ 旧备份立即失效，用旧备份恢复会让整把密钥不可用 。
幕 9/11 · 合并上云 · 迁移风险
地址投毒 + 通函对整合的硬约束poisoning & the regulatory constraints
地址投毒：两条并行控制
规模（CMU 学术）：2022-07→2024-06 在 ETH+BSC 上 270M 次尝试 / 6,633 笔成功 / ≥$83.8M 损失
① 大额前必发小额测试笔 + 独立信道确认收款方（Chainalysis 明确背书这一实践：测试笔没到账，正是它阻止了更大损失）
② 目的地址只能取自白名单 ，禁止从交易历史 / 最近联系人里选 ——投毒地址就是靠"长得像"混进历史记录的；全长逐字符复核
通函（25EC44）对整合的约束
授权人员变更之前 就要做攻击面评估（§III(8)(a)）→ 换签名人不是事后补文档冷钱包避免使用公链智能合约 → 若一方用 Safe 当冷库，须下移到暖/热层
第三方钱包方案须独立代码审查 + 了解其 SDLC → 接管另一方自研代码正落此条，通常需 8–12 周，要排进关键路径
链上资产与账本应做实时对账 （原文为 should）+ 7×24 监控
交割后 72 小时内：revoke 全部遗留 ERC-20/NFT approval + 清查 Safe module/guard；离职签名人先 reshare 作废分片、再办离职。
幕 10/11 · TCO 与合规 · 账
临界点主要由议价费率决定，不由规模决定the break-even is set by your negotiated bps
交易量 / AUM → 年成本 自建（固定 TCO） 外购 20 bps（入门档列表价） 外购 5 bps（议价后） 临界点（随费率右移 4×） bps 为入门档列表价、企业档未公开；临界点主要由议价费率决定，不由规模决定 先说清口径 ：公开可见的 0.10%–0.25% overage 都属自助/入门档列表价 （例如某家是 $999/月、最多 6 个月的入门档），企业档 overage 一律 Custom、未公开 。所以正确说法不是"20 bps 的确定成本"，而是按量计费的结构性风险 ：同样的年外发量，5 bps 与 20 bps 之间差 4 倍，而这个倍数决定了自建的临界点。
做个数量级推演（假设年外发 $500B，仅为反证，未证实） ：20 bps = $1,000M/年，量级上已超主流托管商全年营收——这解释了为什么头部机构必然自研。另注意：部分厂商是 AUC 费 + 外发量费两条线相加 再与月度最低取大，单基数公式只是保守下界 。
先建自建 TCO 模型，它本身就是你和厂商谈 bps 时最强的筹码。
幕 10/11 · TCO 与合规 · 第三条路
买密码学，不买托管buy the crypto, not the custody
开源 + 已审计的 MPC 库 如 Silence Labs 的 DKLs23 实现（Trail of Bits 审计并公开复盘）。避开 Paillier 相关的一类漏洞面 ——注意：这不等于避开全部实现层漏洞 （CGGMP-21 的实现同样被 α-shuffle 打穿过）。
可私有化部署的商业方案 如 Dfns（Enterprise 为 on-prem，明示"No AUM fees. No transaction fees."）、Cordial Systems（on-prem，2026-03 取得 SOC 2 Type II）。把 bps 从成本结构里删掉。
选型时必查的两件事 ① TEE 生态是否一致 ——有的私有化 MPC 基于 Intel SGX ，而 AWS 不提供 SGX 实例，与 Nitro 路线需二选一；② 厂商归属是否变更 ——本领域并购频繁（如 Sodot 已于 2026-04-29 并入 MoonPay Institutional），合同必写 change-of-control。
反直觉但重要：把冷钱包外包是最贵的组合 ——监管强制冷存比例高（HK ≥98%），而 AUC 计费基数是存量 ，等于把 98% 的资产送进最贵的计费口径；而冷钱包恰恰最容易自建 （低频、可离线、CloudHSM 按需启停）。方向应该反过来：冷自建 + 热的签名原语买许可。
不是"自建 vs 外购"二选一——第三条路是买密码学能力，自留托管与策略。
幕 10/11 · TCO 与合规 · 合规地图
25EC44 六大类 = "行业标准"的官方答案the checklist you can actually cite
25EC44 六大类（2025-08-15 即时生效）
① 指定 RO/MIC 专责统管（组织层，最容易漏）
② 冷钱包基础设施：HSM 供应商尽调 + 避免公链智能合约
③ 冷钱包运营：气隙生成 + 须有控制措施防止盲签
④ 第三方钱包：独立代码审查 + 了解 SDLC
⑤ 持续监控：链上-账本实时对账 + 7×24 含假日
⑥ 员工培训：签名核验与异常处置
多辖区冷存对照
辖区 冷存 动向 HK SFC ≥98% 2026 拟设独立托管牌照，无过渡期 MAS SG ≥90% 移动客户资产须新加坡居民高管控制 日本 JFSA ≥95% 拟取消冷钱包豁免 + 监管钱包供应商 FATF — Travel Rule 立法覆盖 83%，但全面合规仅 1 个辖区
≥98% 与"赔偿覆盖冷存 50%/热存 100%"源自 2023-06《VATP 指引》，25EC44 是细化而非替换。
⚠️ 一个高频误传：25EC44 通函里没有任何"12 小时恢复"要求 （该数字来自别处，勿并入合规清单）。成熟度自评建议用 CCSS v9.0 + SWIFT CSCF v2026 ；引用 CSCF 前请复查当期版本（每年 7 月发布次年生效）。
被问"我的方法论符不符合行业标准"——逐条对照这六大类，就是可交付的答案。
幕 11/11 · 前沿 · AI Agent 风险
AI Agent 投毒：0.2%–0.5% 的概率炸弹the poisoning probability nobody wants to hear
内部实测：特定上下文下存在 0.2%–0.5% 的概率，诱导模型生成伪装成管理员 的恶意操作指令——数千次测试中出现过模型自称管理员、要求 rm -rf 某路径（被工具侧拦住）。若钱包审批或规则配置环节引入 AI agent，就存在被触发投毒逻辑、自动执行小额异常转账的风险。
正确姿势 不要把 AI 放在决策链的关键路径上 。AI 适合"异常打分 + 自然语言摘要"，判定权必须交给确定性规则 + 链上 Guard 。小额自动审批阈值以下的路径，恰恰是投毒最容易变现的地方。
业界对应物已产品化 意图级签名前置评估（如 Chainalysis GateSigner）："评估交易在做什么，而非谁签的 "；实时风险引擎在 Venus（2025-09）实现攻击前 18h 告警、12h 全额追回，攻击者净亏。
"签名前用 AI 预演交易最终出向"的正解 = 交易模拟 + Clear Signing，而不是让 AI 拿判定权。
幕 11/11 · 落地
下一步：可选路径与取舍options and trade-offs
场景 A · 自建替代第三方托管
协议选 DKLs23 或 CGGMP24（注意实现侧仅 alpha），不从 GG18 起步 ；IA 单独落实
KMS + Nitro Enclave（或 EC2 实例证明），过 ToB 两张 checklist 逐条评审
成本上最优常是买密码学、不买托管 （省下 bps，保留主权）
最省钱的一条：审批 App 做成独立的第二条信息路径 （把 k 从 1 提到 2）
场景 B · 整合 + IDC 未上云
零迁移第一步：IDC 接 IAM Roles Anywhere ，当天消掉长期 AK/SK（记得写 trust policy 条件）
先问双方是否同一 MPC 平台 ——它决定走 P1 还是 P2/P4，是最大的成本分叉点
整合第一优先级是策略与角色归一 ，不是密钥迁移；先冻结、再取并集从严
把整合与上云合并成一次密钥切换 ；逐条对照 25EC44 六大类
以上为通用场景化建议；具体标的、钱包资产范围与时间表需按各自实际情况书面确认后再细化。
「假如说你多层，就没那么容易被攻破。」 「你又不能锁太死，锁太死没法用了；但你又要保证安全、保证可用性、防止失能。」——安全与可用性，要同时握住。
下一步建议：红蓝对抗 + 攻防 workshop，用演示让三层架构的价值看得见。