Cas d'usage

1. Grains stockés et récépissés d'entrepôt

Situation. Un silo coopératif reçoit 250 t de blé d'un membre, émet un certificat de dépôt, puis vend ensuite le lot en deux parties.

On-chain.

1. createBatch({commodity: HS:100199, unit: KGM, producedAt: harvest, expiresAt: 0, originRef: hash(certificate #CD-88213), metadataHash, uri}, 250_000, member) — le jeton référence le récépissé juridique ; il ne le remplace pas tant que la juridiction ne le prévoit pas.
2. setBatchStatus(id, 1 /* IN_STORAGE */, ref("SILO-3")) par le silo (STATUS_ROLE).
3. transform(member, buyerA, [id], [100_000], [same commodity/unit], [100_000], ref("SALE-1")) — une réorganisation de lots, aucun rôle nécessaire ; parentsOf(newId) == [id].
4. La seconde vente se déroule de même ; les 50 t restantes demeurent dans l'identifiant d'origine.
5. Lors du retrait physique, les unités de l'acheteur sont détruites : burn(buyerA, newId, 100_000) ; le silo retire le lot parent lorsqu'il est vide.

Pourquoi c'est important. L'offre est exacte (totalSupply), la provenance est une chaîne d'événements BatchTransformed, et le registre des récépissés reste la référence faisant foi.

2. Financement avant récolte (CPR, contrat à terme, warrant sur récolte future)

Situation. Un producteur brésilien émet une CPR électronique portant sur 1,000 t de soja à récolter en avril ; un prêteur avance des fonds en contrepartie.

On-chain.

1. createBatch({commodity: HS:120190, unit: TNE, producedAt: 0, expiresAt: 0, originRef: hash(CPR-e registry id), …}, 1000, producer) — producedAt == 0 est la représentation d'un lot futur dans le standard.
2. ExpiryHook(allowPreHarvestTransfers = true) afin que la créance puisse être cédée ; une place de marché au comptant le déploierait avec false.
3. La sûreté du prêteur : setFrozenTokens(producer, id, 1000) par ENFORCER_ROLE (la plateforme agissant en vertu du contrat de nantissement). Le producteur conserve la propriété mais ne peut pas déplacer les unités.
4. À la récolte : setBatchMetadata avec le ticket de pesée ; setBatchStatus(id, 2 /* HARVESTED */) ; la plateforme consigne producedAt dans les métadonnées (le champ on-chain est immuable par conception ; le changement de statut est le fait on-chain).
5. Remboursement : setFrozenTokens(producer, id, 0). Défaut : forcedTransfer(producer, lender, id, 1000) en vertu du nantissement.

Pourquoi c'est important. Les deux événements de crédit les plus courants en agriculture — le nantissement et l'exécution — sont deux appels, tous deux auditables, tous deux compatibles avec le « contrôle » de l'UCC Article 12 et avec les instruments fondés sur un registre.

3. Exportation de café sous l'EUDR

Situation. Un exportateur colombien expédie 20 t de café vert à un torréfacteur de Hambourg après le 30 décembre 2026.

On-chain.

1. createBatch({commodity: HS:090111, unit: KGM, producedAt: harvest, originRef: hash(DDS reference), …}, 20_000, exporter). Les polygones de parcelles restent dans le système d'information de l'UE et dans le stockage restreint de l'exportateur.
2. Le responsable conformité de l'exportateur est un émetteur de confiance pour le thème EUDR:DDS : attest(id, EUDR:DDS, hash(DDS reference), 0).
3. AttestationHook.setRequirement(HS:090111, EUDR:DDS) sur le jeton : les transferts de café sans l'attestation renvoient ATTESTATION_MISSING.
4. Vente : safeTransferFrom(exporter, roaster, id, 20_000, data) ; le torréfacteur, opérateur en aval, conserve la référence DDS pendant cinq ans — elle figure dans les métadonnées du lot qu'il détient désormais.
5. Torréfaction : transform(roaster, roaster, [id], [20_000], [{commodity: HS:090121, …}], [16_800], ref("ROAST-2027-03")) — les parents du lot torréfié pointent vers le lot de café vert et, à travers lui, vers la DDS.

Pourquoi c'est important. La chaîne de références du règlement survit à la transformation, et les données géographiques dont l'EDPB indique qu'elles ne doivent pas figurer sur une chaîne publique n'y figurent jamais.

4. Produits périssables et chaîne du froid

Situation. Un conditionneur expédie des fraises d'une durée de conservation de 12 jours ; une excursion de température est enregistrée pendant le transport.

On-chain.

1. createBatch({commodity: GTIN:…, unit: BX, producedAt: packDate, expiresAt: packDate + 12 days, …}, 4_800, packer) ; les métadonnées portent le code de lot de traçabilité FSMA attribué lors du conditionnement initial.
2. ExpiryHook bloque tout transfert après expiresAt (BATCH_EXPIRED) ; les destructions restent possibles pour un passage en pertes.
3. Un hook de chaîne du froid (DeliveryHook) renvoie IN_TRANSIT pendant le transport et consigne des points de contrôle dans onExecuted.
4. L'excursion est attestée par le prestataire logistique : attest(id, COLDCHAIN:EXCURSION, hash(sensor log), 0) ; un hook côté acheteur peut refuser la réception (politique canReceive) ou les parties règlent la question off-chain avec l'attestation comme preuve.
5. Livraison : burn par le destinataire, ou setBatchStatus(id, 255 /* RETIRED */, ref("DELIVERED")) par le conditionneur.

Pourquoi c'est important. La durée de conservation, la garde et les incidents de qualité sont trois hooks indépendants sur un même enregistrement de lot ; aucun n'a exigé de modification du jeton.

5. Distribution coopérative et règlement des membres

Situation. Une coopérative commercialise un lot mutualisé de 1,000 t et doit répartir le produit de la vente et le grain résiduel entre 40 membres.

On-chain.

1. Les membres livrent dans le pool : chaque livraison est un createBatch au profit du membre, puis transform(member, coop, [ids], [amounts], [pool spec], [amount], ref("POOL-2026")) fusionne dans le lot du pool (réorganisation de lots, aucun rôle nécessaire si la denrée et l'unité sont identiques).
2. parentsOf(pool) énumère chaque livraison de membre — la clé de répartition est on-chain.
3. Vente du pool à un acheteur : un seul safeTransferFrom.
4. Résidus : transform(coop, coop, [pool], [remaining], [40 outputs], [per-member amounts], ref("RESIDUAL")) puis safeBatchTransferFrom vers les membres.

Pourquoi c'est important. La mutualisation et la démutualisation, qui résident aujourd'hui dans les registres des coopératives, sont des opérations de filiation avec des quantités exactes.

6. Rappel

Situation. Un laboratoire détecte de l'aflatoxine au-delà de la limite dans un lot de maïs déjà fractionné et en partie transformé.

On-chain.

1. Le laboratoire (émetteur de confiance pour LAB:AFLATOXIN) atteste le résultat : attest(id, LAB:AFLATOXIN, hash(report), 0).
2. La plateforme retire le lot : setBatchStatus(id, 255, ref("RECALL-2026-07")) ; les transferts s'arrêtent immédiatement (ARexBatchRetired), les destructions restent possibles.
3. Traçage aval : chaque événement BatchTransformed dont les inputIds contiennent id fournit les lots enfants ; récursivement, les lots d'aliments pour animaux et de denrées alimentaires affectés. Traçage amont : parentsOf.
4. Le régulateur reçoit la liste des identifiants et des détenteurs concernés à partir du journal d'événements — l'exigence des 24 heures est satisfaite par une requête d'indexeur, et non par une recherche dans des archives.

Pourquoi c'est important. La portée d'un rappel est une requête de graphe sur des événements standardisés, ce que le CTE de transformation de FSMA 204 a été conçu pour rendre possible.

Ce que ces scénarios ont en commun

• Quatre interfaces, trois hooks de référence et le registre d'attestations couvrent les six ; aucun scénario n'a exigé de modification du standard.
• Les instruments juridiques (récépissés, CPR-e, DDS, rapports de laboratoire) sont référencés et hachés, non réimplémentés.
• La mise en application (gel, transfert forcé, retrait) est présente dans chaque scénario de financement et de conformité et constitue toujours un événement.
• Les données personnelles n'apparaissent jamais on-chain.