A blockchain supply chain system records events about products (made, shipped, received, inspected, sold) on a ledger shared by the companies involved, so each can verify provenance without relying on one party's database. The ledger is the easy part; getting accurate data in, and getting competitors to participate, is where these projects succeed or fail.
What problem are you actually solving?
Supply chain blockchain projects usually target one of four goals. Being clear about which one is yours shapes everything else.
- Provenance and authenticity: proving origin to consumers or brands, for luxury goods, food or minerals.
- Regulatory traceability: demonstrating chain of custody to authorities, as in pharmaceuticals or food safety recalls.
- Process automation between companies: triggering payments or document release when shipments hit milestones.
- Sustainability and compliance reporting: supporting claims about emissions, sourcing or recycled content, increasingly relevant with the EU's Digital Product Passport requirements under its ecodesign rules.
The lesson from TradeLens
TradeLens, the shipping platform built by Maersk and IBM, was among the most ambitious supply chain blockchain efforts. It was shut down after its operators concluded it had not achieved the necessary industry-wide commercial collaboration. Competing carriers were reluctant to join a platform controlled by a rival. The technology worked; the governance did not. Any supply chain network needs a neutral governance model that participants believe in, often a consortium or independent foundation, before it needs a smart contract.
Architecture of a traceability system
| Layer | Role | Typical choices |
|---|---|---|
| Identification | Uniquely identify products, batches, locations and parties | GS1 identifiers (GTIN, SSCC, GLN), serialized barcodes, RFID, NFC tags |
| Event capture | Record what happened, where, when and why | GS1 EPCIS 2.0 events from ERP, warehouse systems, scanners and sensors |
| Off-chain storage | Hold full event data and documents | Each participant's systems, shared databases, IPFS for public documents |
| Ledger | Anchor event hashes, ownership transfers and permissions | Permissioned networks, or a public chain or consensus service for anchoring |
| Applications | Recall tools, consumer verification pages, partner dashboards, APIs | Web apps and integrations with existing ERP and logistics platforms |
Using established standards such as GS1 EPCIS is one of the best decisions you can make. Your partners' systems may already produce it, and it keeps your data portable if the ledger choice changes.
For anchoring, a public ordering service such as Hedera's consensus service is one cost-predictable option; see Hedera development. For consortium-only data, permissioned ledgers are common.
The oracle problem, in supply chain form
A ledger can prove that a record has not changed since it was written. It cannot prove the record was true. If a supplier scans the wrong pallet or relabels counterfeit goods, the blockchain will faithfully preserve the lie. Mitigations include:
- Tamper-evident packaging and secure tags that are hard to clone
- IoT sensors with device-level identity for temperature, location and shock data, covered in blockchain IoT development
- Cross-checking events from independent parties (a shipment marked sent must be marked received)
- Audits and inspections tied to reputation or contractual penalties
Some projects link a physical item to a digital token so that ownership transfers can be tracked; see NFTs for physical assets for that design.
Development process
- Pick one product line and one question ("where did this batch come from?") instead of the whole supply chain.
- Map participants and data owners, including what each is willing to share and with whom.
- Agree on governance: who operates nodes, who can onboard members, who pays.
- Standardize data with GS1 identifiers and EPCIS events.
- Build integrations with participants' ERP and warehouse systems; this is usually the largest workload.
- Run a pilot with a handful of partners and measure recall time, dispute rates or verification usage. A focused proof of concept is a sensible first step.
- Scale only after participants see value without being subsidized.
Costs and timelines
A technical pilot with a few partners can be built in a few months by a small team, assuming partners can export event data. Production rollouts across a supply network commonly take a year or more because each partner integration, contract and training program takes time. Budget for ongoing operations, onboarding support and governance, not just development.
When not to use blockchain here
If one company controls the supply chain (vertically integrated, or a dominant buyer that can mandate a platform), a shared database run by that company is simpler. If partners will not share data, a ledger does not change that. And if consumers never check provenance, a consumer-facing chain adds cost without value. For regulated pharmaceutical traceability specifically, see blockchain for the pharma industry.
Frequently asked questions
Should supply chain data be on a public blockchain?
Commercially sensitive data generally should not. A common compromise is to keep data off-chain and anchor hashes on a public chain, gaining public verifiability without disclosure.
Can blockchain stop counterfeits?
It helps only when combined with hard-to-clone physical identifiers and verification at the point of sale. On its own, it records whatever it is told.
Do all suppliers need to run a node?
No. Smaller participants usually submit events through an API or portal operated by a larger member or a service provider, at the cost of trusting that operator.