Casos de uso

1. Grano almacenado y certificados de depósito

Situación. Un centro de acopio cooperativo recibe 250 t de trigo de un socio y emite un certificado de depósito. Más adelante vende el lote en dos partes.

En la cadena.

1. createBatch({commodity: HS:100199, unit: KGM, producedAt: harvest, expiresAt: 0, originRef: hash(certificate #CD-88213), metadataHash, uri}, 250_000, member): el token hace referencia al certificado legal, pero no lo reemplaza mientras la jurisdicción no lo disponga.
2. El centro de acopio llama a setBatchStatus(id, 1 /* IN_STORAGE */, ref("SILO-3")) con STATUS_ROLE.
3. transform(member, buyerA, [id], [100_000], [same commodity/unit], [100_000], ref("SALE-1")): es una reagrupación, así que no requiere rol; parentsOf(newId) == [id].
4. La segunda venta sigue el mismo camino. Las 50 t restantes quedan en el id original.
5. Cuando el comprador retira el grano, se queman sus unidades con burn(buyerA, newId, 100_000). El centro de acopio da de baja el lote padre cuando queda vacío.

Por qué importa. El suministro total es exacto (totalSupply), la procedencia queda registrada como una cadena de eventos BatchTransformed y el registro de certificados sigue siendo la fuente oficial.

2. Financiamiento antes de la cosecha (CPR, contrato a término, warrant sobre cosecha futura)

Situación. Un productor brasileño emite una CPR electrónica por 1,000 t de soja que cosechará en abril. Un prestamista le adelanta fondos con esa CPR como respaldo.

En la cadena.

1. createBatch({commodity: HS:120190, unit: TNE, producedAt: 0, expiresAt: 0, originRef: hash(CPR-e registry id), …}, 1000, producer): con producedAt == 0, el estándar representa un lote futuro.
2. ExpiryHook(allowPreHarvestTransfers = true) permite ceder el derecho de cobro. Un marketplace de entrega inmediata lo desplegaría con false.
3. La garantía del prestamista: ENFORCER_ROLE llama a setFrozenTokens(producer, id, 1000), es decir, la plataforma actúa según el contrato de prenda. El productor sigue siendo el dueño, pero no puede mover las unidades.
4. En la cosecha: setBatchMetadata con la boleta de pesaje y luego setBatchStatus(id, 2 /* HARVESTED */). La plataforma registra producedAt en los metadatos, porque ese campo en la cadena es inmutable por diseño; el hecho que queda en la cadena es el cambio de estado.
5. Si el productor paga: setFrozenTokens(producer, id, 0). Si incumple: forcedTransfer(producer, lender, id, 1000) según la prenda.

Por qué importa. Los dos eventos de crédito más comunes en el agro, la prenda y su ejecución, se resuelven con dos llamadas. Ambas son auditables y compatibles con el concepto de «control» del Artículo 12 del UCC y con los instrumentos que se inscriben en registros.

3. Exportación de café según el EUDR

Situación. Un exportador colombiano envía 20 t de café verde a un tostador de Hamburgo después del 30 de diciembre de 2026.

En la cadena.

1. createBatch({commodity: HS:090111, unit: KGM, producedAt: harvest, originRef: hash(DDS reference), …}, 20_000, exporter). Los polígonos de las parcelas quedan en el Sistema de Información de la UE y en el almacenamiento restringido del exportador.
2. El oficial de cumplimiento del exportador es emisor de confianza para el tema EUDR:DDS y emite la atestación (certificado o constancia verificable): attest(id, EUDR:DDS, hash(DDS reference), 0).
3. El token tiene AttestationHook (HS:090111 → EUDR:DDS): toda transferencia de café sin la atestación devuelve ATTESTATION_MISSING.
4. Venta: safeTransferFrom(exporter, roaster, id, 20_000, data). El tostador, como operador posterior en la cadena de suministro, conserva la referencia de la DDS durante cinco años: la tiene en los metadatos del lote que ahora posee.
5. Tostado: transform(roaster, roaster, [id], [20_000], [{commodity: HS:090121, …}], [16_800], ref("ROAST-2027-03")). Los lotes padre del café tostado apuntan al lote verde y, a través de él, a la DDS.

Por qué importa. La cadena de referencias que exige el reglamento se mantiene después del procesamiento. Y los datos geográficos que, según el EDPB, no deben estar en una cadena pública nunca llegan a ella.

4. Productos perecederos y cadena de frío

Situación. Un empacador envía fresas con una vida útil de 12 días. Durante el transporte se registra una desviación de temperatura.

En la cadena.

1. createBatch({commodity: GTIN:…, unit: BX, producedAt: packDate, expiresAt: packDate + 12 days, …}, 4_800, packer). Los metadatos incluyen el código de lote de trazabilidad de la FSMA asignado en el empaque inicial.
2. ExpiryHook bloquea toda transferencia después de expiresAt (BATCH_EXPIRED). Las quemas siguen permitidas para dar de baja la mercadería.
3. Un hook de cadena de frío (DeliveryHook) devuelve IN_TRANSIT durante el transporte y registra los puntos de control en onExecuted.
4. El operador logístico atesta la desviación con attest(id, COLDCHAIN:EXCURSION, hash(sensor log), 0). Un hook del lado del comprador puede rechazar la recepción (política de canReceive), o las partes pueden resolverlo fuera de la cadena con la atestación como evidencia.
5. Entrega: el receptor ejecuta burn, o el empacador ejecuta setBatchStatus(id, 255 /* RETIRED */, ref("DELIVERED")).

Por qué importa. La vida útil, la custodia y los incidentes de calidad son tres hooks independientes sobre un mismo registro de lote. Ninguno obligó a modificar el token.

5. Acopio cooperativo y liquidación a los socios

Situación. Una cooperativa comercializa un lote común de 1,000 t y debe repartir entre 40 socios los ingresos y el grano sobrante.

En la cadena.

1. Los socios entregan al lote común. Cada entrega es un createBatch a favor del socio, seguido de transform(member, coop, [ids], [amounts], [pool spec], [amount], ref("POOL-2026")), que la fusiona en el lote común (es una reagrupación y no requiere rol si el producto y la unidad coinciden).
2. parentsOf(pool) lista todas las entregas de los socios, así que la clave de reparto queda en la cadena.
3. La venta del lote común a un comprador es un solo safeTransferFrom.
4. Sobrantes: transform(coop, coop, [pool], [remaining], [40 outputs], [per-member amounts], ref("RESIDUAL")) y luego safeBatchTransferFrom a los socios.

Por qué importa. Armar y desarmar un lote común, algo que hoy vive en los libros de cada cooperativa, se vuelve una operación de linaje con cantidades exactas.

6. Retiro del mercado

Situación. Un laboratorio detecta aflatoxina por encima del límite en un lote de maíz que ya se dividió y se procesó en parte.

En la cadena.

1. El laboratorio, emisor de confianza para LAB:AFLATOXIN, atesta el resultado con attest(id, LAB:AFLATOXIN, hash(report), 0).
2. La plataforma da de baja el lote con setBatchStatus(id, 255, ref("RECALL-2026-07")). Las transferencias se detienen de inmediato (ARexBatchRetired), pero las quemas (destrucción) siguen permitidas.
3. Rastreo hacia adelante: cada BatchTransformed cuyos inputIds incluyen id devuelve los lotes hijos y, de forma recursiva, los lotes de alimento animal y de alimentos afectados. Rastreo hacia atrás: parentsOf.
4. El regulador recibe, a partir del registro de eventos, la lista de ids y titulares afectados. El plazo de 24 horas se cumple con una consulta al indexador, no con una búsqueda en archivos.

Por qué importa. El alcance de un retiro del mercado es una consulta sobre un grafo de eventos estandarizados. Para eso se diseñó el CTE de transformación de la FSMA 204.

Qué tienen en común estos escenarios

• Cuatro interfaces, tres hooks de referencia y el registro de atestaciones cubren los seis escenarios; ninguno requirió cambiar el estándar.
• Los instrumentos legales (certificados, CPR-e, DDS, informes de laboratorio) se referencian y se registran por su hash; no se vuelven a implementar.
• Los controles de cumplimiento (congelar, transferencia forzosa, dar de baja) aparecen en todos los escenarios de financiamiento y cumplimiento, y siempre generan un evento.
• Los datos personales nunca aparecen en la cadena.