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

Der Standard veröffentlicht eine informative Abbildung, Ereignis für Ereignis:

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

UN Transparency Protocol (UNTP 0.7.0)

Eine informative Abbildung überführt eine Charge, ihre Ereignisse und ihre Attestierungen in Credentials nach UNTP 0.7.0, mit denselben Kennungen wie die EPCIS-Abbildung, sodass sich beide verknüpfen lassen:

Credentials folgen dem W3C Verifiable Credentials Data Model 2.0 und werden mit VC-JOSE-COSE unter dem did:web des Ausstellers signiert; der Widerruf nutzt eine Bitstring Status List. Ein signiertes Credential lässt sich zusätzlich als Attestierung an seiner Charge verankern, deren Referenz der Hash des Credentials ist; der Anker beweist die Festlegung, die Signatur den Inhalt. Ein Credential enthält nur, was der Token oder seine Metadaten enthalten, und Werte, die eine Methode erfordern (ein Fußabdruck, eine Risikobewertung), erscheinen nur, wenn eine benannte Partei sie deklariert hat. Die Abbildung nennt, was sie nicht abdeckt, angefangen beim Digitalen Produktpass der EU: Die ESPR gilt nicht für Lebensmittel, Futtermittel oder lebende Pflanzen und Tiere, und A-REX macht für sie keine Aussage zum Produktpass.

Deklarierte CO₂-Fußabdrücke (PACT 3.0.3)

ADR-018 (Vorgeschlagen) erlaubt einer Charge, unter extensions.pact_pcf des Metadatendokuments einen Produkt-CO₂-Fußabdruck zu tragen, den ein Dritter berechnet hat. Das Fragment folgt den WBCSD PACT Technical Specifications 3.0.3 Feld für Feld: wer ihn deklariert hat, die deklarierte Einheit und der Bezugszeitraum, der Fußabdruck mit und ohne biogene Aufnahme sowie ein verpflichtender Verifizierungsstatus, der bei einem verifizierten Fußabdruck den Verifizierer nennt. Er wird übernommen, nie berechnet, summiert oder an die aus der Charge hergestellten Chargen weitergegeben, und er ist keine Kohlenstoffgutschrift (ADR-014). Die Abbildung ist ein eigenständiges Derivat von PACT und kopiert keine PACT-Datei.

Rohstoff- und Einheitencodes

Ein Rohstoffcode ist keccak256("<SCHEME>:<CODE>") für jedes Schema: das Harmonisierte System (HS), nationale Zolltarifnomenklaturen (NCM im Mercosur, CN und TARIC in der EU, HTS in den Vereinigten Staaten und weitere), FAO, CPC, GTIN oder ein eigenes Schema des Ausstellers. Seit dem Metadatenschema 1.1.0 ist auch das Schema im Dokument offen, sodass die Metadaten den On-Chain-Code spiegeln können. Einheiten sind Codes der UN/CEFACT-Empfehlung 20 (KGM, TNE, LTR), die Liste, die EDI, EPCIS und Zoll bereits verwenden.

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.

Mit Regel-Engines und Plattformen

Eine Regel oder ein Add-on kann einen Deskriptor arex.module/1 veröffentlichen: ein JSON-Dokument mit ihren Parametern, Einstellungen, erforderlichen Chargenfeldern, Zertifikatstypen, Ereignissen, Ablehnungscodes und der Angabe, wie ihr Zustand in eine neue Version übergeht. Eine Plattform, eine Wallet, ein Indexer oder ein Auditor, der Deskriptoren liest, bindet eine neue Regel ohne eigens geschriebenen Code ein. Das Format ist informativ und hat den Status Vorgeschlagen; es wird zu einem empfohlenen Format, sobald ein zweiter unabhängiger Implementierer es nutzt. Revision 1.1 ergänzt eine optionale, informative Liste ops der Operationen, die eine Regel steuert; fehlt sie, sind sie unbekannt, und sie wird nie zur Durchsetzung verwendet.

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. Zwischen Token auf derselben oder auf verschiedenen Chains benennt eine Charge, die aus der Charge eines anderen Tokens hergestellt wurde, diese in der Liste upstream ihrer Metadaten (Schema 1.2.0) über Chain-ID, Contract und Token-ID. Diese Referenzen sind Behauptungen des Ausstellers und am vorgelagerten Token zu prüfen.

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