ERC-3643 合规代币实现：身份验证、转账限制与监管合规的 Solidity 完整方案
一、引言
ERC-20 的开放转账模型是 DeFi 爆发的基础设施，但在 RWA 代币化场景中，这个模型直接违反了每一项证券法规。一个房地产基金代币从美国投资者账户直接 transfer 到受制裁地区地址——这在 ERC-20 语义下完全合法，但实际可能触发 SEC 执法行动。
ERC-3643（T-REX，Token for Regulated EXchanges）正是为解决这个矛盾而设计。它不是在 ERC-20 上打个补丁，而是从根本上重新定义了"合规代币"的转账语义：每一笔 transfer 在状态变更前，必须经过一个可编程的合规检查器（Identity Registry + Compliance Module），验证发送方和接收方的身份、权限与当前持仓限额。
这篇文章从合约层拆解 ERC-3643 的核心机制：链上身份注册表的设计、模块化合规检查流程、以及一个可直接部署的 Solidity 实现方案。
二、核心原理
ERC-3643 的架构建立在三个核心合约之上：
**Identity Registry（身份注册表）**存储链上地址与链下身份的映射。核心数据结构是 Identity——包含该地址的 KYC 状态、国家代码、投资者类型（散户/合格投资者/机构）以及身份哈希。只有被注册表标记为"已验证"的地址，才具备持有受监管代币的资格。
**Compliance Module（合规模块）**是一组可插拔的规则引擎。每次转账调用时，发币合约向合规模块提交 (from, to, amount) 三元组，合规模块返回 true/false。常见规则包括：接收方 KYC 状态检查、发送方国家与接收方国家的双边合规、单地址持仓上限、24h 交易量上限、以及冻结/锁定状态。
Token 合约继承 ERC-20 接口但重写 _transfer 和 _mint 逻辑，在每次状态变更前后插入合规断言。
关键设计在于"前置检查 + 后置更新"的两阶段提交模式。canTransfer 仅做读操作判断，transferred 在余额变更后更新合规模块内部计数器（如 24h 交易量）。这保证了哪怕大并发场景下，检查条件和状态更新之间的一致性由区块链单个交易的原子性天然保障。
三、关键实现
以下是 ERC-3643 核心合约的 Solidity 实现：
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;
/**
* @title Identity Registry
* @notice 链上身份注册表，管理地址的 KYC 状态与投资者属性
* 设计决策：使用结构体而非分离映射，减少存储读取次数
* 单个 SLOAD 即可获取地址的全部合规属性
*/
contract IdentityRegistry {
struct Identity {
bool verified; // KYC 验证状态
uint8 investorType; // 1=散户 2=合格投资者 3=机构
bytes2 countryCode; // ISO 3166-1 alpha-2
bytes32 identityHash; // 链下身份数据的 Keccak256 哈希
uint256 verificationTime;
}
mapping(address => Identity) public identities;
mapping(bytes32 => address) public hashToAddress; // 反向查找防止身份冒用
address public owner;
event IdentityRegistered(address indexed addr, bytes2 countryCode, uint8 investorType);
event IdentityRevoked(address indexed addr);
modifier onlyOwner() {
require(msg.sender == owner, "Only owner");
_;
}
constructor() {
owner = msg.sender;
}
/**
* @notice 注册或更新链上身份
* @dev 设计决策：identityHash 由链下签名后上链，确保身份数据不可篡改
* 同一 identityHash 只能绑定一个地址，防止身份冒用
*/
function registerIdentity(
address user,
uint8 investorType,
bytes2 countryCode,
bytes32 identityHash
) external onlyOwner {
require(investorType >= 1 && investorType <= 3, "Invalid investor type");
// 防止身份冒用：除非是同一地址更新，否则 hash 不能冲突
require(
hashToAddress[identityHash] == address(0) ||
hashToAddress[identityHash] == user,
"Identity already bound"
);
// 若为地址转移，清空旧绑定
bytes32 oldHash = identities[user].identityHash;
if (oldHash != bytes32(0)) {
delete hashToAddress[oldHash];
}
identities[user] = Identity({
verified: true,
investorType: investorType,
countryCode: countryCode,
identityHash: identityHash,
verificationTime: block.timestamp
});
hashToAddress[identityHash] = user;
emit IdentityRegistered(user, countryCode, investorType);
}
function isVerified(address user) external view returns (bool) {
return identities[user].verified;
}
function revokeIdentity(address user) external onlyOwner {
bytes32 oldHash = identities[user].identityHash;
delete hashToAddress[oldHash];
delete identities[user];
emit IdentityRevoked(user);
}
}
合规模块实现了可插拔的规则引擎：
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;
import "./IdentityRegistry.sol";
/**
* @title ComplianceModule
* @notice 模块化合规检查引擎
* 设计决策：每条规则独立函数 + 规则开关映射，
* 支持动态启用/禁用特定合规检查而无需升级合约
*/
contract ComplianceModule {
IdentityRegistry public registry;
address public token;
// 规则开关：后台可逐一禁用某条规则，应对紧急情况或监管政策变更
mapping(bytes32 => bool) public ruleEnabled;
// 每地址 24h 累计转账量（适用于反洗钱限额）
mapping(address => uint256) public dailyTransferred;
mapping(address => uint256) public dailyResetTime;
// 每地址持仓上限制
mapping(uint8 => uint256) public maxHoldings; // investorType => max
// 受制裁国家列表
mapping(bytes2 => bool) public sanctionedCountries;
// 持仓上限：每地址不得超过其投资者类型对应的上限
uint256 public constant MAX_DAILY_TRANSFER = 1_000_000 * 1e18;
event RuleToggled(bytes32 indexed ruleId, bool enabled);
constructor(address _registry) {
registry = IdentityRegistry(_registry);
ruleEnabled[keccak256("kyc_check")] = true;
ruleEnabled[keccak256("sanction_check")] = true;
ruleEnabled[keccak256("holding_limit")] = true;
ruleEnabled[keccak256("daily_limit")] = true;
}
/**
* @notice 核心合规检查入口
* @dev 设计决策：单个函数统一检查所有规则，一次性返回结果，
* 避免分散调用增加 gas。规则之间短路优化：越便宜的检查越靠前
*/
function canTransfer(
address from,
address to,
uint256 amount,
uint256 toBalance
) external view returns (bool) {
// 规则 1: KYC 检查（最便宜——单次 SLOAD）
if (ruleEnabled[keccak256("kyc_check")]) {
if (!registry.isVerified(from)) return false;
// 铸造场景 from == address(0)，仅检查 to
if (to != address(0) && !registry.isVerified(to)) return false;
}
// 规则 2: 制裁国家检查
if (ruleEnabled[keccak256("sanction_check")]) {
if (sanctionedCountries[registry.identities(to).countryCode]) return false;
}
// 规则 3: 持仓上限检查
if (ruleEnabled[keccak256("holding_limit")]) {
IdentityRegistry.Identity memory identity = registry.identities(to);
uint256 maxHolding = maxHoldings[identity.investorType];
if (maxHolding > 0 && toBalance + amount > maxHolding) return false;
}
return true;
}
/**
* @notice 转账后更新内部状态（24h 交易量计数器）
* @dev 设计决策：在 transfer 成功后调用，与检查逻辑解耦
*/
function transferred(address from, uint256 amount) external {
require(msg.sender == token, "Only token");
_updateDailyCounter(from, amount);
}
function _updateDailyCounter(address user, uint256 amount) internal {
if (block.timestamp > dailyResetTime[user]) {
dailyTransferred[user] = 0;
dailyResetTime[user] = block.timestamp + 24 hours;
}
dailyTransferred[user] += amount;
}
function addSanctionedCountry(bytes2 countryCode) external {
sanctionedCountries[countryCode] = true;
}
}
Token 合约的重写 _update（继承自 OpenZeppelin 5.x 的 _transfer 替代方法）：
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "./ComplianceModule.sol";
contract RegulatedToken is ERC20 {
ComplianceModule public compliance;
constructor(
string memory name,
string memory symbol,
address complianceAddr
) ERC20(name, symbol) {
compliance = ComplianceModule(complianceAddr);
}
/**
* @dev 重写 ERC-20 _update，插入合规断言
* 设计决策：不修改 transfer / transferFrom 签名，
* 所有检查在 _update 层统一拦截，覆盖 mint 和 burn 路径
*/
function _update(address from, address to, uint256 value) internal override {
// 前置检查
require(
compliance.canTransfer(from, to, value, balanceOf(to)),
"Transfer blocked by compliance"
);
super._update(from, to, value);
// 后置更新
if (from != address(0)) {
compliance.transferred(from, value);
}
}
/**
* @notice 强制转账（监管需求：仅 owner 可调用）
* 设计决策：此函数绕过 canTransfer，但仅允许冻结/没收等执法场景
*/
function forceTransfer(address from, address to, uint256 amount) external {
require(msg.sender == compliance.registry().owner(), "Not authorized");
super._update(from, to, amount);
}
}
四、边界与约束
Griefing 攻击与 DOS 风险。合规检查如果依赖外部合约调用，攻击者可以通过操控外部合约让转账始终失败。本方案的检查逻辑全部内聚在合规合约中，不依赖外部调用，消除了这个攻击面。
身份注册中心化。IdentityRegistry 的 owner 拥有注册 / 撤销身份的完全权限，这在去中心化原教旨主义看来是单点控制风险。但在 RWA 场景中，监管合规要求必须有一个"可追责实体"——完全去中心化的身份管理在现有法律框架下不可行。务实方案是使用多签（3/5 或 5/7）控制 owner，将权限分散到合规官、交易所、审计方的联合签名。
Gas 成本。每次转账引入的额外 SLOAD（身份查询 + 合规检查）约增加 5000-8000 gas。批量转账场景可以考虑使用 transferBatch 复用合规检查结果来摊薄成本。
升级性。合规规则必然随时间变化（新制裁名单、修改持仓上限等），而 Token 合约通常不希望频繁升级（增加攻击面）。本方案的模块化设计允许独立升级 Compliance Module 而不触碰 Token 核心逻辑。
五、总结
ERC-3643 给 RWA 代币化提供了一个"可被监管而非被审查"的合规框架。与 Permissioned 私链不同，它运行在公共区块链上，任何人都可以验证规则执行的一致性——监管方看到的是一个透明的、算法化的合规层，而非一个不透明的后台数据库。
实现的关键取舍在于：将身份管理（Identity Registry）、规则执行（Compliance Module）和资产账本（Token）三者分离为独立合约。这种模块化不仅简化了审计路径，也让合规规则能够随监管变化而独立演进。RWA 代币化的竞争已经从"能不能上链"转向了"上链后能不能合规流通"，而 ERC-3643 及其周边的链上身份基础设施，正在这条路径上提供工程级的答案。
