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 metadata schema uses EPCIS/CBV names on purpose so that an exporter maps fields, not concepts.

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.

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.

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