On-chain vs off-chain

Una objeción frecuente de los compradores técnicos: “si está en una blockchain, mis secretos comerciales se filtran.” Esta página explica por qué eso no es así, y qué es lo que la plataforma efectivamente pone on-chain.

TL;DR

• On-chain: hashes, checkpoints de custodia, identidad (DIDs).
• Off-chain: datos de negocio, specs, costos, fotos, PII, documentos sin procesar.

Verificabilidad sin exponer contenido. La idea es la misma que en Git: el SHA prueba integridad, el diff vive en tu repositorio privado.

Qué va on-chain

Hashes de eventos críticos

Cada evento capturado produce un payload JSON canónico. Tracium lo hashea (SHA-256) y escribe el hash al contrato TraceEvents. Lo que queda on-chain es el hash + timestamp + DID del actor.

El payload original (con la foto, el nombre del operador, la geolocalización, el peso del lote) se queda en la base de datos operativa y en almacenamiento direccionable por contenido, bajo control de acceso delimitado por tenant.

Checkpoints de custodia

Cuando una organización transfiere custodia a otra (ej. tier-2 envía a tier-1), el record on-chain captura:

• DID de origen
• DID de destino
• Identificador de lote (TLC)
• Timestamp
• Hash del documento de transferencia de custodia

Las condiciones de precio, términos de contrato, y detalles de envío se quedan off-chain.

Identidad (DIDs)

Los DIDs de tenant + organización son públicos. El DID en sí mismo no revela nada sensible: es solo un identificador criptográfico. Igual que una clave pública.

Punteros de metadata NFT

Cada producto / batch / pasaporte tiene un NFT. El campo metadata del NFT es un IPFS CID que apunta al JSON canónico para ese lote. El CID es público; el acceso para obtener el contenido desde IPFS puede ser controlado (gateway privado) o público (gateway público).

Para pasaportes orientados al consumidor (Fidenta), la metadata es pública por diseño: ese es el valor del producto. Para documentos de compliance B2B, la metadata se queda detrás de autenticación.

Qué se queda off-chain

Datos de negocio

• Specs de producto (recetas, fórmulas, materiales, BOMs)
• Precios, márgenes, contratos, términos comerciales
• Parámetros de proceso (curvas de temperatura, ajustes de molienda, ratios de tintura)

Datos personales

• Nombres de operadores, identificadores de empleados
• Info personal de productores chicos (nombre, geolocalización del hogar, familia, etc.)
• Identidades de auditores (nombres de certificadores, números de sello)

Evidencia sin procesar

• Fotos y documentos en almacenamiento de objetos controlado por tenant
• Reportes de lab, documentos de certificación
• Documentación de aduanas

Por qué este split

Verificabilidad de grado auditoría:

• Un auditor puede verificar una cadena de custodia sin ver secretos comerciales. Chequea que el hash on-chain coincida con el documento que le entrega el productor. No se filtra contenido.

Confianza multi-actor:

• Diferentes organizaciones pueden probar que manejaron un lote sin acordar una base de datos compartida. La chain es la fuente de verdad para custodia; cada org mantiene sus propios datos.

Eficiencia de almacenamiento:

• El almacenamiento en blockchain es caro y permanente. Poner una foto de 5MB on-chain está mal; poner su hash SHA-256 de 32 bytes on-chain está bien.

Compliance de privacidad:

• GDPR + regulaciones similares requieren borrar datos a pedido. Los datos personales on-chain son permanentes y no se pueden borrar; eso es una violación de GDPR. Los datos personales van off-chain, donde se pueden redactar.

Verificación sin exposición

Un flujo típico de auditoría:

1. Auditor pide un Due Diligence Statement para el envío TLC-2026-A1.
2. Compliance officer extrae el paquete desde Tracium (off-chain).
3. El paquete incluye: lista de eventos + IPFS CIDs + hashes de transacciones on-chain.
4. El auditor independientemente:
   • Hashea el documento → coincide con el hash on-chain ✓
   • Resuelve el IPFS CID → coincide con el documento ✓
   • Verifica los DIDs de actores contra la chain ✓
5. El auditor firma. El productor nunca tuvo que exponer datos de negocio que el auditor no necesita.

Cómo se ven los contratos

Los 13 smart contracts se dividen:

• Identidad (7): Tenant, Organization, Person, Permissions, DID resolver, name registry.
• Proceso (4): NFT inventory, trace events, mapa de procesos, custodia.
• Plantillas (2): factories de plantillas por instancia.

Las ABIs y addresses por chain se exponen en la API reference.