Lösungsüberblick

Drei Ebenen, eine Abhängigkeitsrichtung

A-REX trennt, was standardisiert werden muss, von dem, was lediglich funktionieren muss:

Die vier Schichten des Standards

flowchart TB
    L3["Schicht 3 · IARexAttest<br/>attest · revokeAttestation · isAttested · vertrauenswürdige Aussteller je Thema"]
    L2["Schicht 2 · IARexHook + IARexHookManager<br/>hookFlags · check → bytes32 · onExecuted · getHooks"]
    L1["Schicht 1 · IARexBatch<br/>createBatch · batchOf · setBatchStatus · setBatchMetadata · transform · parentsOf"]
    L0["Schicht 0 · ERC-1155 + ERC-165 + IERC7943MultiToken<br/>Einfrieren · forcedTransfer · canSend · canReceive · canTransfer"]
    L3 --- L2 --- L1 --- L0
    classDef l3 fill:#edf5ff,stroke:#0f62fe,color:#161616
    classDef l2 fill:#d0e2ff,stroke:#0f62fe,color:#161616
    classDef l1 fill:#a6c8ff,stroke:#0f62fe,color:#161616
    classDef l0 fill:#78a9ff,stroke:#0043ce,color:#161616
    class L3 l3
    class L2 l2
    class L1 l1
    class L0 l0

Die zwei Ebenen des Repositorys und die Abhängigkeitsrichtung

flowchart LR
    STD["<b>Der Standard</b><br/>standard/ · contracts/standard/<br/>normativ · CC0"]
    REF["<b>Referenzimplementierung</b><br/>ARexToken · ARexAttestations<br/>MIT"]
    DEMO["<b>Demonstrationen</b><br/>7 Hooks · 3 Erweiterungen<br/>MIT · nicht normativ"]
    STD -->|umgesetzt durch| REF -->|demonstriert durch| DEMO
    DEMO -.->|hängen nur von den Schnittstellen ab| STD

Der Standard hängt nie von der Referenz ab; der Token hängt nie von den Hooks ab. Entfernt man jeden Hook und jede Erweiterung, bleibt ein konformer Token bestehen. Diese Eigenschaft erlaubt es einem Dritten, A-REX zu implementieren, ohne etwas aus diesem Repository zu übernehmen außer sechs Schnittstellendateien.

Was eine Charge ist

Eine Charge ist eine ERC-1155-Token-ID mit einem Datensatz:

struct Batch {
    address issuer;        // who created it (or performed the transformation)
    uint64  createdAt;
    uint8   status;        // 0 ACTIVE · 255 RETIRED (terminal) · 1..254 issuer-defined
    bytes32 commodity;     // keccak256("HS:100199"), keccak256("FAO:0111"), keccak256("GTIN:0779…")
    bytes32 unit;          // UN/CEFACT Rec. 20: "KGM", "TNE", "LTR", "BX"
    uint64  producedAt;    // 0 = not yet produced (pre-harvest)
    uint64  expiresAt;     // 0 = none
    bytes32 originRef;     // hash / reference to origin evidence — never coordinates
    bytes32 metadataHash;  // keccak256 of the off-chain document
    string  uri;           // where the document is
}

Alles Umfangreichere – Güteklasse, Feuchtigkeit, Protein, Verpackung, GS1-Kennungen, der Chargencode für die Rückverfolgbarkeit, die Referenz der EUDR-Erklärung, Laborberichte, die Statustabelle des Ausstellers – befindet sich im Metadatendokument, dessen Hash On-Chain festgeschrieben ist. Das Dokument folgt einem veröffentlichten JSON-Schema, das an EPCIS 2.0 und die Schlüsseldatenelemente von FSMA 204 ausgerichtet ist.

Die Transfer-Pipeline

Jede Saldenänderung – Mint, Transfer, Burn, erzwungener Transfer, Transformation – läuft im Referenz-Token durch einen einzigen Durchgangspunkt. Die Reihenfolge ist festgelegt und prüfbar:

flowchart TD
    A["safeTransferFrom / createBatch / burn / forcedTransfer / transform"] --> B["Reentrancy-Sperre"]
    B --> C{"pausiert?"}
    C -- ja, nicht erzwungen --> X1[EnforcedPause]
    C -- nein --> D{"canSend from / canReceive to<br/>Konjunktion der ELIGIBILITY-Hooks"}
    D -- false --> X2[ERC7943CannotSend / CannotReceive]
    D -- true --> E{"je ID: vorhanden? nicht stillgelegt?<br/>Betrag ≤ Saldo − eingefroren?"}
    E -- Fehlschlag --> X3[ARexBatchNotFound / ARexBatchRetired /<br/>ERC7943InsufficientUnfrozenBalance]
    E -- ok --> F{"je ID, je CHECK-Hook der Reihe nach:<br/>check → Code"}
    F -- Code ≠ 0 --> X4["ARexHookRejected(hook, code)"]
    F -- alle 0 --> G["Salden aktualisiert · Gesamtmenge nachgeführt"]
    G --> H["je ID, je EXECUTED-Hook: onExecuted"]
    H --> I["Sperre aufheben"]

Zwei Views geben dieselbe Logik wieder, ohne den Zustand zu ändern: canTransfer (boolesch, wie ERC-7943 es verlangt) und transferCheck (der erste Ablehnungscode, damit eine Benutzeroberfläche dem Nutzer mitteilen kann, warum).

Erzwungene Transfers überspringen die Pause und die Berechtigungsprüfungen – die Durchsetzung muss funktionieren, wenn alles andere eingefroren ist –, führen die Hooks aber dennoch mit OP_FORCED_TRANSFER aus, sodass ein Hook beispielsweise auf einer Gerichtsbeschluss-Referenz in den Transferdaten bestehen kann.

Abstammung

transform ist die einzige Operation zum Teilen, Zusammenführen und Verarbeiten:

graph LR
    W1["Weizen #1<br/>250 t · Landwirt"] -- "transform (Re-Batching)" --> W2["Weizen #2<br/>100 t · Käufer A"]
    W1 -- "transform (Re-Batching)" --> W3["Weizen #3<br/>150 t · Käufer B"]
    W2 -- "transform (Verarbeitung, TRANSFORMER_ROLE)" --> F4["Mehl #4<br/>75 t · Mühle"]

• Re-Batching (gleicher Rohstoff, gleiche Einheit, erhaltene Menge) steht jedem Inhaber oder zugelassenen Operator offen: eine Genossenschaft, die eine Silocharge auf Mitglieder aufteilt, ein Exporteur, der Lieferungen zusammenführt.
• Verarbeitung (alles andere) erfordert zusätzlich TRANSFORMER_ROLE.
• parentsOf(4) == [2], parentsOf(2) == [1]; ein BatchTransformed-Ereignis pro Operation, das konstruktionsbedingt ein TransformationEvent aus EPCIS ist.

Durchsetzung

ENFORCER_ROLE kann für jedes Konto einen beliebigen Betrag einfrieren (setFrozenTokens; er darf den Saldo übersteigen, wie ERC-7943 es festlegt) und Token ohne Zustimmung des Inhabers bewegen (forcedTransfer). Das macht einen Chargen-Token außerhalb einer Demo nutzbar: ein Kreditgeber, der ein Warrant vollstreckt, ein Gericht, das die Beschlagnahme von eingelagertem Getreide anordnet, ein Lagerhalter, der eine Charge wiedererlangt, nachdem ein Kunde seine Schlüssel verloren hat. Jede Durchsetzungsmaßnahme ist ein Ereignis.

Hooks

Ein Hook ist ein Contract mit fünf Funktionen und einer konstanten Flag-Bitmap. Der Token speichert die Flags bei der Registrierung zwischen, sodass ein Transfer einen externen Aufruf pro interessiertem Hook kostet und nicht eine Schnittstellenabfrage pro Fähigkeit und Modul. Ein Hook erfährt über msg.sender, welcher Token ihn aufruft; ein Deployment kann viele Token bedienen.

Referenz-Hooks demonstrieren die drei Fähigkeiten:

Begleiterweiterungen (keine Hooks): CommodityPriceOracle, CarbonImmobilizationWrapper, ParametricInsurance.

Attestierungen

Ein Begleit-Contract erfasst (batch, topic) → (issuer, reference, validity). Nur für ein Thema vertrauenswürdige Aussteller können attestieren; Widerruf, Ablauf und Vertrauensverlust führen jeweils dazu, dass isAttested falsch ist. Themen sind bytes32, sodass ERC-735-Claim-Themen, Schema-IDs des Ethereum Attestation Service und Hashes von Zertifizierungsnamen allesamt ohne Tabelle im Standard funktionieren.

Akteure und Rollen

Nichts im Standard legt diese Rollen fest; sie zeigen, wie die Referenzimplementierung die MUSS-Anforderungen („auf eine autorisierte Rolle beschränkt“) umsetzt.

Deployment-Varianten

• Öffentliches L2 (Polygon, Arbitrum, Base, Optimism): am günstigsten, am besten komponierbar; geeignet für Rohstoffhandel und Finanzierung, bei denen die Gegenparteien Unternehmen sind.
• Zugangsbeschränkte EVM-Chain: wo Datenschutzbehörden oder die Ankerinstitution es verlangen; der EDPB empfiehlt zugangsbeschränkte Designs ausdrücklich. Der Standard ist Chain-agnostisch.
• Hybrid: Chargen auf einer öffentlichen Chain, eingeschränkte Daten (Parzellenpolygone, Identität des Erzeugers) hinter zugriffskontrolliertem Speicher, auf den aus den Metadaten verwiesen wird.

Der Referenz-Stack wird mit einem Ignition-Modul oder einem Skript ausgerollt: Token-Proxy, Attestierungsregister, Berechtigungs- und Ablauf-Hooks.

Entwurfsentscheidungen und die Alternativen, die sie ersetzen