Interoperabilität

Mit dem Ethereum-Ökosystem

Ein A-REX-Core-Token ist ein ERC-1155-Token. Wallets, Explorer, Marktplätze und Indexer, die ERC-1155 verstehen, funktionieren unverändert: Salden, Sammeltransfers, uri(id), Freigaben, Empfängerprüfungen bei sicheren Transfers. A-REX ergänzt Ereignisse und Views; es entfernt nichts.

Ein A-REX-Core-Token ist ein ERC-7943-Multi-Token. Compliance-Engines und Verwahrungsplattformen, die auf ERC-7943 abzielen (die Automated Compliance Engine von Chainlink hat die Kompatibilität demonstriert; Ausgabeplattformen der ERC-7943-Koalition übernehmen ihn), erkennen canTransfer, forcedTransfer, setFrozenTokens, canSend und canReceive ohne Anpassung.

Mit Datenstandards für die Rückverfolgbarkeit

GS1 EPCIS 2.0 / CBV

Das Metadatenschema verwendet absichtlich die Namen aus EPCIS/CBV, damit ein Exporter Felder abbildet und nicht Konzepte.

FSMA 204

Schlüsseldatenelemente sind Metadatenfelder (traceabilityLotCode, GLN, Daten, Mengen) und Ereignisse; das Transformations-CTE ist BatchTransformed; die Anforderung, Aufzeichnungen binnen 24 Stunden vorzulegen, ist eine Indexer-Abfrage. Die vollständige Zuordnung steht im Kapitel zur regulatorischen Compliance.

Codex, ISO 22000, GLOBALG.A.P., Bio-Schemata

Alle sind Attestierungsthemen. Der Standard zählt sie nicht auf: keccak256("GLOBALGAP:IFA"), keccak256("AREX:CERT:ORGANIC_EU"), keccak256("CODEX:MRL") sind Konventionen, die der Aussteller mit seinem Metadatenschema veröffentlicht.

Mit Registern für Rechtsdokumente

A-REX-Token referenzieren Rechtsinstrumente; sie ersetzen sie nicht, bis eine Rechtsordnung den Token selbst anerkennt:

Mit Identitätssystemen

Der Token stellt nur die Fragen canSend(account) / canReceive(account). Hinter dieser Frage können stehen:

• eine vom Aussteller geführte Zulassungs-/Sperrliste (EligibilityHook);
• ein ONCHAINID-Identitätsregister mit Claim-Themen (das ERC-3643-Modell);
• Attestierungen des Ethereum Attestation Service zum Konto;
• Verifiable Credentials, die Off-Chain geprüft und von einem Relayer On-Chain abgebildet werden;
• ein nationales eID-System (eIDAS-2.0-Wallet in der EU) über einen Credential-Verifizierer.

Keines davon ist Teil des Standards; deshalb können ein Aussteller in Brasilien und einer in Deutschland unterschiedliche Anbieter nutzen und dennoch interoperabel bleiben.

Cross-Chain-Deployment

Der Standard ist Chain-agnostisch. Praktische Muster:

• Eine Heimat-Chain je Aussteller (empfohlen): Abstammung und Durchsetzung bleiben kohärent; andere Chains halten gekapselte Repräsentationen über Adapter im Stil von ERC-7802 oder über CCIP.
• Zugangsbeschränkte EVM-Chain für Aussteller, deren Datenschutzbehörde oder Ankerinstitution dies verlangt; der EDPB bevorzugt zugangsbeschränkte Designs ausdrücklich. Derselbe Bytecode.
• Spiegelungen für Liquidität: eine Chargen-ID auf der Heimat-Chain, ein ERC-20-Wrapper anderswo; der Wrapper muss canTransfer des Heimat-Tokens beachten oder sich auf berechtigte Inhaber beschränken.

Die Abstammung überschreitet nie Chains; Referenzen schon.

Mit Betriebsverwaltungs- und ERP-Systemen

Die Integrationspunkte sind dieselben wie bei jedem ERC-1155-Token, ergänzt um die Chargen-Views:

• Schreibpfad: Ein Originierungsdienst hält ISSUER_ROLE und ruft createBatch aus ERP-Ereignissen auf (Wiegebrücken-Schein, Ausstellung von Lagerscheinen); setBatchStatus/setBatchMetadata aus Lagerereignissen; transform aus Verarbeitungsaufträgen.
• Lesepfad: Ein Indexer materialisiert Chargen, Abstammung, Attestierungen und Durchsetzungsereignisse in den Rückverfolgbarkeitstabellen des ERP; EPCIS-Export für Partner und Aufsichtsbehörden.
• Vorabprüfung: transferCheck ermöglicht es einem ERP, einem Bediener eine Ablehnung zu erklären, bevor eine Transaktion übermittelt wird.
• Kennungen: GS1-Schlüssel in den Metadaten schlagen die Brücke zu bestehenden EDI- und EPCIS-Repositories; UN/CEFACT-Einheiten sind in ERPs bereits vorhanden.

Kompatibilitätsmatrix