· Hernán Pérez Rodal · Engineering · 5 min read
Por que colocamos rastreabilidade on-chain: FSMA 204 compliance no nível de protocolo
A maioria das plataformas de rastreabilidade usa blockchain como marketing. Contamos como e por que na Darwin usamos a nível arquitetural — e quando NÃO faz sentido.
TL;DR — Na Darwin construímos 12 smart contracts sobre Polygon PoS + OP Stack L2 para identity, governance, DID registry e inventário NFT-based. Não é blockchain-washing: é a camada de integridade para conformidade regulatória. Este post conta o que colocamos on-chain, o que deixamos off-chain, e por quê.
O problema que o banco de dados não resolve
FSMA 204 exige que cada Critical Tracking Event (CTE) seja rastreável, íntegro e verificável por anos. Uma pergunta óbvia: por que não guardar tudo em um DB tradicional?
Porque quando a FDA, um varejista ou um auditor independente pergunta:
“Como sabemos que os CTEs que vocês mostram hoje são os mesmos que foram registrados quando o evento aconteceu?”
Em um DB centralizado, a resposta é: “confie no nosso sistema”. Em produção, isso não basta para:
- Audits multi-tier — o varejista não confia no DB do produtor
- Recalls cross-organization — os atores não compartilham infraestrutura
- Compliance com retenção de anos — os dados devem permanecer verificáveis mesmo se uma empresa quebrar
Blockchain resolve isso sem “trust me, bro”. Mas só para os campos corretos.
O que colocamos on-chain (e o que NÃO)
✅ On-chain: o que define integridade
| Componente | Por que on-chain |
|---|---|
| Identity (DID registry) | Cada ator (produtor, planta, transportadora) tem identidade verificável sem depender de uma autoridade central |
| Governance | Regras de quem pode assinar que tipo de CTE, atualizáveis via multisig com audit trail |
| NFT-based inventory | Cada lote = um NFT único com histórico imutável; transferências refletem o movimento físico |
| Attestations críticas | Hashes de CTEs-chave, assinaturas digitais, timestamps — o mínimo para provar integridade sem expor dado sensível |
| FSMA 204 compliance anchors | Checkpoints verificáveis que um auditor pode reconstruir sem acesso à nossa infraestrutura |
❌ Off-chain: o que on-chain quebra
| Componente | Por que off-chain |
|---|---|
| Dado sensível | Nomes, fornecedores, preços, formulações — nada que viole privacidade se for exposto |
| Bulk events | Milhões de CTEs/ano on-chain seriam proibitivamente caros |
| Mídia pesada | Fotos, PDFs, evidência digital — vivem no Cloud Storage, on-chain só o hash |
| Regras de negócio dinâmicas | Risk scoring, ML anomaly detection — off-chain, atualizáveis |
| UI state / preferências | Firebase, cache, sessions — nada que precise ser imutável |
A regra que usamos: on-chain só o que precisa ser publicamente verificável + imutável + cross-organization. Tudo mais é latência e custo desnecessários.
A arquitetura: 12 smart contracts
Nos apoiamos em Polygon PoS para throughput + custo baixo, e OP Stack L2 para operações que exigem settlement ao Ethereum L1.
Os contratos principais:
1. Identity layer
DIDRegistry.sol— Decentralized identifiers por ator (spec W3C DID)RoleManager.sol— Papéis, permissões e delegações com audit trailAttestationRegistry.sol— Assinaturas criptográficas de CTEs-chave
2. Governance
Governance.sol— Multisig para updates de regrasPolicyEngine.sol— Regras de assinatura por tipo de evento (quem pode assinar o quê)
3. Inventory + Traceability
InventoryNFT.sol— ERC-721 estendido: cada lote é um NFT com metadata de CTEsTransferLogger.sol— Movimentos físicos refletidos como transfers on-chainBatchSplitting.sol— Split/merge de lotes preservando lineage
4. Compliance
ComplianceAnchor.sol— Ancora checkpoints FSMA 204 + EUDR com timestampRecallRegistry.sol— Recalls cross-organization, verificáveis por qualquer umDocumentRegistry.sol— Hashes de evidência digital (PDFs, fotos, Due Diligence Statements)
5. Integration
BridgeL1.sol— Finalização seletiva ao Ethereum L1 para eventos críticos (reduz custos mantendo integridade máxima no essencial)
O que não funcionou
Colocar tudo on-chain na V0. Primeira tentativa: todos os CTEs on-chain. Resultado: US$ 0,10-0,30 por evento, e milhares de eventos/dia → orçamento fora de controle. Corrigimos na V1 com o princípio “só checkpoints + hashes”.
Contratos monolíticos. Começamos com um único contract “Traceability.sol” que fazia tudo. Impossível de atualizar sem quebrar referências. Refatoramos em 12 contracts com upgradeable proxies (pattern UUPS).
On-chain identity sem fallback off-chain. Quando um produtor rural perdia sua wallet, perdia identidade. Adicionamos um mecanismo de recuperação via DID governance multisig — você não compromete descentralização, mas dá continuidade operacional.
O que sim funcionou
Separação clara on-chain/off-chain pelo princípio de “necessidade de verificabilidade”.
UUPS upgradeable proxies — podemos evoluir os contratos preservando história e referências.
NFT por lote, não por evento — o lote como entidade atômica on-chain; os eventos relacionados off-chain mas com hash verificável. Equilíbrio entre custo e integridade.
Bridge seletivo L1 — só attestations críticas chegam ao Ethereum L1. O resto vive na L2. Custo 100x menor, integridade 95% equivalente.
Integração com varejistas — quando o Walmart pede audit, eles podem verificar nossos checkpoints on-chain sem precisar de acesso aos nossos sistemas. Isso muda o jogo para supply chain compliance.
Quando blockchain NÃO faz sentido
Para ser honesto: a maioria das features de rastreabilidade NÃO precisa de blockchain.
Se seu caso é:
- Rastreabilidade interna dentro de uma única empresa → DB basta
- Poucos atores de confiança que já compartilham infra → BD centralizado + assinaturas digitais basta
- Dados que mudam frequentemente → você não quer imutabilidade
- Requisitos de baixa criticidade que não passam auditoria → overhead desnecessário
Blockchain faz sentido quando você precisa que terceiros possam verificar integridade sem confiar em você. Para todo o resto, simplifique.
Lessons learned
- On-chain ≠ tudo on-chain — use-a só para o que precisa de verificabilidade cross-organization
- NFT-based inventory escala melhor que event-based — lote como átomo, eventos como hashes ligados
- Os L2s são o sweet spot — custo baixo, segurança alta para a maioria dos casos; bridge seletivo ao L1 para o crítico
- Upgradeable proxies desde o dia 0 — o custo inicial paga de sobra quando você precisa iterar
- Reserve governance off-chain também — multisig on-chain + processos operacionais claros off-chain
E agora?
Estamos explorando zero-knowledge proofs para evidência de compliance sem expor dados sensíveis. O caso: que um varejista possa verificar que um lote cumpre certos critérios (origem, certificação, não-desmatamento) sem precisar acessar todos os dados do produtor.
Se você está construindo rastreabilidade para supply chain regulada e está em dúvida entre DB pura ou blockchain, meu conselho é: comece identificando quais dados precisam de verificabilidade cross-organization. Esse subconjunto vai on-chain. O resto, não.
Está avaliando blockchain para rastreabilidade? Vamos conversar — podemos compartilhar arquitetura e te ajudar a decidir se o caso justifica (às vezes a resposta é “não, e tudo bem”).
