合规代币化标准深度对比 (ERC-3643 / ERC-1400 / ERC-7943)

日期: 2026-05-31 方向: 机构DeFi / RWA 阶段: Phase 1 - RWA协议解剖 (Day 29-42) 标签: #ERC3643 #ERC1400 #ERC7943 #TREX #合规代币

---

今日目标

---

一、标准概述

1.1 标准定位与时间线

2018  ──  ERC-1400草案（Polymath，Adam Dossa & Pablo Ruiz）
        └ 把传统证券概念上链，但过于复杂，迟迟未formal
2020  ──  T-REX诞生（Tokeny Solutions，卢森堡）
        └ 简化ERC-1400，聚焦KYC+合规
2021  ──  ERC-3643草案提交
2023.06 ──  ERC-3643 Final，成为以太坊官方ERC标准
2024  ──  BlackRock、富兰克林、Apollo采用ERC-3643
2025 Q1 ──  ERC-7943草案提出，目标统一RWA标准
2025 Q4 ──  ERC-7943进入Last Call
2026 Q1 ──  机构市场ERC-3643仍占85%份额

1.2 三大标准定位

---

二、架构深度拆解

2.1 ERC-3643 (T-REX) 架构

T-REX = Token for Regulated EXchanges。整个T-REX套件由6个核心合约组成：

                    ┌─────────────────┐
                    │   T-REX Token   │  ← ERC-20兼容
                    │   (IERC3643)    │
                    └────────┬────────┘
                             │
        ┌────────────────────┼────────────────────┐
        │                    │                    │
        ▼                    ▼                    ▼
┌──────────────┐   ┌──────────────────┐   ┌─────────────┐
│   Identity   │   │   Compliance     │   │  Token      │
│   Registry   │   │   (Modular)      │   │  Storage    │
└──────┬───────┘   └─────┬────────────┘   └─────────────┘
       │                 │
       ▼                 ▼
┌──────────────┐   ┌──────────────────┐
│   ONCHAINID  │   │ Compliance Modules│
│  (ERC-734/735)│  │ - CountryAllow    │
└──────────────┘   │ - SupplyLimit     │
                   │ - TimeTransfers   │
                   │ - MaxBalance      │
                   └──────────────────┘

核心合约接口：

// ERC-3643 Token主合约关键函数
interface IERC3643 is IERC20 {
    // 身份与合规
    function identityRegistry() external view returns (IIdentityRegistry);
    function compliance() external view returns (IModularCompliance);

    // 转账控制（核心创新）
    function canTransfer(address _from, address _to, uint256 _amount)
        external view returns (bool);

    // 强制转账（SEC合规需要）
    function forcedTransfer(address _from, address _to, uint256 _amount)
        external returns (bool);

    // 冻结
    function freezePartialTokens(address _userAddress, uint256 _amount) external;
    function setAddressFrozen(address _userAddress, bool _freeze) external;

    // 恢复（密钥丢失场景）
    function recoveryAddress(
        address _lostWallet,
        address _newWallet,
        address _investorOnchainID
    ) external returns (bool);

    // 暂停（紧急情况）
    function pause() external;
    function unpause() external;
}

transfer()内部钩子流程：

function transfer(address _to, uint256 _amount) public override returns (bool) {
    require(!paused(), "ERC-3643: paused");
    require(!_frozen[msg.sender], "ERC-3643: from frozen");
    require(!_frozen[_to], "ERC-3643: to frozen");
    require(balanceOf(msg.sender) - _frozenTokens[msg.sender] >= _amount,
            "ERC-3643: insufficient unfrozen balance");

    // 关键：双重检查
    require(_tokenIdentityRegistry.isVerified(_to),
            "ERC-3643: receiver not verified");  // KYC检查
    require(_tokenCompliance.canTransfer(msg.sender, _to, _amount),
            "ERC-3643: compliance failed");      // 合规规则检查

    // 执行转账
    _transfer(msg.sender, _to, _amount);

    // 通知合规模块
    _tokenCompliance.transferred(msg.sender, _to, _amount);
    return true;
}

2.2 ONCHAINID 身份系统 (ERC-734 / ERC-735)

每个投资者部署一个个人ONCHAINID合约，存储Claims（KYC、AML、Accredited Investor状态等）。

// ERC-735 Claim结构
struct Claim {
    uint256 topic;      // 1=KYC, 2=AML, 3=Accredited, 7=Country
    uint256 scheme;     // 1=ECDSA, 2=RSA, 3=合约
    address issuer;     // 谁签发的（如Securitize）
    bytes signature;    // 签发者签名
    bytes data;         // 实际数据（hash或加密）
    string uri;         // 链下IPFS存证
}

Identity Registry通过ClaimTopicsRegistry约束代币要求哪些Claim：

// 部署T-REX时配置
identityRegistry.setRequiredClaimTopics([1, 2, 3]);  // KYC + AML + Accredited
identityRegistry.setTrustedIssuers([securitizeAddr, fireblocksAddr]);

2.3 ERC-1400 架构（参考）

ERC-1400 = ERC-1410 (Partition) + ERC-1594 (Transfer) + ERC-1643 (Documents) + ERC-1644 (Controller)

核心差异是**Partition（分区）**概念，模拟传统证券的Tranche：

interface IERC1410 {
    function balanceOfByPartition(bytes32 _partition, address _tokenHolder)
        external view returns (uint256);

    function transferByPartition(
        bytes32 _partition,
        address _to,
        uint256 _value,
        bytes calldata _data
    ) external returns (bytes32);
}

典型Partition应用：把同一发行的证券分为：

• bytes32("Locked-Until-2027") = 锁仓部分
• bytes32("Free-Trading") = 已解锁部分
• bytes32("Restricted-US") = 美国限制持有

2.4 ERC-7943 草案

ERC-7943目标：统一所有RWA类型（Fungible/Semi-Fungible/Non-Fungible）+ 内置合规接口 + 跨链友好。

interface IERC7943 {
    // 统一资产标识
    function assetType() external view returns (AssetType);
    enum AssetType { Fungible, SemiFungible, NonFungible }

    // 通用合规检查
    function complianceCheck(
        address from,
        address to,
        uint256 id,        // tokenId或0
        uint256 amount,
        bytes calldata data
    ) external view returns (bool, string memory);

    // 跨链消息验证
    function verifyCrossChainProof(
        uint256 sourceChainId,
        bytes calldata proof
    ) external returns (bool);
}

---

三、资金流/价值流图

投资者(Investor)
    │
    │ 1. 提交KYC材料
    ▼
Securitize / Tokeny (Trusted Issuer)
    │
    │ 2. 验证KYC，签发Claim
    ▼
Investor's ONCHAINID Contract
    │  (链上存储Claim)
    │
    │ 3. 投资者打开钱包，准备购买代币
    ▼
T-REX Token Contract.mint(_to, _amount)
    │
    │ 4. 检查
    ├──► IdentityRegistry.isVerified(_to)?
    │         │
    │         └──► 检查ONCHAINID是否有required claims
    │
    └──► Compliance.canTransfer(0x0, _to, _amount)?
              │
              ├──► CountryAllowModule
              ├──► MaxBalanceModule
              └──► SupplyLimitModule

如果全部通过 → mint成功
如果任一失败 → revert with reason

转账时同样流程：
sender → canTransfer() → IdentityRegistry + Compliance检查 → _transfer()

---

四、风险分析

4.1 合规规则错误风险

• Compliance模块Bug：CountryAllowModule的国家代码错误 → 缓解：模块独立审计、Timelock升级
• 白名单遗漏：某机构投资者ONCHAINID过期未更新 → 缓解：Claim自动过期机制 + 通知

4.2 中心化风险

• Trusted Issuer失信：Securitize如果被黑，可签发任意Claim → 缓解：多签Issuer + Claim revocation机制
• Owner权限过大：Token Owner可调用forcedTransfer → 缓解：链下法律协议+Multi-sig+Timelock

4.3 升级风险

• Proxy升级冻结资产：T-REX大部分用UUPS Proxy，恶意升级可冻结全部 → 缓解：ProxyAdmin Multi-sig + Timelock 48h

4.4 跨链风险

• 跨链KYC不一致：以太坊上验证过KYC，桥到Polygon后未同步 → 缓解：CCIP/LayerZero同步Identity Registry

4.5 法律风险

• Force Transfer合法性：法院判决要求强制转移代币，但代币所在司法辖区不同 → 缓解：明确合约的choice of law + 准据法

---

五、TradFi对照

关键洞察：ERC-3643不是"创造新规则"，而是把美国Reg D / Reg S / Rule 144等条款程序化为链上代码，让传统Transfer Agent的工作可以原子地在链上完成。

---

六、关键速查表

选型决策树

你要发行什么资产？
├── 股权/债券（单一类别） ──► ERC-3643
├── 多Tranche证券（A/B股） ──► ERC-1400
├── NFT形式房产/艺术品 ──► ERC-7943 或 自定义ERC-721扩展
└── 已知会跨5+条链流通 ──► ERC-7943

监管诉求强烈？
├── 美国Reg D / Reg S ──► ERC-3643（机构生态最完整）
├── 欧盟MiCA ──► ERC-3643 + Tokeny CSD集成
└── 新加坡VCC ──► ERC-3643 或 ERC-1400

预算/时间紧？
├── 紧 ──► 用Tokeny/Securitize SaaS（基于ERC-3643）
└── 充裕 ──► 自研ERC-7943

---

七、面试题

Q1: 为什么ERC-3643成为机构事实标准而ERC-1400没有？

回答：

• 复杂度问题：ERC-1400由ERC-1410/1594/1643/1644四个子标准组成，实施成本高
• 生态问题：Polymath基金会推广不力，缺乏头部用户
• 时机问题：ERC-3643在BlackRock入场前刚好成熟（2023.06 Final，2024.03 BUIDL发行）
• 模块化优势：ERC-3643的Compliance模块化让发行人可以快速组合规则
• 工具链：Tokeny提供完整SaaS（CSD/CSDR级别），Securitize是事实标准Transfer Agent

Q2: ERC-3643的forcedTransfer合法吗？是否破坏了"代码即法律"？

回答：

• 合法性：完全合法。Reg D证券本身就允许Issuer/Transfer Agent在特定情况下强制过户（破产、法院判决、KYC失效）
• 不是"代码即法律"：RWA从来不主张code is law，反而是code as legal infrastructure
• 使用场景：
  • 法院判决（如离婚财产分割）
  • 用户私钥丢失 → 配合recoveryAddress
  • SDN制裁名单 → OFAC合规
• 权力制衡：通常用Multi-sig + Timelock + 链下法律授权书三重门

Q3: 如何设计一个跨链ERC-3643？KYC状态如何同步？

回答：

1. 架构选择：Hub-Spoke模型，主链（Ethereum）作为Identity Registry Hub
2. 同步机制：
   • 用CCIP/LayerZero/Hyperlane传递Identity状态变更
   • 投资者ONCHAINID映射到每条链一份镜像合约
3. 冲突处理：
   • Hub失效时，Spoke进入"只赎回不申购"模式
   • 重大状态分歧用Multi-sig仲裁
4. 真实案例：BUIDL在Ethereum/Polygon/Arbitrum多链部署，Securitize用Wormhole + Apex Group的链下注册系统双轨同步

Q4: 如果让你设计一个房产代币化，选哪个标准？

回答：分场景：

• 整套房产单一所有权：ERC-721 + 自定义合规扩展
• 份额化房产（如RealT）：ERC-3643（同质化代币代表LLC份额）
• 多套房产组合：ERC-7943（NFT表示房产，FT表示SPV份额）
• 法律结构：必须搭配Delaware Series LLC或Cayman SPV，链上代币代表LLC会员权益（Membership Interest）

Q5: ERC-3643的Compliance Module可以无限叠加吗？性能如何？

回答：

• 可以叠加：Compliance支持注册多个Module，transfer时遍历所有Module的moduleCheck()
• gas成本：每个Module ~5K-15K gas，10个Module ~100K gas
• 优化方案：
  • 把高频检查（如frozen状态）放在Token主合约，低频放Module
  • 用Bitmap存储Allowlist（节省storage slot）
  • 使用ERC-7201 namespaced storage避免升级冲突
• 生产案例：BUIDL实际只用4个Module：CountryRestrict, MaxSupply, MinTransferAmount, MinHolderBalance

---

明日预告

Day 31: BlackRock BUIDL深度解剖

明天我们将完整拆解BUIDL（BlackRock USD Institutional Digital Liquidity Fund）：

• Securitize架构与全套合约
• Allow-list与白名单转账实现
• 链上每日分红机制
• 与Aave/Sky的DeFi集成
• $2.9B TVL背后的合规设计

预计深度700+行。