Whitepaper · 06
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.