监管型代币协议标准分化：发行、合规和集成各司其职

EVM 监管型代币标准：ERC-1450 管发行，ERC-3643 管身份合规，ERC-7943 管集成。

撰文：@JayLovesPotato，Four Pillars

编译：AididiaoJP，Foresight News

核心要点

EVM 上的监管型代币标准并未走向单一统一规范，而是按功能明确分工。ERC-1450、ERC-3643 和 ERC-7943 因此不宜被看作互相竞争的标准，而应理解为分别负责发行、身份、执行与集成的互补组件。

注：监管型代币标准简单说就是：专门为「受监管的代币」设计的技术规范。普通代币（比如普通 ERC-20）可以随便转、随便持有，几乎没有限制。但监管型代币（Regulated Token）不一样，它通常对应现实中的证券、基金份额、债券、RWA（真实世界资产）等受监管资产，让代币从「谁都能随便转」变成「符合金融监管要求」的技术规则。

各链之间的关键差异，不在于是否具备监管功能，而在于这些功能被实现和执行的位置。EVM 在单个资产合约层面保留了高度灵活性；Solana 和基于 Move 的链把更多功能放在共享代币框架中；Stellar 和 XRPL 则直接嵌入账本；Canton 和 Avalanche L1 则进一步延伸到市场与网络运营层。

监管型代币标准的竞争力，未来更可能取决于它们对监管变化的适应灵活度，而非功能数量的多少。更务实的方向是构建一个合规堆栈：把冻结、强制转账、转账前验证等反复出现的执行功能标准化，同时把身份提供商、司法辖区规则、持有上限等产品特定政策拆成可替换的模块。

即使在机构最熟悉的以太坊 EVM 环境中，也有多个 ERC 在解决监管型代币的类似需求。它们普遍支持转账限制、投资者资格检查、冻结、强制转账和丢失资产恢复。但各标准所假设的法律结构和运营权限却有显著差异。

EVM 之外，其他链也在代币程序、账本或网络层面加入了可比功能，进一步拓宽了监管资产的实现路径。

这在一定程度上反映了监管型代币标准尚未形成清晰结构。更根本的原因是，监管资产所需的功能很难被塞进单一规范里。谁维护证券的法律记录、哪家机构认证投资者资格、事故发生时运营方该保留多少控制权------这些问题因产品和司法辖区而异。

因此，市场正走向一种架构：这些功能被分散在多个层级，并按需组合，而不是追求一个完全自给自足的单一标准。

EVM 上的监管型代币标准

早期标准大多试图把传统金融的运营结构直接复制进代币合约。在 ERC-1450 下，注册过户代理（Registered Transfer Agent）不仅负责发行和赎回，还执行每一笔转账，普通用户被禁止调用 transfer 和 approve。这明确了谁维护法律记录、谁负责响应法院命令或丢失密钥。但与此同时，它也远离了传统 DEX 和借贷协议所假设的无许可资产流动。

ERC-3643 则把监管功能分散到代币合约、身份注册表（Identity Registry）、可信发行方注册表（Trusted Issuers Registry）和独立的合规模块中，而不是集中在单一权威下。转账会对照可信实体签发的声明进行验证，包括 KYC 状态、居住地和合格投资者资格；发行方还可以添加投资者数量、国家级持有上限等规则。在保留基本 ERC-20 结构的同时，能够替换单个规则，这是一个有意义的优势。代价是协调多个合约、身份发行方和特权管理角色带来的运营负担。

更近的 ERC-7943 采取了不同路径：它并不定义监管政策本身，而是暴露一套通用接口，包括 canSend、canReceive、canTransfer、冻结余额查询和强制转账函数。这让钱包、交易所、托管机构和 DeFi 服务能够以一致的方式与不同监管资产交互。换句话说，ERC-3643 是创建监管型代币的堆栈，而 ERC-7943 更接近连接多个堆栈的集成层。最近 CMTAT 实现添加对 ERC-7943 的支持，进一步说明这种最小接口可以叠加在现有发行标准之上。

ERC-7518 和 ERC-8047 则针对更专门的需求。ERC-7518 把不同股份类别、司法辖区和锁定期条件应用到单个 ERC-1155 分区；ERC-8047 则在资产流动时记录父子谱系，让执行可以针对特定资金流而非整个账户。前者让单一资产内的权利区分更明确；后者让事后追踪和执行更精准。它们更可能作为补充更广泛合规堆栈的模块，而不是取代 ERC-3643 的全能标准。

其他链把监管功能放在哪里

Solana 的做法以把反复出现的代币功能放在更底层的共享层为特色。Transfer Hook、Permanent Delegate 和 Confidential Transfer 等功能通过通用 Token Extensions 库提供，Solana Attestation Service 则允许应用复用链下信息，如 KYC 状态、地理位置和投资者资格。这减少了每个发行方独立重建和审计相同功能的需要。不过，当钱包或协议不支持某个扩展时，集成仍可能断裂；此外，配置了 Permanent Delegate 等强大发行方控制的资产，DeFi 应用必须将其视为额外一层对手方风险。

Stellar 和 XRPL 把授权、冻结和追回作为账本原生资产的属性暴露出来。这些控制在转账和原生交易功能中一致生效，应用无需为每个代币合约重新解读自定义逻辑。Stellar 正通过 Stellar Asset Contracts 扩展账本资产与智能合约环境的连接；XRPL 则围绕 MPT 构建，从许可持有、冻结和恢复走向隐私相关功能。然而，规则嵌入账本越深，其演进就越依赖网络升级和共识。控制设置也可能更直接地约束资产的流动性和使用范围。

Sui 和 Aptos 介于 EVM 的合约中心模式与账本原生模式之间。Sui 在 Currency Registry 中记录监管资产的拒绝列表状态和全局暂停权限；Aptos 则通过 Fungible Asset 框架的 TransferRef 冻结账户，或在必要时通过特权转账绕过这些限制。地址封锁和紧急暂停等反复出现的执行功能由框架提供；更复杂的政策，如投资者分类和国家特定持有上限，则留给独立的 Move 模块。在这一点上，它们的架构最接近 EVM 生态自身正在走向的模块化方向。

Canton 把监管范围从代币扩展到整个市场的运营。CIP-56 不仅标准化余额转账，还包括特定方信息披露、接收方批准和原子货银对付（DvP）；Token Standard V2 正在 2026 年的独立 DevNet 上测试。这种设计提供了更强的运营一致性和隐私，但也需要专用的身份和开发环境。因此，现有公链流动性和应用无法简单迁移过来。

Avalanche L1 更适合被理解为构建监管市场本身的选项，而不仅仅是发行监管型代币。运营方可以用白名单限制交易参与者和合约部署者，同时要求验证者满足 KYC、AML 或牌照条件。该堆栈还可以把 Jumio 和 Keyring 等身份提供商连接到 txAllowlist，非常适合仅限机构的交易所或支付网络。代价是运营层面的：验证者、升级、跨链桥和流动性都必须独立管理，成本和碎片化程度远高于在现有 EVM 网络上发行单一代币。

把通用执行功能与监管政策分开

综合来看，这些路径表明两个极端都有明显局限：无论是把整个监管堆栈嵌入网络，还是把所有功能留给单个 ERC。大多数监管资产都会反复出现的通用执行功能------转账前验证、冻结、强制转账、紧急暂停，以及披露管理权限及其相关风险的元数据------最好放在靠近代币框架、账本或像 ERC-7943 这样的最小接口的位置。这样可以降低发行方之间的实现差异和审计成本，同时让钱包、交易所和托管机构能够一致识别资产的控制结构。

相比之下，信任哪些身份提供商、允许哪些司法辖区、如何计算投资者级别的持有上限和锁定期、谁可以执行法律命令------这些决策更适合留给资产特定的 ERC 或独立模块。这些规则因产品和司法辖区而异，且必须随法律变化而更新。如果把它们硬编码进网络基础规则，不仅会拖慢升级，还可能把特定金融市场的政策选择变成通用链的默认设置。

换句话说，监管型代币市场更可能以合规堆栈的形式发展，而不是收敛到单一标准。在这个模型下，可替换的身份、司法辖区和产品特定规则会建立在通用执行功能之上。以太坊及更广泛的 EVM 生态在政策灵活性和现有流动性接入方面仍有优势；账本原生链在执行一致性和运营简洁性上更强；而像 Canton 这样的专用网络则在隐私和机构工作流方面最突出。

因此，采用率不太可能由哪个标准功能列表最长来决定。更重要的是，监管政策能否在不重新发行资产、也不强迫钱包、交易所和托管机构从零重建集成的情况下发生变化。另一个关键测试是：外部参与者能否清晰识别、评估并管理嵌入资产中的强大控制权.