· Hernán Pérez Rodal · Engineering · 5 min read
Why we put traceability on-chain: FSMA 204 compliance at the protocol level
Most traceability platforms use blockchain as marketing. We share how and why we use it architecturally at Darwin, and when it does NOT make sense.
TL;DR: At Darwin we built 13 smart contracts on Polygon PoS + OP Stack L2 for identity, governance, DID registry and NFT-based inventory. This is not blockchain-washing: it’s the integrity layer for regulatory compliance. This post covers what we put on-chain, what we kept off-chain, and why.
The problem a database can’t solve
FSMA 204 requires every Critical Tracking Event (CTE) to be traceable, integral and verifiable for years. The obvious question: why not store everything in a traditional DB?
Because when the FDA, a retailer, or an independent auditor asks:
“How do we know the CTEs you’re showing us today are the same ones that were recorded when the event happened?”
In a centralized DB, the answer is: “trust our system.” In production, that’s not enough for:
- Multi-tier audits: the retailer doesn’t trust the producer’s DB
- Cross-organization recalls: the actors don’t share infrastructure
- Multi-year retention compliance: the data must remain verifiable even if a company goes out of business
Blockchain solves this without “trust me, bro.” But only for the right fields.
What we put on-chain (and what NOT)
✅ On-chain: what defines integrity
| Component | Why on-chain |
|---|---|
| Identity (DID registry) | Each actor (producer, plant, carrier) has verifiable identity without depending on a central authority |
| Governance | Rules on who can sign what kind of CTE, updatable via multisig with audit trail |
| NFT-based inventory | Each lot = a unique NFT with immutable history; transfers mirror physical movement |
| Critical attestations | Hashes of key CTEs, digital signatures, timestamps, the minimum to prove integrity without exposing sensitive data |
| FSMA 204 compliance anchors | Verifiable checkpoints an auditor can reconstruct without access to our infrastructure |
❌ Off-chain: what on-chain breaks
| Component | Why off-chain |
|---|---|
| Sensitive data | Names, suppliers, prices, formulations, nothing that would violate privacy if exposed |
| Bulk events | Millions of CTEs/year on-chain would be prohibitively expensive |
| Heavy media | Photos, PDFs, digital evidence, live in Cloud Storage, on-chain only the hash |
| Dynamic business rules | Risk scoring, ML anomaly detection, off-chain, updatable |
| UI state / preferences | Firebase, cache, sessions, nothing that needs to be immutable |
The rule we use: on-chain only what needs to be publicly verifiable + immutable + cross-organization. Everything else is unnecessary latency and cost.
The architecture: 13 smart contracts
We picked Polygon PoS for throughput + low cost, and OP Stack L2 for operations that need Ethereum L1 settlement.
The main contracts:
1. Identity layer
DIDRegistry.sol, Decentralized identifiers per actor (W3C DID spec)RoleManager.sol, Roles, permissions and delegations with audit trailAttestationRegistry.sol, Cryptographic signatures of key CTEs
2. Governance
Governance.sol, Multisig for rule updatesPolicyEngine.sol, Signing rules by event type (who can sign what)
3. Inventory + Traceability
InventoryNFT.sol, Extended ERC-721: each lot is an NFT with CTE metadataTransferLogger.sol, Physical movements mirrored as on-chain transfersBatchSplitting.sol, Split/merge of lots preserving lineage
4. Compliance
ComplianceAnchor.sol, Anchors FSMA 204 + EUDR checkpoints with timestampRecallRegistry.sol, Cross-organization recalls, verifiable by anyoneDocumentRegistry.sol, Hashes of digital evidence (PDFs, photos, Due Diligence Statements)
5. Integration
BridgeL1.sol, Selective finalization to Ethereum L1 for critical events (cuts cost while keeping max integrity on what matters)
What didn’t work
Putting everything on-chain in V0. First attempt: all CTEs on-chain. Result: $0.10-0.30 per event, and thousands of events/day → out-of-control budget. We fixed it in V1 with the “checkpoints + hashes only” principle.
Monolithic contracts. We started with a single “Traceability.sol” that did everything. Impossible to upgrade without breaking references. We refactored into 13 modular contracts; UUPS upgradeable proxies on the stateful critical ones (InventoryNFT, ProductPassportRegistry), the rest progressing with a planned upgrade path.
On-chain identity without off-chain fallback. When a rural producer lost their wallet, they lost identity. We added a recovery mechanism via DID governance multisig: you don’t compromise decentralization, but you give operational continuity.
What did work
Clear on-chain/off-chain separation by the “need for verifiability” principle.
UUPS upgradeable proxies on stateful critical contracts: we can evolve InventoryNFT and the passport registry while preserving history and references.
NFT per lot, not per event: the lot as an atomic on-chain entity; related events off-chain but with verifiable hash. A balance between cost and integrity.
Selective L1 bridge: only critical attestations reach Ethereum L1. The rest lives on L2. 100x cheaper, 95% equivalent integrity.
Retailer integration: when Walmart asks for an audit, they can verify our on-chain checkpoints without needing access to our systems. That changes the game for supply chain compliance.
When blockchain does NOT make sense
To be honest: most traceability features do NOT need blockchain.
If your case is:
- Internal traceability within a single company → a DB is enough
- A few trusted actors who already share infrastructure → centralized DB + digital signatures is enough
- Data that changes frequently → you don’t want immutability
- Low-criticality requirements that don’t go through audit → unnecessary overhead
Blockchain makes sense when you need third parties to verify integrity without trusting you. For everything else, simplify.
Lessons learned
- On-chain ≠ everything on-chain: use it only for what needs cross-organization verifiability
- NFT-based inventory scales better than event-based: lot as atom, events as linked hashes
- L2s are the sweet spot: low cost, high security for most cases; selective bridge to L1 for the critical stuff
- Upgradeable proxies from day 0: the upfront cost pays off many times over when you need to iterate
- Also keep governance off-chain: on-chain multisig + clear operational processes off-chain
What’s next?
We’re exploring zero-knowledge proofs for compliance evidence without exposing sensitive data. The case: a retailer can verify that a lot meets certain criteria (origin, certification, deforestation-free) without needing access to all the producer’s data.
If you’re building traceability for regulated supply chain and deciding between pure DB or blockchain, my advice is: start by identifying which data needs cross-organization verifiability. That subset goes on-chain. The rest, doesn’t.
Are you evaluating blockchain for traceability? Let’s talk, we can share architecture and help you decide whether the case justifies it (sometimes the answer is “no, and that’s fine”).
