Anwendungsfälle

1. Eingelagertes Getreide und Lagerscheine

Ausgangslage. Ein Genossenschaftslager nimmt 250 t Weizen von einem Mitglied entgegen, stellt ein Hinterlegungszertifikat aus und verkauft die Charge später in zwei Teilen.

On-Chain.

1. createBatch({commodity: HS:100199, unit: KGM, producedAt: harvest, expiresAt: 0, originRef: hash(certificate #CD-88213), metadataHash, uri}, 250_000, member) – der Token verweist auf den rechtlich maßgeblichen Beleg; er ersetzt ihn nicht, bis die Rechtsordnung dies bestimmt.
2. setBatchStatus(id, 1 /* IN_STORAGE */, ref("SILO-3")) durch das Lager (STATUS_ROLE).
3. transform(member, buyerA, [id], [100_000], [same commodity/unit], [100_000], ref("SALE-1")) – ein Re-Batching, keine Rolle erforderlich; parentsOf(newId) == [id].
4. Der zweite Verkauf erfolgt ebenso; die verbleibenden 50 t bleiben in der ursprünglichen ID.
5. Bei der physischen Auslagerung werden die Einheiten des Käufers verbrannt: burn(buyerA, newId, 100_000); das Lager legt die Elterncharge still, sobald sie leer ist.

Warum das wichtig ist. Der Bestand ist exakt (totalSupply), die Provenienz ist eine Kette von BatchTransformed-Ereignissen, und das Lagerscheinregister bleibt maßgeblich.

2. Vorernte-Finanzierung (CPR, Terminkontrakt, Warrant auf künftige Ernte)

Ausgangslage. Ein brasilianischer Erzeuger gibt eine elektronische CPR über 1,000 t Sojabohnen aus, die im April geerntet werden sollen; ein Kreditgeber schießt dagegen Mittel vor.

On-Chain.

1. createBatch({commodity: HS:120190, unit: TNE, producedAt: 0, expiresAt: 0, originRef: hash(CPR-e registry id), …}, 1000, producer) – producedAt == 0 ist die Darstellung einer künftigen Charge im Standard.
2. ExpiryHook(allowPreHarvestTransfers = true), damit die Forderung abgetreten werden kann; ein Spot-Marktplatz würde ihn mit false ausrollen.
3. Das Sicherungsrecht des Kreditgebers: setFrozenTokens(producer, id, 1000) durch ENFORCER_ROLE (die Plattform, die auf Grundlage des Pfandvertrags handelt). Der Erzeuger behält das Eigentum, kann die Einheiten aber nicht bewegen.
4. Bei der Ernte: setBatchMetadata mit dem Wiegeschein; setBatchStatus(id, 2 /* HARVESTED */); die Plattform erfasst producedAt in den Metadaten (das On-Chain-Feld ist konstruktionsbedingt unveränderlich; die Statusänderung ist die On-Chain-Tatsache).
5. Rückzahlung: setFrozenTokens(producer, id, 0). Zahlungsausfall: forcedTransfer(producer, lender, id, 1000) auf Grundlage des Pfandrechts.

Warum das wichtig ist. Die beiden häufigsten Kreditereignisse in der Landwirtschaft – Verpfändung und Vollstreckung – sind zwei Aufrufe, beide prüfbar, beide vereinbar mit der „Kontrolle“ nach UCC Article 12 und mit registerbasierten Instrumenten.

3. Kaffeeexport unter der EUDR

Ausgangslage. Ein kolumbianischer Exporteur liefert nach dem 30. Dezember 2026 20 t Rohkaffee an eine Rösterei in Hamburg.

On-Chain.

1. createBatch({commodity: HS:090111, unit: KGM, producedAt: harvest, originRef: hash(DDS reference), …}, 20_000, exporter). Die Parzellenpolygone verbleiben im EU-Informationssystem und im zugriffsbeschränkten Speicher des Exporteurs.
2. Der Compliance-Beauftragte des Exporteurs ist ein vertrauenswürdiger Aussteller für das Thema EUDR:DDS: attest(id, EUDR:DDS, hash(DDS reference), 0).
3. AttestationHook.setRequirement(HS:090111, EUDR:DDS) am Token: Transfers von Kaffee ohne die Attestierung liefern ATTESTATION_MISSING.
4. Verkauf: safeTransferFrom(exporter, roaster, id, 20_000, data); die Rösterei als nachgelagerter Marktteilnehmer bewahrt die DDS-Referenz fünf Jahre lang auf – sie steht in den Metadaten der Charge, die sie nun hält.
5. Rösten: transform(roaster, roaster, [id], [20_000], [{commodity: HS:090121, …}], [16_800], ref("ROAST-2027-03")) – die Eltern der gerösteten Charge verweisen auf die Rohkaffee-Charge und über diese auf die DDS.

Warum das wichtig ist. Die Referenzkette der Verordnung übersteht die Verarbeitung, und die Geodaten, die laut EDPB nicht auf einer öffentlichen Chain liegen dürfen, liegen dort nie.

4. Verderbliche Frischware und Kühlkette

Ausgangslage. Ein Abpacker versendet Erdbeeren mit einer Haltbarkeit von 12 Tagen; während des Transports wird eine Temperaturabweichung erfasst.

On-Chain.

1. createBatch({commodity: GTIN:…, unit: BX, producedAt: packDate, expiresAt: packDate + 12 days, …}, 4_800, packer); die Metadaten enthalten den bei der Erstverpackung vergebenen FSMA-Chargencode für die Rückverfolgbarkeit.
2. ExpiryHook blockiert jeden Transfer nach expiresAt (BATCH_EXPIRED); Burns bleiben zur Abschreibung möglich.
3. Ein Kühlketten-Hook (DeliveryHook) liefert während des Transports IN_TRANSIT und erfasst Kontrollpunkte in onExecuted.
4. Die Abweichung wird vom Logistikdienstleister attestiert: attest(id, COLDCHAIN:EXCURSION, hash(sensor log), 0); ein Hook auf Käuferseite kann die Annahme verweigern (canReceive-Richtlinie), oder die Parteien einigen sich Off-Chain, wobei die Attestierung als Nachweis dient.
5. Lieferung: burn durch den Empfänger oder setBatchStatus(id, 255 /* RETIRED */, ref("DELIVERED")) durch den Abpacker.

Warum das wichtig ist. Haltbarkeit, Verwahrung und Qualitätsvorfälle sind drei unabhängige Hooks über einem Chargendatensatz; keiner davon erforderte eine Änderung am Token.

5. Genossenschaftliche Verteilung und Abrechnung mit den Mitgliedern

Ausgangslage. Eine Genossenschaft vermarktet eine gepoolte Charge von 1,000 t und muss Erlöse und Restgetreide auf 40 Mitglieder verteilen.

On-Chain.

1. Mitglieder liefern in den Pool: Jede Lieferung ist ein createBatch an das Mitglied, anschließend führt transform(member, coop, [ids], [amounts], [pool spec], [amount], ref("POOL-2026")) sie in die Pool-Charge zusammen (Re-Batching, keine Rolle erforderlich, wenn Rohstoff und Einheit gleich sind).
2. parentsOf(pool) listet jede Mitgliederlieferung auf – der Verteilungsschlüssel liegt On-Chain.
3. Verkauf des Pools an einen Käufer: ein safeTransferFrom.
4. Reste: transform(coop, coop, [pool], [remaining], [40 outputs], [per-member amounts], ref("RESIDUAL")) und safeBatchTransferFrom an die Mitglieder.

Warum das wichtig ist. Die Bildung und Auflösung von Pools, die heute in Genossenschaftsbüchern stattfinden, sind Abstammungsoperationen mit exakten Mengen.

6. Rückruf

Ausgangslage. Ein Labor findet in einer Maischarge, die bereits geteilt und teilweise verarbeitet wurde, Aflatoxin oberhalb des Grenzwerts.

On-Chain.

1. Das Labor (vertrauenswürdiger Aussteller für LAB:AFLATOXIN) attestiert das Ergebnis: attest(id, LAB:AFLATOXIN, hash(report), 0).
2. Die Plattform legt die Charge still: setBatchStatus(id, 255, ref("RECALL-2026-07")); Transfers stoppen sofort (ARexBatchRetired), Burns (Vernichtung) bleiben möglich.
3. Vorwärtsverfolgung: Jedes BatchTransformed, dessen inputIds id enthalten, liefert die Kindchargen; rekursiv die betroffenen Futter- und Lebensmittelchargen. Rückwärtsverfolgung: parentsOf.
4. Die Aufsichtsbehörde erhält die Liste der betroffenen IDs und Inhaber aus dem Ereignisprotokoll – die 24-Stunden-Anforderung wird durch eine Indexer-Abfrage erfüllt, nicht durch eine Aktensuche.

Warum das wichtig ist. Der Umfang eines Rückrufs ist eine Graphabfrage über standardisierte Ereignisse – genau das soll das Transformations-CTE von FSMA 204 ermöglichen.

Was diese Szenarien gemeinsam haben

• Vier Schnittstellen, drei Referenz-Hooks und das Attestierungsregister decken alle sechs ab; kein Szenario erforderte eine Änderung am Standard.
• Rechtsinstrumente (Belege, CPR-e, DDS, Laborberichte) werden referenziert und gehasht, nicht neu implementiert.
• Durchsetzung (Einfrieren, erzwungener Transfer, Stilllegung) kommt in jedem Finanzierungs- und Compliance-Szenario vor und ist stets ein Ereignis.
• Personenbezogene Daten erscheinen nie On-Chain.