白皮书 · 12
互操作性
A-REX 代币如何融入现有世界：Ethereum 代币标准、合规引擎、可追溯性与产品护照数据标准、碳足迹、法律文件登记簿、身份系统、跨链基础设施和现有农场系统。
与 Ethereum 生态系统
A-REX Core 代币就是一个 ERC-1155 代币。理解 ERC-1155 的钱包、区块浏览器、市场和索引器无需改动即可工作：余额、批量转移、uri(id)、授权、安全转移的接收方检查。A-REX 增加了事件和视图函数；它不移除任何东西。
A-REX Core 代币就是一个 ERC-7943 多代币。以 ERC-7943 为目标的合规引擎和保管平台（Chainlink 的 Automated Compliance Engine 已展示了兼容性；ERC-7943 联盟中的签发平台正在采用它）无需适配即可识别 canTransfer、forcedTransfer、setFrozenTokens、canSend 和 canReceive。
| 标准 | 关系 |
|---|---|
| ERC-1155 | 基础；A-REX Core 是其扩展 |
| ERC-165 | 接口发现；已公布五个 id |
| ERC-7943 | 必需；强制执行接口被原样采用 |
| ERC-3643 | 参考适配器（ADR-020，提议中）：每个批次都可以作为 ERC-3643 代币被读取（余额、资格、冻结数量、暂停、流转），方式是一个直接从代币读取的视图和一个仅发送通知的钩子，后者不能允许或拒绝任何操作；A-REX 代币本身保持不变。已针对 T-REX 4.1.6 测试。把 ERC-3643 合规模块包装为 IARexHook，以及把批次包装为 ERC-3643 证券，仍然只是设计，尚未实现。通过 ERC-3643 读取一个批次并不会使其成为证券。 |
| ERC-735 / ONCHAINID 声明 | 声明主题直接映射为 IARexAttest 主题（bytes32(uint256 topic)）；参考声明签发方（ADR-021，提议中）把企业在 A-REX 中的状态呈现为 ONCHAINID 声明，这些声明仅在 A-REX 信任其签名者期间有效，在被读取的那一刻进行检查，并且只有签名者可以撤销。已针对 ONCHAINID 2.2.1 测试。 |
| Ethereum Attestation Service | schema UID 是有效的 IARexAttest 主题；参考镜像（ADR-022，提议中）在 EAS 上以两个不带解析器（resolver）的 schema 发布有效的证书和批次记录，并在 A-REX 撤销、不再信任或更改它们时撤销其副本。已针对 EAS 1.4.0 测试。以 EAS 为后盾的 IARexAttest 注册表仍然只是设计，尚未实现。 |
| ERC-7201 | 参考实现的存储布局 |
| ERC-7573、预留/托管模式 | 货款对付和托管是钩子或配套合约；标准不规定结算方式 |
| ERC-7802 / Chainlink CCIP | 跨链铸造/销毁适配器可以包装该代币；谱系留在源链上，引用则随之流转 |
与可追溯性数据标准
GS1 EPCIS 2.0 / CBV
标准发布了一份逐个事件的资料性映射：
| 链上 | EPCIS 2.0 |
|---|---|
BatchCreated | ObjectEvent ADD，bizStep = creating_class_instance（批次级），分配实例 id 时为 commissioning，quantityList（单位取自第 20 号建议书），批次主数据放在 ilmd 中 |
TransferSingle / TransferBatch | ObjectEvent OBSERVE，以所有权双方作为来源和目的地；纯粹的所有权变更不带 bizStep，仅当元数据或可追溯性钩子表明货物发生了移动时才使用 shipping/receiving |
BatchTransformed | TransformationEvent（inputQuantityList、outputQuantityList、取自 processRef 的 transformationID）；重新分批使用 bizStep = repackaging，加工使用 creating_class_instance |
带有 upstream 引用的 BatchCreated | 货物由另一代币的批次加工而来时为 TransformationEvent，否则为以供应商为来源的 ObjectEvent；共同的 epcClass 把它与供应商自己的事件连接起来 |
ForcedTransfer | ObjectEvent OBSERVE，货物被置于法律扣留之下时为 holding |
BatchStatusChanged | 带有 disposition 的 ObjectEvent，其取值来自签发方的状态表 |
Attested / AttestationRevoked | 带有证书引用的 ObjectEvent（inspecting，实验室则为 sampling） |
元数据 gs1.* | GTIN、LGTIN、SSCC、GLN、Digital Link |
元数据 extensions | 创建事件的 ilmd；申报的足迹作为 arex:declaredFootprint |
元数据模式有意使用 EPCIS/CBV 的名称，使导出器只需映射字段，而无需映射概念。
UN Transparency Protocol（UNTP 0.7.0）
一份资料性映射把批次、其事件及其证明转换为 UNTP 0.7.0 凭证，所用标识符与 EPCIS 映射相同，因此两者可以相互连接：
| A-REX | UNTP 凭证 | 签发方 |
|---|---|---|
| 批次、其来源、设施和证书 | 数字产品护照（Digital Product Passport，credentialSubject 为一个 Product，每个批次一份） | 批次签发方 |
| 铸造与加工；转移与接收；销毁、状态变更和元数据更正 | 数字可追溯性事件（Digital Traceability Events）：MakeEvent；MoveEvent；ModifyEvent，每个事件都关联到其交易 | 批次签发方 |
| 来自认证机构或实验室的证明 | 指向评估方数字符合性凭证（Digital Conformity Credential）的引用 | 评估方，绝不是批次签发方 |
凭证遵循 W3C 可验证凭证数据模型 2.0，并在签发方的 did:web 下以 VC-JOSE-COSE 签名；撤销使用 Bitstring Status List。签名后的凭证还可以作为证明锚定到其批次，该证明的引用即凭证的哈希；锚定证明的是承诺，签名证明的是内容。凭证只携带代币或其元数据所持有的内容，需要某种方法才能得出的值（足迹、风险评分）只有在具名方作出申报时才会出现。该映射说明了它不涵盖的内容，首先是欧盟数字产品护照：ESPR 不适用于食品、饲料或活体植物和动物，A-REX 也不就它们提出任何护照主张。
申报的碳足迹（PACT 3.0.3）
ADR-018（提议中）允许批次在元数据文档的 extensions.pact_pcf 下携带由第三方计算的产品碳足迹。该片段逐字段遵循 WBCSD PACT 技术规范 3.0.3：由谁申报、申报单位和参考期、包含与不包含生物源吸收的足迹，以及必填的验证状态，在足迹经过验证时写明验证方。足迹只被复制，绝不被计算、求和或传递给由该批次制成的批次，它也不是碳信用（ADR-014）。该映射是 PACT 的一个独立衍生作品，不复制任何 PACT 文件。
商品与单位代码
商品代码是 keccak256("<SCHEME>:<CODE>")，适用于任何方案：协调制度（HS）、各国关税税目（南方共同市场的 NCM、欧盟的 CN 和 TARIC、美国的 HTS 等）、FAO、CPC、GTIN，或签发方自己的方案。自元数据模式 1.1.0 起，文档中的方案同样是开放的，因此元数据可以与链上代码保持一致。单位采用 UN/CEFACT 第 20 号建议书代码（KGM、TNE、LTR），也就是 EDI、EPCIS 和海关已经在使用的代码表。
FSMA 204
关键数据元素是元数据字段（traceabilityLotCode、GLN、日期、数量）和事件；转化类 CTE 即 BatchTransformed；24 小时记录请求就是一次索引器查询。完整的对应关系见监管一章。
Codex、ISO 22000、GLOBALG.A.P. 与有机认证方案
它们都是证明主题。标准不对其进行枚举：keccak256("GLOBALGAP:IFA")、keccak256("AREX:CERT:ORGANIC_EU")、keccak256("CODEX:MRL") 是签发方连同其元数据模式一起发布的约定。
与法律文件登记簿
A-REX 代币引用法律工具；在司法辖区承认代币本身之前，它们不取代这些工具：
| 工具 | 所在位置 | 代币如何引用 |
|---|---|---|
| 美国电子仓单（7 CFR 869） | 获 USDA 授权的 EWR 提供方 | documents[].registry、originRef |
| 巴西 CPR-e、CDA/WA | 获央行授权的登记机构 | documents[].registryId；producedAt == 0 的收获前批次 |
| 阿根廷 certificado de depósito / 权证（第 9.643 号法律） | 仓库 | originRef 哈希 |
| 电子提单（MLETR 司法辖区） | eBL 平台 | 文档哈希；在 MLETR 司法辖区，代币本身即可满足排他性控制 |
| EUDR 尽职调查声明 | 欧盟信息系统 | origin.eudr.ddsReference、证明 EUDR:DDS |
与身份系统
代币只询问 canSend(account) / canReceive(account)。在这个问题背后可以是：
- 由签发方维护的白名单/黑名单（
EligibilityHook）； - 带有声明主题的 ONCHAINID 身份注册表（ERC-3643 模型）；
- 针对该账户的 Ethereum Attestation Service 证明；
- 在链下验证、再由中继方反映到链上的可验证凭证；
- 通过凭证验证方接入的国家 e-ID 方案（欧盟的 eIDAS 2.0 钱包）。
它们都不是标准的一部分，因此巴西的签发方和德国的签发方可以使用不同的提供方，同时保持互操作。
与规则引擎和平台
规则或附加组件可以发布一个 arex.module/1 描述符：一份 JSON 文档，包含其参数、设置、所需的批次字段、证书类型、事件、拒绝代码，以及其状态如何迁移到新版本。读取描述符的平台、钱包、索引器或审计方无需定制代码即可集成新规则。该格式是资料性的，状态为提议中；在第二个独立实现者使用它之后，它将成为推荐格式。修订版 1.1 新增可选的参考性列表 ops，列出规则所管辖的操作；缺省表示未知，且绝不用于执行管控。
跨链部署
该标准与具体链无关。实用模式如下：
- 每个签发方一条主链（推荐）：谱系和强制执行保持一致；其他链通过 ERC-7802 风格的适配器或 CCIP 持有包装后的表示。
- 许可制 EVM 链，适用于其数据保护机构或核心机构要求这样做的签发方；EDPB 明确倾向于许可制设计。字节码相同。
- 为流动性设置的镜像：批次 id 在主链上，其他链上则是 ERC-20 包装合约；该包装合约必须遵从主链代币的
canTransfer，或把自身限制在具备资格的持有人范围内。
谱系从不跨链；引用则会。在同一条链或不同链上的代币之间，由另一代币的批次制成的批次，会在其元数据的 upstream 列表（模式 1.2.0）中按链 id、合约和代币 id 指明该批次。这些引用是签发方的主张，需要对照上游代币进行核查。
与农场管理和 ERP 系统
集成点与任何 ERC-1155 代币相同，另加批次视图函数：
- 写入路径：发起服务持有
ISSUER_ROLE，根据 ERP 事件（地磅单、仓单签发）调用createBatch；根据仓库事件调用setBatchStatus/setBatchMetadata；根据加工订单调用transform。 - 读取路径：索引器把批次、谱系、证明和强制执行事件物化到 ERP 的可追溯性表中；面向合作伙伴和监管者提供 EPCIS 导出。
- 预检：
transferCheck让 ERP 在提交交易之前向操作员解释拒绝的原因。 - 标识符：元数据中的 GS1 键可与现有 EDI 和 EPCIS 存储库衔接；UN/CEFACT 单位本就存在于各 ERP 中。
兼容性矩阵
| 能力 | 状态 |
|---|---|
| ERC-1155 钱包 / 市场 | 原生支持 |
| ERC-7943 合规工具 | 原生支持 |
| 读取批次的 ERC-3643 工具 | 参考适配器（ADR-020，提议中） |
| 作为钩子的 ERC-3643 合规模块 | 设计，尚未实现 |
| 基于 A-REX 状态的 ONCHAINID 声明 | 参考声明签发方（ADR-021，提议中） |
| ERC-735 / EAS 证明 | 主题映射；EAS 镜像（ADR-022，提议中） |
| EPCIS 2.0 导出 | 资料性事件映射；字段名称见模式；在索引器一侧完成 |
| UNTP 0.7.0 凭证 | 资料性映射；由签发方签名（did:web、VC-JOSE-COSE） |
| PACT 3.0.3 足迹 | extensions.pact_pcf（ADR-018，提议中） |
| 规则描述符 | arex.module/1（资料性，提议中） |
| 代币之间的谱系 | 元数据 upstream（模式 1.2.0） |
| 许可制 EVM | 字节码相同 |
| 跨链 | 包装合约；谱系留在主链 |