On-chain vs off-chain

A frequent objection from technical buyers: “if it’s on a blockchain, my trade secrets leak.” This page explains why that’s not the case, and what the platform actually puts on-chain.

TL;DR

• On-chain: hashes, custody checkpoints, identity (DIDs).
• Off-chain: business data, specs, costs, photos, PII, raw documents.

Verifiability without exposing content. Like Git: the SHA proves integrity; the diff lives in your repo.

What goes on-chain

Critical event hashes

Each captured event produces a canonical JSON payload. Tracium hashes it (SHA-256) and writes the hash to the TraceEvents contract. The hash + timestamp + actor DID is what’s on-chain.

The original payload (the photo, the operator name, the geolocation, the lot weight) stays in the operational database and content-addressed storage under tenant-scoped access control.

Custody checkpoints

When an organization transfers custody to another (e.g. tier-2 ships to tier-1), the on-chain record captures:

• Source DID
• Destination DID
• Lot identifier (TLC)
• Timestamp
• Hash of the custody-transfer document

The pricing terms, contract conditions, and shipping details stay off-chain.

Identity (DIDs)

Tenant + organization DIDs are public. The DID itself doesn’t reveal anything sensitive: it’s just a cryptographic identifier. Same as a public key.

NFT metadata pointers

Each product / batch / passport has an NFT. The NFT’s metadata field is an IPFS CID pointing to the canonical JSON for that lot. The CID is public; access to fetch the content from IPFS can be gated (private gateway) or public (public gateway).

For consumer-facing passports (Fidenta), metadata is public on purpose. That’s the value prop. For B2B compliance docs, metadata stays behind authentication.

What stays off-chain

Business data

• Product specs (recipes, formulas, materials, BOMs)
• Pricing, margins, contracts, commercial terms
• Process parameters (temperature curves, milling settings, dye ratios)

People data

• Operator names, employee identifiers
• Smallholder personal info (name, geolocation of home, family, etc.)
• Auditor identities (certifier names, seal numbers)

Raw evidence

• Photos and documents (stored in object and content-addressed storage, gated by tenant)
• Lab reports, certification documents
• Customs paperwork

Why this split

Audit-grade verifiability:

• An auditor can verify a custody chain without seeing trade secrets. They check that the on-chain hash matches the document the producer hands them. No content leaks.

Multi-party trust:

• Different organizations can prove they handled a lot without agreeing on a shared database. The chain is the source of truth for custody; each org keeps its own data.

Storage efficiency:

• Blockchain storage is expensive and permanent. Putting a 5MB photo on-chain is wrong; putting its 32-byte SHA-256 hash on-chain is right.

Privacy compliance:

• GDPR + similar regulations require data deletion on request. Personal data that goes on-chain is permanent and can’t be deleted, which is a GDPR violation. Personal data goes off-chain, where it can be redacted.

Verification without exposure

A typical audit flow:

1. Auditor requests a Due Diligence Statement for shipment TLC-2026-A1.
2. Compliance officer pulls the bundle from Tracium (off-chain).
3. Bundle includes: events list + IPFS CIDs + on-chain transaction hashes.
4. Auditor independently:
   • Hashes the document → matches the on-chain hash ✓
   • Resolves the IPFS CID → matches the document ✓
   • Verifies the actor DIDs against the chain ✓
5. Auditor signs off. Producer never had to expose business data the auditor doesn’t need.

What the contracts look like

The 13 smart contracts split:

• Identity (7): Tenant, Organization, Person, Permissions, DID resolver, name registry.
• Process (4): NFT inventory, trace events, process map, custody.
• Templates (2): per-instance template factories.

ABIs and deployed addresses are exposed in the API reference.