Interoperability

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.

With traceability data standards

GS1 EPCIS 2.0 / CBV

The standard publishes an informative mapping, event by event:

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

Sensor readings are not part of the core. A delivery hook can record a temperature on-chain, and other measurements (humidity, CO₂ and O₂, shock, tilt, door, position) stay off-chain in the same sensorElementList, by their CBV type and Rec. 20 unit. The mapping describes a pattern for committing to them: per time window, the worst temperature reading with a reference that is a root over every reading of the window and the original message it came from, so an auditor can check a reading against the chain. The commitment proves what the recorder held at that block, not that the device measured correctly. Read points and business locations are site identifiers, never coordinates.

UN Transparency Protocol (UNTP 0.7.0)

An informative mapping turns a batch, its events and its attestations into UNTP 0.7.0 credentials, with the same identifiers as the EPCIS mapping so the two can be joined:

Credentials follow the W3C Verifiable Credentials Data Model 2.0 and are signed with VC-JOSE-COSE under the issuer's did:web; revocation uses a Bitstring Status List. A signed credential can also be anchored to its batch as an attestation whose reference is the credential's hash; the anchor proves the commitment, the signature proves the content. A credential carries only what the token or its metadata holds, and values that need a method (a footprint, a risk score) appear only when a named party declared them. The mapping states what it does not cover, starting with the EU Digital Product Passport: the ESPR does not apply to food, feed or live plants and animals, and A-REX makes no passport claim for them.

Where the goods were produced is given as codes: the country (ISO 3166-1), the first-level subdivision (ISO 3166-2, for example BR-MG), and a town's UN/LOCODE only for a business site such as a warehouse or a port, never for a farm. Sensor readings go in the sensorData of the delivery's MoveEvent; a passport carries at most a summary. From metadata schema 1.3.0 (ADR-024, Proposed), origin.region is always such a code.

Declared carbon footprints (PACT 3.0.3)

ADR-018 (Proposed) lets a batch carry a product carbon footprint that a third party calculated, under extensions.pact_pcf of the metadata document. The fragment follows the WBCSD PACT Technical Specifications 3.0.3 field by field: who declared it, the declared unit and reference period, the footprint with and without biogenic uptake, and a required verification status that names the verifier when the footprint is verified. It is copied, never calculated, summed or passed on to the batches made from the lot, and it is not a carbon credit (ADR-014). The mapping is a separate derivative of PACT and copies no PACT file.

Commodity and unit codes

A commodity code is keccak256("<SCHEME>:<CODE>") for any scheme: the Harmonized System (HS), national tariff nomenclatures (NCM in Mercosur, CN and TARIC in the EU, HTS in the United States, and others), FAO, CPC, GTIN, or the issuer's own. Since metadata schema 1.1.0 the scheme in the document is open too, so the metadata can mirror the on-chain code. Units are UN/CEFACT Recommendation 20 codes (KGM, TNE, LTR), the list EDI, EPCIS and customs already use.

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:

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.

With rule engines and platforms

A rule or an add-on can publish an arex.module/1 descriptor: a JSON document with its parameters, settings, required batch fields, certificate types, events, rejection codes and how its state carries over to a new version. A platform, wallet, indexer or auditor that reads descriptors integrates a new rule without custom code. The format is informative and Proposed; it becomes a recommended format once a second independent implementer consumes it. Revision 1.1 adds an optional, informative ops list of the operations a rule governs; absent means unknown, and it is never used for enforcement. Revision 1.2 adds the place type ref:site (the originRef its lots carry, never a location) and says that declared gas is measured with the settings filled (optional gas.setup). Revision 1.3 documents the fields its first consumer already writes (actions, the contract's own errors, measures, per-delivery data and a full form of events), all optional. Revision 1.4 adds what a platform needs to build forms for add-ons: more kinds of value, what reaches the ledger (never personal data), presentation and checks per field, read-only views, and how a record maps to EPCIS and a UNTP passport (a characteristic declared by its organisation, never a claim). Revision 1.5 salts every fingerprint: a descriptor that declares fingerprint: { "scheme": "salted-jcs/1" } records the hash of each value together with its own 32-byte salt, so short texts, numbers or plot outlines cannot be found by trying candidates. Revision 1.6 adds measures that are not totals (avg, min, max of a number field, never summed across groups or companies) and two ways to group them, by the party that created the lot (party) and by its site (site); the moisture add-on template of reference release 2.0.0-alpha.10 uses it for the average moisture at intake. Revision 1.7 lets a field's visibleWhen take the vocabulary descriptor's condition tree (all, any, not; at most 3 levels and 12 leaves) over the other fields of the form; the single condition of revision 1.4 stays valid, deprecated.

Organisations can publish their own field work types, process types and stage lists as arex.vocab/1 vocabulary definitions. Each one maps to one of 26 reference stage classes (for example drying or fermenting) and to a GS1 CBV business step. Their EPCIS events carry three layers: the CBV bizStep that any EPCIS system reads, the reference class (arex:stageClass) that lets two organisations with different names compare their records, and the organisation's own type, names and published values. In a UNTP passport the values are characteristics, never claims. A processed lot's metadata can name the process type and the run behind it in a process object, planned for metadata schema 1.4.0. Revision 1.1 adds an optional form layout (sections, widths, conditions) that only narrows what the fields accept. Revision 1.2 lets conditions use not, go 3 levels deep with up to 12 leaves, and read the record's context in codes (the crop as an EPPO code, days since planting, site kind, country, the HS heading of the product, the latest stage); unknown context reads as empty. Revision 1.3 adds a stage list's order: strict (the default; a required earlier stage must be recorded first) or flexible (any order, gaps left to reports). Revision 1.4 adds coffee process methods (washed, natural, honey, pulped_natural, wet_hulled, anaerobic and more) that a process type gives its outputs and a batch's process metadata carries: a declaration of the organisation, not a certification. Revision 1.5 adds subclasses of the broad classes (separating, conditioning, sorting_grading, heat_treating) from a closed list, so a reader matches another organisation's step of a broad class only by its subclass or an explicit mapping per sender. Revision 1.6 adds to_processor, a subclass of transporting: goods sent to a processor that works them for their owner (toll processing), so custody moves while title stays. Ledger tags, stage references and site subjects are salted, so no process flow or farm timeline can be read from the ledger, and money is never written plain on the ledger. A packing or loading stage recorded with a logistic unit (an SSCC, a container number) maps to an EPCIS AggregationEvent. In reference release 2.0.0-alpha.9, CompanyFactsHook writes these records on the ledger and RequireStageHook refuses deliveries of lots that lack the required stages; neither module is required. All of it is informative and Proposed.

Cross-chain deployment

A-REX Core is an EVM standard (ADR-026, Proposed): a conformant token runs on any EVM network at the paris level or later, and the standard keeps no list of networks; which ones an organisation may use is set by its policy profile. Networks are named by CAIP-2 ids, such as eip155:8453 or hedera:mainnet. 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. Between tokens on the same chain or on different chains, a batch made from another token's batch names it in the upstream list of its metadata (schema 1.2.0) by chain id, contract and token id. Those references are the issuer's claims, to be checked against the upstream token. From schema 1.4.0 (Proposed), an entry may also give the CAIP-2 network, and a batch recorded on a network that is not EVM is named by its network and its CAIP-19 asset.

Records anyone can check, on any network

The evidence around a token does not depend on the token's network. Once per period, an issuer can combine the fingerprints of its records (its audit log, reports, documents) into one Merkle root and publish those 32 bytes on several independent networks: its own EVM network, Bitcoin through OpenTimestamps and the Hedera Consensus Service. Each record receives a short arex.anchor-proof/1 proof. Anyone who holds the record and its proof can check, with no A-REX service, that the record existed unchanged no later than the time each network received the root; an EVM contract can check the same proof with OpenZeppelin MerkleProof. Only hashes are published, never personal data. The format is informative and Proposed (ADR-026). Which networks an issuer anchors on is policy, set by its jurisdiction or organisation profile, and a proof is valid with any number of receipts. A Hedera receipt names its transaction id when the root is sent, and gains the message's sequence number and consensus time once a public mirror node confirms it.

Where a signed report's numbers come from

A report computed from an issuer's records, such as "1 200 kg delivered to one buyer in October" or a list of records, can carry its sources: one line per record it read, with where the ledger holds that record and the values the report used. Each line is an arex.report-sources/1 source; its leaf is keccak256(0x03 ‖ JCS(source)), and the sorted leaves are paired into one sources root. The root and the SHA-256 of the sources file (<report>.sources.csv) are sealed with the report, in its signed manifest or under the signature of a PDF, so no line can be added, removed or changed later. The report says how many of its records check against the ledger, how many through a fingerprint on the ledger (a daily anchor or a readings window) and how many are only the issuer's records, covered by its seal. A source never holds a personal value in clear. A reader checks it all with no A-REX service: verify-sources.mjs, a standalone checker (Node.js 20, nothing to install) that any implementation can ship, recomputes every leaf and the root, compares them with the report, then reads each ledger record from any node of its network. A report with several cards keeps one sources file and one root; each line names its card in the optional section member (revision 1.1), so each card's numbers add up on their own.

node verify-sources.mjs report.csv.sources.csv --manifest report.csv.manifest.json --rpc https://<a node of the network>

The format is informative and Proposed (report sources revision 1.1). The standard's document, shared under early access, gives the file's columns, every check and an example vector; the schema describes one source.

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