Problemstellung

1. Eine Charge hat keine On-Chain-Identität

Eine ERC-1155-ID ist eine Zahl mit Salden. Nichts im Basisstandard sagt, um welchen Rohstoff es sich handelt, in welcher Einheit, wann er produziert wurde, wann er abläuft oder wo seine Herkunftsnachweise liegen. Jedes Projekt, das landwirtschaftliche Güter tokenisiert, erfindet sein eigenes Struct, seine eigenen Enums und sein eigenes Metadatenlayout. Zwei solche Token können nicht vom selben Indexer gelesen, von derselben Compliance-Engine abgesichert oder in dasselbe EPCIS-Dokument exportiert werden.

Anforderung: ein minimaler, offener Chargendatensatz, den jeder Implementierer übernehmen kann, ohne die Liste von Kulturen, Güteklassen oder Lebenszyklen eines anderen akzeptieren zu müssen.

2. Chargen werden zu anderen Chargen, Token nicht

Aus Weizen wird Mehl; eine Silozelle mit 250 Tonnen wird zu zwei Lieferungen; vierzig Lieferungen werden zu einem Pool. Rückverfolgbarkeitsvorschriften und GS1 EPCIS legen ausdrücklich fest, dass es sich dabei um Transformationsereignisse handelt, die Eingaben mit Ausgaben samt Mengen verknüpfen. Ein Token, der nur gemintet, transferiert und verbrannt werden kann, vermag sie nicht auszudrücken; daher reißt die Provenienzkette beim ersten Verarbeitungsschritt ab – genau dort, wo Rückrufe und Massenbilanz-Audits sie benötigen.

Anforderung: eine Operation, die Eingaben verbrennt, Ausgaben mintet, Elternchargen erfasst und Mengen atomar emittiert.

3. Reale Ansprüche benötigen Durchsetzung

Eingelagertes Getreide wird verpfändet, mit einem Embargo belegt, gepfändet, versichert und zurückgerufen. Ein Token, der von einer autorisierten Partei nicht gegen den Willen des Inhabers eingefroren oder bewegt werden kann, kann eine solche Charge gegenüber einem Kreditgeber, einem Gericht oder einer Aufsichtsbehörde nicht repräsentieren. Die Erwartung des Marktes nach dem GENIUS Act und ERC-7943 ist, dass jeder durch einen realen Anspruch gedeckte Token einer rechtmäßigen Anordnung nachkommen kann und dass jede solche Maßnahme prüfbar ist.

Anforderung: Einfrieren, erzwungener Transfer, Berechtigung und Pause in einer Standardform mit Standardereignissen.

4. Regeln unterscheiden sich nach Rohstoff, Rechtsordnung und Gegenpartei

Verderblichkeitsregeln für Erdbeeren, Saisonfenster für den Getreidehandel, Sanktionsprüfung, Kontingente je Käufer, Verwahrung während des Transports, vor dem Export erforderliche Dokumente: Jeder Aussteller benötigt einige davon, keiner benötigt alle. Monolithische Compliance-Frameworks scheitern hier, ebenso Ad-hoc-Modulsysteme, deren Schnittstellen nicht geteilt werden – eine für einen Token geschriebene Regel läuft nicht auf einem anderen.

Anforderung: eine kleine, standardisierte Erweiterungsschnittstelle mit geordneter Auswertung und maschinenlesbaren Ablehnungsgründen, damit Regeln über Token hinweg portierbar sind.

5. Zertifizierung betrifft die Charge, nicht nur den Erzeuger

Für Identität und Erzeuger-Credentials gibt es ausgereifte Lösungen (ONCHAINID, Attestierungsdienste, Verifiable Credentials, nationale eID). Was Käufer, Zollbehörden und Aufsichtsbehörden prüfen, ist, ob diese Charge ein Bio-Zertifikat, ein Pflanzengesundheitszeugnis, ein Laborergebnis oder eine EUDR-Erklärung hat. Dafür gibt es On-Chain keine Standardform, und geschlossene Aufzählungen von Zertifizierungsarten veralten an dem Tag, an dem ein neues Schema erscheint.

Anforderung: Attestierungen, geschlüsselt nach Charge und offenem Thema, ausgestellt ausschließlich von Parteien, die für dieses Thema vertrauenswürdig sind, mit Widerruf und Ablauf.

6. Personenbezogene Daten und öffentliche Ledger stehen im Konflikt

Die Geolokalisierung einer Parzelle identifiziert einen Erzeuger. Die Leitlinien des Europäischen Datenschutzausschusses von 2026 halten fest, dass On-Chain-Inhalte und -Metadaten grundsätzlich personenbezogene Daten sind, dass Hashing keine Anonymisierung gewährleistet und dass Verantwortliche es vermeiden sollten, personenbezogene Daten On-Chain zu speichern. Frühe Token-Designs für die Landwirtschaft – einschließlich der ersten Generation von A-REX selbst – speicherten Koordinaten unveränderlich.

Anforderung: Der Standard muss personenbezogene Daten On-Chain konstruktionsbedingt unmöglich machen: Referenzen und Hashes On-Chain, Nachweise Off-Chain mit Zugriffskontrolle.

7. Rechtsinstrumente existieren bereits

Lagerscheine, Warrants, Ernteforderungen (CPR), Konnossemente und Sorgfaltserklärungen unterliegen gesetzlichen Regelungen und werden bei zugelassenen Stellen registriert. Ein Token, der außerhalb einer Rechtsordnung, die ein solches Instrument anerkennt (Staaten, die das MLETR übernommen haben, und Staaten mit UCC Article 12), für sich in Anspruch nimmt, ein solches Instrument zu sein, schafft ein Rechtsrisiko; ein Token, der darauf verweist, schafft Wert.

Anforderung: vollwertige Referenzen auf externe Instrumente im Chargendatensatz und in den Metadaten; eine Durchsetzung, die mit der „Kontrolle“ nach UCC Article 12 und der „ausschließlichen Kontrolle“ nach MLETR vereinbar ist.

8. Standards, die Produkte sind, werden nicht übernommen

Die erste Generation von A-REX verlangte ein Betriebsregister und einen Identitäts-Contract, legte neun Lebenszyklusstatus, elf Rohstoffe und US-amerikanische Güteklassenbezeichnungen fest und implementierte eine Bewertungsformel im Kern. Kein unabhängiges Team würde diese Einschränkungen im Austausch gegen Interoperabilität akzeptieren. Die Standards, die sich in diesem Bereich durchgesetzt haben (ERC-3643, ERC-7943), standardisieren wenige Schnittstellen und lassen das Produkt außen vor.

Anforderung: nur Schnittstellen; Referenzimplementierung getrennt; Module als Demonstrationen.

Zusammenfassung der Anforderungen