Whitepaper · 03
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/ |