某些代币在 A 交易所地址与 B 托管地址之间能转、反过来却被拒，或者从游戏内金库往玩家钱包放行、往同类合约转出却被禁——这类”看方向放行”的规则，过去都埋在单个代币合约的内部逻辑里，外人查不到依据。ERC-8327 把这类规则搬上一张公共查询表：任何代币只要声明了”资产类别”，就能查一张按方向组织的路由表。标准仓库中该提案处于评审（Review）阶段。
一张三元组查询表
按规范，注册表对一个有序三元组回答是或否：源域、目标域、资产类别，三者都是 bytes32 形式的 opaque 标识——域代表一个司法辖区、受监管交易场所、企业网络、游戏经济体之类由应用自定义的边界。查询函数是 isRoutePermitted(sourceDomain, destinationDomain, assetClass)，配套的 getRoute 返回完整条目：除允许状态外，还有许可证据哈希、撤销证据哈希和 effectiveAt 生效时间戳（uint64）。写入侧对应 setRoute 与 revokeRoute，各触发 RouteSet 与 RouteRevoked 事件，三个索引参数让路由变更可以用事件反查法追溯收据里的日志也能查账：topics 和 data 怎么反查一笔转账。另有 isRoutePermittedBatch 一次问一批方向。
方向是认真的：A 到 B 通不代表 B 到 A 通
规范把方向性写进了模型：同两个域之间，去程与回程是两条独立记录；同一对域之间，不同资产类别又是不同记录。这比”白名单/黑名单”式的单集合表达更贴近现实合规需求——例如受监管发行方常要求代币只能从合规托管域流向交易所域，反向则叠加额外限制。对你排查”这笔转不动”的问题，这个结构的含义是：别只检查目标地址在不在名单，而要问”这个方向、这个资产类别”的组合路由状态。
可选的延迟撤销扩展
核心接口还支持一个可选扩展：撤销不必即时生效，可先 initiateRevocation 发起、期间可 cancelRevocation 取消、到达生效条件后以 lazy 方式生效或用 finalizeRevocation 敲定，状态由 getRevocation 查询。发起、取消、敲定都有对应事件。这个设计对应真实世界的”政策过渡期”：路由关闭前留出缓冲，而不是瞬间掐断。
注册表不管的四件事
规范明确划界：它不给域分配地址、不推导资产类别、不验证证据内容是否属实、不执行任何转账拦截。真正的拦截发生在代币或转账控制器里——是那个合约自己去查表并在转账路径上执行结果。所以排查顺序应当是：先在代币合约文档或源码里确认它查询了哪张注册表、用哪套域标识体系，再查注册表本体对该三元组的当前值与最近事件；两边都干净还被拒的，才轮到代币自身的地址级逻辑。
与普通用户的关系
普通用户不会被要求直接调用这些函数，但 2026 年合规资产与 RWA 场景里，这类”政策即合约”的查询面正在变多。它能给你的确定收益只有一条：转账被拒时把”路由状态”作为独立排查项——查事件、查注册表当前值、对比生效时间戳——而不是默认怀疑网络拥堵或钱包故障。表查得到、事件翻得动、方向讲得清，正是标准把”为什么不行”变得可回答的方式。
三种典型误判与对应动作
第一种，把路由拒绝当成交易失败重复广播：路由判断发生在代币合约的执行逻辑里，重发多少次结果都一样，先查 isRoutePermitted 的回答再决定下一步。第二种，只看 getRoute 的布尔结论不看 effectiveAt：条目可能刚写入尚未生效，或处于延迟撤销的过渡窗口，把时间戳与当前链上时间对比才下结论。第三种，把注册表地址本身当成对手方风险源：注册表只是只读查询面，真正决定放行的是代币合约，评估风险时要分清”表的管理方”与”拦截逻辑的执行方”是否同一主体——两者分离时，政策变更的传播路径更长，也更容易出现表与执行不一致的短暂窗口，这类不一致以事件时间线为准逐段还原。
风险提示：路由表内容由其管理方设定，证据哈希指向的事实需另行核验；转账被拒请以代币源码与注册表事件为判准，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。