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.

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.

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.

Cross-chain deployment

The standard is chain-agnostic. 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.

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