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.
Versions
The standard and its reference implementation have separate version numbers. A name such as "alpha.10" on its own is a release of the reference implementation, not of the standard.
| What | Version | What it is |
|---|---|---|
| Standard (A-REX Core) | 2.1.0-alpha.2 | The specification and its interfaces. Text proposed after this release is marked Proposed and is not part of it. |
| Batch metadata schema | 1.2.0 released, 1.4.0 Proposed | The off-chain lot document committed by the token. |
| Reference implementation | 2.0.0-alpha.10 | The MIT contracts that implement standard 2.1.0-alpha.2. |
| Conformance suite | 1.1.0 | The clause-by-clause tests any implementation runs; it ships with the reference implementation. |
The numbers count different things: the standard counts changes to the specification, the implementation counts its own releases. Both started at 2.0.0; the standard's 2.1 changed no interface, event or requirement, so a 2.0 implementation implements it.
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 89 clauses, 75 at MUST level and 14 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; under the same rule, attesting again never replaces another issuer's record nor revives a revoked one. |
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-024 (Proposed): places as ISO codes | From metadata schema 1.3.0, origin.region is an ISO 3166-2 subdivision code such as BR-MG (the country's ISO 3166-1 code where none applies), checked by pattern; a name for people goes in the optional origin.regionName. Documents of earlier versions stay valid. |
| ADR-025 (Proposed): hooks bound to one token | A hook may be bound to one token when it is deployed, if it makes that token public and refuses every call from another address with a named error; hooks that are not bound keep serving whichever token calls them. The reference traceability hook is bound. |
| 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. |
| ADR-023 (Proposed): several values in one transfer's data | A transfer's data may be a tagged envelope of up to 8 entries, each a key and a value, so that each rule reads only its own key; 32-byte data keeps its earlier meaning. It adds no requirement. |
| ADR-026 (Proposed): networks | A-REX Core stays an EVM standard: any EVM network at the paris level or later can host a conformant token, networks are named by CAIP-2 ids and the standard keeps no list of them; the evidence around a token can be anchored on any network. |
| Metadata schema 1.4.0 (Proposed) | An upstream entry may give the CAIP-2 network of the batch it names; a batch on a network that is not EVM is named by its CAIP-19 asset. |
Rule descriptor arex.module/1 (informative, Proposed) | A JSON document a rule or add-on publishes so that consumers integrate it without custom code. |
Formats arex.vocab/1, arex.anchor-proof/1 and arex.report-sources/1 (informative, Proposed) | An organisation's own vocabulary of field work, processes and stages; proofs that a record existed unchanged, anchored on any network; the sources of a report's numbers, one line per record. |
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). Metadata schemas 1.3.0 and 1.4.0 are Proposed and not released. 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.