Blockchain in the Supply Chain: Traceability, IoT Data and What Holds Up in Production

Supply-chain ledger pilots tend to fail somewhere other than the ledger. The chain runs fine. The trouble is the data going into it: a lot number a warehouse clerk typed at 4 a.m., or a temperature logger that spent half the trip on the passenger seat because someone wanted to keep it charged. A blockchain will preserve that record perfectly, mistakes included, for as long as the network exists.

So we'll skip the argument that blockchain "fits" supply chains and stick to the narrow conditions where a shared ledger earns its keep, what belongs on it, and how sensor data gets there without anyone pretending the oracle problem has been solved. To be clear up front: we haven't built a supply-chain product for a client, and where something below is our view rather than field experience, we'll say so. What we have built is Blokstorage, a file proof platform, and the pattern at its core (files stay off chain, a proof goes on chain) turns out to be most of what a traceability system needs.

A shared ledger only beats a database in one situation

If one company runs the system and everyone else logs in to it, use a database. Postgres with an append-only audit table and signed rows will beat any chain on cost and latency, and you can hire for it anywhere. A fair number of "blockchain traceability" products are exactly that, with a ledger attached for the sales deck.

The ledger starts to make sense when several companies need to write to the same record and none of them will accept another as the operator. Think of a grower, a packer, a freight forwarder, a customs broker and a retailer, each with its own ERP and its own incentives. If the retailer hosts the database, the grower has to trust that a rejection record won't be quietly edited during a dispute. If the grower hosts it, the retailer carries that risk instead. A ledger replicated across the parties, where every write is signed by the company that made it and ordering is agreed by consensus, takes the single host out of the picture.

That's the whole argument. A chain is slower than a database and costs more per write, so the case can't rest on performance. It rests on the fact that nobody owns the record alone.

Here's a quick test we'd suggest: name the party you're protecting the data from. If the answer is outside attackers, you want good security on an ordinary system. If the answer is the other members of the network, and they're also the ones who'd host it, a ledger might be the right call.

What goes on chain and what stays off

The mistake that eats budgets is putting documents on chain. Bills of lading, certificates of analysis, phytosanitary certificates, photos of a crushed pallet: none of it belongs in block storage. Those files are large and often carry personal or commercially sensitive data. Once they're replicated to every node, you can't take them back.

What goes on chain is small and structural. A custody or business event says that this lot, identified by its GS1 identifier, moved from location X to location Y at time T, and it carries the signature of the party making the claim. Next to it sits a hash of each supporting document, so anyone holding the PDF can prove it's the same file that was recorded. Sensor data shows up as a single hash or Merkle root covering a batch of readings (more on that below), never as the raw feed.

Everything else lives in each company's own systems, or in a shared document store with access controls. When a dispute comes up, the documents get hashed and compared against the anchored record. If the hashes match, the document hasn't changed since the event was written. If they don't, someone has some explaining to do.

This is the same split Blokstorage uses. The file never touches the chain. The platform computes a cryptographic fingerprint, anchors a proof record on chain, and gives the owner a public verification link that a third party can check without trusting us or the storage provider. Swap "file" for "the certificate of analysis attached to lot 4471" and you have the document half of a traceability system.

One caveat on hashing. Low-entropy values can be guessed. Hash a field like "4°C" on its own and anyone can hash every plausible temperature until one matches. Hash whole documents, or add a random salt that's stored off chain with the data.

Use EPCIS instead of inventing an event format

Projects in this space get into trouble when every participant has to adopt a homegrown event schema. That's avoidable. GS1 already maintains EPCIS, a standard for describing what happened to which item, where, when and why. Version 2.0, ratified in 2022, added JSON and JSON-LD syntax alongside a REST interface, and events can now carry sensor data. Its companion standard, the Core Business Vocabulary, supplies agreed values for business steps such as shipping and receiving, and for dispositions such as in transit or recalled.

The practical upside goes beyond tidiness. Some large retailers already publish EPCIS requirements for their suppliers, so the partners you need on the network may have tooling for it. Your on-chain record becomes a hash of a standard EPCIS event plus a reference to where it's stored, and the event itself can travel over the normal EPCIS interfaces. You aren't asking a packing house in another country to learn your data model. You're asking them to sign something they may already produce.

It also keeps you portable. If the ledger choice turns out to be wrong in three years, a clean archive of EPCIS events with their hashes moves to a new system far more easily than a pile of custom contract storage.

IoT at the edge, and the oracle problem

Cold chain is where IoT and ledgers get pitched together most often, and it's where the hard problems are easiest to see.

Start with the device. If a temperature logger sends readings to a gateway and the gateway writes them to the chain, the chain only proves what the gateway said. A better design has the device sign each reading, or each batch, with a key held in a secure element on the logger itself, so the signature identifies the hardware that produced the number. The gateway becomes a courier that can drop messages but can't forge them. Rotating those keys and revoking a device that went missing on a dock in Rotterdam is real work, and it's usually the line item nobody budgeted.

Then cost. Writing every reading on chain is a bad idea on any network. On a public chain each write has a fee. On a permissioned chain the bill shows up as storage growth and node hardware at every member. A logger reporting every five minutes produces 288 readings a day; across a few thousand shipments that's tens of millions of writes a month for data almost nobody will look at.

The usual answer is to collect readings off chain, build a Merkle tree over one shipment's readings for a time window, and anchor only the root. Any single reading can later be proved against that root with a short Merkle proof, so nothing is lost. Threshold breaches (the load sat above 8°C for 40 minutes) deserve their own events, because those are the readings people will argue about.

Then the problem no architecture fixes. A blockchain can't tell whether the sensor lied. If the logger was in a cooler bag in the cab while the trailer warmed up, every signed reading is authentic and every reading is wrong. This is the oracle problem in its plainest form: the chain guarantees the integrity of a claim after it's made, not the truth of the claim.

You can narrow the gap. Tamper-evident mounting helps, as do two sensors per load, cross-checks against GPS and door-open events, and recording who handled the device at each handover. You can't close it. Anyone who tells you a ledger makes sensor data trustworthy on its own is selling something.

What the ledger does give you is accountability. When a reading is signed by a device registered to the forwarder, and the handover event is signed by the forwarder, a bad reading has an owner. Our view is that this changes behaviour more than any amount of cryptography.

Permissioned or public?

For a supplier network, our default view is a permissioned network where the member companies run the nodes, with periodic state roots anchored to a public chain if outsiders need to verify anything.

A permissioned EVM network gives you known validators, no gas market, controlled membership and fast finality from a BFT consensus protocol such as QBFT. It also gives you an operations bill: someone has to run validators and coordinate upgrades across companies that don't share an IT department. We've written separately about Quorum, Besu and permissioned EVM networks, including the fact that the built-in privacy tooling those networks relied on for years has been retired. That matters if some members need to see data that others mustn't.

A public chain removes the operations bill and lets anyone, a regulator or an end customer included, verify a record without joining a consortium. You pay for that in fees, and whatever metadata you write is visible to everyone on a network whose governance you don't control. For pure proof anchoring (hashes and roots, no business data) a public chain is often the simpler choice. That's how Blokstorage works: the proof is public, the content isn't.

Whichever route you take, running nodes is not a side task. We operate production block producer infrastructure on Vaulta through EOS Support, and the lesson that transfers is that the node software is the easy part. Monitoring, failover, key handling and upgrade coordination between independent operators are where the hours go. A five-company consortium where nobody has staffed for that will end up with a network that degrades quietly until the day someone needs it in a dispute.

A checklist before you fund a pilot

These are the questions we'd want answered before anyone writes contract code. If several come back as "we don't know yet," the pilot isn't ready.

• Which companies will write to the ledger, and has each one agreed to run a node, or accepted that it won't?
• Who are you protecting the record from? If it isn't the other participants, look hard at a plain database first.
• Will everyone use one event standard (EPCIS, ideally), and who maps each partner's ERP data into it?
• What exactly goes on chain? Write the schema down. If it contains a document, a person's name or a raw sensor feed, revise it.
• How are device and company keys issued, rotated and revoked, and who pays for the secure hardware?
• What happens when an event is wrong? Ledgers don't delete, so corrections are new events that reference old ones, and someone has to own that process.
• Who will actually verify a record? If no customer, auditor or regulator ever checks one, the ledger has no audience.
• What's the exit plan if the consortium breaks up or the platform choice turns out wrong?

A pilot with good answers to those usually ends up smaller than the original pitch. It's also far more likely to survive contact with real shipments.

If you're scoping a traceability or proof system, talk to us. We'll tell you honestly if a database would do the job.