Standard
A-REX Core — the standard
What the standard defines, what a conforming token does, how it changes and how it becomes an ERC. The normative text is shared under early access.
Status
Draft 2.1.0-alpha.2, before submission, with batch metadata schema 1.2.0. The text is written in the format of an Ethereum Request for Comments so that it can go to ethereum/ERCs once independent implementers have used the interfaces in production. It will be published under CC0; the reference implementation is MIT. Until two independent implementers exist, accepted changes are marked provisional.
What it defines
A-REX Core is a small extension of ERC-1155 and ERC-7943. A batch (a lot of a physical commodity, or the right to a future lot) is one ERC-1155 token id. The standard adds four layers to it:
| Layer | Interface | What it covers | Required |
|---|---|---|---|
| 0 | ERC-1155, ERC-165, IERC7943MultiToken | balances and batch transfers; freeze, forced transfer, account eligibility | yes |
| 1 | IARexBatch | the batch record: open commodity and unit codes, production and expiry times, an origin reference, a commitment to an off-chain document, a lifecycle status, and lineage when a lot is split, merged or processed | yes |
| 2 | IARexHook, IARexHookManager | one ordered pipeline of external rule contracts; a rule answers with a machine-readable reason | yes |
| 3 | IARexAttest | certifications, inspections and declarations per batch and topic, from issuers trusted for that topic | recommended, in the token or a companion contract |
What a conforming token does
- It behaves as an ordinary ERC-1155 token, so wallets, marketplaces and indexers work unchanged.
- It exposes the ERC-7943 enforcement surface: a lot can be frozen or moved under a court order, a lien or a recall, and every such action is visible on chain.
- It keeps a record for every batch and records each split, merge or processing step, so the parents of a lot can always be traced.
- It runs every transfer through its rule pipeline and can say why a transfer is refused.
- It declares the interfaces it implements, so tools can detect it.
A rule contract (a hook) conforms when it implements IARexHook. One rule contract can serve many tokens.
How conformance is checked
The reference implementation ships a conformance suite that does not depend on it: an implementation under test is reached only through the standard interfaces and a small adapter its authors write. Each test carries the clause it checks; there are 85 clauses, 74 at MUST level and 11 at SHOULD level. A run ends with a verdict, and a conformance claim must explain every clause it skipped. Clauses that cannot be observed on chain, such as the rule that the origin reference holds no personal data, are left to review.
Proposed and not released
These changes are written down and open for review. None of them is accepted: each waits for the confirmation of two independent implementers, and the MUST-level ones follow the rule for major changes.
| Proposal | What it would change |
|---|---|
| ADR-019 (Proposed): capabilities in the standard, policy in profiles | The standard fixes roles, events, data shapes, pause and revocation semantics and privacy rules; who may use a capability, whether it is on and which lists or authorities apply move to versioned policy profiles per jurisdiction and organization. It brings two clarifications: the origin reference MUST NOT be derived from location (no hash or encoding of coordinates or plot geometry); and the issuer of an attestation, or a revoker it delegated, revokes it, while an administrative role SHOULD NOT revoke an attestation it did not issue in 2.x and MUST NOT from 3.0, so that tokens already deployed stay conformant. |
ADR-017 (Proposed): extensions in the metadata | Metadata schema 1.3.0 would add an optional extensions object, one entry per rule, validated by the schema fragment of the rule's descriptor. |
| ADR-018 (Proposed): declared carbon footprint | A batch may carry a product carbon footprint declared by a named third party, copied from PACT 3.0.3 into extensions.pact_pcf with a verification status; never calculated, summed or passed on to other batches. |
| ADR-020, ADR-021, ADR-022 (Proposed): reference adapters | ERC-3643 tooling reads each lot through a view that cannot allow or refuse anything; ONCHAINID claims valid while A-REX trusts their signer; an EAS mirror of live certificates and lot records. Informative: they add no requirement. |
Rule descriptor arex.module/1 (informative, Proposed) | A JSON document a rule or add-on publishes so that consumers integrate it without custom code. |
The informative mappings to GS1 EPCIS 2.0, the UN Transparency Protocol 0.7.0, PACT 3.0.3, ERC-3643 and the Ethereum Attestation Service add no requirement; Interoperability summarizes them.
What it leaves out
There is no list of crops, grades or certifications: codes are open. There is no personal data on chain: no plot coordinates, names or identifiers of natural persons, and no value computed from a plot's location. No identity provider, oracle or registry is mandated, and no policy: who may enforce, pause or screen, and against which lists, is the issuer's decision under its jurisdiction. Decay curves, delivery workflows, carbon accounting and insurance are built as rules or companion contracts; the reference implementation demonstrates some of them, and conformance does not depend on them.
Versioning
The interfaces are versioned with the standard. A change to a function, an event or a requirement is a major version and comes with a migration note. Optional additions, such as new recommended codes or metadata fields, are a minor version: metadata schema 1.1.0 opened the commodity scheme, and schema 1.2.0 added references to batches of other tokens (upstream). Every document valid under an earlier schema stays valid. Until submission the interfaces may still change, always as a major version.
Path to an ERC
The text goes to ethereum/ERCs when four conditions hold: a production deployment with real batches has run for six months; at least three independent rule contracts exist; the reference implementation has a published third-party audit; and the interfaces have not changed for one release cycle. The roadmap is in Future Developments.
What this site withholds
The normative clauses, the interface sources and their identifiers, the rejection codes and the batch metadata schema stay in the standard repository while it is private. Companies that want to implement A-REX, issue batches with it or audit it request read access on Request early access. Each request is reviewed by hand; approved readers receive read-only access to the standard and to the reference implementation. The material stays confidential until it is published under CC0, and early access grants no exclusivity.