KYC 代币化与可重用合规凭证

日期: 2026-05-26 方向: 机构DeFi / RWA 阶段: Phase 1 - 监管与合规框架 (Day 15-28) 标签: #监管 #合规 #KYC #PermissionedDeFi #Quadrata #AaveArc

---

今日目标

---

一、KYC 链上化的演进历程

1.1 三代 KYC 链上方案

第一代（2018-2020）：链下 KYC + 链上白名单
  - KYC 在链下完成（如 Sumsub）
  - 白名单地址人工写入智能合约
  - 缺点：每个协议独立维护，KYC 无法复用

第二代（2021-2023）：KYC NFT
  - 用户 KYC 后获得 NFT（如 Quadrata Passport）
  - DApp 检查 NFT 持有
  - 改进：可移植
  - 缺点：NFT 公开可见、无选择性披露

第三代（2023-）：KYC VC + ZK
  - W3C VC 标准
  - ZK 证明选择性披露
  - 离线可证明（不依赖链上 NFT）
  - 例：Polygon ID, Sismo, Holonym

1.2 关键挑战：可移植性 vs 监管认可

核心 Tradeoff：
  - 完全去中心化 KYC = 监管不认可
  - 完全中心化 KYC = 失去 Web3 价值
  - 解决：受监管 Issuer + 去中心化 Verifier

---

二、主流 KYC 代币化方案

2.1 Quadrata Passport

• 公司：Quadrata（纽约）
• 2022-Q1 上线
• 结构：每个钱包一个 Passport NFT（不可转让 ERC-4671）
• 属性（attributes）：
  • DID（用户 ID）
  • Country（国家代码）
  • AML（风险评分 1-9）
  • IsBusiness（B2B 标识）
• 集成方：Frax、Decentralized Identifier Foundation 多个 DeFi
• 特点：
  • 链上完全可见（隐私不足）
  • 但提供 selective disclosure 模式
  • 与 KYC 提供商（Onfido、Sumsub）整合

2.2 Civic Pass

• 公司：Civic Technologies（旧金山）
• 历史：2017 ICO 项目
• 结构：NFT-style Pass
• 类型：
  • Uniqueness Pass（防女巫）
  • Liveness Pass（活体检测）
  • Identity Pass（KYC L1）
  • Accreditation Pass（合格投资者）
• 链：Solana 主，扩展至 EVM
• 集成：Solend、Mango Markets、Solrise

2.3 Coinbase Verifications（CBID）

• 公司：Coinbase
• 2024-08 上线
• 结构：基于 EAS（Ethereum Attestation Service）的 attestation
• 链：Base
• 属性：
  • Verified Country（地理）
  • Verified Account（Coinbase KYC 通过）
  • Trading Limit
• 使用方式：用户通过 Coinbase 在 Base 链申请 attestation，DApp 读取
• 优势：
  • 接入 Coinbase 7000 万用户
  • EAS 标准开放，可被任何应用使用
  • Base 链 gas 极低

2.4 Worldcoin Anchor / World ID

• 类型：Proof of Personhood（不是严格 KYC，但有反女巫属性）
• 机制：见 Day 24

2.5 Holonym Privacy Pool

• 类型：ZK KYC（用 ZK 证明 KYC 通过，但不暴露身份信息）
• 创新：与传统 KYC 服务商（Onfido、Persona）整合，输出 ZK proof

---

三、Permissioned DeFi 案例：Aave Arc

3.1 Aave Arc 概述

• 2021-12 上线
• 退出运行：2023-Q2 关闭（用户基础不足）
• 教训：Permissioned DeFi 早期市场未成熟

3.2 Aave Arc 架构

┌────────────────────────────────────────────────────┐
│  KYC 提供商（白名单 Whitelister）                    │
│  - Fireblocks 是首个白名单运营商                     │
│  - 候选：SEBA, Tokensoft 等                         │
└────────────────────────────────────────────────────┘
                    │ 添加合规钱包到白名单
                    ▼
┌────────────────────────────────────────────────────┐
│  Permissioned Pool（Aave Arc Pool）                  │
│  - Modifier: onlyWhitelisted                       │
│  - 仅白名单地址可 supply / borrow                   │
└────────────────────────────────────────────────────┘
                    │
                    ▼
┌────────────────────────────────────────────────────┐
│  机构客户                                            │
│  - 通过 Fireblocks 等 KYC 接入                      │
│  - 获得"许可"使用 Aave Arc                          │
└────────────────────────────────────────────────────┘

3.3 Aave Arc 智能合约关键代码

contract PermissionedLendingPool is LendingPool {
    address public permissionManager;
    
    modifier onlyPermitted(address user) {
        require(
            IPermissionManager(permissionManager).isInRole(user, ROLE.DEPOSITOR),
            "ARC_USER_NOT_PERMITTED"
        );
        _;
    }
    
    function deposit(...) external onlyPermitted(msg.sender) {
        super.deposit(...);
    }
}

contract PermissionManager {
    mapping(address => mapping(uint8 => bool)) private permissions;
    
    function addPermissions(
        address user,
        uint8[] calldata roles
    ) external onlyWhitelister {
        for (uint i; i < roles.length; i++) {
            permissions[user][roles[i]] = true;
        }
    }
}

3.4 Aave Arc 失败原因分析

1. Permissioned KYC 重复：Fireblocks KYC 已经做了，再加白名单冗余
2. 流动性碎片化：与公开 Aave 池流动性分离，利率劣
3. 机构需求不足：2021-2022 牛市机构不缺 yield
4. MakerDAO RWA 路径竞争：MakerDAO 通过传统 SPV 接入 RWA，更受机构欢迎

3.5 后继者：Aave Horizon、Maple Finance

Aave Horizon（2025-）

• Aave V3 + KYC NFT 版本
• 支持代币化国债（BUIDL）作为抵押
• 通过 Securitize 集成

Maple Finance

• 机构借贷协议
• 通过 KYC 池（每个池有 Pool Delegate 做 KYC）
• 已发放 $5B+ 贷款（2024）
• 客户：Wintermute、Auros、Folkvang 等机构做市商

---

四、EAS（Ethereum Attestation Service）

4.1 EAS 概述

• 由：The Graph 早期成员、Coinbase 等推动
• 类型：通用 attestation 框架
• 链：Ethereum、Base、Optimism、Arbitrum、Polygon 等

4.2 EAS 工作原理

1. Schema 定义（如 KYCAttestation = { address, country, kycLevel }）
2. Attester（如 KYC 提供商）发起 attestation：
   "Address 0x742... is KYC L2, country US"
3. attestation 上链（或链下，可选）
4. Verifier 查询：
   - 链上：直接读 attestation
   - 链下：通过 EAS GraphQL API

4.3 EAS 智能合约接口

interface IEAS {
    function attest(
        AttestationRequest calldata request
    ) external payable returns (bytes32);
    
    function getAttestation(
        bytes32 uid
    ) external view returns (Attestation memory);
}

struct Attestation {
    bytes32 uid;
    bytes32 schema;
    uint64 time;
    uint64 expirationTime;
    address recipient;
    address attester;
    bytes data;
}

4.4 Verax（Linea）

• Linea 链上的 attestation 注册
• 与 EAS 类似但侧重 Linea 生态

4.5 Coinbase Verified Pool

• Coinbase 在 Base 链推出
• 用户通过 Coinbase Verifications 接入特定 DeFi 池
• 例：Verified Aerodrome（DEX）、Verified Compound

---

五、KYC 可移植性架构

5.1 "KYC Once, Use Many" 架构

┌────────────────────────────────────────────────────┐
│  Tier 1: KYC Issuer (持牌)                           │
│  ├─ Sumsub (KYC L2)                                 │
│  ├─ Onfido (Liveness)                               │
│  ├─ Coinbase Verifications                          │
│  └─ Persona (US Accredited)                         │
│  发行 ZK VC 至用户钱包                               │
└────────────────────────────────────────────────────┘
                    │
                    ▼
┌────────────────────────────────────────────────────┐
│  Tier 2: Identity Aggregator                         │
│  ├─ Polygon ID Wallet                               │
│  ├─ Disco.xyz                                       │
│  └─ Holonym Privacy Pool                            │
│  存储 + 选择性出示 VC                                │
└────────────────────────────────────────────────────┘
                    │
                    ▼
┌────────────────────────────────────────────────────┐
│  Tier 3: Verifier (DeFi Protocols)                   │
│  ├─ DEX                                              │
│  ├─ Lending                                          │
│  ├─ RWA                                              │
│  └─ Derivatives                                      │
│  ZK proof 验证：仅检查需要的属性                     │
└────────────────────────────────────────────────────┘

5.2 跨协议复用机制

contract MultiVerifier {
    mapping(bytes32 => bool) public approvedSchemas;
    mapping(address => mapping(bytes32 => bool)) public userVerified;
    
    // 用户在协议 A 提交 ZK proof
    function verify(
        bytes32 schemaId,
        bytes calldata zkProof,
        bytes calldata publicInputs
    ) external {
        require(approvedSchemas[schemaId], "Schema not approved");
        require(
            zkVerifier.verifyProof(zkProof, publicInputs),
            "Invalid proof"
        );
        userVerified[msg.sender][schemaId] = true;
    }
    
    // 协议 B 直接读取
    function isVerified(
        address user,
        bytes32 schemaId
    ) external view returns (bool) {
        return userVerified[user][schemaId];
    }
}

5.3 集成层级（参考实现）

---

六、TradFi 监管 → Web3 映射

6.1 银行 CDD 流程对应

6.2 Aave Arc 模式 vs 传统经纪商账户

传统经纪账户：
  - 客户在券商开户（KYC）
  - 客户 → 券商 → 交易所
  - 券商承担 KYC 责任

Aave Arc 模式：
  - 客户在 Fireblocks KYC
  - Fireblocks 添加客户钱包到白名单
  - 客户 → Aave Arc 池
  - Fireblocks（Whitelister）承担 KYC 责任

6.3 监管认可状态

• 欧盟 MiCA：CASP 须 KYC，可使用 KYC VC（但需自行验证）
• 美国 BSA：MSB 须 KYC，VC 形式可接受但 Issuer 须受监管
• 新加坡 MAS：Project Guardian 试点采用 Polygon ID 类方案
• 香港 HKMA：Project Ensemble 采用 KYC VC

6.4 Permissioned DeFi 的合规价值

监管视角：
  Permissioned DeFi 是"可识别 + 可监督"的 DeFi
  - 所有交互方都 KYC
  - 监管可获取交易记录
  - 出现问题可追责

机构视角：
  - 解决了"DeFi 监管不确定"问题
  - 但流动性弱于公链 DeFi
  - 用于"机构间池子"，不直接服务零售

---

七、关键速查 Cheat Sheet

---

八、面试题（资深级）

Q1: 设计一个"KYC 复用"协议，让用户一次 KYC 在多 DeFi 协议使用，关键架构是什么？

STAR-T：

• Situation：用户每个新 DeFi 都要重新 KYC，体验差且成本高
• Task：设计可移植 KYC 架构
• Action：
  1. 核心：KYC 即 VC：用户在 Issuer（如 Sumsub）KYC 后获得 ZK VC
  2. 存储：Polygon ID Wallet（用户控制）+ 备份至 Disco
  3. 链上锚点：在 EAS 创建 attestation（仅指针，不含 PII）
  4. 协议接入：每个 DeFi 协议接受多 Issuer（白名单），通过 ZK 验证
  5. 撤销机制：Issuer 维护 revocation list（链上 Merkle root）
  6. Issuer 治理：DeFi 协议或第三方治理决定 trusted Issuer 列表
  7. 隐私保护：ZK 证明仅披露必要属性（age >18、country in EU）
• Result：用户 KYC 一次后无缝接入数十个 DeFi 协议
• Trade-off：Issuer 信任问题、监管认可路径长

Q2: Aave Arc 失败的核心原因是什么？后继者如何避免？

回答：

• Aave Arc 失败原因：
  1. 流动性分离：白名单池流动性远低于公开池，利率不利
  2. KYC 重复：Fireblocks 已 KYC 但还要白名单
  3. 市场不成熟：2021-2022 机构 yield 需求不足
  4. MakerDAO 竞争：MakerDAO RWA 模式（SPV + Foundation）更熟悉
  5. 运营复杂：Whitelister 需常规维护，成本高
• 后继者改进：
  1. Aave Horizon：直接接受代币化国债（BUIDL）抵押，无需独立池
  2. Maple：Pool Delegate 模式分散 KYC 责任
  3. Centrifuge：通过 Tinlake 池接入 RWA，KYC 在协议层
  4. 市场成熟：2024 高利率时代机构进入 DeFi 寻 yield，需求真实
  5. 集成 RWA：直接让代币化国债成为抵押品，不需独立 KYC 池

Q3: Coinbase Verifications 为什么部署在 Base 而不是 Ethereum？

回答：

• Base 优势：
  1. Gas 极低：attestation 创建几美分（vs Ethereum 几美元）
  2. Coinbase 控制：Base 是 Coinbase 的 L2
  3. 生态聚集：Base DeFi 协议自然采用 CBID
• 战略意图：
  1. Coinbase 推 Base 生态，CBID 是关键基础设施
  2. 把 1.1 亿 Coinbase 用户引导到 Base
  3. 与 World ID（Optimism）形成竞争
• EAS 跨链：CBID 通过 EAS 标准可被其他链调用（through CCIP 或预言机）
• 架构启示：
  • 大型 KYC 提供商（Coinbase、Binance）有动力建立"身份层"
  • 链选择影响 KYC 标准的 lock-in
  • 未来可能多 KYC 提供商之间互通（类似 SWIFT/Bridge）

Q4: KYC NFT vs ZK KYC VC，机构客户更偏好哪种？

回答：

• 机构客户偏好 ZK KYC VC：
  1. 隐私：机构持仓不愿被竞争对手看到（KYC NFT 链上可见）
  2. 选择性披露：可只披露 Accredited 状态，不披露具体资产
  3. 多场景：同一 KYC 用于多协议
• 零售客户更接受 KYC NFT：
  1. 简单：拥有 NFT 即可
  2. UX 好：无需 ZK proof 生成
• 对比：

  KYC NFT      ZK KYC VC
  公开           隐私
  简单           复杂
  ERC 标准成熟    ZK 工具仍在演进
  Gas 便宜        Gas 较贵（ZK 验证）
  无选择性        选择性披露
  

• 架构建议：双轨制
  • 零售/普惠产品：KYC NFT
  • 机构产品：ZK KYC VC
  • 桥接：从 NFT 升级到 VC 不需重新 KYC

Q5: 如果一家欧洲银行想接入 Aave V3 做 yield，KYC 架构应如何设计？

回答：

• 挑战：
  • 银行不能直接接入公开 Aave（无 KYC，监管不允许）
  • 需保留银行级合规
• 架构方案 A：通过 Aave Horizon：
  1. 银行 KYC 由 Securitize / Tokeny 等持牌机构完成
  2. 银行钱包在 Horizon 白名单
  3. 银行通过 BUIDL 等 RWA 抵押，借出稳定币 yield
  4. 监管报告链下生成
• 架构方案 B：自建 Permissioned Pool：
  1. 银行作为 LP 提供流动性
  2. 仅其客户（银行 KYC 钱包）可借
  3. 利率由银行设定（vs Aave 算法）
  4. 完全合规但流动性受限
• 架构方案 C：通过中介（Maple）：
  1. 银行作为 Pool Delegate
  2. 自定义 borrowers（已 KYC）
  3. 链上透明 + 监管报告
• 推荐：方案 C（Maple）—— 平衡合规、流动性、灵活性
• 预算：合规咨询 €1M + 集成 €0.5M，年运营 €1M

---

九、明日预告

明日（Day 26）我们进入 Web3 合规最大悖论——隐私 + 合规悖论：研究 Vitalik 等 2023 年论文《Privacy Pools: A New Approach》、ZK-KYC、Tornado Cash 案教训、混币器 vs 隐私池的合规设计差异、选择性披露（Selective Disclosure）的技术与监管路径。