· Hernán Pérez Rodal · Engineering · 5 min read
Por qué pusimos trazabilidad on-chain: FSMA 204 compliance a nivel protocolo
La mayoría de las plataformas de trazabilidad usan blockchain como marketing. Contamos cómo y por qué en Darwin la usamos a nivel arquitectónico — y cuándo NO tiene sentido.
TL;DR — En Darwin construimos 12 smart contracts sobre Polygon PoS + OP Stack L2 para identity, governance, DID registry e inventario NFT-based. No es blockchain-washing: es la capa de integridad para compliance regulatorio. Este post cuenta qué pusimos on-chain, qué dejamos off-chain, y por qué.
El problema que no se resuelve con bases de datos
FSMA 204 exige que cada Critical Tracking Event (CTE) sea rastreable, íntegro y verificable durante años. Una pregunta obvia: ¿por qué no guardar todo en una DB tradicional?
Porque cuando la FDA, un retailer, o un auditor independiente pregunta:
“¿Cómo sabemos que los CTEs que nos muestran hoy son los mismos que se registraron cuando el evento ocurrió?”
En una DB centralizada, la respuesta es: “confiá en nuestro sistema”. En producción, eso no alcanza para:
- Audits multi-tier — el retailer no confía en la DB del productor
- Recalls cross-organization — los actores no comparten infraestructura
- Compliance con retención de años — los datos deben seguir verificables incluso si una empresa quiebra
Blockchain resuelve esto sin “trust me, bro”. Pero solo para los campos correctos.
Qué pusimos on-chain (y qué NO)
✅ On-chain: lo que define integridad
| Componente | Por qué on-chain |
|---|---|
| Identity (DID registry) | Cada actor (productor, planta, transportista) tiene identidad verificable sin depender de una autoridad central |
| Governance | Reglas de quién puede firmar qué tipo de CTE, actualizables via multisig con audit trail |
| NFT-based inventory | Cada lote = un NFT único con historial inmutable; transferencias reflejan el movimiento físico |
| Attestations críticas | Hashes de CTEs clave, firmas digitales, timestamps — lo mínimo para probar integridad sin exponer data sensible |
| FSMA 204 compliance anchors | Checkpoints verificables que un auditor puede reconstruir sin acceso a nuestra infraestructura |
❌ Off-chain: lo que on-chain rompe
| Componente | Por qué off-chain |
|---|---|
| Data sensible | Nombres, proveedores, precios, formulaciones — nada que viole privacidad si se expone |
| Bulk events | Millones de CTEs/año en on-chain serían prohibitivamente caros |
| Media pesada | Fotos, PDFs, evidencia digital — viven en Cloud Storage, on-chain solo el hash |
| Reglas de negocio dinámicas | Risk scoring, ML anomaly detection — off-chain, actualizable |
| UI state / preferencias | Firebase, cache, sessions — nada que deba ser inmutable |
La regla que usamos: on-chain solo lo que necesita ser públicamente verificable + inmutable + cross-organization. Todo lo demás es latencia y costo innecesario.
La arquitectura: 12 smart contracts
Nos paramos en Polygon PoS para throughput + bajo costo, y OP Stack L2 para operaciones que requieren settlement a Ethereum L1.
Los contratos principales:
1. Identity layer
DIDRegistry.sol— Decentralized identifiers por actor (W3C DID spec)RoleManager.sol— Roles, permisos y delegaciones con audit trailAttestationRegistry.sol— Firmas criptográficas de CTEs clave
2. Governance
Governance.sol— Multisig para updates de reglasPolicyEngine.sol— Reglas de firma por tipo de evento (quién puede firmar qué)
3. Inventory + Traceability
InventoryNFT.sol— ERC-721 extendido: cada lote es un NFT con metadata de CTEsTransferLogger.sol— Movimientos físicos reflejados como transfers on-chainBatchSplitting.sol— Split/merge de lotes preservando lineage
4. Compliance
ComplianceAnchor.sol— Ancla checkpoints FSMA 204 + EUDR con timestampRecallRegistry.sol— Recalls cross-organization, verificable por cualquieraDocumentRegistry.sol— Hashes de evidencia digital (PDFs, fotos, Due Diligence Statements)
5. Integration
BridgeL1.sol— Finalización selectiva a Ethereum L1 para eventos críticos (reduce costos manteniendo integridad máxima en lo esencial)
Lo que no funcionó
Poner todo on-chain en la V0. Primer intento: todos los CTEs on-chain. Resultado: $0.10-0.30 por evento, y miles de eventos/día → presupuesto fuera de control. Corregimos en la V1 con el principio “solo checkpoints + hashes”.
Contratos monolíticos. Empezamos con un solo contract “Traceability.sol” que hacía todo. Imposible de actualizar sin romper referencias. Refactoreamos a 12 contracts con upgradeable proxies (UUPS pattern).
On-chain identity sin fallback off-chain. Cuando un productor rural perdía su wallet, perdía identidad. Agregamos un mecanismo de recuperación via DID governance multisig — no comprometés descentralización, pero das continuidad operativa.
Lo que sí funcionó
Separación clara on-chain/off-chain por principio de “necesidad de verificabilidad”.
UUPS upgradeable proxies — podemos evolucionar los contratos preservando historia y referencias.
NFT por lote, no por evento — el lote como entidad atómica on-chain; los eventos relacionados off-chain pero con hash verificable. Balance entre costo y integridad.
Bridge selectivo L1 — solo attestations críticas llegan a Ethereum L1. El resto vive en L2. Costo 100x menor, integridad 95% equivalente.
Integración con retailers — cuando Walmart pide audit, pueden verificar nuestros checkpoints on-chain sin necesidad de acceso a nuestros sistemas. Eso cambia el juego para supply chain compliance.
Cuándo blockchain NO tiene sentido
Para ser honesto: la mayoría de features de trazabilidad NO necesitan blockchain.
Si tu caso es:
- Trazabilidad interna dentro de una sola empresa → DB es suficiente
- Pocos actores de confianza que ya comparten infra → BD centralizada + firmas digitales alcanza
- Datos que cambian frecuentemente → no querés inmutabilidad
- Requerimientos de baja criticidad que no pasan auditoría → overhead innecesario
Blockchain tiene sentido cuando necesitás que terceros puedan verificar integridad sin confiar en vos. Para todo lo demás, simplificá.
Lessons learned
- On-chain ≠ todo on-chain — usalo solo para lo que necesita verificabilidad cross-organization
- NFT-based inventory escala mejor que event-based — lote como átomo, eventos como hashes enlazados
- L2s son el sweet spot — costo bajo, seguridad alta para la mayoría de casos; bridge selectivo a L1 para lo crítico
- Upgradeable proxies desde el día 0 — el costo inicial paga con creces cuando necesitás iterar
- Reserva governance off-chain también — multisig on-chain + procesos operativos claros off-chain
¿Y ahora?
Estamos explorando zero-knowledge proofs para evidencia de compliance sin exponer datos sensibles. El caso: que un retailer pueda verificar que un lote cumple ciertos criterios (origen, certificación, no-deforestación) sin necesidad de acceder a todos los datos del productor.
Si estás construyendo trazabilidad para supply chain regulado y dudás entre DB pura o blockchain, mi consejo es: empezá identificando qué datos necesitan verificabilidad cross-organization. Ese subset va on-chain. El resto, no.
¿Estás evaluando blockchain para trazabilidad? Hablemos — podemos compartir arquitectura y ayudarte a decidir si el caso lo justifica (a veces la respuesta es “no, y está bien”).
