返回 Expert 笔记
Expert Day 9

加密货币机构托管 - Fireblocks深度

### 1.1 Fireblocks公司概览

2026-05-10
Phase 1 - TradFi基础设施深度 (Day 1-14)
机构金融FireblocksMPCPolicyEngineInstitutionalCustody

日期: 2026-05-10 方向: 机构DeFi / RWA 阶段: Phase 1 - TradFi基础设施深度 (Day 1-14) 标签: #机构金融 #Fireblocks #MPC #PolicyEngine #InstitutionalCustody

今日目标

类型内容
学习Fireblocks架构、MPC算法、Policy Engine设计、Fireblocks Network
实操阅读Fireblocks API文档，画"Fireblocks技术栈架构图"
产出Fireblocks架构深度解读 + 与TradFi托管映射

一、核心概念

1.1 Fireblocks公司概览

  • 创立: 2018年, by Michael Shaulov + Idan Ofrat + Pavel Berengoltz (前Check Point高管)
  • 总部: New York
  • 估值: $8B (2022 Series E)
  • AUC通过Fireblocks: $7T+ 累计交易量 (2024)
  • 客户: 2000+ 机构 (BNY Mellon, BNP Paribas, Revolut, Galaxy, Tower Research等)
  • 覆盖: 100+ blockchains, 1500+ tokens
  • 技术核心: MPC-CMP (Multi-Party Computation - Cooperative Multi-Party)

1.2 为什么Fireblocks赢得机构市场

  机构托管/钱包技术演进:
  
  Gen 1: Hot Wallet (Coinbase early)
    - Single private key
    - 风险: 私钥泄露=资产清零
    
  Gen 2: Cold Storage (BitGo early)
    - 离线private key
    - 风险: 操作慢, 恢复难, 仍single-point
    
  Gen 3: Multi-Signature (Gnosis Safe, BitGo)
    - On-chain多签
    - 优: 链上原生安全
    - 缺: gas贵, 跨链不一致, on-chain透明
    
  Gen 4: HSM-Based (银行级)
    - Hardware Security Module
    - 优: 物理安全
    - 缺: HSM成单点
    
  Gen 5: MPC (Fireblocks/Coinbase Custody/Anchorage)
    - 私钥从未完整存在 (split shards)
    - 优: 无单点, 跨链统一, 链下签名
    - 这是当前机构市场标准

  Gen 6 (实验中): MPC + TEE + ZK proofs

1.3 MPC核心原理

Multi-Party Computation = 多方计算: 多个参与方各持有数据片段，共同计算结果而不暴露各自的数据。

  Traditional Multi-Sig (on-chain):
   User A signs ──► Tx
   User B signs ──► Tx
   User C signs ──► Tx
   ↓ on-chain verifies (need 2-of-3)
   ↓ 链上记录: 3 signatures visible

  MPC Threshold Signatures (off-chain):
   Party A computes share_A
   Party B computes share_B
   Party C computes share_C
   ↓ MPC protocol generates ONE signature
   ↓ on-chain: looks like single-key wallet
   ↓ 私钥从未完整存在过

1.4 MPC vs Multi-Sig对比

维度On-chain Multi-SigMPC Threshold Signatures
链上可见多签门槛+签名者看起来像单签钱包
隐私暴露签名者结构完全私密
Gas成本高 (~3-5x单签)单签级
跨链一致各链需独立部署一套MPC支持所有链
升级链上合约升级链下软件升级
灵活性链上规则固定链下Policy灵活
无新地址加签者需新地址Threshold可调 (refresh)
链上认证强 (合约可验证)弱 (链上看是单签)
兼容性仅支持的链任何ECDSA链

二、Fireblocks架构

2.1 整体技术栈

┌──────────────────────────────────────────────────────────┐
│           Customer Front-End                              │
│  ┌─────────────┬──────────────┬──────────────┐           │
│  │  Web Console │  Mobile App  │  REST/Webhook│           │
│  │              │  (approval)  │  API         │           │
│  └─────────────┴──────────────┴──────────────┘           │
└──────────────────────────────────────────────────────────┘
                          │
┌──────────────────────────────────────────────────────────┐
│           Fireblocks Cloud Service                        │
│                                                            │
│  ┌──────────────────────────────────────┐                │
│  │   Workspace Manager                   │                │
│  │   - User/Role management              │                │
│  │   - Audit log                         │                │
│  └──────────────────────────────────────┘                │
│                                                            │
│  ┌──────────────────────────────────────┐                │
│  │   Policy Engine (TAP/Co-Signer)      │                │
│  │   - Transaction Authorization Policy │                │
│  │   - Whitelist/blacklist                │                │
│  │   - Velocity limits                  │                │
│  │   - Amount thresholds                │                │
│  │   - Time windows                     │                │
│  └──────────────────────────────────────┘                │
│                                                            │
│  ┌──────────────────────────────────────┐                │
│  │   Compliance Layer                    │                │
│  │   - Chainalysis/TRM integration      │                │
│  │   - Travel Rule (Notabene)           │                │
│  │   - AML alerts                       │                │
│  └──────────────────────────────────────┘                │
│                                                            │
│  ┌──────────────────────────────────────┐                │
│  │   Asset Connectivity Layer            │                │
│  │   - 100+ blockchains                  │                │
│  │   - 1500+ tokens                      │                │
│  │   - 50+ exchanges (CEX integration)   │                │
│  │   - 100+ DeFi protocols (Web3 access) │                │
│  └──────────────────────────────────────┘                │
└──────────────────────────────────────────────────────────┘
                          │
┌──────────────────────────────────────────────────────────┐
│       MPC Signing Layer (distributed)                     │
│                                                            │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐                │
│   │ MPC Node │  │ MPC Node │  │ MPC Node │                │
│   │  (FB AWS)│  │  (FB GCP)│  │  (Cust.)  │                │
│   │ HSM-backed│ │ HSM-backed│ │ HSM-backed│                │
│   └──────────┘  └──────────┘  └──────────┘                │
│       Cooperative MPC Protocol Communication              │
└──────────────────────────────────────────────────────────┘
                          │
┌──────────────────────────────────────────────────────────┐
│       Blockchain Networks                                  │
│   Bitcoin │ Ethereum │ Solana │ Polygon │ Arbitrum │...   │
└──────────────────────────────────────────────────────────┘

2.2 MPC-CMP (Cooperative Multi-Party)

Fireblocks的核心专利技术，2020年发表。

关键创新：

  • non-interactive signing for ECDSA & EdDSA
  • single round signing 比传统MPC快10x
  • scalable to many parties (3+ shards typical)
  • proactive secret sharing 定期refresh shards

典型部署：

  • 3 MPC nodes:
    • Node 1: Fireblocks SaaS (AWS region 1)
    • Node 2: Fireblocks SaaS (AWS region 2 or GCP)
    • Node 3: Customer-controlled (Co-Signer or HSM)
  • 2-of-3 threshold typical
  • Customer alone不能签 (Fireblocks shards alone也不能)
  • Fireblocks内部不同region两个node需要被攻陷+客户node也被攻陷=完整签名

三、Policy Engine 深度解析

3.1 Transaction Authorization Policy (TAP)

Fireblocks的"链下智能合约"——所有交易必须通过Policy。

# 简化的Policy YAML示例

policies:
  # Rule 1: 大额转账需要多人审批
  - name: "Large transfer approval"
    condition:
      asset: ANY
      amount_usd: ">100000"
    action: REQUIRE_APPROVAL
    approvers:
      - role: CFO
      - role: CTO
      - quorum: 2_of_2
    
  # Rule 2: 白名单地址限制
  - name: "Outbound whitelist"
    condition:
      direction: OUTBOUND
      destination: NOT_IN whitelist_addresses
    action: BLOCK
    
  # Rule 3: 日累计限额
  - name: "Daily limit per asset"
    condition:
      asset: BTC
      time_window: 24h
      cumulative_amount: ">10 BTC"
    action: BLOCK
    
  # Rule 4: 工作时间限制
  - name: "Outside business hours"
    condition:
      time: NOT_IN "Mon-Fri 9-17 UTC"
    action: REQUIRE_APPROVAL
    approvers:
      - role: ON_CALL_OPS
    
  # Rule 5: 制裁筛查
  - name: "OFAC screening"
    condition:
      destination_risk_score: ">75" (via Chainalysis)
    action: BLOCK
    notify: [COMPLIANCE_TEAM]

  # Rule 6: DeFi交互
  - name: "DeFi protocol whitelist"
    condition:
      tx_type: SMART_CONTRACT_CALL
      contract: NOT_IN approved_defi_contracts
    action: REQUIRE_APPROVAL
    approvers:
      - role: HEAD_OF_DEFI_DESK

3.2 Policy Engine数据流

  User initiates transaction (UI/API)
     │
     ▼
  ┌──────────────────────────┐
  │ Pre-execution validation │
  │ - Asset/amount/destination│
  └──────────────────────────┘
     │
     ▼
  ┌──────────────────────────┐
  │ Compliance check          │
  │ - Chainalysis risk score  │
  │ - Travel Rule check       │
  └──────────────────────────┘
     │
     ▼
  ┌──────────────────────────┐
  │ Policy Engine evaluation  │
  │ - Match all rules         │
  │ - Determine action         │
  └──────────────────────────┘
     │
     ├─── BLOCK → Reject + notify
     ├─── ALLOW → Proceed to MPC signing
     └─── REQUIRE_APPROVAL → Wait
            │
            ▼
       ┌──────────────────────────┐
       │ Approval workflow         │
       │ - Notify approvers (App)  │
       │ - Collect approvals       │
       │ - Quorum check            │
       └──────────────────────────┘
            │
            ▼
       MPC signing → Broadcast to chain
            │
            ▼
       Audit log (immutable)

3.3 Co-Signer (客户自托节点)

机构客户可以运行自己的Co-Signer:

  • Hardware: SGX/HSM硬件
  • 软件: Fireblocks提供的MPC client
  • 部署: 客户自己DC or AWS Nitro Enclave
  • 价值: 即使Fireblocks被全攻破, 客户node仍是必要门
  • 类比: "客户银行保险柜的钥匙之一"

四、Fireblocks Network

4.1 什么是FB Network

Fireblocks Network = 2000+机构间的加密资产路由层, 类似SWIFT for Crypto。

  Concept:
  Member A wants to send to Member B
  ↓
  Both已在Fireblocks Network内
  ↓
  No need to manage destination address
  ↓
  Settlement via Fireblocks routing
  ↓
  Faster + safer + compliant

4.2 FB Network核心功能

功能描述
Address Discovery不需要交换钱包地址, 只需Network ID
Travel Rule自动交换compliance data
Settlement链上结算, 链下追踪
Risk Scoring内嵌Chainalysis评分
Counterparty Whitelist一键approve trusted partner

4.3 FB Network数据 (2024)

  • 2000+ members
  • 累计**$7T+ 交易量**
  • 包括: BNY Mellon, BNP Paribas, Revolut, Galaxy, Tower Research, Anchorage(部分集成)等
  • 类比: SWIFT in 1980s, growing pains但建立网络效应

4.4 FB Network vs 传统跨行交易

  传统:
  Bank A wallet ──manually copy address──> Bank B wallet
  Risk: 复制粘贴错误, 钓鱼, 反洗钱缺失

  FB Network:
  Bank A account ──"Send to FB-Network-ID-XXX"──> Bank B account
  Risk: 显著降低, 自动合规

五、Fireblocks API实战

5.1 主要API endpoints

# Authentication: API Key + JWT (RS256, signed with private key)

# Vaults (持仓账户)
GET    /v1/vault/accounts                    # 列出所有vault
POST   /v1/vault/accounts                    # 创建新vault
GET    /v1/vault/accounts/{vaultId}          # 获取详情
GET    /v1/vault/accounts/{vaultId}/{assetId} # 获取资产余额
POST   /v1/vault/accounts/{vaultId}/{assetId}/addresses  # 生成新地址

# Transactions
POST   /v1/transactions                      # 创建交易
GET    /v1/transactions                      # 列表
GET    /v1/transactions/{txId}               # 详情
PUT    /v1/transactions/{txId}/cancel        # 取消(若pending)

# Internal Wallets (内部转账目的地)
POST   /v1/internal_wallets

# External Wallets (whitelisted外部地址)
POST   /v1/external_wallets

# Network Connections
GET    /v1/network_connections
POST   /v1/network_connections

# Webhooks
GET    /v1/webhooks

5.2 创建交易示例

// Fireblocks SDK (TypeScript)
import { FireblocksSDK, TransactionOperation, PeerType } from "fireblocks-sdk";

const fb = new FireblocksSDK(apiSecret, apiKey);

// 1. 简单转账 (V2A: Vault-to-Address)
const tx = await fb.createTransaction({
    operation: TransactionOperation.TRANSFER,
    assetId: "USDC_BASE",
    source: { type: PeerType.VAULT_ACCOUNT, id: "0" },
    destination: {
        type: PeerType.ONE_TIME_ADDRESS,
        oneTimeAddress: { address: "0x..." }
    },
    amount: "100",
    note: "Payment for invoice #123"
});

// 2. 跨vault转账 (V2V)
const tx2 = await fb.createTransaction({
    operation: TransactionOperation.TRANSFER,
    assetId: "ETH",
    source: { type: PeerType.VAULT_ACCOUNT, id: "0" },
    destination: { type: PeerType.VAULT_ACCOUNT, id: "1" },
    amount: "1.5"
});

// 3. Smart Contract调用
const tx3 = await fb.createTransaction({
    operation: TransactionOperation.CONTRACT_CALL,
    assetId: "ETH",
    source: { type: PeerType.VAULT_ACCOUNT, id: "0" },
    destination: {
        type: PeerType.ONE_TIME_ADDRESS,
        oneTimeAddress: { address: "0xUniswapRouter" }
    },
    extraParameters: {
        contractCallData: "0x..." // ABI-encoded function call
    },
    note: "Swap 100 USDC for ETH on Uniswap V3"
});

// 4. Webhooks (异步状态)
// On vault credit/debit, transaction status update, etc.
// POST /your-webhook-endpoint
// {
//   "type": "TRANSACTION_STATUS_UPDATED",
//   "data": { "id": "tx-id", "status": "COMPLETED", ... }
// }

5.3 Webhook事件类型

TRANSACTION_CREATED
TRANSACTION_STATUS_UPDATED  
TRANSACTION_APPROVAL_STATUS_UPDATED  
VAULT_ACCOUNT_ADDED
VAULT_ACCOUNT_ASSET_ADDED
INTERNAL_WALLET_ASSET_ADDED  
EXTERNAL_WALLET_ASSET_ADDED
EXCHANGE_ACCOUNT_ADDED
NETWORK_CONNECTION_ADDED

六、TradFi → Web3 映射

Fireblocks概念TradFi对应设计差异
Vault AccountCustody Account链上原生
WorkspaceCustomer Master多租户隔离
MPCHSM key vault + Joint Account链下分布式
Policy Engine (TAP)银行Internal Control matrix灵活可编程
Co-Signer客户控制的key custody类比客户保险柜钥匙
WhitelistBanker SI database (DTCC ALERT)链上去中心管理
FB NetworkSWIFT for crypto网络效应建设中
Travel Rule integration银行AML system链上自动化
Webhook交易状态通知API原生
CEX IntegrationPrime Broker接入DeFi+CEX统一

6.1 链上Multi-sig (Gnosis Safe) vs Fireblocks

  场景: 100人公司管理$50M Crypto Treasury

  Gnosis Safe (链上):
  - 7-of-10 multi-sig
  - 优: 链上透明可审计, code is law
  - 缺: 
    * 每个签名者需要hardware wallet
    * 紧急时刻coordination难
    * Whitelist靠Smart Contract升级
    * 跨链体验割裂(每条链一个Safe)
    * Gas成本高

  Fireblocks:
  - Workspace + Policy Engine
  - 优:
    * 跨100+链统一体验
    * 灵活Policy (无需合约升级)
    * Mobile App approval
    * Compliance内嵌
    * Audit log完整
  - 缺:
    * 信任Fireblocks technology + governance
    * 月费$10-100K (机构级)
    * 学习曲线

6.2 设计案例: 创业公司Crypto Treasury

  Stage 1 (早期, $1M-$10M Treasury):
  → Gnosis Safe 3-of-5
  → 自管, 0月费
  → 接受UX痛苦

  Stage 2 ($10M-$100M):
  → Fireblocks Free tier or BitGo Self-Service
  → Policy Engine简单设置
  → 月费~$10K

  Stage 3 ($100M-$1B):
  → Fireblocks Plus + Co-Signer
  → 复杂Policy + Compliance栈
  → 月费~$50K
  → SOC 2 audit prep

  Stage 4 ($1B+, 上市Public):
  → Fireblocks Enterprise + 自建Co-Signer
  → 与Fund Admin (BNY/SS)集成
  → 完整合规栈 (SOC 1/2/ISO/NYDFS)
  → 月费$200K+

七、关键速查

项目内容
Fireblocks成立2018年
估值$8B (2022)
客户数2000+ 机构
累计交易量$7T+
链支持100+
Token支持1500+
核心技术MPC-CMP (2020 paper)
典型MPC配置2-of-3 (FB×2 + Customer×1)
Policy EngineTransaction Authorization Policy (TAP)
FB Network成员2000+
Co-Signer客户自控MPC node
API协议REST + Webhook + JWT auth
SOCSOC 1+2 Type 2, ISO 27001/27017/27018
主要竞品BitGo, Anchorage, Copper, Komainu, Coinbase Custody

八、面试题（资深级）

Q1: 解释MPC-CMP与传统Multi-Sig的核心技术差异，以及为什么机构市场80%都选MPC？

30秒版：MPC-CMP是Fireblocks 2020年发表的论文, 核心创新是 non-interactive ECDSA threshold signing in single round, 比传统MPC快10x。机构选MPC因为: ①链上看是单签 (隐私); ②跨链统一 (一套MPC支持100+链); ③Policy灵活 (链下可编程); ④Gas成本低。Multi-Sig的优势是链上可验证+code is law, 但机构 prefer闭环管理 + 监管沟通便利。

2分钟版：

  • MPC-CMP核心创新 (Lindell-Nof 2020 + Fireblocks):
    • Non-interactive: 之前GG18/GG20协议需要多轮交互, CMP一轮搞定
    • Pre-signing: 提前生成"signing materials", 真签名时只需1轮
    • ECDSA threshold: 同样适用Bitcoin/Ethereum/etc
    • Proactive refresh: 定期重生shards防长期攻击
    • Identifiable abort: 谁不诚实可识别+排除
  • 关键Math: t-of-n threshold ECDSA, 私钥d = sum(d_i), 各方持d_i但d从未拼合
  • 机构选MPC理由:
    • 隐私: 链上看是单签, 不暴露多签结构 (vs Gnosis Safe一眼看出7-of-10)
    • 跨链一致: 一个MPC vault支持BTC/ETH/SOL/L2s, multi-sig需各链分别部署
    • Policy灵活: TAP是链下软件, 改规则不需链上升级
    • 运营效率: Mobile approval比hardware wallet签快
    • 合规集成: Chainalysis/TRM/Travel Rule原生
    • 审计: 链下完整log + SOC 2认证
  • Multi-Sig仍然适合:
    • DAO Treasury (need transparent on-chain governance)
    • 完全trust-less场景
    • 大规模散户场景(每用户成本低)
  • PM启示: 服务机构客户首选MPC (Fireblocks/BitGo/Anchorage); DAO/Web3 native可用Safe; 不要混淆。

Q2: 设计一个Hedge Fund的Fireblocks Policy, 平衡安全与运营效率。

30秒版：分层Policy = ①Cold Vault (>$10M) 需CFO+CTO+CEO 3-of-3审批, 仅white-list to OTC; ②Trading Hot Vault ($1M-$10M) Trader + Risk Officer 2-of-2 + 24h velocity limit; ③DeFi Vault (<$1M) Trader 1-of-1 + 严格contract whitelist + Chainalysis check. 配合off-hours stricter rules + 紧急freeze机制。

2分钟版：

# Hedge Fund Fireblocks Policy

# Vault 1: Cold Treasury ($50M+)
- name: "Cold Vault Withdrawal"
  condition:
    vault_id: "cold-treasury"
  action: REQUIRE_APPROVAL
  approvers:
    - role: CEO (1 required)
    - role: CFO (1 required)
    - role: CTO (1 required)
    quorum: 3_of_3
  whitelist_only: true
  velocity_limit: "$10M / 24h"

# Vault 2: Trading Hot Wallet ($1-5M)
- name: "Trading Withdrawal" 
  condition:
    vault_id: "trading-hot"
    amount_usd: "<$5M"
  action: REQUIRE_APPROVAL
  approvers:
    - role: HEAD_OF_TRADING (1 required)
    - role: RISK_OFFICER (1 required)
    quorum: 2_of_2
  velocity_limit: "$10M / 24h"
  external_approval_for_amount: ">$1M"

- name: "Trading Withdrawal Larger"
  condition:
    vault_id: "trading-hot"
    amount_usd: ">$5M"
  action: REQUIRE_APPROVAL
  approvers:
    - role: CEO + HEAD_OF_TRADING + RISK_OFFICER
    quorum: 3_of_3

# Vault 3: DeFi Vault ($500K cap)
- name: "DeFi Interaction"
  condition:
    vault_id: "defi-vault"
    tx_type: SMART_CONTRACT_CALL
    contract: IN approved_defi_contracts  # Aave, Uniswap V3, etc
  action: ALLOW
  approvers:
    - role: DEFI_TRADER (1 required)

- name: "DeFi New Contract"
  condition:
    vault_id: "defi-vault"
    contract: NOT_IN approved_defi_contracts
  action: REQUIRE_APPROVAL
  approvers:
    - role: CTO + RISK_OFFICER
    quorum: 2_of_2

# Cross-cutting rules
- name: "Off-hours stricter"
  condition:
    time: NOT_IN "Mon-Fri 8-18 UTC"
  override:
    add_approver: ON_CALL_OPS

- name: "OFAC blacklist"
  condition:
    destination_risk_score: ">75"
  action: BLOCK
  notify: COMPLIANCE_TEAM

- name: "Travel Rule (>$1K external)"
  condition:
    direction: OUTBOUND
    destination_type: VASP
    amount_usd: ">$1000"
  action: ENFORCE_TRAVEL_RULE_DATA

# Emergency
- name: "Freeze Mode"
  trigger: MANUAL_BY_CISO
  action: BLOCK_ALL_OUTBOUND
  • 关键设计原则:
    • 职责分离 (SoD): 不同决策不同人
    • 速率限制: 防止单次大额or burst attack
    • 白名单优先: known counterparties vs random
    • 时间窗口: 工作时间 vs off-hours
    • 紧急熔断: CISO-level freeze
    • 合规内嵌: OFAC + Travel Rule自动
  • 挑战:
    • Policy复杂会impact运营效率
    • 太严苛会被workaround
    • 需要定期审查+演练

Q3: Fireblocks Network如果成功, 会替代SWIFT吗?

30秒版：部分替代, 但不是颠覆。FB Network主要服务机构间Crypto/Tokenized Asset结算——这是SWIFT当前不覆盖的细分(SWIFT是Fiat msg)。FB Network的网络效应仍在早期(~2000机构 vs SWIFT 11K+银行)，但增长快。长期看: SWIFT做Fiat, FB Network/Onyx/Partior做Tokenized, 各占一壁。完全取代SWIFT需要法币上链(Wholesale CBDC)规模化。

2分钟版：

  • FB Network定位:
    • 不是SWIFT替代, 是"Crypto-native SWIFT"
    • 服务机构间链上资产路由+合规
    • 核心价值: 减少地址管理痛点 + 自动Travel Rule
  • vs SWIFT 当前对比:
    维度SWIFTFB Network
    资产Fiat (via banks)Crypto + Tokenized
    成员11K+ banks2000+ 机构
    监管Belgium NBB + 多国美国SaaS, 各国合规
    速度数小时-数天链速 (秒-分钟)
    成本中低
  • 重叠领域: 跨境Tokenized资产 (Stablecoin/RWA/CBDC)
  • 演进可能:
    • Path 1: 互补: SWIFT做Fiat, FB Network/Partior/Onyx做Tokenized, 各做各的
    • Path 2: SWIFT扩展: SWIFT 2024-2025已在试点tokenized asset连接, 可能内化Crypto
    • Path 3: 整合: 大型协同 standards body
  • 网络效应竞争:
    • SWIFT 50年累积, hard to disrupt
    • FB Network新, 但增长速度+技术优势明显
    • 关键变量: Wholesale CBDC + Tokenized Securities规模
  • 2030推演: SWIFT仍主导Fiat支付; FB Network/类似机构覆盖Crypto/Tokenized细分; 边界因CBDC而模糊。

Q4: 解释Co-Signer设计哲学, 以及它如何处理"Fireblocks自己被攻陷"的极端场景?

30秒版：Co-Signer = 客户运行的MPC node, 是2-of-3配置中的客户shard。即使Fireblocks SaaS两个shards都被攻陷, 没有客户Co-Signer的shard也无法签名转移资产。本质是**"客户不完全信任Fireblocks"** 的technical embodiment。但Co-Signer增加运维复杂度, 多数中小客户不部署。

2分钟版：

  • Co-Signer原理:
    • Fireblocks默认2-of-3: 2 nodes Fireblocks控制 + 1 node客户控制
    • 默认情况, Fireblocks两端都compromise = 2 shards够 → 资产可被盗
    • Co-Signer就是客户控制的第3个node, 强制需要客户action才能签
  • 部署模式:
    • Cloud Co-Signer: 客户AWS/GCP账号下deploy, Fireblocks API调用
    • HSM Co-Signer: 客户专用HSM硬件, 完全离线密钥管理
    • SGX/Nitro Enclave: 加密enclave, 即使host compromise内部也安全
  • 威胁模型:
    • Fireblocks两shard被盗: Co-Signer阻止
    • Insider attack at Fireblocks: Co-Signer阻止
    • Cloud provider compromise: Co-Signer + HSM阻止
    • Customer Co-Signer compromise: 需Fireblocks两端也被同时盗 = 不可能
  • 运维负担:
    • 客户need 24×7 Co-Signer服务
    • 升级、监控、disaster recovery
    • 不部署的客户(中小机构)接受Fireblocks完全信任
  • 真实案例: 2024年Fireblocks被某政府sub-poena要求冻结某客户 → Co-Signer客户不会被影响 (Fireblocks技术上无法单方面动)
  • 链上类比: 类似"客户保险柜的钥匙之一" + Custodian持有的钥匙之二/三. 与Multi-sig的"M-of-N"设计哲学一致, 但实现机制不同(链下MPC vs 链上Multi-sig)。
  • PM启示: 给机构推Crypto Custody必须支持Co-Signer选项, 否则大客户(Pension Fund/Sovereign Wealth)不会采用。

Q5: 假设你是Fireblocks PM, 制定2026-2028路线图, 重点是什么?

30秒版：三大方向 = ①Tokenized Asset/RWA Hub (跟上BUIDL/USDY/Tokenized Bond潮流, 提供机构级RWA托管+发行平台); ②DeFi原生集成深化 (从基础接入到Strategy as a Service, 帮机构客户安全DeFi yield); ③Wholesale CBDC adapter (与各国央行wholesale CBDC试点对接, 占位下一代支付基础设施)。同时地理扩展重点亚洲(新加坡/香港/印度)与中东(阿联酋)。

2分钟版：

  • 战略主线: Fireblocks从"Crypto Custody"扩展到"Tokenized Financial Infrastructure Platform"
  • 方向1: RWA/Tokenized Asset Hub:
    • 与BlackRock BUIDL/Ondo USDY/Franklin BENJI等深度集成
    • 提供"Tokenized Asset Issuance Platform" SaaS给银行(类似与BNY合作的下一代版本)
    • 自动化合规(Reg D/Reg S compliance check)
    • 跨链RWA路由
    • 目标: 2028年Tokenized Asset AUC占FB总量30%+
  • 方向2: DeFi Native+++:
    • 当前: 接入100+ DeFi协议但更多是access layer
    • 未来: "DeFi Strategy Vaults" - 预先组合的策略(yield, basis trading)
    • 风险监控+Auto-rebalance
    • 与Aave/Morpho/Compound深合作机构层
    • 目标: 帮机构客户从"被动持有"变"主动yield earn"
  • 方向3: Wholesale CBDC + Permissioned Chain:
    • 与Project Agorá/mBridge等央行试点合作
    • 提供"CBDC custody adapter"
    • 与Onyx/Partior/Fnality互通
    • 目标: 占位下一代机构支付Layer
  • 方向4: Geographic expansion:
    • 新加坡: MAS license, Asia机构客户
    • 香港: 2025稳定币条例 + Web3战略
    • 印度: SEBI/RBI sandbox入手
    • UAE: VARA license, 中东主权基金
    • 欧洲: MiCA license平台化
  • 方向5: Consumer-facing (defensive):
    • 当前完全to B
    • 2026开始通过"白标"方式给Banks/Fintech ToC
    • 不直接竞争Coinbase/Binance, 但enable他们
  • 关键KPI:
    • 客户数 2000 → 5000+
    • 累计交易量 $7T → $30T
    • Tokenized AUC从近零到$500B+
    • Wholesale CBDC试点参与5+央行
  • 风险:
    • 大行内部化(BNY可能从合作转自建)
    • 监管碎片化
    • 估值压力(2022 $8B, 2024未上市但需重新估值)

九、明日预告

明天 (Day 10) 进入 机构托管对比 ——Anchorage/Copper/BitGo/Coinbase Custody详细对比, 5家产品矩阵差异化分析, 机构选型方法论。

上一篇
Day 8: 机构托管基础
下一篇
Day 10: 机构托管对比