When we set out to add blockchain provenance to Vetra Model Farm, the obvious choice was a single public chain — EVM-compatible, well-documented, and with solid tooling. But a pure public chain approach had a fundamental problem: our clients don't want their operational data (daily health observations, feed costs, internal animal transfers) permanently visible on a public ledger.
The Dual-Layer Approach
We settled on a two-layer architecture that separates operational data from public verifiability:
- Layer 1 — Hyperledger Fabric: A private permissioned blockchain where every material farm event (health observation, ownership transfer, weight record) is logged. Access is restricted to the farm operator and their authorised parties (banks, insurers, government).
- Layer 2 — Polygon EVM: A public EVM-compatible chain where we mint ERC-721 NFTs that serve as export passports. Each NFT contains only the hash of the Fabric record — no raw data, just a cryptographic commitment.
The Integration Layer
Between Django and the blockchain layers sits a Spring Boot service that handles the async choreography. RabbitMQ topic exchanges route events from the Django application to the blockchain service, which:
- Submits the event to the Hyperledger Fabric chaincode via the Fabric Gateway SDK.
- Uploads supporting media (photos, documents) to IPFS via Pinata.
- On export certification, mints an ERC-721 NFT on Polygon using Web3j, embedding the Fabric transaction hash and IPFS CID.
Why This Works
The result is a system where operational data stays private and performant (Fabric can handle thousands of transactions per second), while public verifiability is achieved through the Polygon NFT. A buyer or government inspector can verify the authenticity of an export certificate without ever accessing the farm's internal records.
Dead-letter queues on RabbitMQ ensure that blockchain failures don't take down the core application — the farm keeps running, and blockchain writes are retried asynchronously.