链上合规不靠拦交易：ERC-8106 用事件给 RWA 代币记账

受监管的代币资产做合规，传统做法是在转账函数里塞校验、不合格就 revert。ERC-8106（RWA Event-based Compliance Framework）选了另一条路：交易照过，合规以标准化事件的形式留下来，事后审计有统一格式的账可查。按 ercs 仓库记录，该提案状态为 Draft，创建于 2025 年 12 月 16 日。

两类主体与一张登记表

标准把链上地址分成两类：合规实体（Compliance Entity）代表受监管的法律主体，例如企业金库、托管账户；去中心化实体（Decentralized Entity）代表普通用户、路由合约、结算合约等链上参与者。登记合约提供 registerComplianceEntity 做显式注册，entityTypeOf 做查询，并定死一个默认规则：没有明确注册过的地址一律按去中心化实体返回。主体类型变更必须发出 EntityTypeUpdated 事件，事件里带 reasonHash 指向链下文档（KYC 记录、法律主体登记材料），并带 operator 字段标明是谁授权了这次变更。注册、默认值、事件、原因哈希、操作者问责，五条硬性要求构成一个闭环：链上永远有当前状态的权威答案，且每次改动都能追到人。

事件即合规观察：软策略的含义

另一半是 ComplianceObserved 事件：代币合约（标准以 ERC-20 上的 purchaseRWA 为示例入口）在发生业务事件时，把合规相关的观察结果按统一结构写进事件日志。标准把这称为软策略——合规意图通过事件标注表达，而不是通过 revert 拦截表达。这样做的好处一目了然：链上交互不会因为某个链下名单的抖动而大面积失败，合规系统作为旁路观察者工作，索引器和审计工具按事件流重建每一笔业务的时间线；BizID 哈希把同一业务流程的多笔转账关联起来，防止拆单后看不出是同一件事。

别把记账当成放行

这套设计要读得准。第一，软策略绝不等于没有合规：事件标注的前提是链下合规体系有权事后处置，冻结、追索、法律手段都在链外，链内只是留痕。第二，事件不会替你拦截错误交易——一个把 ERC-8106 当”合规通过证书”的集成方理解反了：观察事件记录的是”发生了什么、系统怎么看”，不是”协议批准了什么”。第三，主体分类的权威在登记合约与 reasonHash 指向的链下文件，分类错误会让整条事件时间线得出错误结论，核对EntityTypeUpdated 历史是审计的第一步。

索引器与审计脚本怎么消费这套事件

对做监控和审计的工具作者，这套标准的接入成本比看起来低。实体侧维护一张影子表即可：监听 EntityTypeUpdated，按实体地址折叠出”任意时点的主体类型”状态机，entityTypeOf 的当前值用于对账，历史分叉靠事件时间线还原；reasonHash 存成外链字段，审计界面里点开应当直达披露文档，点不开的直接标红。业务侧解析 ComplianceObserved 事件流，用 BizID 做分组键，把同一业务流程名下的多笔转账串成一串，任何一笔转账若没有对应的观察事件，就进入了”未标注交易”清单——软策略体系里，缺标注本身就是最高优先级的异常信号，比标注内容更值得报警。再叠一层交叉核对：把 ERC-20 标准 Transfer 流与合规事件流做双向差集，链上有转账无事件、有事件无转账，两种不匹配各自指向集成缺陷或解析缺陷。工具按这个骨架搭建后，换一个采用同一标准的项目，改动量集中在字段映射，逻辑层完全复用——这正是标准化事件格式对审计生态的实际红利。

对关注实物资产代币化收藏品的读者，它的现实价值是给了一个审计切口：一个自称合规的 RWA 藏品项目，如果支持这套事件，你就能直接问三个问题——合规主体名单在哪查、观察事件覆盖哪些业务动作、reasonHash 指向的文档是否公开。三个问题的答案质量，比任何合规徽标都更能说明问题。本文为机制说明，不构成任何投资建议。