Whitepaper · 06
Kernstandard
Die Begründung hinter jedem Element von A-REX Core: warum der Chargendatensatz genau diese Felder hat, warum Abstammung eine Operation und kein Mapping ist, warum die Durchsetzung aus ERC-7943 stammt, warum Codes Enums ersetzen und welche Lehren den Entwurf geprägt haben.
Entwurfsziel: die kleinste Schnittstelle, die ein Dritter implementiert
Ein Standard wird übernommen, wenn seine Implementierung weniger kostet, als nicht interoperabel zu sein. Jedes Feld, jede Funktion und jede Regel in A-REX Core musste einen Test bestehen: Würde ein unabhängiges Team, das eine Getreidelager-Plattform in Argentinien oder das System eines Kaffeeexporteurs in Kolumbien baut, diese Einschränkung im Austausch gegen Interoperabilität akzeptieren? Aufzählungen von Kulturen, US-amerikanische Güteklassenbezeichnungen, ein verpflichtendes Betriebsregister, ein vorgeschriebener Identitäts-Stack und eine Bewertungsformel haben diesen Test alle nicht bestanden. Chargenidentität, Abstammung, Durchsetzung und ein Erweiterungspunkt haben ihn bestanden.
Der Chargendatensatz, Feld für Feld
| Feld | Warum es On-Chain liegt | Warum es so gestaltet ist |
|---|---|---|
commodity: bytes32 | Hooks, Marktplätze und Aufsichtsbehörden müssen nach Produkt filtern können, ohne Metadaten zu parsen | keccak256("HS:100199") akzeptiert jedes Schema (HS, FAO/CPC, GTIN, nationale Codes) ohne Tabelle im Standard; ein Enum würde die Kulturliste der Welt beim Deployment einfrieren |
unit: bytes32 | Mengen sind ohne Einheit bedeutungslos; ein Transfer von 1000 sind 1000 kg oder 1000 Kisten | UN/CEFACT-Empfehlung 20 ist die Codeliste, die von EDI, EPCIS und Zoll verwendet wird |
producedAt: uint64 | Verderblichkeit, Saisonalität und Terminkontrakte knüpfen alle an den Produktionszeitpunkt an | 0 bedeutet „noch nicht produziert“: Ernteforderungen, Terminkontrakte und Warrants auf künftige Ernten sind die vorherrschenden Finanzierungsinstrumente der Landwirtschaft in Lateinamerika und müssen abbildbar sein |
expiresAt: uint64 | die häufigste Transferregel in der Landwirtschaft lautet „nicht nach diesem Datum“ | 0 bedeutet kein Ablauf; Hooks entscheiden, was der Ablauf nach sich zieht |
originRef: bytes32 | die Herkunft muss nachweisbar sein (EUDR, Bio, geografische Angaben) | ein Hash oder eine Referenz, niemals Koordinaten: Die Geolokalisierung der Parzelle eines Erzeugers ist ein personenbezogenes Datum (EDPB-Leitlinien 02/2025 v2.0, Juli 2026), und eine unveränderliche öffentliche Chain kann einer Löschung nicht nachkommen |
metadataHash: bytes32 + uri | alles Übrige liegt Off-Chain, aber der Token muss sich darauf festlegen | Hash eines kanonischen JSON-Dokuments nach einem veröffentlichten Schema; uri kann IPFS, HTTPS oder ein GS1 Digital Link sein |
status: uint8 | eine Charge durchläuft einen Lebenszyklus, und manche Zustände müssen Bewegungen blockieren | offene Werte mit zwei Fixpunkten (0 aktiv, 255 stillgelegt); das frühere Enum mit neun Zuständen kodierte das Vokabular einer einzigen Lieferkette und war von jedem Inhaber änderbar |
issuer, createdAt | Rechenschaftspflicht und Audit | vom Contract gesetzt, nie vom Aufrufer |
Was bewusst fehlt: Breiten- und Längengrad, Betriebskennung, Güteklassen-Enum, Feuchtigkeit und Protein, Verifizierungs-Flag und Verifizierer-Adresse, ein Feld quantity (maßgeblich ist die Mengenverfolgung von ERC-1155) und jeder Wertbegriff.
Abstammung als Operation
Ein Lebenszyklus mit einem Zustand PROCESSED, aber ohne Möglichkeit, das verarbeitete Gut zu erzeugen, ist ein häufiger Fehler. Rückverfolgbarkeitsregime legen ausdrücklich fest, dass die Transformation ein Ereignis ist, das Eingaben mit Ausgaben verknüpft: das kritische Verfolgungsereignis Transformation nach FSMA 204, das TransformationEvent von EPCIS 2.0 mit inputQuantityList und outputQuantityList. Ein von einem Administrator geschriebenes Mapping der Elternchargen würde weder die Mengen noch die Atomarität abbilden.
transform(from, to, inputIds, inputAmounts, outputs, outputAmounts, processRef) verbrennt und mintet in einer Transaktion, erfasst die Elternchargen bei jeder Ausgabe, emittiert ein Ereignis mit allen Mengen und einer Prozessreferenz und führt die Hook-Pipeline für jeden Teilvorgang aus. Teilen (1→n), Zusammenführen (n→1) und Verarbeiten (n→m) sind dieselbe Funktion. Die Referenzimplementierung erlaubt jedem Inhaber das Re-Batching (gleicher Rohstoff und gleiche Einheit, erhaltene Menge), verlangt aber TRANSFORMER_ROLE, um die Art oder die Menge der Güter zu verändern – eine Mühle kann Weizen zu Mehl verarbeiten, ein Landwirt kann Weizen nicht in Gold verwandeln.
Durchsetzung aus ERC-7943, nicht neu erfunden
Landwirtschaftliche Chargen unterliegen regelmäßig Pfandrechten, Warrants, Embargos, Insolvenzverfahren und Rückrufen. Ein Token, der von einer autorisierten Partei nicht gegen den Willen des Inhabers eingefroren oder bewegt werden kann, kann eine solche Charge gegenüber einer Bank, einem Gericht oder einer Aufsichtsbehörde nicht repräsentieren. ERC-3643 hat dies 2021 für Wertpapiere gelöst; ERC-7943 hat es für jedes Real-World-Asset verallgemeinert und im Mai 2026 mit einer ERC-1155-Variante den Status Final erreicht. A-REX übernimmt diese Schnittstelle wörtlich, statt eine eigene zu definieren, damit ERC-7943-fähige Compliance-Engines (Chainlink ACE, ERC-3643-Tooling) einen A-REX-Token ohne Anpassung erkennen.
Die Multi-Token-Variante passt natürlich zu ERC-1155: Das Einfrieren erfolgt je Konto und je Chargen-ID, erzwungene Transfers benennen die Charge, die Berechtigung gilt je Konto.
Ein Hook, geordnet, mit Codes
Ein Modulsystem auf Basis von fünf Fähigkeitsschnittstellen, die bei jedem Transfer jeweils mit supportsInterface abgefragt werden, skaliert nicht; bei acht Modulen und fünf IDs in einem Sammeltransfer waren das achtzig statische Aufrufe, bevor irgendeine Regel lief. Ablehnungen waren freie Zeichenketten, die kein Indexer interpretieren und kein Test zuverlässig vergleichen konnte.
A-REX Core definiert eine Hook-Schnittstelle mit einer konstanten Flag-Bitmap, die bei der Registrierung zwischengespeichert wird. Der Token wertet Hooks in einer festen Reihenfolge aus und stoppt beim ersten bytes32-Code ungleich null, wobei er mit ARexHookRejected(hook, code) revertiert. Die Reihenfolge ist prüfbar (getHooks), das Entfernen bewahrt sie, und ein Hook erfährt den aufrufenden Token über msg.sender, sodass ein Deployment viele Token bedient. Die Berechtigung (canSend/canReceive) ist in dieselbe Schnittstelle integriert, damit die ERC-7943-Views des Tokens die Konjunktion seiner Hooks sind.
Warum Codes und keine benutzerdefinierten Fehler des Hooks? Weil check eine View ist, die komponierbar sein muss: Der Token muss jeden Hook befragen, Antworten vergleichen und die erste über transferCheck ohne Revert bereitstellen. Codes sind günstig, indexierbar, übersetzbar und mit Namensräumen versehen (keccak256("AREX:BATCH_EXPIRED"), keccak256("MYHOOK:QUOTA")).
Attestierungen je Charge, Aussteller je Thema
Die Zertifizierung eines Erzeugers ist ein Identitätsproblem mit ausgereiften Lösungen (ONCHAINID, Ethereum Attestation Service, Verifiable Credentials, nationale eID). Die Zertifizierung einer Charge ist das, was Käufer, Zollbehörden und Aufsichtsbehörden prüfen, und dafür gab es keine Standardform. IARexAttest erfasst (batch, topic) → (issuer, reference, validity) und lässt einen Administrator entscheiden, welcher Aussteller zu welchem Thema attestieren darf; das spiegelt das Register vertrauenswürdiger Aussteller von ERC-3643, ohne einen Identitätsanbieter vorzuschreiben. Themen sind offene bytes32, sodass ERC-735-Claim-Themen, EAS-Schema-IDs und Hashes von Zertifizierungsnamen nebeneinander bestehen.
isAttested ist die einzige Frage, die ein Hook stellt: Es liefert falsch, wenn die Attestierung fehlt, widerrufen oder abgelaufen ist oder ihr Aussteller das Vertrauen verloren hat. So kann ein Hook „Kaffee-Chargen benötigen eine EUDR-Sorgfaltsreferenz, bevor sie verkauft werden können“ in sechs Zeilen durchsetzen.
Was der Standard nicht sagt
- Er sagt nicht, wer Chargen erstellen, den Status ändern oder Durchsetzungsmaßnahmen ergreifen darf – nur, dass dies Rollen sind, niemals Salden.
- Er sagt nicht, was die Status 1..254 bedeuten; der Aussteller veröffentlicht eine Tabelle in den Metadaten.
- Er sagt nicht, wie eine Charge zu bewerten ist, wie sie verfällt, wann sie saisonal gehandelt werden darf, wie sie geliefert oder versichert wird: All das sind Hooks oder Begleit-Contracts.
- Er sagt nicht, welche Chain, welcher Identitätsanbieter, welches Oracle, welches Register.
- Er sagt nicht, ob der Token ein Wertpapier oder eine Ware ist.
Lehren, die den Entwurf geprägt haben
| Lehre | Folge in A-REX Core |
|---|---|
| Ein Standard, der ein Betriebsregister und ein Identitätssystem als ERFORDERLICH vorsieht, ist kein Token-Standard, sondern ein Produkt | nichts außerhalb des Tokens ist erforderlich |
| Ein geschlossenes Enum in einer Funktionssignatur macht jedes „dynamische Register“ von Rohstoffen zu totem Code | Rohstoffe, Einheiten, Status und Themen sind offene Codes |
| Eine aus dem Saldo abgeleitete Befugnis ist in einem Token mit mehreren Inhabern eine Schwachstelle | Statusänderungen sind rollengesteuert; RETIRED ist terminal |
| Geschäftslogik im Kern widerspricht einem „Kern ohne Geschäftslogik“ | Bewertung, Verfall und Fenster liegen in Hooks |
| Ein Build, der aus einem sauberen Klon nicht kompiliert, ist keine Referenzimplementierung | Abhängigkeiten fixiert, Lockfile eingecheckt, CI bei jedem Push |
| Regulatorische Daten in einem Whitepaper veralten; der Code, der von ihnen abhängt, darf es nicht | der Token speichert Referenzen und Hashes, niemals regulatorische Logik |
Abwärtskompatibilität
A-REX-Core-Token sind vollwertige ERC-1155- und ERC-7943-Token. Wallets, Marktplätze und Indexer, die ERC-1155 kennen, funktionieren unverändert; ERC-7943-fähiges Compliance-Tooling erkennt die Durchsetzungsschnittstelle. Für andere Token geschriebene Regel-Engines lassen sich über einen IARexHook-Adapter anbinden, solange ihre Entscheidungen nur von den Aufrufparametern und dem Chargendatensatz abhängen.