桥接系统设计 #2 — 合规层 (Compliance Layer)

日期: 2026-06-21 方向: 机构DeFi / RWA 阶段: Phase 1 - 机构DeFi与桥接系统设计 (Day 43-56) 标签: #合规层 #KYCOracle #Allowlist #TravelRule #设计文档

---

今日目标

---

一、合规层在桥接架构中的位置

1.1 上下游关系

┌─────────────────────────────────────────┐
│          Risk Layer (Day 54)             │
│      ↑ 给风控层: 合规状态信号               │
├─────────────────────────────────────────┤
│       Reporting Layer (Day 53)           │
│      ↑ 给报表层: 司法管辖标签              │
├─────────────────────────────────────────┤
│       Settlement Layer (Day 52)          │
│      ↑ 给清算层: Allow/Deny信号            │
├─────────────────────────────────────────┤
│       Compliance Layer (Day 51) ★ Today  │
│      ↑ 输入: 身份signal from 托管层        │
├─────────────────────────────────────────┤
│       Custody Layer (Day 50)             │
└─────────────────────────────────────────┘

1.2 合规层的核心职责

1. 身份验证(Identity Verification)：KYC/KYB/UBO穿透
2. 准入控制(Access Control)：基于身份+资产决定能否交易
3. 制裁筛查(Sanctions Screening)：OFAC/EU/UN制裁名单实时检查
4. 信息共享(Information Sharing)：Travel Rule下的VASP间数据交换
5. 报告(Reporting)：监管要求的SAR/CTR/CRS报告生成
6. 审计追溯(Audit Trail)：每个合规决定的可审计记录

1.3 链上 vs 链下职责划分

链下 (Off-chain) ──────────────────────────────┐
- KYC Document Collection                       │
- Refinitiv/Onfido/Trulioo verification        │
- UBO Investigation (深度KYC)                   │
- 政治人物(PEP)筛查                             │
- 敏感司法管辖判断                              │
                                                │
链下 → 链上 ────────────────────────────────────┘
- KYC Hash (zk-proof of KYC, not raw data)
- Sanctions List Updates (每5分钟)
- Identity Token (ERC-3643 OnchainID)
- Allowlist Bitmap
                                                
链上 (On-chain) ───────────────────────────────┐
- isAllowed(address) check                      │
- canTransfer(from, to) check                   │
- isSanctioned(address) check                   │
- jurisdiction(address) lookup                  │
- 紧急冻结(Emergency Freeze)                     │
- Compliance Event Logging                      │

核心原则：原始KYC文档永远不上链，只上链签名/哈希。

---

二、KYC Oracle模式

2.1 三种KYC上链模式

模式A：合约内嵌（On-chain Hardcoded）

• KYC状态硬编码在Token合约里
• 例：早期Polymath ST-20

优点：简单 缺点：

• 升级困难（每次更新需要redeployment）
• 链上数据膨胀
• Privacy差（所有KYC状态公开）

模式B：Mapping查询（Centralized Registry）

• 一个Registry合约存储 mapping(address => KYCStatus)
• 每次交易查询Registry

优点：可独立升级 缺点：仍是Centralized（单点故障）

模式C：Oracle模式（推荐）

• 链下KYC Provider维护数据
• 链上Oracle合约提供查询接口
• 类似Chainlink Price Oracle，但是KYC data

优点：

• 数据所有权清晰（KYC在专业方手里）
• 可多Oracle源（多Provider提供同一查询）
• Privacy友好（链上只暴露查询结果，不是raw data）

缺点：

• 需要信任Oracle Operator
• Oracle故障可能造成全协议停摆

2.2 KYC Oracle架构

┌─────────────────────────────────────────────────┐
│  Off-chain: KYC Providers                        │
│  - Refinitiv (PEP, Sanctions)                    │
│  - Onfido (Document, Biometric)                  │
│  - Sumsub (Crypto-native, Travel Rule)           │
│  - Trulioo (Identity)                            │
└────────────────────┬─────────────────────────────┘
                     │ Verified KYC Data
┌────────────────────┴─────────────────────────────┐
│  Off-chain: Aggregator (Tokeny / Sumsub)         │
│  - Combines multiple Provider data               │
│  - Generates ONCHAINID                           │
│  - Issues Verifiable Credentials                 │
└────────────────────┬─────────────────────────────┘
                     │ Signed Attestations
┌────────────────────┴─────────────────────────────┐
│  On-chain: KYC Oracle                            │
│  - Receives signed attestations                  │
│  - Stores latest hash + metadata                 │
│  - Provides query interface                      │
└────────────────────┬─────────────────────────────┘
                     │ Query API
┌────────────────────┴─────────────────────────────┐
│  Consumer Contracts                              │
│  - Token Contracts (ERC-3643)                    │
│  - DeFi Protocols (Aave Arc-style)               │
│  - Settlement Layer                              │
└─────────────────────────────────────────────────┘

2.3 ERC-3643 (T-REX) 与 ONCHAINID

ERC-3643：Tokeny提出的合规Token标准（2021），现为事实标准。

核心组件：

1. ONCHAINID：链上身份合约（per user）
2. ClaimIssuer：发布Claims的实体（如KYC Provider）
3. Compliance Contract：Token-specific的合规规则
4. ClaimsTopic：身份属性（KYC=1, AML=2, Accredited=7, ...）

// ERC-3643简化版
interface IIdentity {
    struct Claim {
        uint256 topic;          // 1=KYC, 2=AML, 7=Accredited
        uint256 scheme;         // signature scheme
        address issuer;         // ClaimIssuer
        bytes signature;
        bytes data;
        string uri;             // off-chain document URI
    }
    
    function getClaim(bytes32 claimId) external view returns (Claim memory);
    function getClaimIdsByTopic(uint256 topic) external view returns (bytes32[] memory);
    function addClaim(uint256 topic, uint256 scheme, address issuer, bytes calldata signature, bytes calldata data, string calldata uri) external;
}

interface ICompliance {
    function canTransfer(address from, address to, uint256 amount) external view returns (bool);
    function transferred(address from, address to, uint256 amount) external;
    function created(address to, uint256 amount) external;
    function destroyed(address from, uint256 amount) external;
    
    // Token绑定
    function bindToken(address token) external;
    function unbindToken(address token) external;
}

---

三、合规层架构详细设计

3.1 模块边界图

┌─────────────────────────────────────────────────────────┐
│              Compliance Layer (Day 51)                   │
│                                                          │
│  ┌──────────────────────────────────────────────────┐   │
│  │  1. Identity Module                               │   │
│  │  - KYC/KYB Onboarding                             │   │
│  │  - ONCHAINID generation                           │   │
│  │  - Claim issuance & verification                  │   │
│  │  - Identity lifecycle (renewal, expiry)           │   │
│  └──────────────────────────────────────────────────┘   │
│                                                          │
│  ┌──────────────────────────────────────────────────┐   │
│  │  2. Allowlist Module                              │   │
│  │  - Per-asset allowlist                            │   │
│  │  - Per-jurisdiction matrix                        │   │
│  │  - Investor classification (QIB, Accredited, Retail) │
│  │  - Bulk update mechanisms                         │   │
│  └──────────────────────────────────────────────────┘   │
│                                                          │
│  ┌──────────────────────────────────────────────────┐   │
│  │  3. Sanctions Module                              │   │
│  │  - OFAC/EU/UN list synchronization                │   │
│  │  - Real-time screening                            │   │
│  │  - Indirect exposure detection                    │   │
│  │  - Auto-freeze mechanism                          │   │
│  └──────────────────────────────────────────────────┘   │
│                                                          │
│  ┌──────────────────────────────────────────────────┐   │
│  │  4. Travel Rule Module                            │   │
│  │  - Originator/Beneficiary data exchange           │   │
│  │  - VASP-to-VASP messaging                         │   │
│  │  - Notabene/Sumsub/TRP integration                │   │
│  │  - Threshold detection ($1K USD)                  │   │
│  └──────────────────────────────────────────────────┘   │
│                                                          │
│  ┌──────────────────────────────────────────────────┐   │
│  │  5. Reporting Module                              │   │
│  │  - SAR (Suspicious Activity Report)               │   │
│  │  - CTR (Currency Transaction Report)              │   │
│  │  - CRS (Common Reporting Standard)                │   │
│  │  - Real-time regulatory queries                   │   │
│  └──────────────────────────────────────────────────┘   │
│                                                          │
│  ┌──────────────────────────────────────────────────┐   │
│  │  6. Audit Module                                  │   │
│  │  - Compliance decision logging                    │   │
│  │  - Immutable trail (on-chain + off-chain)         │   │
│  │  - Regulator-friendly query interface             │   │
│  └──────────────────────────────────────────────────┘   │
│                                                          │
│         ↓ Output to other layers ↓                       │
│  - 给清算层: canTransfer(from, to, amount) → bool        │
│  - 给报表层: jurisdiction(address) + investorType         │
│  - 给风控层: isSanctioned(address) + complianceScore     │
└─────────────────────────────────────────────────────────┘

3.2 核心合约接口

A. KYC Oracle (Identity Registry)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IKYCOracle {
    enum KYCLevel { None, Basic, Standard, Enhanced }
    enum InvestorType { Retail, Accredited, QIB, Sophisticated }
    
    struct KYCData {
        bytes32 onchainId;          // 关联ONCHAINID合约
        KYCLevel level;
        InvestorType investorType;
        uint8 jurisdiction;          // ISO 3166-1 numeric code
        uint64 verifiedAt;
        uint64 expiresAt;
        address kycProvider;         // 哪个Provider verified
        bytes32 documentHash;        // KYC文档哈希
    }
    
    // 主查询
    function getKYC(address user) external view returns (KYCData memory);
    function isKYCValid(address user) external view returns (bool);
    function isKYCValidForLevel(address user, KYCLevel minLevel) external view returns (bool);
    
    // Provider操作
    function attestKYC(address user, KYCData calldata data, bytes calldata signature) external;
    function revokeKYC(address user, string calldata reason) external;
    function renewKYC(address user, uint64 newExpiresAt) external;
    
    // 紧急
    function emergencyFreeze(address user) external; // 仅admin
    
    event KYCAttested(address indexed user, KYCLevel level, address indexed provider);
    event KYCRevoked(address indexed user, string reason);
    event KYCFrozen(address indexed user, uint64 timestamp);
}

B. Allowlist Manager

interface IAllowlistManager {
    // 资产-司法-投资人类型 三维Allowlist
    struct AllowlistRule {
        address asset;
        uint8[] allowedJurisdictions;
        InvestorType[] allowedInvestorTypes;
        bool active;
    }
    
    // 主查询（被Token合约调用）
    function isAllowed(address asset, address user) external view returns (bool);
    function isAllowedForAmount(address asset, address user, uint256 amount) external view returns (bool);
    
    // 规则管理
    function addRule(AllowlistRule calldata rule) external;
    function updateRule(uint256 ruleId, AllowlistRule calldata rule) external;
    function disableRule(uint256 ruleId) external;
    
    // 临时白名单（特殊case）
    function addToTemporaryAllowlist(address user, address asset, uint64 expiresAt) external;
    
    // 批量操作（Gas optimization）
    function batchCheck(address asset, address[] calldata users) external view returns (bool[] memory);
}

C. Sanctions Registry

interface ISanctionsRegistry {
    enum SanctionSource { OFAC, EU, UN, UK, JAPAN, OTHER }
    enum SanctionLevel { None, Watch, Restricted, Sanctioned }
    
    struct SanctionEntry {
        address sanctionedAddress;
        SanctionSource source;
        SanctionLevel level;
        uint64 listedAt;
        bytes32 reasonHash;          // 原因哈希（Off-chain详情）
    }
    
    // 主查询
    function isSanctioned(address user) external view returns (bool);
    function getSanctionLevel(address user) external view returns (SanctionLevel);
    function getSanctionDetails(address user) external view returns (SanctionEntry memory);
    
    // 间接exposure检测（Chainalysis集成）
    function getIndirectExposureScore(address user) external view returns (uint8); // 0-100
    
    // 名单更新（仅认证Provider）
    function addSanction(SanctionEntry calldata entry) external;
    function removeSanction(address user, SanctionSource source) external;
    function batchUpdate(SanctionEntry[] calldata entries) external;
    
    event SanctionAdded(address indexed user, SanctionSource source, SanctionLevel level);
    event SanctionRemoved(address indexed user, SanctionSource source);
}

D. Travel Rule Module

interface ITravelRule {
    struct OriginatorBeneficiary {
        bytes32 originatorVASPId;
        bytes32 beneficiaryVASPId;
        bytes32 originatorIdHash;     // 不上链原始信息
        bytes32 beneficiaryIdHash;
        uint256 amountUSD;
        uint64 timestamp;
    }
    
    // 检查交易是否需要Travel Rule
    function requiresTravelRule(address from, address to, uint256 amount) external view returns (bool);
    
    // 链上记录Travel Rule交易
    function recordTravelRule(bytes32 txHash, OriginatorBeneficiary calldata data) external;
    
    // 查询历史
    function getTravelRuleData(bytes32 txHash) external view returns (OriginatorBeneficiary memory);
    
    event TravelRuleRecorded(bytes32 indexed txHash, bytes32 originatorVASP, bytes32 beneficiaryVASP);
}

E. Master Compliance Hook (集成)

/// @notice 单一入口给其他层调用
interface IComplianceHook {
    /// @notice 检查一笔交易是否合规
    /// @return canProceed 是否允许
    /// @return reason 拒绝原因
    function checkTransaction(
        address asset,
        address from,
        address to,
        uint256 amount
    ) external view returns (bool canProceed, string memory reason);
    
    /// @notice 通知合规层一笔交易完成（用于Travel Rule记录、报告生成等）
    function recordTransaction(
        address asset,
        address from,
        address to,
        uint256 amount,
        bytes32 txHash
    ) external;
    
    /// @notice 紧急冻结（被风控层调用）
    function emergencyAction(address user, string calldata reason) external;
}

3.3 序列图1：客户Onboarding（KYC到链上）

sequenceDiagram
  participant Client as 机构客户
  participant Custody as Custody Layer (Day 50)
  participant Onboard as Onboarding Service
  participant Refinitiv as Refinitiv (PEP/Sanctions)
  participant Onfido as Onfido (Doc Verify)
  participant Sumsub as Sumsub (Aggregator)
  participant Oracle as KYC Oracle
  participant Allowlist as Allowlist Manager
  participant Identity as ONCHAINID

  Note over Client,Onboard: T0: 客户提交资料
  Client->>Custody: 申请创建Vault
  Custody->>Onboard: KYB request (entity info, UBO)
  
  Note over Onboard,Onfido: T+1d: 多Provider验证
  Onboard->>Refinitiv: 检查PEP/Sanctions
  Refinitiv-->>Onboard: ✓ Clear
  Onboard->>Onfido: 验证Articles of Incorporation
  Onfido-->>Onboard: ✓ Verified
  Onboard->>Sumsub: 整合数据
  
  Note over Sumsub,Identity: T+1d: 生成ONCHAINID
  Sumsub->>Identity: deployONCHAINID(client)
  Identity-->>Sumsub: ONCHAINID address
  
  Note over Sumsub,Oracle: T+1d: 链上Attest
  Sumsub->>Oracle: attestKYC({
    user: clientWallet,
    onchainId: 0x...,
    level: Enhanced,
    investorType: QIB,
    jurisdiction: 840 (US),
    expiresAt: now + 1y,
    provider: sumsub,
    documentHash: keccak256(docs)
  }, signature)
  Oracle->>Oracle: 验证Provider签名
  Oracle->>Oracle: 存储 KYCData[user]
  Oracle->>Identity: addClaim(topic=KYC, issuer=sumsub, ...)
  Identity-->>Oracle: ✓
  
  Note over Oracle,Allowlist: 触发Allowlist更新
  Oracle->>Allowlist: notifyKYCUpdate(user, jurisdiction=US, type=QIB)
  Allowlist->>Allowlist: 应用规则
  Allowlist->>Allowlist: addToAllowlist(user, [BUIDL, OUSG, USDC])
  
  Note over Custody: T+1d: Custody层激活
  Onboard->>Custody: ✓ Onboarded
  Custody->>Client: Vault ready, sub-accounts can be created

3.4 序列图2：交易合规检查

sequenceDiagram
  participant Trader as 机构Trader
  participant Custody as Custody Layer
  participant Compliance as Compliance Hook
  participant Oracle as KYC Oracle
  participant Allowlist as Allowlist
  participant Sanctions as Sanctions Registry
  participant TravelRule as Travel Rule
  participant Settlement as Settlement Layer

  Note over Trader,Custody: T0: 发起交易
  Trader->>Custody: 转账 1000 BUIDL to 0xRecipient
  
  Note over Custody,Sanctions: T+0.1s: 合规检查
  Custody->>Compliance: checkTransaction(BUIDL, sender, recipient, 1000)
  
  par 并行查询
    Compliance->>Oracle: isKYCValid(sender)?
    Oracle-->>Compliance: ✓ (Enhanced, expires in 200d)
    
    Compliance->>Oracle: isKYCValid(recipient)?
    Oracle-->>Compliance: ✓ (Standard, expires in 300d)
    
    Compliance->>Sanctions: isSanctioned(sender)?
    Sanctions-->>Compliance: ✗ Clear
    
    Compliance->>Sanctions: isSanctioned(recipient)?
    Sanctions-->>Compliance: ✗ Clear
    
    Compliance->>Allowlist: isAllowed(BUIDL, recipient)?
    Allowlist->>Allowlist: 检查 recipient.investorType ≥ QIB
    Allowlist-->>Compliance: ✓ Allowed
  end
  
  Note over Compliance,TravelRule: T+0.2s: Travel Rule (因 amount > $1K)
  Compliance->>TravelRule: requiresTravelRule(sender, recipient, $1M)?
  TravelRule-->>Compliance: ✓ Required
  TravelRule->>TravelRule: 触发 off-chain VASP消息
  TravelRule->>Compliance: ✓ Will record after settlement
  
  Compliance-->>Custody: ✓ Approved
  Custody->>Settlement: proceed
  Settlement->>Settlement: 链上 transfer
  
  Note over Settlement,TravelRule: T+settlement_time: Post-settlement
  Settlement->>Compliance: recordTransaction(txHash)
  Compliance->>TravelRule: recordTravelRule(txHash, originator, beneficiary)

3.5 序列图3：制裁名单更新与冻结

sequenceDiagram
  participant OFAC as OFAC SDN List
  participant Sync as OFAC Sync Service
  participant Sanctions as Sanctions Registry
  participant Compliance as Compliance Hook
  participant Custody as Custody Layer
  participant Officer as Compliance Officer

  Note over OFAC,Sync: T0: OFAC更新名单
  Sync->>OFAC: pull latest SDN list (every 5 min)
  OFAC-->>Sync: 新增 5个地址
  
  Note over Sync,Sanctions: T+5min: 链上更新
  Sync->>Sanctions: batchUpdate([5 new entries])
  Sanctions->>Sanctions: 写入Registry
  Sanctions->>Sanctions: emit SanctionAdded events
  
  Note over Sanctions,Compliance: 触发ripple effect
  Sanctions->>Compliance: notifyNewSanctions(addresses)
  
  loop 对每个新制裁地址
    Compliance->>Compliance: 检查该地址是否有active position
    alt 有持仓
      Compliance->>Custody: 紧急冻结 sub-account
      Custody->>Custody: deactivateAccount
      Compliance->>Officer: ALERT - existing exposure
    end
  end
  
  Note over Officer,Custody: T+10min: 人工调查
  Officer->>Compliance: 查询exposure
  Compliance->>Compliance: 列出所有interaction (since 90 days)
  Officer->>Officer: 决定是否SAR Report
  Officer->>Compliance: 提交SAR
  
  Note over Compliance: T+24h: 监管报告
  Compliance->>Compliance: 自动生成SAR.xml
  Compliance->>FinCEN: 报送(off-chain)

---

四、设计决策与权衡

4.1 KYC上链多少？

完全上链（不推荐）：

• 链上存名字、地址、护照号
• 优点：完全去中心化
• 缺点：违反GDPR、客户隐私、安全风险

完全链下（不够）：

• 链上完全没KYC信息
• 缺点：链上无法做合规检查

哈希上链（推荐）：

• 链上存：KYC等级、司法、过期时间、文档哈希
• 链下存：原始文档（KYC Provider数据库）
• ZK Future：未来可zk-prove "I am KYCed by X" without revealing details

4.2 多Provider vs 单Provider

单Provider：

• 简单
• 但单点故障

多Provider（推荐）：

• 一个Provider故障不影响系统
• 可以"投票"机制（2-of-3 Providers确认）
• 成本高但风险低

机构选择：通常用Sumsub或Tokeny作为Aggregator，背后接入Refinitiv + Onfido + Trulioo等，对客户呈现单一接口。

4.3 Sanctions名单多源

OFAC SDN：美国（必须） EU Consolidated：欧盟（在欧洲业务必须） UN 1267 Committee：联合国（全球必须） UK HMT Financial Sanctions：英国 Japan METI：日本 Canada Special Economic Measures：加拿大

机构策略：取最严（Union），不论在哪个司法都遵守所有名单。这导致Aave Arc等无法服务朝鲜+俄罗斯+伊朗+叙利亚等多地客户。

4.4 KYC过期处理

严格模式（不推荐）：

• KYC过期立即冻结所有操作
• 用户体验极差

宽限模式（推荐）：

• KYC过期前30天通知
• 过期后90天宽限期
• 宽限期内只能"提现"，不能新增Position
• 90天后才完全冻结

自动续期：

• 每年Provider重新验证（KYB可能2-5年一次）
• 用户提交更新文件即可
• 避免完全重新onboarding

4.5 Travel Rule阈值

FATF推荐$1000 USD以上需要Travel Rule。

机构如何实现：

• 链上检测金额（实时USD价值，依赖Oracle）
• 跨链交易也算（不仅是单链转账）
• VASP-to-Self的边界判断（出入金CEX vs 客户自有钱包）

主流Travel Rule Solutions：

• Notabene
• Sumsub Travel Rule
• TRP (Travel Rule Protocol)
• Shyft Network
• VerifyVASP

机构通常选1-2家，与CEX/其他机构互联。

---

五、风险与攻击面

5.1 KYC Provider Compromise

威胁：KYC Provider内部员工或外部攻击者，给恶意地址签发"KYC Verified"证明。 缓解：

• 多Provider要求（至少2-of-3）
• KYC Provider的多签私钥（不是单一EOA）
• 定期Audit Provider的内部流程
• Provider Insurance ($100M+ coverage)

5.2 Sanctions Sync延迟

威胁：OFAC更新名单后，链上sync慢，导致合规违规。 缓解：

• 5分钟sync频率（vs 标准24h）
• 多Sync源（直接OFAC API + Chainalysis + Elliptic + Refinitiv）
• 如果Sync中断，自动进入"Pause Mode"（保守拒绝所有交易）
• 监管已接受"商业最佳努力"的判断（不是bulletproof要求）

5.3 Cross-Jurisdiction Conflict

威胁：US OFAC制裁某地址，但EU MiCA未跟进，导致欧洲客户的"合法交易"在美国被视违规。 缓解：

• 取并集（最严）
• 可能导致一些客户业务受限
• 与法律部门定期Review冲突
• 每个客户记录"适用司法"（对该客户哪些规则生效）

5.4 Privacy Leak

威胁：链上的合规事件包含太多信息（如"User X is QIB"），可能被分析推断身份。 缓解：

• 只Log必要信息
• 使用ONCHAINID代替直接address
• ZK proof（未来）
• 定期Privacy Audit

5.5 Compliance Bypass

威胁：用户用未经合规的链下swap绕过链上allowlist（如Bisq P2P）。 缓解：

• Token-level enforcement（ERC-3643的canTransfer）
• 即使P2P转移，接收方也必须allowed
• 监控异常P2P pattern
• 法律救济（不可依赖技术单一解决）

---

六、TradFi对照表

---

七、关键速查

主要KYC/Compliance Provider对比

合规检查响应时间目标

主要Compliance相关法规速查

---

八、面试题（资深级）

Q1: 为什么不直接把KYC PDF文档存IPFS？

深度回答： 法律问题：

• GDPR要求"被遗忘权"，IPFS不可删除（违反）
• KYC含敏感个人信息，公开IPFS暴露隐私
• 监管要求KYC数据在特定司法存储

技术问题：

• 文档大小1-10MB，存IPFS成本高
• IPFS可能丢失（Pin Service失效）
• 没有加密IPFS不安全

正确做法：

• 文档存在KYC Provider的合规存储（AWS S3 in approved region）
• 链上只存哈希
• 可证明文档存在性，但不暴露内容

Q2: 如何在ZK下实现"KYC了但不知道身份"？

深度回答： 目标：用户能向DApp证明"我有KYC"，但DApp不知道用户具体身份。

技术路径（zk-KYC）：

1. KYC Provider给用户签发"signed claim"：Sign(provider_pk, KYC=true, exp=2026)
2. 用户用ZK电路证明：
   • 知道一个valid signature on a KYC claim
   • 该signature来自approved Provider
   • claim未过期
   • 但不暴露signature本身或具体KYC内容
3. DApp验证ZK proof，approve交易

实际项目：

• Polygon ID (zk-KYC)
• Sismo (Verifiable Credentials with ZK)
• Worldcoin (proof of personhood)

机构采用：仍在早期。机构更接受"链上明文KYC等级 + 链下原始数据"模式，因为监管要求"穿透"。zk-KYC可能2027+成主流。

Q3: 设计跨链合规层（用户在以太坊KYC了，能否在Arbitrum也用？）

深度回答： 挑战：每条链是独立环境，KYC状态如何跨链？

方案A：每条链单独KYC

• 用户每条链都做一次
• 简单但用户体验差

方案B：Cross-Chain Identity Bridge

• 主链（以太坊）作为KYC源
• 通过LayerZero/CCIP把KYC状态桥到其他链
• 同步KYC变更

方案C：Universal Identity Layer

• 类似BAS（BNB Account Service）或Worldcoin
• 用户在L0层有Identity NFT
• 各L1/L2 Compliance合约都查询L0

推荐：方案B + ZK bridge

• KYC源在以太坊（最安全）
• Periodic sync到L2 (每天)
• Critical action用zk-proof现场验证
• 紧急冻结through L0实时

Q4: Travel Rule在DeFi下如何实现？

深度回答： 问题：DeFi没有"VASP"概念，谁来发送/接收Travel Rule data？

方案1：协议级集成

• 协议本身是VASP（Aave Arc就这样）
• 协议对所有用户做KYC
• 协议间消息走Notabene/Sumsub

方案2：钱包级集成

• Fireblocks/Anchorage等托管方做VASP
• 用户操作经过托管方时VASP生效
• 真自托管（如硬件钱包）困难

方案3：地址级标签

• Chainalysis给每个address打"VASP X owns this address"标签
• 协议查询，自动发送Travel Rule data
• 不Cover所有address（只覆盖已知VASP）

实际机构操作：方案1+2组合。完全自托管+完全Permissionless DeFi下，Travel Rule无法enforce，监管事实上不要求。

Q5: 评价"链上合规"是否可能完全自动化

深度回答： 结论：80%自动化是可能的，但20%必须人工。

可自动化（80%）：

• KYC数据查询和验证
• Sanctions名单实时筛查
• Allowlist规则enforcement
• Travel Rule数据交换
• 日常报告生成

不可自动化（20%）：

• 复杂SAR判断：需要人工评估"可疑"
• PEP判断：政治人物身份变化（如某官员退休，不再PEP）
• 法律变更适应：新法规出来需要法律团队解读
• 争议处理：用户claim "我不应该被冻结"
• 跨司法复杂case：US客户在欧洲交易

未来趋势：

• AI辅助SAR判断（不替代人工）
• ZK隐私让自动化更友好
• Smart Contract Compliance模块化（LegoBlock方式）
• 监管自身链上化（Reg-on-chain）

机构最佳实践：

• 自动化覆盖80%日常case
• 人工Review覆盖20%edge case
• AI辅助decision但不替代
• 持续培训合规团队Web3

---

九、明日预告

Day 52: 桥接系统设计 #3 — 清算层 (Settlement Layer)。基于Day 50托管层和Day 51合规层的输出，设计T+0 atomic DvP清算引擎。包括HTLC原理、跨链atomic swap、Cash-vs-Securities (CvS) 结算、机构Settlement Window设计。同样700+行深度文档。