标准
A-REX Core — 标准
标准定义了什么、合规代币做什么、标准如何变更，以及如何成为 ERC。规范性文本通过提前访问提供。
状态
草案 2.1.0-alpha.2，尚未提交，批次元数据模式为 1.2.0。文本采用以太坊征求意见稿（ERC）的格式撰写，以便在独立实现者于生产环境中使用这些接口之后提交至 ethereum/ERCs。它将以 CC0 发布；参考实现采用 MIT 许可。在出现两个独立实现者之前，已接受的更改均标记为暂定。
版本
标准与其参考实现使用各自独立的版本号。单独出现的 “alpha.10” 之类的名称指的是参考实现的版本，而不是标准的版本。
| 项目 | 版本 | 说明 |
|---|---|---|
| 标准（A-REX Core） | 2.1.0-alpha.2 | 规范及其接口。在此版本之后提出的文本标记为“提议”，不属于该版本。 |
| 批次元数据模式 | 1.2.0 已发布，1.4.0 提议中 | 代币所承诺的链下批次文档。 |
| 参考实现 | 2.0.0-alpha.10 | 实现标准 2.1.0-alpha.2 的 MIT 许可合约。 |
| 一致性测试套件 | 1.1.0 | 任何实现都要运行的逐条款测试；随参考实现一起发布。 |
这些编号计数的对象不同：标准计数规范的变更，实现计数自身的发布。两者都从 2.0.0 开始；标准的 2.1 版没有改变任何接口、事件或要求，因此 2.0 版实现可以实现它。
定义的内容
A-REX Core 是对 ERC-1155 和 ERC-7943 的一个小型扩展。一个批次（实物商品的一批货，或对未来一批货的权利）就是一个 ERC-1155 代币 id。标准在其上增加四层：
| 层 | 接口 | 涵盖内容 | 是否必需 |
|---|---|---|---|
| 0 | ERC-1155、ERC-165、IERC7943MultiToken | 余额与批量转移；冻结、强制转移、账户资格 | 是 |
| 1 | IARexBatch | 批次记录：开放的商品与单位代码、生产与到期时间、产地引用、对链下文档的承诺、生命周期状态，以及批次被拆分、合并或加工时的谱系 | 是 |
| 2 | IARexHook、IARexHookManager | 一条有序的外部规则合约流水线；规则以机器可读的原因作答 | 是 |
| 3 | IARexAttest | 按批次和主题记录的认证、检验与声明，来自该主题的受信任签发方 | 建议，在代币内或伴随合约中 |
合规代币做什么
- 它的行为与普通 ERC-1155 代币一致，钱包、交易市场和索引器无需改动即可使用。
- 它提供 ERC-7943 的执行接口：批次可因法院命令、留置权或召回而被冻结或转移，且每一项此类操作都在链上可见。
- 它为每个批次保存记录，并记下每一次拆分、合并或加工，因此始终可以追溯批次的来源。
- 它让每笔转移都经过规则流水线，并能说明转移被拒绝的原因。
- 它声明所实现的接口，以便工具能够识别。
规则合约（钩子）只要实现 IARexHook 即为合规。一个规则合约可以服务多个代币。
如何检查一致性
参考实现附带一套不依赖于它的一致性测试套件：被测实现只通过标准接口以及由其作者编写的一个小型适配器接入。每项测试都标注其所检查的条款；共有 89 项条款，其中 75 项为 MUST 级，14 项为 SHOULD 级。每次运行都以一个结论结束，而一致性声明必须解释其跳过的每一项条款。无法在链上观察的条款，例如产地引用不含个人数据这一规则，留待审查。
已提议、未发布
以下更改已经成文并开放审议。它们都尚未被接受：每一项都在等待两个独立实现者的确认，MUST 级的更改还要遵循主版本变更的规则。
| 提案 | 将改变什么 |
|---|---|
| ADR-019（提议中）：能力在标准中，政策在配置中 | 标准确定角色、事件、数据形态、暂停与撤销的语义以及隐私规则；谁可以使用某项能力、该能力是否启用、适用哪些名单或机构，则移至按司法辖区和组织划分、带版本的政策配置中。它带来两项澄清：产地引用不得由位置推导（不得是坐标或地块几何形状的哈希或编码）；证明由其签发方或其委托的撤销方撤销，而管理性角色在 2.x 中不应撤销并非由它签发的证明，自 3.0 起不得撤销，从而使已经部署的代币仍然符合标准；按照同一规则，再次出具证明绝不会替换另一签发方的记录，也不会恢复已撤销的记录。 |
ADR-017（提议中）：元数据中的 extensions | 元数据模式 1.3.0 将增加一个可选的 extensions 对象，每条规则一项，由该规则描述符的模式片段验证。 |
| ADR-024（提议中）：以 ISO 代码表示地点 | 自元数据模式 1.3.0 起，origin.region 是 ISO 3166-2 行政区划代码，例如 BR-MG（无适用区划时为国家的 ISO 3166-1 代码），并按模式校验；供人阅读的名称放在可选的 origin.regionName 中。早期版本的文档仍然有效。 |
| ADR-025（提议中）：绑定到单一代币的钩子 | 钩子可以在部署时绑定到单一代币，前提是它公开该代币，并以具名错误拒绝来自任何其他地址的调用；未绑定的钩子仍为调用它的任何代币服务。参考实现的追溯钩子是绑定的。 |
| ADR-018（提议中）：申报的碳足迹 | 批次可以携带由具名第三方申报的产品碳足迹，从 PACT 3.0.3 复制到 extensions.pact_pcf 中并附验证状态；绝不被计算、求和或传递给其他批次。 |
| ADR-020、ADR-021、ADR-022（提议中）：参考适配器 | ERC-3643 工具通过一个不能允许或拒绝任何操作的视图读取每个批次；ONCHAINID 声明在 A-REX 信任其签名者期间有效；EAS 上有效证书和批次记录的镜像。资料性：它们不增加任何要求。 |
| ADR-023（提议中）：一次转移的数据中包含多个值 | 转移的 data 可以是一个带标签的封装，最多 8 个条目，每个条目由一个键和一个值组成，使每条规则只读取自己的键；32 字节的数据保持原有含义。它不增加任何要求。 |
| ADR-026（提议中）：网络 | A-REX Core 仍是一个 EVM 标准：任何达到 paris 级别或更高级别的 EVM 网络都可以承载符合标准的代币，网络以 CAIP-2 ID 指明，标准不维护网络列表；围绕代币的证据可以锚定在任何网络上。 |
| 元数据模式 1.4.0（提议中） | upstream 条目可以给出其所指批次的 CAIP-2 network；位于非 EVM 网络上的批次以其 CAIP-19 资产来指明。 |
规则描述符 arex.module/1（资料性，提议中） | 规则或附加组件发布的一份 JSON 文档，使使用方无需定制代码即可集成它。 |
格式 arex.vocab/1、arex.anchor-proof/1 和 arex.report-sources/1（资料性，提议中） | 组织自有的田间作业、工艺和阶段词汇；证明某条记录未经更改地存在、可锚定在任何网络上的证明；报告中数字的来源，每条记录一行。 |
面向 GS1 EPCIS 2.0、UN Transparency Protocol 0.7.0、PACT 3.0.3、ERC-3643 和 Ethereum Attestation Service 的资料性映射不增加任何要求；互操作性对它们作了概述。
不包含的内容
没有作物、等级或认证的清单：代码是开放的。链上没有个人数据：没有地块坐标、姓名或自然人标识，也没有由地块位置计算得出的值。不强制任何身份提供方、预言机或登记处，也不规定政策：谁可以强制执行、暂停或筛查，以及依据哪些名单，由签发方根据其所在司法辖区决定。损耗曲线、交付流程、碳核算和保险以规则或伴随合约的形式构建；参考实现演示了其中一部分，合规性不依赖于它们。
版本管理
接口随标准一起进行版本管理。对函数、事件或要求的变更属于主版本，并附带迁移说明。可选的补充，例如新的推荐代码或元数据字段，属于次版本：元数据模式 1.1.0 开放了商品方案，模式 1.2.0 增加了对其他代币批次的引用（upstream）。元数据模式 1.3.0 和 1.4.0 处于提议中，尚未发布。在较早模式下有效的每份文档都保持有效。在提交之前接口仍可能变更，且始终以主版本发布。
通往 ERC 之路
当四个条件全部满足时，文本将提交至 ethereum/ERCs：使用真实批次的生产部署已运行六个月；至少存在三个独立的规则合约；参考实现已有公开的第三方审计；接口在一个发布周期内保持不变。路线图见未来发展。
本网站保留的内容
在标准仓库保持私有期间，规范性条款、接口源代码及其标识、拒绝代码和批次元数据模式都保留在标准仓库中。希望实现 A-REX、用它发行批次或对其进行审计的企业，可在申请提前访问申请读取权限。每一份申请都会人工审核；获批的读者将获得标准与参考实现的只读访问权限。在以 CC0 发布之前，相关材料保持保密，提前访问不授予任何排他性。