白皮书 · 06

核心标准

A-REX Core 各要素背后的理由：为什么批次记录恰好具有这些字段，为什么谱系是一项操作而不是一个映射，为什么强制执行来自 ERC-7943，为什么用代码取代枚举，以及哪些经验教训塑造了这一设计。

设计目标：第三方愿意实现的最小接口

当实现某个标准的成本低于不具备互操作性的成本时，该标准才会被采用。A-REX Core 中的每个字段、函数和规则都必须通过一项测试：一个独立团队，无论是在阿根廷构建粮库平台，还是在哥伦比亚构建咖啡出口商的系统，是否愿意为了互操作性而接受这一约束？ 作物枚举、美国的等级名称、强制性的农场注册表、规定的身份技术栈和估值公式，都没有通过这项测试。批次身份、谱系、强制执行和一个扩展点通过了测试。

逐字段看批次记录

字段	为什么在链上	为什么这样设计
`commodity: bytes32`	钩子、市场和监管者必须无需解析元数据就能按产品过滤	`keccak256("HS:100199")` 可接受任何方案（HS、FAO/CPC、GTIN、各国代码），标准中无需维护一张表；枚举会把世界作物清单冻结在部署的那一刻
`unit: bytes32`	没有单位，数量就毫无意义；一笔 `1000` 的转移可能是 1000 千克，也可能是 1000 箱	UN/CEFACT 第 20 号建议书是 EDI、EPCIS 和海关使用的代码表
`producedAt: uint64`	易腐性、季节性和远期合约都以生产时间为依据	`0` 表示“尚未生产”：以未来收成为标的的作物应收账款、远期合约和权证，是拉丁美洲占主导地位的农业融资工具，必须能够被表示
`expiresAt: uint64`	农业中最常见的转移规则是“不得晚于此日期”	`0` 表示无到期；到期意味着什么由钩子决定
`originRef: bytes32`	来源必须可证明（EUDR、有机、地理标志）	一个哈希或引用，绝不是坐标：生产者的地块地理位置属于个人数据（EDPB 指南 02/2025 v2.0，2026 年七月），而不可变的公共链无法落实删除要求
`metadataHash: bytes32` + `uri`	其余一切都在链下，但代币必须对其作出承诺	对遵循已发布模式的规范 JSON 文档取哈希；`uri` 可以是 IPFS、HTTPS 或 GS1 Digital Link
`status: uint8`	批次要经历一个生命周期，某些状态必须阻止流动	开放取值，带两个固定点（`0` 为活跃，`255` 为已注销）；此前的九状态枚举编码的是某一条供应链的词汇，并且任何持有人都能更改它
`issuer`、`createdAt`	问责与审计	由合约设置，绝不由调用方设置

刻意缺失的内容：纬度和经度、农场标识符、等级枚举、水分和蛋白质、验证标志和验证方地址、quantity 字段（以 ERC-1155 的供应量跟踪为准），以及任何价值概念。

谱系即操作

有 PROCESSED 状态却无法产出加工品的生命周期，是一个常见错误。可追溯性制度明确指出，转化是把输入与输出联系起来的一个事件：FSMA 204 的转化关键追踪事件，EPCIS 2.0 带有 inputQuantityList 和 outputQuantityList 的 TransformationEvent。由管理员写入的父批次映射，既无法承载数量，也无法保证原子性。

transform(from, to, inputIds, inputAmounts, outputs, outputAmounts, processRef) 在一笔交易中完成销毁与铸造，在每个输出上记录父批次，发出一个包含全部数量和一个流程引用的事件，并对每一笔变动运行钩子管线。拆分（1→n）、合并（n→1）和加工（n→m）是同一个函数。参考实现允许任何持有人重新分批（商品和单位相同，数量守恒），但改变货物的性质或数量则需要 TRANSFORMER_ROLE——磨坊可以把小麦变成面粉，农户却不能把小麦变成黄金。

强制执行取自 ERC-7943，而非重新发明

农业批次经常受到留置权、权证、禁运、破产程序和召回的约束。一个无法被授权方违背持有人意愿而冻结或移动的代币，无法在银行、法院或监管者面前代表这样的批次。ERC-3643 在 2021 年为证券解决了这个问题；ERC-7943 把它推广到任何现实世界资产，并在 2026 年五月带着一个 ERC-1155 变体达到 Final 状态。A-REX 原样采用该接口，而不是自行定义，使得支持 ERC-7943 的合规引擎（Chainlink ACE、ERC-3643 工具）无需适配即可识别 A-REX 代币。

多代币变体与 ERC-1155 天然契合：冻结按账户和批次 id 进行，强制转移指明批次，资格按账户判定。

一个钩子，有序，带代码

基于五个能力接口构建的模块系统——每次转移都要对每个接口调用 supportsInterface 进行探测——无法扩展；在一次包含五个 id 的批量转移中，若有八个模块，则在任何规则运行之前就有八十次静态调用。拒绝原因是自由格式的字符串，没有索引器能够解释，也没有测试能够可靠地比较。

A-REX Core 定义了一个钩子接口，带有在注册时缓存的常量标志位图。代币按固定顺序对钩子求值，并在遇到第一个非零 bytes32 代码时停止，以 ARexHookRejected(hook, code) 回滚。该顺序是可审计的（getHooks），移除钩子时会保持顺序，钩子通过 msg.sender 得知调用方代币，因此一次部署可以为多个代币服务。资格（canSend/canReceive）被并入同一个接口，使代币的 ERC-7943 视图成为其各钩子的合取。

为什么用代码，而不是钩子自定义错误？因为 check 是一个必须可组合的视图函数：代币需要询问每个钩子、比较答案，并通过 transferCheck 在不回滚的情况下暴露第一个答案。代码成本低、可索引、可翻译，并且带有命名空间（keccak256("AREX:BATCH_EXPIRED")、keccak256("MYHOOK:QUOTA")）。

按批次的证明，按主题的签发方

认证一个生产者是一个身份问题，已有成熟的解决方案（ONCHAINID、Ethereum Attestation Service、可验证凭证、国家 e-ID）。认证一个批次才是买方、海关和监管者要核查的内容，而它此前没有标准形式。IARexAttest 记录 (batch, topic) → (issuer, reference, validity)，并让管理员决定哪个签发方可以对哪个主题出具证明，这与 ERC-3643 的可信签发方注册表如出一辙，同时不规定身份提供方。主题是开放的 bytes32，因此 ERC-735 声明主题、EAS schema id 和认证名称的哈希可以并存。

isAttested 是钩子唯一要问的问题：证明不存在、已被撤销、已到期或其签发方已失去信任时，它为 false。这使钩子只需六行代码就能强制执行“咖啡批次在出售之前需要有 EUDR 尽职调查引用”。

标准没有规定什么

它没有规定谁可以创建批次、更改状态或强制执行——只规定这些是角色，而绝不是余额。
它没有规定状态 1..254 的含义；签发方在元数据中发布一张表。
它没有规定如何给批次估值、批次如何衰减、批次何时可以按季节性交易、如何交付或投保：这些全都属于钩子或配套合约。
它没有规定使用哪条链、哪个身份提供方、哪个预言机、哪个注册表。
它没有规定代币是证券还是商品。

塑造设计的经验教训

经验教训	在 A-REX Core 中的结果
把农场注册表和身份系统列为必需项的标准，不是代币标准，而是产品	代币之外的任何东西都不是必需的
函数签名中的封闭枚举，会让任何商品的“动态注册表”沦为死代码	商品、单位、状态和主题都是开放代码
由余额推导出的权限，在多持有人代币中是一个漏洞	状态更改由角色把关；RETIRED 为终态
核心中的业务逻辑，与“核心不含业务逻辑”自相矛盾	估值、衰减和窗口都放在钩子中
无法从干净克隆编译通过的构建，不是参考实现	依赖固定版本，锁文件已提交，每次推送都运行 CI
白皮书中的监管日期会过时；依赖这些日期的代码则不能过时	代币只存储引用和哈希，绝不存储监管逻辑

向后兼容性

A-REX Core 代币是完整的 ERC-1155 和 ERC-7943 代币。了解 ERC-1155 的钱包、市场和索引器无需改动即可工作；支持 ERC-7943 的合规工具会识别其强制执行接口。为其他代币编写的规则引擎，只要其决策仅取决于调用参数和批次记录，就可以通过 IARexHook 适配器接入。