Casos de uso

1. Grano almacenado y recibos de almacén

Situación. Un elevador cooperativo recibe 250 t de trigo de un socio, emite un certificado de depósito y más tarde 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 referencia el recibo legal; no lo sustituye hasta que la jurisdicción así lo establezca.
2. setBatchStatus(id, 1 /* IN_STORAGE */, ref("SILO-3")) por parte del elevador (STATUS_ROLE).
3. transform(member, buyerA, [id], [100_000], [same commodity/unit], [100_000], ref("SALE-1")): una reagrupación, sin necesidad de rol; parentsOf(newId) == [id].
4. La segunda venta se hace igual; las 50 t restantes permanecen en el id original.
5. En la salida física del grano, las unidades del comprador se queman: burn(buyerA, newId, 100_000); el elevador retira el lote progenitor cuando queda vacío.

Por qué importa. El suministro es exacto (totalSupply), la procedencia es una cadena de eventos BatchTransformed y el registro de recibos sigue siendo el que prevalece.

2. Financiación de precosecha (CPR, contrato a plazo, warrant sobre cosecha futura)

Situación. Un productor brasileño emite una CPR electrónica por 1,000 t de soja que se cosechará en abril; un prestamista adelanta fondos con cargo a ella.

En la cadena.

1. createBatch({commodity: HS:120190, unit: TNE, producedAt: 0, expiresAt: 0, originRef: hash(CPR-e registry id), …}, 1000, producer): producedAt == 0 es la representación que hace el estándar de un lote futuro.
2. ExpiryHook(allowPreHarvestTransfers = true) para que el derecho de cobro pueda cederse; un mercado al contado lo desplegaría con false.
3. La garantía mobiliaria del prestamista: setFrozenTokens(producer, id, 1000) por parte de ENFORCER_ROLE (la plataforma que actúa en virtud del contrato de prenda). El productor conserva la titularidad, pero no puede mover las unidades.
4. En la cosecha: setBatchMetadata con el ticket de pesaje; setBatchStatus(id, 2 /* HARVESTED */); la plataforma registra producedAt en los metadatos (el campo en la cadena es inmutable por diseño; el cambio de estado es el hecho en la cadena).
5. Reembolso: setFrozenTokens(producer, id, 0). Incumplimiento: forcedTransfer(producer, lender, id, 1000) en virtud de la prenda.

Por qué importa. Los dos eventos de crédito más habituales en la agricultura, la prenda y su ejecución, son dos llamadas, ambas auditables, ambas compatibles con el «control» del Artículo 12 de la UCC y con los instrumentos basados en registros.

3. Exportación de café bajo 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 permanecen en el Sistema de Información de la UE y en el almacenamiento restringido del exportador.
2. El responsable de cumplimiento del exportador es un emisor de confianza para el tema EUDR:DDS: attest(id, EUDR:DDS, hash(DDS reference), 0).
3. AttestationHook.setRequirement(HS:090111, EUDR:DDS) en el token: las transferencias de café sin la atestación devuelven ATTESTATION_MISSING.
4. Venta: safeTransferFrom(exporter, roaster, id, 20_000, data); el tostador, como operador posterior, conserva la referencia de la DDS durante cinco años: figura 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 progenitores del lote tostado apuntan al lote verde y, a través de este, a la DDS.

Por qué importa. La cadena de referencias del reglamento sobrevive al procesamiento, y los datos geográficos que, según el EDPB, no deben estar en una cadena pública nunca lo están.

4. Productos perecederos y cadena de frío

Situación. Un envasador envía fresas con una vida útil de 12 días; durante el tránsito 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 envasado inicial.
2. ExpiryHook bloquea cualquier transferencia posterior a expiresAt (BATCH_EXPIRED); las quemas siguen siendo posibles para la baja contable.
3. Un hook de cadena de frío (DeliveryHook) devuelve IN_TRANSIT durante el transporte y registra puntos de control en onExecuted.
4. La desviación es atestada por el proveedor logístico: 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 lo resuelven fuera de la cadena, con la atestación como evidencia.
5. Entrega: burn por parte del receptor, o setBatchStatus(id, 255 /* RETIRED */, ref("DELIVERED")) por parte del envasador.

Por qué importa. La vida útil, la custodia y las incidencias de calidad son tres hooks independientes sobre un mismo registro de lote; ninguno de ellos exigió un cambio en el token.

5. Distribución cooperativa y liquidación a los socios

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

En la cadena.

1. Los socios entregan al lote agrupado: cada entrega es un createBatch al socio, y después transform(member, coop, [ids], [amounts], [pool spec], [amount], ref("POOL-2026")) que fusiona en el lote agrupado (reagrupación, sin necesidad de rol si el producto básico y la unidad son los mismos).
2. parentsOf(pool) enumera todas las entregas de los socios: la clave de reparto está en la cadena.
3. Venta del lote agrupado a un comprador: un único safeTransferFrom.
4. Remanentes: transform(coop, coop, [pool], [remaining], [40 outputs], [per-member amounts], ref("RESIDUAL")) y safeBatchTransferFrom a los socios.

Por qué importa. La agrupación y la desagrupación, que hoy residen en los libros de las cooperativas, son operaciones de linaje con cantidades exactas.

6. Retirada de producto del mercado

Situación. Un laboratorio detecta aflatoxina por encima del límite en un lote de maíz que ya había sido dividido y parcialmente procesado.

En la cadena.

1. El laboratorio (emisor de confianza para LAB:AFLATOXIN) atesta el resultado: attest(id, LAB:AFLATOXIN, hash(report), 0).
2. La plataforma retira el lote: setBatchStatus(id, 255, ref("RECALL-2026-07")); las transferencias se detienen de inmediato (ARexBatchRetired), las quemas (destrucción) siguen siendo posibles.
3. Rastreo hacia adelante: cada BatchTransformed cuyos inputIds contienen id arroja los descendientes; de forma recursiva, los lotes afectados de piensos y alimentos. Rastreo hacia atrás: parentsOf.
4. El regulador recibe del registro de eventos la lista de ids y titulares afectados: el requisito de 24 horas se cumple con una consulta a un indexador, no con una búsqueda de registros.

Por qué importa. El alcance de una retirada de producto es una consulta de grafos sobre eventos estandarizados, que es lo que el CTE de transformación de la FSMA 204 se diseñó para hacer posible.

Qué tienen en común estos escenarios

• Cuatro interfaces, tres hooks de referencia y el registro de atestaciones cubren los seis; ningún escenario necesitó un cambio en el estándar.
• Los instrumentos jurídicos (recibos, CPR-e, DDS, informes de laboratorio) se referencian y se registran mediante su hash, no se reimplementan.
• La ejecución forzosa (congelación, transferencia forzosa, retiro) está presente en todos los escenarios de financiación y de cumplimiento y es siempre un evento.
• Los datos personales nunca aparecen en la cadena.