# A-REX Core: A Minimal Standard for Agricultural Batch Tokens on ERC-1155

**A Technical Whitepaper**

---

**Authors:** A-REX Development Team  
**Version:** 2.0.0-alpha.2  
**Status:** Standard draft (pre-submission) with reference implementation

**Date:** September 2026

**Document type:** Technical whitepaper

---

## Abstract

A-REX Core is a minimal extension of ERC-1155 and ERC-7943 for tokenized agricultural batches: batch identity with open codes, atomic lineage (`transform`), an ordered hook pipeline with machine-readable rejection codes, and open attestations. The normative text is `standard/AREX-CORE.md`; this document is its rationale, regulatory map, use cases, implementation guide and measured performance. It separates implemented behaviour (with tests) from proposed work, and it does not claim regulatory certification, an independent security audit, or measured economic outcomes.

**Keywords:** Blockchain, Agriculture, Supply Chain, Tokenization, Regulatory Compliance, ERC-1155, Smart Contracts

---

## Table of Contents

1. [Executive Summary](#1-executive-summary)
2. [Introduction](#2-introduction)
3. [Problem Statement](#3-problem-statement)
4. [Solution Overview](#4-solution-overview)
5. [Technical Specification](#5-technical-specification)
6. [Core Standard](#6-core-standard)
7. [Module System](#7-module-system)
8. [Security Framework](#8-security-framework)
9. [Regulatory Compliance](#9-regulatory-compliance)
10. [Use Cases](#10-use-cases)
11. [Implementation Guide](#11-implementation-guide)
12. [Interoperability](#12-interoperability)
13. [Performance Analysis](#13-performance-analysis)
14. [Future Developments](#14-future-developments)
15. [Conclusion](#15-conclusion)
16. [Appendices](#16-appendices)

---


---

# 1. Executive Summary


_A-REX Core in one chapter: what the standard is, what it deliberately leaves out, how it is positioned legally, and how it intends to become a de-facto standard before it becomes an official one._

## The problem in one paragraph

Agricultural lots are the largest class of physical assets without an interoperable on-chain form. Existing token standards cover the two ends of the problem: ERC-3643 standardizes permissioned *securities* on ERC-20, and ERC-7943 (Final, May 2026) standardizes the *enforcement surface* every real-world-asset token needs. Traceability regimes such as GS1 EPCIS 2.0, the FDA Food Traceability Rule (FSMA 204) and the EU Deforestation Regulation (EUDR) define *what* must be recorded about a lot. None of them lets a token **be** a lot: with a production date, a unit, an origin reference, a lifecycle, and — above all — the ability to be split, merged and processed into other lots while keeping its provenance.

## The standard in one paragraph

A-REX Core is a small, extensible extension of ERC-1155: the normative core is deliberately minimal so that it can be adopted, and it scales through what it leaves open (codes, hooks, attestations, lineage) rather than through what it prescribes. A conformant token implements four small interfaces:

| Layer | Interface | What it adds |
|---|---|---|
| 0 | `IERC7943MultiToken` (verbatim from ERC-7943) | freeze, forced transfer, account eligibility, `canTransfer` |
| 1 | `IARexBatch` | open commodity and unit codes, production and expiry times, origin reference, metadata commitment, role-controlled status, and `transform` — the only way to split, merge or process a batch, recording its parents |
| 2 | `IARexHook` / `IARexHookManager` | one ordered pipeline of rule contracts returning `bytes32` codes instead of reverting with strings |
| 3 | `IARexAttest` | attestations per batch and topic (certifications, inspections, regulatory declarations) with trusted issuers per topic |

Everything agricultural that is *not* the identity or the lineage of a batch — decay curves, seasonal windows, delivery workflows, oracles, carbon accounting, insurance — is **out of the standard**. It lives in hooks and companion contracts that demonstrate the interfaces, exactly as T-REX's compliance modules demonstrate ERC-3643 without being part of it.

## Five design rules

1. **No closed enumerations.** Commodities, units, statuses and attestation topics are open codes. Adding quinoa, a Brazilian grading scheme or a new sustainability label never requires a redeploy.
2. **No personal data on-chain.** The origin of a batch is a hash or a reference (an EUDR due-diligence statement number, a warehouse receipt id, a truncated geohash), never a plot coordinate. This follows the European Data Protection Board's 2026 guidelines on blockchain.
3. **Pre-harvest is first-class.** A batch with `producedAt == 0` is a future lot — the object of a crop receivable, a forward or a warrant.
4. **Status is authority, not balance.** Only a role can change a batch's lifecycle status; holding one kilogram of a lot grants nothing over the lot.
5. **Lineage is mandatory.** `transform` burns inputs, mints outputs and records parents. It maps one-to-one to an EPCIS `TransformationEvent`, which is what a recall, a transformation critical tracking event under FSMA 204, or a mass-balance audit needs.

## Legal positioning

A-REX takes no position on whether a token issued with it is a security, a commodity, a crypto-asset under MiCA, a certificate of deposit or a receivable. That depends on how the token is offered and what it represents, not on the interface — the *Howey* test itself arose from citrus groves sold to passive investors. The standard therefore ships the enforcement surface that every classification requires (freeze, forced transfer, eligibility, pause, auditable events) and leaves policy to hooks and to the issuer's counsel. The regulatory chapter gives dates verified in September 2026: FSMA 204 compliance on 20 July 2028; EUDR application on 30 December 2026 (medium and large operators) and 30 June 2027 (micro and small); MiCA fully applicable since 30 December 2024; EDPB blockchain guidelines final since July 2026.

## What exists today

- A normative text in ERC format (`standard/AREX-CORE.md`, CC0) and the Solidity interfaces (`contracts/standard/`, CC0). This site withholds that text. Companies that implement A-REX, issue batches with it, or audit it request read access while the repositories are private. The written terms say the standard will be published under CC0 and that early access grants no exclusivity.
- A reference implementation (`ARexToken`, `ARexAttestations`, MIT): UUPS upgradeable, ERC-7201 storage, role-based access control, reentrancy-locked hook pipeline, 24.1 KB (under the EIP-170 limit).
- Reference hooks: eligibility (allow/block/sanctions with source and TTL), expiry, attestation requirements per commodity, perishability decay models, seasonal windows, delivery custody and settlement, and EPCIS-shaped traceability.
- Companion extensions: a deterministic commodity price oracle, a wrapper for registry-immobilised carbon credits (attestation, never issuance), and attestation-triggered parametric insurance.
- Tests: 42 on the reference implementation, hooks and extensions (including a seeded randomized invariant test); continuous integration; pinned dependencies; a JSON Schema for batch metadata aligned with EPCIS 2.0 and FSMA 204 key data elements.
- Engineering documentation in system-design form: a System Design Document with component, data, interaction and operational models, sixteen architectural decision records, a requirements traceability matrix and an audit-readiness package.

## What A-REX is not

- Not a farm registry, not an identity system, not an oracle network. Those are integrations, chosen by the issuer.
- Not a valuation engine. The core has no notion of price or decay; a hook or an off-chain service provides it.
- Not a carbon registry. Carbon credits can be referenced and gated by attestations; issuing them is the registry's job.
- Not an ERC yet. The interfaces will be submitted to `ethereum/ERCs` only after a production deployment, independent hook implementations and a third-party audit, because an ERC freezes what it standardizes.

## How it becomes a standard

ERC-3643 was in production for three years before its EIP, and its *Final* status followed adoption rather than causing it. ERC-7943 went from draft to Final in eight months with a six-function interface and a coalition of implementers. A-REX follows the same path: freeze a small interface, ship a working reference, prove it with real lots, gather independent implementers, then submit. The roadmap is in the *Future Developments* chapter.

## Reading guide

- **Decision makers**: this chapter, *Solution Overview*, *Regulatory Compliance*, *Use Cases*.
- **Engineers**: *Technical Specification*, *Core Standard*, *Hooks and Reference Modules*, *Implementation Guide*, *Security Framework*.
- **Integrators and regulators**: *Interoperability*, *Regulatory Compliance*, Appendix A.


---

# 2. Introduction


_Why agricultural batches need a token standard, what exists today, what the regulatory drivers actually are (with dates verified in September 2026), and how A-REX approaches the problem._

## The asset class without a representation

Agricultural production is measured in lots: a silo bin of wheat, a container of green coffee, a pallet of strawberries, a pen of cattle, a future harvest pledged to a lender. Lots are split, merged, stored, processed into other lots, inspected, certified, pledged, seized and recalled. Every one of those operations is recorded today in a mixture of warehouse ledgers, ERP tables, paper receipts, registry entries and email.

Blockchain token standards were built for other things. ERC-20 represents fungible balances with no identity. ERC-721 represents unique items with no quantity. ERC-1155 represents many ids with quantities in one contract — the right shape — but says nothing about what an id *is*. ERC-3643 adds permissioning and enforcement for securities on ERC-20. ERC-7943 (Final, May 2026) generalizes enforcement to any real-world asset, including an ERC-1155 variant, but deliberately says nothing about the asset.

What is missing is small and specific: a way for an ERC-1155 id to carry the identity of a lot (commodity, unit, production and expiry time, origin reference, metadata commitment), a lifecycle controlled by the right party, and — decisively — a way to turn lots into other lots while keeping their provenance. That is what A-REX Core adds, and nothing more.

## What has been tried

- **Enterprise permissioned platforms** (IBM Food Trust and similar) demonstrated that shared traceability across a supply chain reduces trace time from days to seconds, and also that adoption depends on an anchor participant, on GS1-compatible data, and on integration rather than tokens.
- **Commodity tokenization ventures** in Latin America showed real demand for tokenized grain and livestock as collateral and as means of payment, generally structured around existing legal instruments (certificates of deposit, warrants, CPR) rather than replacing them.
- **Carbon tokenization** showed the cost of getting registry relationships wrong: after tokens were minted on retired credits, the largest registries prohibited the practice and now accept only immobilised credits as a basis.
- **Broad security-token standards** (ERC-1400) gathered few independent implementations; narrow ones with working references and coalitions (ERC-3643, ERC-7943) became standards.

The lesson A-REX draws: standardize the interface, not the product; reference legal instruments, do not replace them; keep the interface small enough that a third party implements it in days.

## Regulatory drivers, as they stand in September 2026

| Regime | What it requires | Status |
|---|---|---|
| **FSMA 204** (FDA Food Traceability Rule, U.S.) | key data elements at critical tracking events — including *transformation* — for foods on the Food Traceability List; records producible within 24 hours | compliance date **20 July 2028** (extended from January 2026 by FDA's final rule of August 2025) |
| **EUDR** (Regulation (EU) 2023/1115, amended by 2025/2650) | due-diligence statements with plot geolocation for cattle, cocoa, coffee, palm oil, rubber, soya, wood; downstream operators keep DDS references | application **30 December 2026** (medium/large) and **30 June 2027** (micro/small); simplified declarations for primary operators |
| **MiCA** (EU) | white paper and CASP regime for crypto-assets that are not financial instruments; fractions of unique assets are fungible | fully applicable since **30 December 2024** |
| **EDPB Guidelines 02/2025** (EU) | on-chain data is personal data in principle; avoid storing personal data on-chain; justify public over permissioned designs | final version 2.0 adopted **7 July 2026** |
| **SEC interpretive release 33-11412** (U.S.) | transaction-based analysis under *Howey*; issuer promises and marketing decisive; no safe harbour | **17 March 2026** |
| **GENIUS Act** (U.S.) | payment stablecoin issuers must be able to freeze, seize and burn on lawful order | enacted **July 2025**; sets the market's expectation for enforcement on any real-world token |
| **UCC Article 12** (U.S. states) | "control" of controllable electronic records perfects security interests | enacted in more than 30 states; New York effective **3 June 2026** |
| **CNV RG 1150/2026** (Argentina) | definitive regime for tokenized securities on real-world assets via registered VASPs | **June 2026** |
| **CPR-e / CVM Resolution 88 revision** (Brazil) | electronic crop receivables registered with Central Bank-authorized entities; tokenized offers | in force; CVM revision under analysis after the January 2026 consultation |
| **GS1 EPCIS 2.0** | event vocabulary for traceability, recommended by FDA for FSMA 204 records | current |

Two things follow. First, the traceability obligations are real but their deadlines are later than early whitepapers assumed; there is time to do this properly. Second, the legal nature of a batch token is decided by the offer, not by the interface — so the interface must support every outcome.

## The A-REX approach

1. **Extend ERC-1155, adopt ERC-7943.** Everything that already works for ERC-1155 keeps working; enforcement is standard, not bespoke.
2. **Minimal batch identity.** Open codes for commodity and unit; production time that may be in the future; an origin *reference*, never coordinates; a hash commitment to an off-chain document with a published schema aligned with EPCIS and FSMA key data elements.
3. **Lineage as an operation.** `transform` burns inputs and mints outputs in one transaction, recording parents and quantities — an EPCIS `TransformationEvent` by construction.
4. **One extension point.** Hooks are independent contracts that return codes; the token evaluates them in order. Perishability, seasonality, custody, quotas, documents and escrow are hooks, not standard.
5. **Attestations per batch.** Certifications, inspections and regulatory declarations are `(batch, topic) → (issuer, reference, validity)` with trusted issuers per topic.
6. **Hooks and extensions demonstrate; they are not the standard.** Every domain rule shipped in the repository is a demonstration of the interfaces, replaceable without touching the standard.

## How to read this whitepaper

- *Problem Statement* states the gap without inflated numbers.
- *Solution Overview*, *Technical Specification*, *Core Standard* and *Hooks and Reference Modules* describe the standard and its rationale.
- *Security Framework* and *Regulatory Compliance* cover threat model, enforcement and the legal map.
- *Use Cases* walks through six scenarios call by call.
- *Implementation Guide* and *Interoperability* are for engineers and integrators.
- *Performance Analysis* reports measured gas.
- *Future Developments* is the roadmap to standardization.
- Appendices hold the interface reference, glossary and bibliography.


---

# 3. Problem Statement


_The specific gaps that A-REX Core addresses, stated as engineering and legal problems rather than as market sizes. Where an earlier version of this document quoted figures without a verifiable source, they have been removed._

## 1. A lot has no on-chain identity

An ERC-1155 id is a number with balances. Nothing in the base standard says what commodity it is, in what unit, when it was produced, when it expires, or where its origin evidence lives. Every project that tokenizes agricultural goods invents its own struct, its own enums and its own metadata layout. Two such tokens cannot be read by the same indexer, gated by the same compliance engine, or exported to the same EPCIS document.

**Requirement:** a minimal, open batch record that any implementer can adopt without accepting anyone else's list of crops, grades or lifecycles.

## 2. Lots become other lots, tokens do not

Wheat becomes flour; a 250-tonne bin becomes two shipments; forty deliveries become one pool. Traceability regulation and GS1 EPCIS are explicit that these are *transformation events* linking inputs to outputs with quantities. A token that can only be minted, transferred and burned cannot express them, so the provenance chain breaks at the first processing step — exactly where recalls and mass-balance audits need it.

**Requirement:** one operation that burns inputs, mints outputs, records parents and emits quantities atomically.

## 3. Real-world claims need enforcement

Stored grain is pledged, embargoed, seized, insured and recalled. A token that cannot be frozen or moved by an authorized party against the holder's will cannot represent such a lot to a lender, a court or a regulator. The market's expectation, after the GENIUS Act and ERC-7943, is that any token backed by a real-world claim can honour a lawful order, and that every such action is auditable.

**Requirement:** freeze, forced transfer, eligibility and pause, in a standard shape with standard events.

## 4. Rules differ by commodity, jurisdiction and counterparty

Perishability rules for strawberries, seasonal windows for grain trading, sanctions screening, quotas per buyer, custody during transport, documents required before export: every issuer needs some of these and none needs all. Monolithic compliance frameworks fail here, and so do ad-hoc module systems whose interfaces are not shared — a rule written for one token does not run on another.

**Requirement:** one small, standard extension interface with ordered evaluation and machine-readable rejection reasons, so that rules are portable across tokens.

## 5. Certification is about the lot, not only the producer

Identity and producer credentials have mature solutions (ONCHAINID, attestation services, verifiable credentials, national e-ID). What buyers, customs and regulators check is whether *this lot* has an organic certificate, a phytosanitary certificate, a lab result, an EUDR declaration. There is no standard form for that on-chain, and closed enumerations of certification types go stale the day a new scheme appears.

**Requirement:** attestations keyed by batch and open topic, issued only by parties trusted for that topic, with revocation and expiry.

## 6. Personal data and public ledgers conflict

Plot geolocation identifies a producer. The European Data Protection Board's 2026 guidelines state that on-chain content and metadata are personal data in principle, that hashing does not guarantee anonymisation, and that controllers should avoid storing personal data on-chain. Early agricultural token designs — including A-REX's own first generation — stored coordinates immutably.

**Requirement:** the standard must make personal data on-chain impossible by design: references and hashes on-chain, evidence off-chain with access control.

## 7. Legal instruments already exist

Warehouse receipts, warrants, crop receivables (CPR), bills of lading and due-diligence statements are governed by statute and registered with authorized entities. A token that claims to *be* such an instrument outside a jurisdiction that recognizes it (MLETR adopters, UCC Article 12 states) creates legal risk; a token that *references* it creates value.

**Requirement:** first-class references to external instruments in the batch record and metadata; enforcement compatible with "control" under UCC Article 12 and "exclusive control" under MLETR.

## 8. Standards that are products do not get adopted

The first generation of A-REX required a farm registry and an identity contract, fixed nine lifecycle states, eleven commodities and U.S. grade names, and implemented a valuation formula in the core. No independent team would accept those constraints in exchange for interoperability. The standards that were adopted in this space (ERC-3643, ERC-7943) standardize a few interfaces and leave the product outside.

**Requirement:** interfaces only; reference implementation separate; modules as demonstrations.

## Summary of requirements

| # | Requirement | Where A-REX Core answers it |
|---|---|---|
| 1 | open batch identity | `IARexBatch.Batch`, `BatchInit` |
| 2 | atomic lineage | `transform`, `parentsOf`, `BatchTransformed` |
| 3 | enforcement | `IERC7943MultiToken`, pause |
| 4 | portable rules | `IARexHook`, `IARexHookManager`, `bytes32` codes |
| 5 | lot attestations | `IARexAttest` |
| 6 | no personal data on-chain | `originRef` rule, metadata schema `restricted` pointer |
| 7 | legal instruments referenced | `originRef`, `documents[]` in metadata |
| 8 | interfaces only | `standard/`, `contracts/standard/` vs `contracts/reference/` |


---

# 4. Solution Overview


_Architecture of A-REX Core: three tiers with one direction of dependency, the transfer pipeline, the actors, and how the pieces are deployed._

## Three tiers, one direction of dependency

A-REX separates what must be **standardized** from what must merely **work**:

**The four layers of the standard**

```mermaid
flowchart TB
    L3["Layer 3 · IARexAttest<br/>attestations for a batch and a topic"]
    L2["Layer 2 · IARexHook + IARexHookManager<br/>one ordered pipeline of rules"]
    L1["Layer 1 · IARexBatch<br/>identity, status, a metadata commitment, and lineage"]
    L0["Layer 0 · ERC-1155 + ERC-165 + IERC7943MultiToken<br/>balances and an enforcement surface"]
    L3 --- L2 --- L1 --- L0
    classDef l3 fill:#edf5ff,stroke:#0f62fe,color:#161616
    classDef l2 fill:#d0e2ff,stroke:#0f62fe,color:#161616
    classDef l1 fill:#a6c8ff,stroke:#0f62fe,color:#161616
    classDef l0 fill:#78a9ff,stroke:#0043ce,color:#161616
    class L3 l3
    class L2 l2
    class L1 l1
    class L0 l0
```

**The two tiers of the repository and the direction of dependency**

```mermaid
flowchart LR
    STD["<b>The standard</b><br/>standard/ · contracts/standard/<br/>normative · CC0"]
    REF["<b>Reference implementation</b><br/>ARexToken · ARexAttestations<br/>MIT"]
    DEMO["<b>Demonstrations</b><br/>7 hooks · 3 extensions<br/>MIT · not normative"]
    STD -->|implemented by| REF -->|demonstrated by| DEMO
    DEMO -.->|depend only on the interfaces| STD
```

The standard never depends on the reference; the token never depends on the hooks. Remove every hook and every extension and a conformant token still exists. A third party obtains the normative text through early access, rather than from this public chapter.

## What a batch is

A batch is an ERC-1155 token id. The field layout stays in the normative text.


Everything richer — grade, moisture, protein, packaging, GS1 identifiers, the traceability lot code, the EUDR declaration reference, lab reports, the issuer's status table — lives in the metadata document whose hash is committed on-chain. The document follows a published JSON Schema aligned with EPCIS 2.0 and the FSMA 204 key data elements.

## The transfer pipeline

Every balance change — mint, transfer, burn, forced transfer, transformation — passes through one choke point in the reference token. The order is fixed and auditable:

```mermaid
flowchart TD
    A[safeTransferFrom / createBatch / burn / forcedTransfer / transform] --> B[reentrancy lock]
    B --> C{paused?}
    C -- yes, not forced --> X1[EnforcedPause]
    C -- no --> D{canSend from / canReceive to<br/>conjunction of ELIGIBILITY hooks}
    D -- false --> X2[ERC7943CannotSend / CannotReceive]
    D -- true --> E{per id: exists? not retired?<br/>amount ≤ balance − frozen?}
    E -- fail --> X3[ARexBatchNotFound / ARexBatchRetired /<br/>ERC7943InsufficientUnfrozenBalance]
    E -- ok --> F{per id, per CHECK hook in order:<br/>check → code}
    F -- code ≠ 0 --> X4["ARexHookRejected(hook, code)"]
    F -- all 0 --> G[balances updated · supply tracked]
    G --> H[per id, per EXECUTED hook: onExecuted]
    H --> I[unlock]
```

Two views replay the same logic without changing state: `canTransfer` (boolean, as ERC-7943 requires) and `transferCheck` (the first rejection code, so an interface can tell the user *why*).

Forced transfers skip the pause and the eligibility checks — enforcement must work when everything else is frozen — but still run the hooks with `OP_FORCED_TRANSFER`, so a hook can insist, for example, on a court-order reference in the transfer data.

## Lineage

`transform` is the single operation for splitting, merging and processing:

```mermaid
graph LR
    W1["wheat #1<br/>250 t · farmer"] -- "transform (re-batch)" --> W2["wheat #2<br/>100 t · buyer A"]
    W1 -- "transform (re-batch)" --> W3["wheat #3<br/>150 t · buyer B"]
    W2 -- "transform (processing, TRANSFORMER_ROLE)" --> F4["flour #4<br/>75 t · mill"]
```

- *Re-batching* (same commodity, same unit, conserved quantity) is open to any holder or approved operator: a cooperative splitting a silo lot among members, an exporter merging deliveries.
- *Processing* (anything else) additionally requires `TRANSFORMER_ROLE`.
- `parentsOf(4) == [2]`, `parentsOf(2) == [1]`; one `BatchTransformed` event per operation, which is an EPCIS `TransformationEvent` by construction.

## Enforcement

`ENFORCER_ROLE` can freeze any amount for any account (`setFrozenTokens`, may exceed the balance, as ERC-7943 specifies) and move tokens without the holder's consent (`forcedTransfer`). This is what makes a batch token usable outside a demo: a lender executing a warrant, a court ordering the seizure of stored grain, a warehouse recovering a lot after a customer loses keys. Every enforcement action is an event.

## Hooks

A hook is a contract with five functions and a constant flags bitmap. The token caches the flags at registration, so a transfer costs one external call per interested hook, not one interface probe per capability per module. A hook learns which token is calling from `msg.sender`; one deployment can serve many tokens.

Reference hooks demonstrate the three capabilities:

| Hook | Capability | What it proves |
|---|---|---|
| `EligibilityHook` | CHECK + ELIGIBILITY | allow/block lists and sanctions feed `canSend` / `canReceive` and produce precise codes |
| `ExpiryHook` | CHECK | perishability and pre-harvest gating derived purely from the batch record |
| `AttestationHook` | CHECK | "coffee needs an EUDR declaration attested before it can be sold" |
| `PerishabilityHook` | CHECK | decay models and value views; expired or valueless lots do not move |
| `SeasonalHook` | CHECK | harvest and trading windows per commodity |
| `DeliveryHook` | CHECK + EXECUTED | custody lock during delivery; settlement is the transfer itself, identified by `data` |
| `TraceabilityHook` | EXECUTED | EPCIS-shaped event log of every operation plus manual critical tracking events |

Companion extensions (not hooks): `CommodityPriceOracle`, `CarbonImmobilizationWrapper`, `ParametricInsurance`.

## Attestations

A companion contract records `(batch, topic) → (issuer, reference, validity)`. Only issuers trusted for a topic can attest; revocation, expiry and loss of trust all make `isAttested` false. Topics are `bytes32`, so ERC-735 claim topics, Ethereum Attestation Service schema ids and hashes of certification names all work without a table in the standard.

## Actors and roles

| Actor | Typical role in the reference token | Typical action |
|---|---|---|
| Originator platform, cooperative, elevator | `ISSUER_ROLE` | `createBatch` |
| Farmer / holder | none | transfer, re-batch, burn |
| Mill, packer, processor | `TRANSFORMER_ROLE` | processing `transform` |
| Warehouse, inspector, platform | `STATUS_ROLE` | `setBatchStatus`, `setBatchMetadata` |
| Certifier, laboratory, authority | trusted issuer for a topic | `attest` |
| Lender, court-appointed custodian, compliance | `ENFORCER_ROLE` | `setFrozenTokens`, `forcedTransfer` |
| Governance (multisig, timelock) | `DEFAULT_ADMIN_ROLE`, `HOOK_ADMIN_ROLE`, `UPGRADER_ROLE`, `PAUSER_ROLE` | roles, hooks, upgrades, pause |

Nothing in the standard fixes these roles; they are how the reference implementation exercises the MUSTs ("restricted to an authorized role").

## Deployment shapes

- **Public L2 (Polygon, Arbitrum, Base, Optimism)**: cheapest, most composable; suited to commodity trading and financing where counterparties are businesses.
- **Permissioned EVM chain**: where data-protection authorities or the anchor institution require it; the EDPB expressly encourages permissioned designs. The standard is chain-agnostic.
- **Hybrid**: batches on a public chain, restricted data (plot polygons, producer identity) behind access-controlled storage referenced from metadata.

The reference stack deploys with one Ignition module or one script: token proxy, attestation registry, eligibility and expiry hooks.

## Design decisions and the alternatives they replace

| Alternative considered | A-REX Core | Reason |
|---|---|---|
| a wide core interface with enums for commodity, grade, state | 8-function `IARexBatch` with open codes | nothing to redeploy for a new crop, scheme or lifecycle |
| capability interfaces probed on every transfer | one hook interface, flags cached | gas linear in hooks, not in ids × modules × probes |
| string reasons | `bytes32` codes and typed errors | machine-readable, indexable |
| lifecycle state changeable by any holder | role only; RETIRED terminal | security |
| harvest date required in the past | `producedAt == 0` allowed | pre-harvest financing |
| no split / merge / processing | `transform` + `parentsOf` | traceability, recalls, EPCIS |
| no freeze or forced transfer | ERC-7943 | enforceability |
| coordinates stored on-chain | origin reference only | GDPR / EDPB 02/2025 |
| registry and identity contracts required | nothing required | no imposed identity stack |


---

# 5. Technical Specification


_What A-REX Core covers, and what this chapter withholds._

## Purpose of this chapter

This chapter states the scope of the standard. The normative clauses stay in the standard repository, together with signatures, constants, error names, storage layouts, and the metadata schema.

## Audience

A public reader can learn which problem the standard addresses and which kinds of rule it leaves open. A company that wants to implement A-REX, issue batches with it, or audit it requests the normative text on [Request early access](/access).

## Layers

| Layer | What it is for |
|---|---|
| Enforcement | Freeze, forced transfer, and account eligibility, so a lot can sit under a lien, a recall, or a court order. |
| Batch identity | Commodity, unit, time, an origin reference, a commitment to an off-chain document, and a lifecycle status. |
| Lineage | A lot can be split, merged, or processed, and the parent lots remain linked. |
| Rules | One ordered pipeline of external contracts. A rule reports a result. The rule does not define a new token. |
| Attestations | Statements about a batch and a topic, from issuers trusted for that topic. |

## Outside the standard

Crop lists, grade names, prices, decay curves, identity systems, and carbon issuance sit outside the core. They can be demonstrated beside it. Conformance does not require them.

## Withheld on purpose

The normative specification, the interface sources, and the batch metadata schema are available under the early-access process. Access is for evaluation, implementation, and feedback. Each request is reviewed by hand. Approved readers receive read-only access to the standard repository and the reference implementation. The material stays confidential until it is published. The written terms say the standard will be published under CC0 and that early access grants no exclusivity.

## Boundary of this chapter

This chapter names purposes. The early-access page is [Request early access](/access).


---

# 6. Core Standard


_The rationale behind each element of A-REX Core: why the batch record has exactly these fields, why lineage is an operation and not a mapping, why enforcement comes from ERC-7943, why codes replace enums, and which lessons shaped the design._

## Design goal: the smallest interface a third party will implement

A standard is adopted when implementing it costs less than not being interoperable. Every field, function and rule in A-REX Core had to pass one test: *would an independent team, building a grain elevator platform in Argentina or a coffee exporter's system in Colombia, accept this constraint in exchange for interoperability?* Enumerations of crops, US grade names, a mandatory farm registry, a prescribed identity stack and a valuation formula all failed that test. Batch identity, lineage, enforcement and an extension point passed it.

## The batch record, field by field

| Field | Why it is on-chain | Why it is shaped this way |
|---|---|---|
| `commodity: bytes32` | hooks, marketplaces and regulators must filter by product without parsing metadata | `keccak256("HS:100199")` accepts any scheme (HS, FAO/CPC, GTIN, national codes) without a table in the standard; an enum would freeze the world's crop list at deployment |
| `unit: bytes32` | quantities are meaningless without a unit; a transfer of `1000` is 1000 kg or 1000 boxes | UN/CEFACT Recommendation 20 is the code list used by EDI, EPCIS and customs |
| `producedAt: uint64` | perishability, seasonality and forward contracts all key off production time | `0` means "not yet produced": crop receivables, forwards and warrants on future harvests are the dominant agricultural financing instruments in Latin America and must be representable |
| `expiresAt: uint64` | the most common transfer rule in agriculture is "not after this date" | `0` means none; hooks decide what expiry implies |
| `originRef: bytes32` | origin must be provable (EUDR, organic, geographic indications) | a hash or reference, never coordinates: plot geolocation of a producer is personal data (EDPB Guidelines 02/2025 v2.0, July 2026) and an immutable public chain cannot honour erasure |
| `metadataHash: bytes32` + `uri` | everything else is off-chain, but the token must commit to it | hash of a canonical JSON document following a published schema; `uri` can be IPFS, HTTPS or a GS1 Digital Link |
| `status: uint8` | a lot moves through a lifecycle and some states must block movement | open values with two fixed points (`0` active, `255` retired); the previous nine-state enum encoded one supply chain's vocabulary and was changeable by any holder |
| `issuer`, `createdAt` | accountability and audit | set by the contract, never by the caller |

What is deliberately absent: latitude and longitude, farm identifier, grade enum, moisture and protein, verification flag and verifier address, a `quantity` field (ERC-1155 supply tracking is authoritative), and any notion of value.

## Lineage as an operation

A lifecycle with a `PROCESSED` state but no way to produce the processed good is a common mistake. Traceability regimes are explicit that transformation is an *event* linking inputs to outputs: FSMA 204's *transformation* critical tracking event, EPCIS 2.0's `TransformationEvent` with `inputQuantityList` and `outputQuantityList`. A mapping of parents written by an administrator would not carry the quantities or the atomicity.

`transform(from, to, inputIds, inputAmounts, outputs, outputAmounts, processRef)` burns and mints in one transaction, records parents on every output, emits one event with all quantities and a process reference, and runs the hook pipeline on every leg. Split (1→n), merge (n→1) and processing (n→m) are the same function. The reference implementation lets any holder re-batch (same commodity and unit, conserved quantity) but requires `TRANSFORMER_ROLE` to change the nature or the quantity of goods — a mill can turn wheat into flour, a farmer cannot turn wheat into gold.

## Enforcement from ERC-7943, not reinvented

Agricultural lots are routinely subject to liens, warrants, embargoes, insolvency proceedings and recalls. A token that cannot be frozen or moved by an authorized party against the holder's will cannot represent such a lot in front of a bank, a court or a regulator. ERC-3643 solved this for securities in 2021; ERC-7943 generalized it for any real-world asset and reached Final status in May 2026 with an ERC-1155 variant. A-REX adopts that interface verbatim rather than defining its own, so that ERC-7943-aware compliance engines (Chainlink ACE, ERC-3643 tooling) recognize an A-REX token without adaptation.

The multi-token variant fits ERC-1155 naturally: freezing is per account and per batch id, forced transfers name the batch, eligibility is per account.

## One hook, ordered, with codes

A module system built on five capability interfaces, each probed with `supportsInterface` on every transfer, does not scale; with eight modules and five ids in a batch transfer that was eighty static calls before any rule ran. Rejections were free-form strings that no indexer could interpret and no test could compare reliably.

A-REX Core defines one hook interface with a constant flags bitmap cached at registration. The token evaluates hooks in a fixed order and stops at the first non-zero `bytes32` code, reverting with `ARexHookRejected(hook, code)`. The order is auditable (`getHooks`), removal preserves it, and a hook learns the calling token from `msg.sender`, so one deployment serves many tokens. Eligibility (`canSend`/`canReceive`) is folded into the same interface so that the token's ERC-7943 views are the conjunction of its hooks.

Why codes and not custom errors from the hook? Because `check` is a view that must compose: the token needs to *ask* every hook, compare answers, and expose the first one through `transferCheck` without a revert. Codes are cheap, indexable, translatable, and namespaced (`keccak256("AREX:BATCH_EXPIRED")`, `keccak256("MYHOOK:QUOTA")`).

## Attestations per batch, issuers per topic

Certifying a *producer* is an identity problem with mature solutions (ONCHAINID, Ethereum Attestation Service, verifiable credentials, national e-ID). Certifying a *lot* is what buyers, customs and regulators verify, and it had no standard form. `IARexAttest` records `(batch, topic) → (issuer, reference, validity)` and lets an administrator decide which issuer may attest to which topic, mirroring ERC-3643's trusted-issuers registry without prescribing an identity provider. Topics are open `bytes32`, so ERC-735 claim topics, EAS schema ids and hashes of certification names coexist.

`isAttested` is the single question a hook asks: it is false if the attestation is absent, revoked, expired, or its issuer has lost trust. This lets a hook enforce "coffee batches need an EUDR due-diligence reference before they can be sold" in six lines.

## What the standard does not say

- It does not say who may create batches, change status or enforce — only that these are roles, never balances.
- It does not say what statuses 1..254 mean; the issuer publishes a table in metadata.
- It does not say how to value a batch, how it decays, when it may be traded seasonally, how it is delivered or insured: all hooks or companion contracts.
- It does not say which chain, which identity provider, which oracle, which registry.
- It does not say whether the token is a security or a commodity.

## Lessons that shaped the design

| Lesson | Consequence in A-REX Core |
|---|---|
| A standard that includes a farm registry and an identity system as REQUIRED is not a token standard, it is a product | nothing outside the token is required |
| A closed enum in a function signature makes any "dynamic registry" of commodities dead code | commodities, units, statuses and topics are open codes |
| Authority derived from balance is a vulnerability in a multi-holder token | status changes are role-gated; RETIRED is terminal |
| Business logic in the core contradicts "core without business logic" | valuation, decay and windows live in hooks |
| A build that does not compile from a clean clone is not a reference implementation | dependencies pinned, lockfile committed, CI on every push |
| Regulatory dates in a whitepaper age; the code that depends on them must not | the token stores references and hashes, never regulatory logic |

## Backwards compatibility

A-REX Core tokens are full ERC-1155 and ERC-7943 tokens. Wallets, marketplaces and indexers that know ERC-1155 work unchanged; ERC-7943-aware compliance tooling recognizes the enforcement surface. Rule engines written for other tokens attach through an `IARexHook` adapter as long as their decisions depend only on the call parameters and the batch record.


---

# 7. Hooks and Reference Modules


_How functionality is added to a conformant token without touching the standard: the hook contract, the reference hooks, the companion extensions, and how to write, test and register your own._

## Modules are demonstrations, not the standard

The relationship between A-REX Core and its modules is the one between ERC-3643 and T-REX's compliance modules: the **interface** through which modules plug in is standardized; the **modules** are not. A conformant token with zero hooks is a valid A-REX token. A hook written by anyone is compatible with every conformant token. This is what makes the ecosystem grow without the standard changing.

```mermaid
graph LR
    T[ARexToken<br/>conformant token] -->|"check / onExecuted / canSend / canReceive"| H1[EligibilityHook]
    T --> H2[ExpiryHook]
    T --> H3[AttestationHook]
    T --> H4[Your hook]
    H3 --> A[ARexAttestations]
```

## The hook contract


| Callback | When | Must |
|---|---|---|
| `check` | before balances change, per affected id, hooks in registration order, stop at first non-zero | be a view; never revert for policy |
| `onExecuted` | after balances change, per id, in order | not call the token's balance-changing functions (the token is locked) |
| `canSend` / `canReceive` | on every transfer and for the token's ERC-7943 views | be views |

`op` is one of `OP_MINT (1)`, `OP_TRANSFER (2)`, `OP_BURN (3)`, `OP_FORCED_TRANSFER (4)`, `OP_TRANSFORM (5)`. In a transformation, inputs arrive with `to == 0` and outputs with `from == 0`. `data` is the ERC-1155 transfer data, `abi.encode(processRef)` for transforms, empty for forced transfers.

The calling token is `msg.sender`. A hook that needs the batch reads `IARexBatch(msg.sender).batchOf(id)`.

## Reference hooks

### EligibilityHook — allow, block, sanction

Demonstrates `HOOK_ELIGIBILITY`. Maintains an optional allowlist, a blocklist and a sanctions list; `canSend`/`canReceive` return their conjunction; `check` returns `SANCTIONED`, `SENDER_INELIGIBLE` or `RECEIVER_INELIGIBLE` so that interfaces can explain the refusal. Forced transfers are always allowed: seizing goods from a sanctioned account is the point of enforcement. In production the lists are fed by an identity registry (ONCHAINID, EAS, verifiable credentials) or a sanctions oracle; the hook does not care which.

### ExpiryHook — perishability without a module

Stateless. Reads `expiresAt` and `producedAt` from the batch. Blocks mints and transfers of expired batches (`BATCH_EXPIRED`) but not burns (write-off) or forced transfers (enforcement). Optionally blocks transfers of batches that are not yet produced (`BATCH_NOT_PRODUCED`) — a platform that finances pre-harvest sets the flag to allow them; a spot marketplace sets it to block them. This one hook covers the blocking part of perishability; decay curves become a view helper or an off-chain valuation.

### AttestationHook — regulatory gating per commodity

Maps a commodity code to a required attestation topic. Before a transfer, reads the batch, looks up the requirement, asks the attestation registry `isAttested` and returns `ATTESTATION_MISSING` otherwise. "Coffee needs an EUDR due-diligence reference", "organic-labelled batches need a valid organic certificate", "cattle needs a sanitary certificate" are each one call to `setRequirement`.

### PerishabilityHook — decay models

Decay configuration per commodity code with per-batch override; models NONE, LINEAR (to a floor at expiry), EXPONENTIAL (half-life) and STEP (drop every interval). Views `valueBps`, `secondsRemaining`, `isExpired`. Blocks mints and transfers of expired batches (`BATCH_EXPIRED`) and transfers of batches whose remaining value is zero (`PERISH:NO_VALUE`); never blocks burns or enforcement.

### SeasonalHook — harvest and trading windows

Absolute `[start, end]` windows per commodity and operation (at most 16 per key). A commodity/op with no windows is unrestricted. Typical use: `OP_MINT` limited to the harvest window, `OP_TRANSFER` to the trading window; `SEASON_CLOSED` otherwise.

### DeliveryHook — custody and settlement

A sender schedules a delivery of `amount` units to a receiver via a carrier; the units are locked (an O(1) counter, so `check` never iterates over history). Carrier and sensors record pickup, transit and temperature readings (breach flag); the receiver confirms delivery; disputes go to an arbiter. Settlement is the ERC-1155 transfer itself: sender → receiver, exact amount, with `data = abi.encode(deliveryId)`; `check` allows it only when the delivery is DELIVERED and `onExecuted` marks it SETTLED and unlocks. Free (unlocked) units keep moving.

### TraceabilityHook — EPCIS-shaped event log

Observes every token operation and classifies it with CBV business steps (`commissioning`, `shipping`, `destroying`, `transforming`) and dispositions (`active`, `in_transit`, `destroyed`, `seized`); `RECORDER_ROLE` records non-token critical tracking events (cooling, packing, receiving) with `readPoint` and `bizLocation`. Two modes: emit-only (about +17 k gas per transfer; an indexer rebuilds the log) or persist (about +184 k; `getEvents` answers on-chain, paginated).

## Companion extensions

Three concerns never needed to be transfer rules; they are plain contracts that read or write attestations:

| Extension | What it does |
|---|---|
| `CommodityPriceOracle` | reporters submit prices per commodity; rounds are numbered, finalized by quorum with the median, or manually once a minimum is reached; `latestAnswer`, `isStale` |
| `CarbonImmobilizationWrapper` | records credits immobilised in a registry (registry, serial range, vintage, tonnes, proof), links tonnes to batches, mirrors retirement and release, writes the attestation `AREX:CARBON:IMMOBILIZED`; never mints credits |
| `ParametricInsurance` | ERC-20 pool; policy per batch with a trigger topic; the claim pays when the trigger is attested before expiry |


## Writing your own hook

The worked example `contracts/examples/SeasonHook.sol` stays in the repository. `test/standard/ImplementationGuide.test.js` exercises it for readers with access. `SeasonalHook` is the reference module for several windows per commodity and per operation.


Rules of thumb:

1. The symbols `OK` and `OP_FORCED_TRANSFER` are defined in the normative text.
2. Burn behaviour is defined in the normative text.
3. The callback `check` is defined in the normative text.
4. Code names such as `ARexCodes.code("MYNS", "NAME")` are defined in the normative text.
5. Flag values are defined in the normative text.
6. The callbacks `onExecuted` and `check` are defined in the normative text.

## Registering and ordering


Put cheap, high-rejection rules first. `HOOK_ADMIN_ROLE` should sit behind a multisig or timelock: whoever controls the pipeline controls which transfers are possible.

## Testing

`test/standard/helpers.js` deploys the reference stack. `RecordingHook` records every callback and can be told to reject with any code; `ReentrantHook` attempts to re-enter the token from `onExecuted` and proves the lock. `DomainHooks.test.js` and `Extensions.test.js` cover the ported hooks and companions; `Invariants.test.js` runs a seeded random sequence of operations and checks supply conservation, terminal status and that `canTransfer` predicts every outcome.

## Interoperating with ERC-3643 compliance

An ERC-3643 compliance module exposes `moduleCheck(from, to, value, compliance)`. A hook that calls it for `OP_TRANSFER` and maps `false` to a code makes country restrictions, balance caps and time locks written for security tokens reusable on batch tokens. The reverse — exposing an A-REX hook to an ERC-3643 token — is equally mechanical. Chainlink's Automated Compliance Engine integrates through the same pattern: its policy engine becomes one hook.


---

# 8. Security Framework


_Threat model, invariants, access control, the hook trust boundary, enforcement key management, upgrade safety and audit posture of the A-REX Core reference implementation._

## Security posture in one paragraph

The reference token has one choke point (`_update`), a fixed evaluation order, a reentrancy lock around the entire hook sequence, role-based authority that is never derived from balances, ERC-7201 storage, and a small surface: eight external state-changing functions beyond ERC-1155. The most powerful capabilities — freezing, forced transfer, hook administration, upgrades — are separate roles intended for multisigs and timelocks, and every use of them is an event.

## Invariants

| Invariant | Enforced by | Tested by |
|---|---|---|
| `totalSupply(id)` equals the sum of balances for `id` | OpenZeppelin `ERC1155Supply`; `transform` burns then mints through `_update` | lineage tests (split, merge, processing) |
| `status == 255` is terminal | `setBatchStatus` reverts with `ARexInvalidStatusTransition` | status tests |
| A retired batch cannot be minted or transferred, only burned | `_update` | retired-batch test |
| `amount ≤ balance − frozen` for holder-initiated moves | `_update`; `forcedTransfer` lowers `frozen` to `balance − amount` | freeze/forced tests |
| No hook can re-enter a balance-changing function | storage lock set before checks, cleared after notifications | `ReentrantHook` test |
| Hooks are evaluated in registration order; removal preserves order | array shift in `removeHook` | ordering test |
| A rejected operation changes no balance and emits no transfer | checks run before `super._update` | rejection test (executed count unchanged) |
| Authority never derives from balance | every state-changing function is role-gated or ERC-1155-approval-gated | "holding tokens grants nothing" tests |
| `canTransfer == (transferCheck == 0)` | `canTransfer` is defined as that | conformance tests |

## Threat model

### Actors and capabilities

| Actor | Can | Cannot |
|---|---|---|
| Holder | transfer unfrozen units to eligible receivers; burn; re-batch same commodity/unit with conserved quantity | change status, mint, process into another commodity, move frozen units |
| Approved operator | same as holder for the approving account | anything a holder cannot |
| `ISSUER_ROLE` | create batches | move others' tokens |
| `TRANSFORMER_ROLE` | processing transforms of tokens it holds or is approved for | transform tokens without approval |
| `STATUS_ROLE` | change status (including retire), update metadata | move tokens |
| `ENFORCER_ROLE` | freeze any amount; force any transfer | bypass hooks (they run with `OP_FORCED_TRANSFER`) |
| `HOOK_ADMIN_ROLE` | add/remove hooks | change balances directly |
| `PAUSER_ROLE` | halt everything except forced transfers | — |
| `UPGRADER_ROLE` | replace implementation | — (this is total power; see key management) |
| Hook contract | reject operations; observe them; answer eligibility | re-enter; change balances |

### Scenarios

**Malicious or buggy hook (denial of service).** A hook that always rejects blocks all transfers of the token; one that reverts in `check` does the same. Mitigation: `HOOK_ADMIN_ROLE` can remove any hook at any time (order preserved); `PAUSER_ROLE` can halt while investigating; forced transfers still run, so enforcement is not lost. Registration verifies ERC-165 support and non-zero flags, and rejects EOAs. Recommendation: audit hooks before registering; keep the number small; put the admin behind a timelock so that hook changes are visible before they take effect.

**Hook re-entrance.** A hook's `onExecuted` calls back into `safeTransferFrom`. Mitigation: the lock; the call reverts with `ARexReentrantCall`. Note that ERC-1155's receiver callback (`onERC1155Received`) runs *after* the lock is released, as in every ERC-1155 token; the token's state is final by then.

**Compromised enforcement key.** Whoever holds `ENFORCER_ROLE` can move any tokens. Mitigation: multisig with a documented procedure (court order, pledge agreement, sanctions notice); every action emits `ForcedTransfer`/`Frozen`; hooks can require an order reference in transfer data (`OP_FORCED_TRANSFER` is not exempt from hooks). Consider a timelock for non-urgent enforcement.

**Compromised upgrader.** Total compromise. Mitigation: multisig plus timelock; OpenZeppelin upgrade validations in CI; ERC-7201 storage to avoid layout accidents.

**Status abuse.** `STATUS_ROLE` can retire a batch held by others. This is intentional — a warehouse, inspector or regulator declaring a lot unfit — and must be disclosed to holders. Mitigation: assign to an accountable institution; every change is an event with a reason.

**Issuer fraud.** `ISSUER_ROLE` can create a batch that does not exist physically. The token cannot prevent this; it makes it attributable (`issuer`, `originRef`, `metadataHash`) and lets attestations from independent parties (warehouse, inspector, registry) be required before transfer via `AttestationHook`.

**Metadata substitution.** `setBatchMetadata` changes the hash and URI. Mitigation: role-gated; `BatchMetadataUpdated` and `URI` events keep the history; earlier documents remain verifiable against earlier hashes.

**Front-running of `transferCheck`.** A pre-flight check can become stale before the transaction executes (a hook's state changes). The transaction re-evaluates; the worst case is a revert with a precise code.

**Gas griefing through hooks.** Each hook adds one external call per affected id per phase. A hook with unbounded loops makes transfers unaffordable. Mitigation: hook authoring rules (bounded `check`), review before registration.

**Upgradeable hook trust.** A hook deployed behind a proxy can change transfer policy without any change on the token. Mitigation: treat hook admin keys with the same care as `HOOK_ADMIN_ROLE`; prefer immutable hooks for production.

## Access control model

OpenZeppelin `AccessControl` with eight roles on the token and one on the attestation registry; `DEFAULT_ADMIN_ROLE` administers all of them. Recommended production layout:

| Role | Holder |
|---|---|
| `DEFAULT_ADMIN_ROLE`, `UPGRADER_ROLE`, `HOOK_ADMIN_ROLE` | governance multisig behind a timelock |
| `ENFORCER_ROLE` | enforcement multisig (compliance + legal) |
| `PAUSER_ROLE` | incident-response key (fast) |
| `ISSUER_ROLE`, `STATUS_ROLE`, `TRANSFORMER_ROLE` | operational services with least privilege, rotated |
| `ATTEST_ADMIN_ROLE` | certification authority or platform |

`initialize` grants everything to one admin for convenience; the deployment checklist requires redistribution before production.

## Enforcement and pause semantics

- Pause blocks mints, transfers, burns and transforms; it does **not** block forced transfers, so a lawful order can be executed during an incident.
- Forced transfers skip `canSend`/`canReceive` and the frozen-balance check, lower the frozen amount to what remains, and still run hooks with `OP_FORCED_TRANSFER`. Reference hooks return `OK` for that op; a hook that governs enforcement may require order references in `data`.
- Freezing may exceed the balance (ERC-7943), so a lien can cover future deposits.

## Upgrade safety

- UUPS; `_authorizeUpgrade` gated by `UPGRADER_ROLE`.
- ERC-7201 namespaced storage struct; append-only.
- OpenZeppelin upgrades plugin validations run in tests and should run in CI before any upgrade transaction.
- The per-file `optimizer.runs = 1` setting keeps the implementation under EIP-170; a change that pushes it over fails at compile time with a warning and at deployment with a revert.

## Dependency and build security

- OpenZeppelin Contracts and Contracts-Upgradeable pinned to 5.3.0; lockfile committed; CI uses `npm ci`.
- Solidity 0.8.22, viaIR, EVM `paris` (no transient storage dependence, deployable on chains that have not adopted Cancun).
- No external libraries linked; no delegatecall outside the UUPS proxy.

## Audit posture

- 46 tests on the reference implementation, hooks and extensions cover every invariant above, including a seeded randomized invariant run.
- Gas and size are measured by scripts in the repository.
- A third-party audit of `ARexToken`, `ARexAttestations` and the reference hooks is a stated precondition for a production anchor and for submitting the ERC (see *Future Developments*).
- Formal verification of the pipeline invariants is on the roadmap; the invariants are small enough to be stated as properties.

## Residual risks the standard does not remove

- The physical existence and quality of a lot are attested, not proven; the token makes claims attributable, not true.
- Off-chain metadata availability depends on the storage chosen; the hash guarantees integrity, not availability.
- Hook and module governance is only as good as the keys that control it.


---

# 9. Regulatory Compliance


_How A-REX Core maps to the regimes that govern agricultural lots and the tokens that represent them. Dates and legal references were verified in September 2026; where a statement is an inference rather than a verified fact, it is marked. Nothing here is legal advice._

## The position of the standard

A-REX Core does **not** classify the token. Whether a batch token is a security, a commodity, a crypto-asset under MiCA, an electronic warehouse receipt or a receivable depends on how it is offered, to whom, and what rights it carries — not on the interface. The standard's job is to make every one of those outcomes *implementable*: it ships the enforcement surface all of them require (freeze, forced transfer, eligibility, pause, auditable events), keeps personal data off-chain, and leaves policy to hooks and to the issuer's counsel.

This is a deliberate rejection of the argument "commodities, not securities, therefore no compliance stack". That argument is wrong as a matter of law and is discussed below.

## Food traceability

### FSMA 204 — FDA Food Traceability Rule (United States)

| Fact | Status (Sept 2026) |
|---|---|
| Rule | 21 CFR Part 1 Subpart S, final rule of November 2022 |
| Compliance date | **20 July 2028** (FDA extended the original 20 January 2026 date by 30 months; final rule of 7 August 2025; the Continuing Appropriations Act of 2026 bars enforcement before that date) |
| Scope | foods on the Food Traceability List (leafy greens, fresh-cut produce, tomatoes, peppers, cucumbers, melons, herbs, sprouts, shell eggs, nut butters, finfish, crustaceans, molluscs, soft cheeses, deli salads) |
| Obligation | maintain key data elements (KDE) at each critical tracking event (CTE): harvesting, cooling, initial packing, first land-based receiving, shipping, receiving, transformation; produce an electronic sortable spreadsheet within 24 hours of an FDA request |
| Recommended format | GS1 EPCIS 2.0 (FDA guidance and GS1 US mapping of CTEs to EPCIS events) |

**How A-REX maps:**

| FSMA element | A-REX Core |
|---|---|
| Traceability lot code (TLC) | `traceabilityLotCode` in the metadata document, assigned by the packer — never derived from the token id |
| Product description, quantity, unit | `commodity`, `totalSupply(id)`, `unit` |
| Location description of the TLC source | GLN in metadata; `originRef` commits to the record |
| Harvest / cooling / packing dates | `producedAt` plus dated events in metadata |
| Shipping / receiving | ERC-1155 `TransferSingle`/`TransferBatch` events with the parties, plus hook-recorded custody events |
| Transformation CTE (inputs → outputs with quantities) | `transform` → `BatchTransformed(inputIds, inputAmounts, outputIds, outputAmounts, processRef)`; `parentsOf` |
| 24-hour production of records | events are indexable; the metadata schema fields are named after EPCIS/KDE so an exporter can emit the spreadsheet or an EPCIS document directly |

What A-REX does **not** do: it does not itself produce the FDA spreadsheet, and it does not hold the KDEs that are personal or commercial (addresses, contact names). Those are in the metadata document or in the restricted pointer.

### EUDR — Regulation (EU) 2023/1115 as amended by Regulation (EU) 2025/2650

| Fact | Status (Sept 2026) |
|---|---|
| Application | **30 December 2026** for medium and large operators and traders; **30 June 2027** for micro and small operators. The Commission has stated there will be no third postponement. |
| Scope | cattle, cocoa, coffee, oil palm, rubber, soya, wood and listed derived products |
| Obligation | due-diligence statement (DDS) in the EU Information System with geolocation of plots; the 2025 amendment introduces a *simplified declaration* for primary operators and lighter duties for downstream operators, who keep DDS reference numbers for five years |
| Penalties | up to 4 % of EU turnover, confiscation, exclusion from public procurement |

**How A-REX maps:**

- The DDS reference number is what downstream operators must keep: it goes into metadata (`origin.eudr.ddsReference`) and is committed by `originRef`. Precise plot geolocation stays in the EU Information System and in the operator's restricted storage, not on-chain.
- `AttestationHook` can require an attestation with topic `EUDR:DDS` from a trusted issuer (the operator's compliance function or a verifier) before a coffee or cocoa batch can be transferred.
- `transform` preserves the link from a roasted or processed batch back to the batches whose DDS references cover it.

### GS1 EPCIS 2.0 and identifiers

The metadata schema uses EPCIS/CBV vocabulary (`bizStep`, `disposition`, `readPoint`, `bizLocation`) and GS1 identifiers (GTIN, LGTIN, SSCC, GLN, Digital Link). On-chain events map to EPCIS events as follows:

| A-REX event | EPCIS 2.0 |
|---|---|
| `BatchCreated` | `ObjectEvent` (ADD), `bizStep = commissioning` or `harvesting` |
| `TransferSingle` / `TransferBatch` | `ObjectEvent` (OBSERVE) with `bizStep = shipping` / `receiving`, or `AssociationEvent` for custody |
| `BatchTransformed` | `TransformationEvent` (`inputQuantityList`, `outputQuantityList`, `transformationID = processRef`) |
| `BatchStatusChanged` | `ObjectEvent` with `disposition` change |
| `Attested` | `ObjectEvent` with certification extension, or a sensor/attestation element |

An indexer can therefore emit an EPCIS document from chain data without bespoke logic.

## The legal nature of the token

### United States

- **Securities law.** *SEC v. W.J. Howey Co.* (1946) concerned interests in citrus groves sold to passive investors with a service contract; the Supreme Court held them investment contracts. The test still governs. The SEC's interpretive release of 17 March 2026 (Release 33-11412) classifies crypto assets by the substance of the transaction and stresses issuer promises and marketing; it does not create a safe harbour for tokenized physical commodities. A batch token sold to investors expecting profit from the operator's efforts is likely a security; the same token held by a buyer who will take delivery likely is not.
- **Commodities law.** Spot commodity transactions between commercial parties are outside the Commodity Exchange Act's registration regime; forward contracts with intent to deliver are excluded; retail leveraged transactions require actual delivery within 28 days (CEA §2(c)(2)(D)). A pre-harvest batch (`producedAt == 0`) is naturally a forward; how it is marketed determines the regime. The market-structure bill that would give the CFTC exclusive jurisdiction over "digital commodities" (CLARITY Act) failed cloture in the Senate on 15 September 2026 and is not law.
- **Warehouse receipts.** Under the U.S. Warehouse Act electronic warehouse receipts are issued through USDA-authorized providers (7 CFR Part 869). A batch token may *reference* an EWR (`documents[].registry`), not replace it.
- **UCC Article 12.** More than thirty states have enacted the 2022 amendments on controllable electronic records; New York's took effect on 3 June 2026. "Control" of the token can perfect a security interest; `forcedTransfer` and freezing are compatible with that framework when documented.
- **GENIUS Act (July 2025).** Applies to payment stablecoins, not to batch tokens, but it made "technological capability to comply with lawful orders to seize, freeze, burn or prevent the transfer" the market's baseline expectation for any token with a real-world claim. ERC-7943 provides exactly that surface.

### European Union

- **MiCA** (fully applicable since 30 December 2024). A fungible batch token offered to the public in the EU is an "other crypto-asset" under Title II unless an exemption applies (fewer than 150 persons per member state, less than €1 million over 12 months, or qualified investors only); Recital 11 states that fractions of a unique asset are not "unique and non-fungible", so the NFT exclusion does not apply to lot fractions. If the token carries a right to income or is a share in a vehicle, ESMA's December 2024 guidelines push it toward MiFID II, where the DLT Pilot Regime applies.
- **GDPR and the EDPB.** Guidelines 02/2025 on blockchain, final version 2.0 adopted 7 July 2026: on-chain content and metadata are personal data in principle, hashing and encryption do not guarantee anonymisation, controllers should avoid storing personal data on-chain and should justify a public chain over a permissioned one. A-REX's `originRef` rule and the `restricted` pointer in the metadata schema exist because of this.
- **Digital Product Passport (ESPR).** Food and feed are excluded from the ESPR; A-REX makes no DPP claim for food. Fibres and wood may fall under future delegated acts.

### Latin America

- **Argentina.** CNV General Resolution 1150/2026 (June 2026) established the definitive regime for tokenized securities on real-world assets through registered virtual-asset service providers, after the 2025 sandbox. Grain tokens that represent certificates of deposit and warrants (Law 9.643) operate under the warehouse regime; a token that pools lots for investors is a security. The structure of the offer decides.
- **Brazil.** The electronic CPR (Cédula de Produto Rural, Law 8.929/1994 as amended by Law 13.986/2020) is registered with entities authorized by the Central Bank and is the dominant tokenized agricultural instrument. Tokenized CPR issuance exceeded R$ 400 million in January 2026. CVM is revising Resolution 88 (public consultation closed January 2026) to admit cooperatives and rural producers as issuers. A batch token in Brazil should *reference* the registered CPR-e or CDA/WA, not replace it.
- **Paraguay** adopted the UNCITRAL Model Law on Electronic Transferable Records (2021), which is the legal basis for electronic warrants; its securities regulator is evaluating the recognition of livestock tokens as digital warrants.
- **Chile** regulates virtual financial assets under the Fintech Law (21.521) with no commodity-specific regime yet.

### Electronic transferable records

Where a jurisdiction has adopted UNCITRAL's MLETR (Singapore, United Kingdom via the Electronic Trade Documents Act 2023, France, Bahrain, Paraguay, ADGM, among others), an electronic bill of lading or warehouse receipt is valid if a reliable system ensures exclusive control. A batch token can satisfy the "exclusive control" test — the holder of the units controls them, and `forcedTransfer` provides the court-ordered transfer such laws contemplate — but only within MLETR jurisdictions; elsewhere the paper document still governs and the token references it.

## Sanctions and anti-money-laundering

A-REX provides the mechanism, not the list: `EligibilityHook` (or any hook) answers `canSend`/`canReceive`; the source of truth is the issuer's screening provider. The token's `forcedTransfer` and `setFrozenTokens` give the issuer the means to comply with blocking orders. Every enforcement action is an event, which is what an examiner asks for.

## Carbon and sustainability claims

Verra prohibits tokens on retired credits and accepts only *immobilised* credits as the basis for tokens; Gold Standard follows a similar policy. A carbon claim attached to a batch is therefore an **attestation** (`AREX:CARBON:IMMOBILIZED`, reference = hash of the registry record and immobilisation proof) written by `CarbonImmobilizationWrapper`, which records immobilisations, links tonnes to batches and mirrors retirements and releases; it never mints credits. The previous-generation carbon module, which generated its own serial numbers, has been replaced by it. In the EU, Directive 2024/825 on empowering consumers for the green transition treats unsubstantiated environmental claims as unfair commercial practices.

## Privacy by design in the standard

| Rule | Where |
|---|---|
| No raw coordinates or natural-person identifiers on-chain | `IARexBatch.originRef` MUST NOT contain them (normative) |
| Metadata document split into public and restricted parts | `standard/schema/batch-metadata.schema.json` (`restricted` pointer, `geohashPrecision`) |
| Hash commitments instead of content | `metadataHash`, attestation `ref` |
| Permissioned deployment as a first-class option | chain-agnostic standard; EDPB-recommended |
| Erasure | on-chain data is hashes and references; the personal data they point to can be deleted, breaking the link |

## Checklist for an issuer

1. Determine the legal nature of the offer with counsel in each target jurisdiction (security / commodity / crypto-asset / warehouse receipt / receivable).
2. Configure eligibility (KYC/KYB, sanctions) as a hook; keep the identity provider outside the token.
3. Assign `ENFORCER_ROLE` to a multisig with a documented procedure for lawful orders.
4. Publish the status table and the metadata schema version; assign TLCs at packing.
5. For EUDR commodities, require the `EUDR:DDS` attestation before transfer.
6. Keep plot geolocation and producer identity in restricted storage; put references on-chain.
7. Reference — do not replace — legal instruments (EWR, CPR-e, CDA/WA, bills of lading) until the jurisdiction recognizes the token itself.
8. Do not attach carbon or sustainability claims that are not registry-backed attestations.

## Sources

FDA compliance-date extension (Federal Register, 7 Aug 2025) · Regulation (EU) 2025/2650 and Council press release of 18 Dec 2025 · EDPB Guidelines 02/2025 v2.0 (7 Jul 2026) · SEC Release 33-11412 (17 Mar 2026) · GENIUS Act, P.L. 119-27 · UCC Article 12 enactment tracking (ABA, Wolters Kluwer 2026) · UNCITRAL MLETR and UK ETDA 2023 · CNV RG 1150/2026 (Boletín Oficial, 11 Jun 2026) · Brazil Law 13.986/2020 and CVM regulatory agenda 2026 · Verra statement on crypto instruments and tokens · ERC-7943 (Final, 27 May 2026) · GS1 US EPCIS recommendations for FSMA 204 CTEs. Full links in `docs/history/REVISION-ESTANDAR-2026.md`.


---

# 10. Use Cases


_Six scenarios showing how the four interfaces of A-REX Core, plus hooks, cover the situations that a grain elevator, a cooperative, an exporter, a lender and a regulator actually face. Each scenario names the calls involved._

## 1. Stored grain and warehouse receipts

**Situation.** A cooperative elevator receives 250 t of wheat from a member, issues a certificate of deposit, and later sells the lot in two parts.

**On-chain.**

1. `createBatch({commodity: HS:100199, unit: KGM, producedAt: harvest, expiresAt: 0, originRef: hash(certificate #CD-88213), metadataHash, uri}, 250_000, member)` — the token references the legal receipt; it does not replace it until the jurisdiction says so.
2. `setBatchStatus(id, 1 /* IN_STORAGE */, ref("SILO-3"))` by the elevator (`STATUS_ROLE`).
3. `transform(member, buyerA, [id], [100_000], [same commodity/unit], [100_000], ref("SALE-1"))` — a re-batch, no role needed; `parentsOf(newId) == [id]`.
4. Second sale likewise; the remaining 50 t stay in the original id.
5. On physical withdrawal the buyer's units are burned: `burn(buyerA, newId, 100_000)`; the elevator retires the parent lot when empty.

**Why it matters.** Supply is exact (`totalSupply`), provenance is a chain of `BatchTransformed` events, and the receipt registry stays authoritative.

## 2. Pre-harvest financing (CPR, forward, warrant on future crop)

**Situation.** A Brazilian producer issues an electronic CPR for 1,000 t of soybeans to be harvested in April; a lender advances funds against it.

**On-chain.**

1. `createBatch({commodity: HS:120190, unit: TNE, producedAt: 0, expiresAt: 0, originRef: hash(CPR-e registry id), …}, 1000, producer)` — `producedAt == 0` is the standard's representation of a future lot.
2. `ExpiryHook(allowPreHarvestTransfers = true)` so the receivable can be assigned; a spot marketplace would deploy it with `false`.
3. The lender's security interest: `setFrozenTokens(producer, id, 1000)` by `ENFORCER_ROLE` (the platform acting under the pledge agreement). The producer keeps title but cannot move the units.
4. At harvest: `setBatchMetadata` with the weighing ticket; `setBatchStatus(id, 2 /* HARVESTED */)`; the platform records `producedAt` in metadata (the on-chain field is immutable by design; the status change is the on-chain fact).
5. Repayment: `setFrozenTokens(producer, id, 0)`. Default: `forcedTransfer(producer, lender, id, 1000)` under the pledge.

**Why it matters.** The two most common credit events in agriculture — pledge and execution — are two calls, both auditable, both compatible with UCC Article 12 "control" and with registry-based instruments.

## 3. Coffee export under the EUDR

**Situation.** A Colombian exporter ships 20 t of green coffee to a roaster in Hamburg after 30 December 2026.

**On-chain.**

1. `createBatch({commodity: HS:090111, unit: KGM, producedAt: harvest, originRef: hash(DDS reference), …}, 20_000, exporter)`. Plot polygons stay in the EU Information System and the exporter's restricted storage.
2. The exporter's compliance officer is a trusted issuer for topic `EUDR:DDS`: `attest(id, EUDR:DDS, hash(DDS reference), 0)`.
3. `AttestationHook` (HS:090111 → EUDR:DDS) on the token: transfers of coffee without the attestation return `ATTESTATION_MISSING`.
4. Sale: `safeTransferFrom(exporter, roaster, id, 20_000, data)`; the roaster, a downstream operator, keeps the DDS reference for five years — it is in the batch metadata it now holds.
5. Roasting: `transform(roaster, roaster, [id], [20_000], [{commodity: HS:090121, …}], [16_800], ref("ROAST-2027-03"))` — the roasted lot's parents point to the green lot and, through it, to the DDS.

**Why it matters.** The regulation's chain of references survives processing, and the geodata that the EDPB says must not be on a public chain never is.

## 4. Perishable produce and cold chain

**Situation.** A packer ships strawberries with a 12-day shelf life; a temperature excursion is recorded in transit.

**On-chain.**

1. `createBatch({commodity: GTIN:…, unit: BX, producedAt: packDate, expiresAt: packDate + 12 days, …}, 4_800, packer)`; the metadata carries the FSMA traceability lot code assigned at initial packing.
2. `ExpiryHook` blocks any transfer after `expiresAt` (`BATCH_EXPIRED`); burns remain possible for write-off.
3. A cold-chain hook (`DeliveryHook`) returns `IN_TRANSIT` during transport and records checkpoints in `onExecuted`.
4. The excursion is attested by the logistics provider: `attest(id, COLDCHAIN:EXCURSION, hash(sensor log), 0)`; a buyer-side hook can refuse receipt (`canReceive` policy) or the parties settle off-chain with the attestation as evidence.
5. Delivery: `burn` by the receiver, or `setBatchStatus(id, 255 /* RETIRED */, ref("DELIVERED"))` by the packer.

**Why it matters.** Shelf life, custody and quality incidents are three independent hooks over one batch record; none of them required a change to the token.

## 5. Cooperative distribution and member settlement

**Situation.** A cooperative markets a 1,000 t pooled lot and must allocate proceeds and residual grain to 40 members.

**On-chain.**

1. Members deliver into the pool: each delivery is a `createBatch` to the member, then `transform(member, coop, [ids], [amounts], [pool spec], [amount], ref("POOL-2026"))` merging into the pool lot (re-batch, no role needed if same commodity and unit).
2. `parentsOf(pool)` lists every member delivery — the allocation key is on-chain.
3. Sale of the pool to a buyer: one `safeTransferFrom`.
4. Residuals: `transform(coop, coop, [pool], [remaining], [40 outputs], [per-member amounts], ref("RESIDUAL"))` and `safeBatchTransferFrom` to members.

**Why it matters.** Pooling and de-pooling, which today live in cooperative ledgers, are lineage operations with exact quantities.

## 6. Recall

**Situation.** A laboratory finds aflatoxin above the limit in a maize lot that was already split and partly processed.

**On-chain.**

1. The laboratory (trusted issuer for `LAB:AFLATOXIN`) attests the result: `attest(id, LAB:AFLATOXIN, hash(report), 0)`.
2. The platform retires the lot: `setBatchStatus(id, 255, ref("RECALL-2026-07"))`; transfers stop immediately (`ARexBatchRetired`), burns (destruction) remain possible.
3. Forward tracing: every `BatchTransformed` whose `inputIds` contain `id` yields the children; recursively, the affected feed and food lots. Backward tracing: `parentsOf`.
4. The regulator receives the list of affected ids and holders from the event log — the 24-hour requirement is met by an indexer query, not by a records search.

**Why it matters.** Recall scope is a graph query over standardized events, which is what FSMA 204's transformation CTE was designed to make possible.

## What these scenarios have in common

- Four interfaces, three reference hooks and the attestation registry cover all six; no scenario needed a change to the standard.
- Legal instruments (receipts, CPR-e, DDS, lab reports) are referenced and hashed, not re-implemented.
- Enforcement (freeze, forced transfer, retire) is present in every financing and compliance scenario and is always an event.
- Personal data never appears on-chain.


---

# 11. Implementation Guide


_What the implementation guide covers, step by step, and how to obtain it._

## What the guide is

The guide takes an engineer from a clean checkout to a deployed batch token with rules and attestations. Every code block in it is copied from a test of the reference implementation and runs in continuous integration, so the guide cannot drift from the code. This page describes its steps; the guide itself, with its code, is part of early access.

## Steps it covers

| Step | What the engineer does |
|---|---|
| Set up and deploy | Installs the reference implementation and deploys the token and the attestation registry. |
| Roles | Gives issuing, processing, enforcement and administration to separate accounts. |
| Create and read a batch | Records a lot with its commodity, unit, dates, origin reference and document commitment. |
| Transfer | Moves units and asks the token why a refused transfer was refused. |
| Lineage | Splits, merges and processes lots, keeping each parent linked. |
| Status and metadata | Moves a lot through its lifecycle and updates its document commitment. |
| Rules | Registers rule contracts in order and checks their effect. |
| Attestations | Trusts issuers per topic and records certificates per lot. |
| Eligibility and enforcement | Restricts accounts, freezes amounts and carries out forced transfers. |
| Retire, index and upgrade | Closes a lot for good, rebuilds the lineage from events, and upgrades the token after validating it. |

## Going to production

The guide ends with a checklist: a reproducible build with tests passing; roles redistributed and the deployer's renounced; rules audited and their order published; the metadata schema version and status table published, with no personal data in the origin reference; legal instruments referenced and the classification of the offer settled with counsel; a third-party audit of the token, the attestation registry and every registered rule; and an upgrade rehearsed before it is needed.

## Access

Companies that want to implement A-REX, issue batches with it or audit it request the guide, with the normative text, on [Request early access](/access).


---

# 12. Interoperability


_How an A-REX token fits the existing world: Ethereum token standards, compliance engines, traceability data standards, legal-document registries, identity systems, cross-chain infrastructure and existing farm systems._

## With the Ethereum ecosystem

An A-REX Core token **is** an ERC-1155 token. Wallets, explorers, marketplaces and indexers that understand ERC-1155 work unchanged: balances, batch transfers, `uri(id)`, approvals, safe-transfer receiver checks. A-REX adds events and views; it removes nothing.

An A-REX Core token **is** an ERC-7943 multi-token. Compliance engines and custody platforms that target ERC-7943 (Chainlink's Automated Compliance Engine has demonstrated compatibility; issuance platforms in the ERC-7943 coalition are adopting it) recognize `canTransfer`, `forcedTransfer`, `setFrozenTokens`, `canSend` and `canReceive` without adaptation.

| Standard | Relationship |
|---|---|
| ERC-1155 | base; A-REX Core is an extension |
| ERC-165 | interface discovery; five ids published |
| ERC-7943 | required; enforcement surface adopted verbatim |
| ERC-3643 | compatible by adaptation: an ERC-3643 compliance module can be wrapped as an `IARexHook` (one call to `moduleCheck`); an A-REX hook can be exposed to an ERC-3643 token. Identity registries used with ERC-3643 (ONCHAINID) plug in as an eligibility hook. |
| ERC-735 / ONCHAINID claims | claim topics map directly to `IARexAttest` topics (`bytes32(uint256 topic)`) |
| Ethereum Attestation Service | schema UIDs are valid `IARexAttest` topics; an EAS-backed attestation registry can implement `IARexAttest` by delegating `isAttested` |
| ERC-7201 | storage layout of the reference implementation |
| ERC-7573, holds/escrow patterns | delivery-versus-payment and escrow are hooks or companion contracts; the standard does not prescribe settlement |
| ERC-7802 / Chainlink CCIP | cross-chain mint/burn adapters can wrap the token; lineage stays on the origin chain, references travel |

## With traceability data standards

### GS1 EPCIS 2.0 / CBV

| On-chain | EPCIS 2.0 |
|---|---|
| `BatchCreated` | `ObjectEvent` ADD, `bizStep = commissioning`/`harvesting`, `quantityList` (unit from Rec. 20) |
| `TransferSingle` / `TransferBatch` | `ObjectEvent` OBSERVE with `bizStep = shipping`/`receiving`; source/destination from `from`/`to` |
| `BatchTransformed` | `TransformationEvent` (`inputQuantityList`, `outputQuantityList`, `transformationID`) |
| `BatchStatusChanged` | `ObjectEvent` with `disposition` |
| `Attested` | certification / sensor element or a dedicated `ObjectEvent` |
| metadata `gs1.*` | GTIN, LGTIN, SSCC, GLN, Digital Link |

The metadata schema uses EPCIS/CBV names on purpose so that an exporter maps fields, not concepts.

### FSMA 204

Key data elements are metadata fields (`traceabilityLotCode`, GLN, dates, quantities) and events; the transformation CTE is `BatchTransformed`; the 24-hour record request is an indexer query. See the regulatory chapter for the full mapping.

### Codex, ISO 22000, GLOBALG.A.P., organic schemes

All are attestation topics. The standard does not enumerate them: `keccak256("GLOBALGAP:IFA")`, `keccak256("AREX:CERT:ORGANIC_EU")`, `keccak256("CODEX:MRL")` are conventions the issuer publishes with its metadata schema.

## With legal-document registries

A-REX tokens **reference** legal instruments; they do not replace them until a jurisdiction recognizes the token itself:

| Instrument | Where it lives | How the token references it |
|---|---|---|
| U.S. electronic warehouse receipt (7 CFR 869) | USDA-authorized EWR provider | `documents[].registry`, `originRef` |
| Brazilian CPR-e, CDA/WA | Central Bank-authorized registrars | `documents[].registryId`; pre-harvest batch with `producedAt == 0` |
| Argentine certificado de depósito / warrant (Law 9.643) | warehouse | `originRef` hash |
| Electronic bill of lading (MLETR jurisdictions) | eBL platform | document hash; in MLETR jurisdictions the token can itself satisfy exclusive control |
| EUDR due-diligence statement | EU Information System | `origin.eudr.ddsReference`, attestation `EUDR:DDS` |

## With identity systems

The token asks only `canSend(account)` / `canReceive(account)`. Behind that question can sit:

- an allow/block list maintained by the issuer (`EligibilityHook`);
- an ONCHAINID identity registry with claim topics (the ERC-3643 model);
- Ethereum Attestation Service attestations on the account;
- verifiable credentials verified off-chain and reflected on-chain by a relayer;
- a national e-ID scheme (eIDAS 2.0 wallet in the EU) through a credential verifier.

None of them is part of the standard, which is why an issuer in Brazil and one in Germany can use different providers and remain interoperable.

## Cross-chain deployment

The standard is chain-agnostic. Practical patterns:

- **Single home chain per issuer** (recommended): lineage and enforcement stay coherent; other chains hold wrapped representations via ERC-7802-style adapters or CCIP.
- **Permissioned EVM chain** for issuers whose data-protection authority or anchor institution requires it; the EDPB expressly favours permissioned designs. Same bytecode.
- **Mirrors for liquidity**: a batch id on the home chain, an ERC-20 wrapper elsewhere; the wrapper must honour `canTransfer` of the home token or restrict itself to eligible holders.

Lineage never crosses chains; references do.

## With farm management and ERP systems

Integration points are the same as for any ERC-1155 token plus the batch views:

- **Write path**: an origination service holds `ISSUER_ROLE` and calls `createBatch` from ERP events (weighbridge ticket, receipt issuance); `setBatchStatus`/`setBatchMetadata` from warehouse events; `transform` from processing orders.
- **Read path**: an indexer materializes batches, lineage, attestations and enforcement events into the ERP's traceability tables; EPCIS export for partners and regulators.
- **Pre-flight**: `transferCheck` lets an ERP explain a refusal to an operator before submitting a transaction.
- **Identifiers**: GS1 keys in metadata bridge to existing EDI and EPCIS repositories; UN/CEFACT units are already in ERPs.

## Compatibility matrix

| Capability | Status |
|---|---|
| ERC-1155 wallets / marketplaces | native |
| ERC-7943 compliance tooling | native |
| ERC-3643 compliance modules | via hook adapter |
| ERC-735 / EAS attestations | topic mapping |
| EPCIS 2.0 export | field mapping in schema; indexer-side |
| Permissioned EVM | same bytecode |
| Cross-chain | wrappers; lineage stays home |


---

# 13. Performance Analysis


_Measured gas of the reference implementation with zero, one and two hooks; what drives the cost; and deployment guidance._

## Method

Numbers below are from `scripts/gas-report-standard.js` run on Hardhat's in-process network against the compiled reference implementation (solc 0.8.22, viaIR, `optimizer.runs = 1` for `ARexToken`), September 2026. "Warm" means the same sender/receiver/id pair as the previous transfer (storage slots already touched in the block). Hooks: `EligibilityHook` (CHECK + ELIGIBILITY) and `ExpiryHook` (CHECK). Reproduce with:

```bash
npx hardhat run scripts/gas-report-standard.js
```

## Results

```mermaid
xychart-beta
    title "Warm transfer gas by number of hooks (thousands)"
    x-axis ["no hooks", "Eligibility", "Eligibility + Expiry"]
    y-axis "gas (k)" 0 --> 140
    bar [66.8, 91.2, 119.6]
```

_Cost grows linearly with the number of hooks: each one is one external `check` call per id, plus `canSend` and `canReceive` for an eligibility hook. The table gives every operation._

| Operation | 0 hooks | 1 hook | 2 hooks |
|---|---:|---:|---:|
| `createBatch` (new id, mint 1000) | 264,096 | 283,831 | 299,396 |
| `safeTransferFrom` (first, cold) | 80,687 | 108,266 | 136,682 |
| `safeTransferFrom` (warm) | 66,790 | 91,166 | 119,582 |
| `transform` split 1 → 2 (two new ids) | 564,422 | 595,707 | 636,858 |
| `setFrozenTokens` | 54,188 | 54,188 | 54,188 |
| `forcedTransfer` | 80,152 | 89,909 | 99,569 |
| `burn` | 66,621 | 83,001 | 93,395 |

Warm transfer with exactly one hook of each kind (marginal cost of the rule):

```mermaid
xychart-beta horizontal
    title "Marginal gas of one hook on a warm transfer (thousands)"
    x-axis ["DeliveryHook", "Traceability (emit)", "EligibilityHook", "ExpiryHook", "SeasonalHook", "PerishabilityHook"]
    y-axis "gas added (k)" 0 --> 35
    bar [12.3, 17.4, 24.4, 25.2, 27.5, 31.0]
```

_`TraceabilityHook` in persisted mode adds 184.5k and is left out of the chart for scale._

| Hook | Gas | Δ vs. no hook |
|---|---:|---:|
| EligibilityHook | 91,166 | +24,376 |
| ExpiryHook | 92,023 | +25,233 |
| SeasonalHook | 94,324 | +27,534 |
| PerishabilityHook | 97,813 | +31,023 |
| DeliveryHook (no active delivery) | 79,076 | +12,286 |
| TraceabilityHook, emit-only | 84,152 | +17,362 |
| TraceabilityHook, persisted | 251,273 | +184,483 |

## What drives the cost

- **A transfer with no hooks costs ~67k warm**, i.e. ERC-1155 plus supply tracking plus the batch existence/status/frozen reads and the pipeline bookkeeping (data stash, lock). This is the floor.
- **Each hook adds roughly 25–30k** on a transfer: one `check` call (view, cross-contract) plus, for eligibility hooks, `canSend` and `canReceive` calls. Cost is linear in the number of hooks and in the number of ids in a batch transfer. Probing every rule contract for every capability with `supportsInterface` before calling it would add several static calls per id; that overhead does not exist because flags are cached at registration.
- **`createBatch` is dominated by storage**: the `Batch` struct (six words plus a string) and the ERC-1155 balance and supply slots. It is a one-time cost per lot.
- **`transform` creates new ids**: a split into two pays two batch records plus two mints plus one burn, plus hook calls on every leg (`OP_TRANSFORM`). A split into *n* is roughly `n × createBatch` plus a burn; merging *n* into one is roughly `n` burns plus one createBatch.
- **Enforcement is cheap**: freezing is one slot; a forced transfer costs what a transfer costs plus the unfreeze write and the event.
- **`transferCheck` / `canTransfer`** are views: free off-chain, and the same code path as the transaction.

## What the design buys

| | Capability-probe design | A-REX Core (`ARexToken`) |
|---|---|---|
| Transfer with *n* rule contracts | ids × modules × (`supportsInterface` probes + hook call) before any logic runs | ids × hooks × 1 call (+2 for eligibility hooks); flags cached at registration |
| Rejection | string revert (copied to memory, not indexable) | custom error with hook address and `bytes32` code |
| Lineage | not available | ~280k per output batch |
| Freeze / forced transfer | not available | 54k / 80k |

The left column describes the design A-REX Core replaces (ADR-004, ADR-005); only the right column is measured.

## Deployment guidance

- **Cost in money** is `gas × gas price × token price`, and the last two change by orders of magnitude between chains and days. As an illustration only, at 0.01 gwei and 3,000 USD per ETH a warm transfer with two hooks (119,582 gas) costs about 0.0036 USD and a `createBatch` (264,096 gas) about 0.008 USD; at 20 gwei on Ethereum mainnet the same operations cost about 7.2 and 15.8 USD. Measure on the target chain before committing to a unit economics model.
- **Batch transfers**: `safeBatchTransferFrom` amortizes fixed costs; hook cost still scales with the number of ids.
- **Hook ordering**: place high-rejection, cheap hooks first; a rejection stops the pipeline before more expensive hooks run.
- **Number of hooks**: three to five covers most issuers; each additional hook is a measurable per-transfer cost and a governance surface.
- **Metadata**: keep `uri` short (a CID or a Digital Link); the string is stored on-chain.
- **Off-chain reads**: use `transferCheck` before submitting; a reverted transaction still costs gas.

## Throughput

The token itself is not the bottleneck; the chain is. A single transfer is one transaction; a transformation with *n* outputs is one transaction with *n* mints. Indexing lineage requires reading `BatchTransformed` events, which are emitted once per operation with full quantity lists, so an indexer does not need to reconstruct anything from per-transfer events.

## Contract size

`ARexToken` deploys at 24,136 bytes (limit 24,576), compiled with `optimizer.runs = 1`. The other contracts are small: `ARexAttestations` 2,708; hooks between 1,358 (`ExpiryHook`) and 6,215 (`DeliveryHook`), `TraceabilityHook` 4,076; extensions between 3,716 and 4,588. Adding functionality to the token itself is size-constrained by design — that is what hooks and companion contracts are for.


---

# 14. Future Developments


_The roadmap from a frozen alpha interface to a de-facto and then an official standard, and the technical work that accompanies it. Dates are targets, not promises._

## Principle

The interfaces are what gets standardized; everything else can evolve. The roadmap therefore has two tracks: **standardization** (make the interfaces trusted and adopted) and **implementation** (make the reference and the modules better without touching the interfaces).

## Standardization track

| Phase | Target | Exit criteria |
|---|---|---|
| **0 · Alpha freeze** (now) | v2.0.0-alpha interfaces published; reference implementation with all domain hooks and extensions; CI; specification in ERC format; system design document, decision records and audit package | no interface change without a major version |
| **1 · Production anchor** (6–12 months) | one real deployment (cooperative, elevator or exporter) with real lots on an L2 or a permissioned chain | six months of operation; public metrics: batches, transformations, forced transfers executed, time to answer a traceability request; third-party audit published |
| **2 · Community** (in parallel) | Ethereum Magicians thread; coalition of independent hook implementers; bidirectional ERC-3643 compliance adapter | three independent `IARexHook` implementations outside this repository; two independent conformant tokens |
| **3 · Submission** | Draft ERC in `ethereum/ERCs` containing only `standard/AREX-CORE.md` (layers 1–3; ERC-7943 referenced, not copied) | editors' acceptance; Last Call without blocking objections |
| **4 · Neutral governance** (year 2) | working group or association independent of the original authors; liaison with ISO TC 307 (the Spanish initiative on ERC-3643) and GS1 | governance documents adopted; specification maintained outside a single company |

Why not submit now: ERC-3643 was in production for three years before its EIP; ERC-7943 reached Final in eight months *because* its coalition already used it. An ERC freezes what it standardizes, and the interfaces deserve one production cycle before they are frozen for everyone.

## Implementation track

### Domain modules: ported (September 2026)

| Module | Now | Status |
|---|---|---|
| Perishability | `PerishabilityHook` (linear, exponential, step; per-commodity and per-batch config) + `ExpiryHook` | done |
| Seasonal | `SeasonalHook` | done |
| Delivery | `DeliveryHook` (state machine, cold chain, disputes, O(1) unit lock, settlement via transfer data) | done |
| Traceability | `TraceabilityHook` (EPCIS vocabulary; emit-only or persisted) | done |
| Sanctions, compliance | `EligibilityHook` (sanctions with source and TTL) | done |
| Transfer limits / quotas | not shipped; the *Hook Development* guide shows a bounded quota hook pattern | open (community) |
| Oracle | `CommodityPriceOracle` (rounds by number, quorum, median) | done |
| Carbon | `CarbonImmobilizationWrapper` (registry-immobilised credits; attestation; no issuance) | done |
| Insurance | `ParametricInsurance` (attestation-triggered) | done |

Remaining implementation work on these components is optimisation and production hardening, not design.

### Settlement and financing primitives

- **Holds and escrow** (delivery-versus-payment): a hook plus a companion implementing conditional release; alignment with ERC-7573 where a payment leg is on-chain.
- **Pledge workflow**: a small contract that drives `setFrozenTokens` / `forcedTransfer` from a pledge agreement hash, so that lenders operate the enforcement role through an auditable procedure rather than raw calls.

### Privacy

- **Selective disclosure of quality data**: zero-knowledge proofs that a measurement in the metadata document is within a limit (moisture, aflatoxin, residues) without revealing the value; the proof becomes an attestation.
- **Restricted-data access control**: reference implementation of the `restricted` pointer with capability tokens for buyers, certifiers and regulators.

### Identity and attestations

- EAS-backed implementation of `IARexAttest`.
- Eligibility hook backed by ONCHAINID claims and by verifiable credentials (eIDAS 2.0 wallets).

### Cross-chain

- ERC-7802 / CCIP wrapper reference; lineage remains on the home chain.

### Tooling

- EPCIS 2.0 exporter over the event log.
- JSON Schema validator and RFC 8785 canonicalizer for metadata.
- Subgraph / indexer templates for batches, lineage, attestations and enforcement.
- Formal verification of the transfer pipeline invariants (supply conservation, terminal status, no re-entrance); a seeded randomized invariant test already exercises them (`test/standard/Invariants.test.js`).

## Research questions

- Whether `status` transitions should be expressible as an on-chain table (issuer-defined automaton) without bloating the standard.
- Whether a standard *account eligibility* interface separate from hooks would ease integration with compliance engines, or whether the hook conjunction is enough.
- Mass-balance rules for processing (yield bounds per commodity pair) as hooks, and their interaction with legitimate losses.
- Reconciliation between on-chain lineage and physical commingling in silos, where "which kilogram" is legally a fungible claim.

## What will not change

- The four interfaces, without a major version and a migration note.
- The rule that modules are demonstrations, not standard.
- The rule that personal data stays off-chain.
- The rule that authority comes from roles, not balances.


---

# 15. Conclusion


_What A-REX Core is, what it proved, what it still has to prove, and how to take part._

## What it is

A-REX Core is the smallest set of interfaces that lets an ERC-1155 token id be an agricultural batch: a commodity and a unit, a production and an expiry time, an origin reference, a metadata commitment, a role-controlled lifecycle, and — through `transform` — a provenance graph that survives splitting, merging and processing. It adopts ERC-7943 for enforcement, defines one ordered hook pipeline with machine-readable rejection codes, and records attestations per batch with trusted issuers per topic. Everything else is outside the standard by design.

## What the redesign established

- **A standard and a product are different things.** Mixing a farm registry, an identity system, enumerations of crops and grades, and a valuation formula into "the standard" was the first design we rejected. None of it survived the question *would an independent implementer accept this constraint?* The interfaces that did survive fit in six files.
- **Lineage is the missing primitive.** Traceability regulation and EPCIS are built around transformation events; a token that cannot become another token cannot serve a recall, a mass-balance audit or an FSMA transformation record. `transform` is now the only way to create a batch from a batch.
- **Enforcement is not optional.** Liens, warrants, seizures and recalls are ordinary events in agriculture; ERC-7943 gives them a standard shape and a standard audit trail.
- **Legal neutrality is the safe position.** The token does not decide whether it is a security or a commodity; it makes every classification implementable and keeps personal data off-chain in line with the EDPB's 2026 guidance.
- **Reference implementations must be reproducible.** Pinned dependencies, a committed lockfile, continuous integration, and a token under the EIP-170 limit are prerequisites for anyone to try the standard.

## What it has not yet proved

- That real lots, real transformations and real enforcement actions run on it for months without the interfaces needing to change.
- That independent teams implement hooks and tokens against the interfaces without help from the authors.
- That the reference implementation withstands a third-party audit.

Until those three are true, A-REX is a well-defined proposal with a working implementation — not a standard. The roadmap does not skip that stage, because the standards that are used today (ERC-3643, ERC-7943) did not.

## How to take part

- **Issuers and platforms**: deploy the reference stack on a testnet with your own lots; report what the interfaces could not express.
- **Hook authors**: write the rule you need (seasonal windows, quotas, custody, documents) against `IARexHook` and publish it; three independent hooks are an explicit milestone.
- **Certifiers, laboratories, registries**: become trusted issuers for your topics; attestations are how your work reaches buyers and regulators on-chain.
- **Compliance and identity providers**: expose your engine as an eligibility hook; ERC-3643 and ERC-7943 tooling adapts in a few lines.
- **Counsel and regulators**: review the regulatory chapter and the enforcement model; tell us where a jurisdiction needs something the interfaces do not provide.
- **Auditors and researchers**: the transfer pipeline invariants are small and stated; break them.

The written terms say the specification will be published under CC0 and the code under MIT. Until that publication, the text stays confidential under the early-access terms, and this site withholds it.


---

# 16. Appendices


## Appendix A: Interface reference

The interface listing stays in the standard repository.

### What stays there

The specification, the interface sources, and the batch metadata schema.

### What a public reader can know

A-REX Core extends a multi-token base with the identity of a lot, lineage when a lot is split or processed, an enforcement surface, one rule pipeline, and attestations from trusted issuers.

### What this chapter withholds

Signatures, error names, storage layouts, and the schema.

### How to request the text

Companies that want to implement A-REX, issue batches with it, or audit it use the early-access page. Each request is reviewed by hand. Approved readers receive read-only access to the standard repository and the reference implementation.

### Terms already written

Access is for evaluation, implementation, and feedback. The material stays confidential until it is published. The written terms say the standard will be published under CC0 and that early access grants no exclusivity.

### Scope of the pages that follow

The glossary, the bibliography, and the questions that follow explain terms. They are the public vocabulary.

### Documents named, not copied

The standard section of this site lists the same documents.

### Boundary

A page that would let a reader copy an interface stays out of this chapter.
## Appendix B: Glossary

| Term | Meaning |
|---|---|
| **Batch** | An ERC-1155 token id with a `Batch` record: a lot of one commodity in one unit with shared origin and production time. |
| **Re-batch** | A `transform` whose outputs have the same commodity and unit as the inputs and whose quantities are conserved (split, merge). Open to holders in the reference implementation. |
| **Processing** | A `transform` that changes commodity, unit or quantity. Requires `TRANSFORMER_ROLE` in the reference implementation. |
| **Lineage** | The graph formed by `BatchTransformed` events and `parentsOf`. |
| **Hook** | A contract implementing `IARexHook`, registered on a token, evaluated in order on every operation. |
| **Rejection code** | A `bytes32` returned by a hook's `check`; `0` means allowed; convention `keccak256("NAMESPACE:NAME")`. |
| **Eligibility** | Account-level permission to send or receive, answered by hooks flagged `HOOK_ELIGIBILITY`; exposed as ERC-7943 `canSend`/`canReceive`. |
| **Frozen balance** | Units an account holds but cannot move (`setFrozenTokens`); may exceed the balance. |
| **Forced transfer** | Movement of units by `ENFORCER_ROLE` without the holder's consent (ERC-7943). |
| **Attestation** | `(batch, topic) → (issuer, reference, validity)` recorded by a trusted issuer for that topic. |
| **Topic** | A `bytes32` identifying the subject of an attestation; open; maps to ERC-735 claim topics and EAS schema ids. |
| **Origin reference** | `originRef`: a hash or reference to origin evidence; never coordinates. |
| **Metadata commitment** | `metadataHash`, keccak256 of the canonical off-chain document at `uri`. |
| **Status** | `uint8` lifecycle value; `0` active, `255` retired (terminal); `1..254` issuer-defined. |
| **CTE / KDE** | Critical tracking event / key data element (FSMA 204). |
| **DDS** | Due-diligence statement (EUDR). |
| **EPCIS** | GS1 Electronic Product Code Information Services, the event vocabulary for traceability (version 2.0). |
| **CPR / CPR-e** | Cédula de Produto Rural, Brazil's crop receivable; electronic form registered with authorized entities. |
| **EWR** | Electronic warehouse receipt under the U.S. Warehouse Act. |
| **MLETR** | UNCITRAL Model Law on Electronic Transferable Records. |
| **ERC-7943 (uRWA)** | Universal Real World Asset interface: freeze, forced transfer, eligibility; Final May 2026. |
| **ERC-3643 (T-REX)** | Permissioned token standard for securities on ERC-20; Final December 2023. |
| **ERC-7201** | Namespaced storage layout for upgradeable contracts. |

## Appendix C: Bibliography

### Standards and specifications

- Radomski, W. et al. "EIP-1155: Multi Token Standard." Ethereum Improvement Proposals, 2018.
- Vogelsteller, F., Buterin, V. "EIP-20: Token Standard." 2015.
- "ERC-165: Standard Interface Detection." 2018.
- "ERC-3643: T-REX — Token for Regulated EXchanges." Final, 15 December 2023. https://eips.ethereum.org/EIPS/eip-3643
- "ERC-7943: uRWA — Universal Real World Asset Interface." Final, 27 May 2026. https://eips.ethereum.org/EIPS/eip-7943
- "ERC-7201: Namespaced Storage Layout." 2023.
- "ERC-735: Claim Holder." 2017 (draft).
- Ethereum Attestation Service documentation.
- GS1. "EPCIS and CBV Standard 2.0." 2022. GS1 US. "EPCIS Recommendations for FSMA 204 Critical Tracking Events." 2024.
- UN/CEFACT. "Recommendation No. 20: Codes for Units of Measure Used in International Trade."
- IETF RFC 8785. "JSON Canonicalization Scheme (JCS)." 2020.
- OpenZeppelin Contracts 5.x documentation; OpenZeppelin and T-REX Network partnership announcement, July 2026.

### Regulation and law

- FDA. "Requirements for Additional Traceability Records for Certain Foods." Final rule, Federal Register 87(219), 2022; "Compliance Date Extension," Federal Register, 7 August 2025.
- Regulation (EU) 2023/1115 (Deforestation); Regulation (EU) 2025/2650 (amendment); Council of the EU press release, 18 December 2025.
- Regulation (EU) 2023/1114 (MiCA); ESMA Guidelines on the qualification of crypto-assets as financial instruments, December 2024.
- European Data Protection Board. "Guidelines 02/2025 on processing of personal data through blockchain technologies," version 2.0, 7 July 2026.
- SEC. Release No. 33-11412, 17 March 2026. *SEC v. W.J. Howey Co.*, 328 U.S. 293 (1946).
- GENIUS Act, Public Law 119-27 (2025); implementing regulations, Federal Register, 18 August 2026.
- Uniform Commercial Code, 2022 Amendments, Article 12 (Controllable Electronic Records).
- U.S. Warehouse Act; 7 CFR Part 869 (Electronic Warehouse Receipts).
- UNCITRAL. "Model Law on Electronic Transferable Records." 2017. United Kingdom, Electronic Trade Documents Act 2023.
- Comisión Nacional de Valores (Argentina). Resolución General 1150/2026. Ley 9.643 (warrants).
- Brazil. Lei 8.929/1994, Lei 13.986/2020 (CPR); Lei 11.076/2004 (CDA/WA); CVM Resolução 88 and Consulta Pública SDM 05/2025.
- Verra. "Verra Addresses Crypto Instruments and Tokens." 2022; VCS Program Guide.
- Directive (EU) 2024/825 (empowering consumers for the green transition).

### Research and industry

- Zhang, P., Schmidt, D. C. "Blockchain Applications in Food Supply Chain Management: A Systematic Review." *Journal of Food Engineering*, 279, 2020.
- Caro, M. P. et al. "Blockchain-based Traceability in Agri-Food Supply Chain Management." IEEE, 2018.
- FAO. "The State of Food and Agriculture." 2023.
- World Bank. "Future of Food: Harnessing Digital Technologies to Improve Food System Outcomes." 2022.
- ERC3643 Association. "History of ERC-3643"; ISO TC 307 standardization initiative announcement.
- Chainlink. "Automated Compliance Engine (ACE): Technical Overview." 2025–2026.

## Appendix D: Templates

Worked examples of a hook, a deployment, and a metadata document stay in the repositories.

### Why they stay there

Those examples are enough to copy an implementation. This public chapter explains terms and consequences.

### Where they live

They ship with the standard repository and the reference implementation, for readers whose early-access request has been approved.
## Appendix E: FAQ

**Is A-REX an ERC?** Not yet. The specification is written in ERC format and will be submitted after a production deployment, independent implementations and an audit. No number has been assigned; names in the code do not use the `ERC` prefix.

**Do I have to use ARexToken?** The reference is one implementation. The interfaces belong to the normative text.

**Do I have to use the reference hooks?** They are demonstrations. Readers with access can read them in the reference repository.

**Can a hook block a forced transfer?** It can return a code for `OP_FORCED_TRANSFER`, and the token will revert. Reference hooks do not; a hook that governs enforcement (e.g. requiring an order reference) may.

**Where do coordinates go?** In restricted off-chain storage referenced from metadata, never on-chain.

**How do I represent a future harvest?** `producedAt = 0`; gate transfers with `ExpiryHook(allowPreHarvestTransfers)`.

**Is quantity conserved in `transform`?** Not by the standard; the reference allows any holder to re-batch when it is conserved and requires `TRANSFORMER_ROLE` otherwise.

**Is the token a security?** The standard does not decide. The offer does. Ask counsel; the enforcement surface is there whatever the answer.