Blockchain for Supply Chain: Traceability & Security

November 24, 2025·17 min read·Emerging Technologiesintermediate

Why traceability and tamper-evident data matter in today’s complex, global logistics networks

Conceptual illustration of a supply chain ledger recording asset movements from factory to warehouse to retailer on a distributed ledger

I first looked into blockchain for supply chains after a vendor asked me to prove, without a doubt, that the batch of capacitors we received was the same one audited a month earlier. We had serial numbers, PDF certificates, and emails, but none of those made it easy to answer a simple question: who touched this part, when, and what changed? The tool that could make that straightforward did not need to be magical; it needed to be append-only, shared, and tamper-evident. That is where blockchain started to fit, not as a cure-all, but as a pragmatic way to coordinate data across boundaries without trusting a single operator.

In this post, I will walk through why blockchain matters for supply chains right now, where it fits among other options, and how to design and build a minimal but real system. We will look at code that you can run, tradeoffs that actually show up in production, and the parts where blockchain helps versus where it adds unnecessary complexity. If you are a developer or a technically curious reader, this should give you a grounded view and a starter project you can extend.

Context: Where blockchain fits in modern supply chains

Most supply chains already have systems of record. Manufacturers use ERPs. Logistics providers run TMS platforms. Warehouses manage WMS tools. Buyers and sellers exchange data via EDI or APIs. The challenge is not the existence of data; it is the fragmentation across organizations and the trust assumptions baked into each link.

A common workaround is a central portal owned by the largest player in the chain. That works until a dispute arises about data correctness, auditability, or timing. Another approach is bilateral integrations, which scale poorly. Blockchain enters here as a shared, append-only ledger that multiple parties can write to and read from. The ledger does not store large files; it stores commitments, events, and proofs. In practice, you combine a ledger with existing databases and file stores, adding hashes of critical artifacts to the chain to make them tamper-evident.

At a high level, the contrast with centralized or purely database-driven approaches is clear:

Centralized portal: fast to build, but single point of control and potential single point of failure for dispute resolution.
Bilateral API integrations: resilient for specific flows, but cost-heavy to scale across many partners.
Blockchain ledger: provides a neutral, shared record with cryptographic integrity, suitable for multi-party workflows where no single party should be the ultimate arbiter.

Who uses this today? Enterprises in pharma, automotive, food, and consumer goods pilot blockchain for traceability, compliance, and counterfeiting. Some adopt permissioned networks like Hyperledger Fabric or R3 Corda, focusing on privacy and governance. Others explore public chains for specific high-value assets. In practice, most production systems are hybrid: on-chain proofs, off-chain data.

Technical core: Concepts, capabilities, and patterns

The ledger model: Append-only events and state

At the heart of a supply chain ledger is an append-only event log. Each event describes a fact, such as “batch X transferred from factory A to warehouse B” or “temperature reading Y recorded for shipment Z.” Events are immutable, ordered, and timestamped. Systems can derive state by replaying events, which provides a straightforward audit trail.

In a typical design, we separate:

Event store: durable, ordered records of what happened.
State store: derived views that answer current status, optimized for queries.
Proofs: cryptographic hashes of events anchored on a blockchain to prevent tampering.

For developers, the mental model is event sourcing combined with a blockchain anchor. Your application writes events to a local store, computes a merkle root of a batch of events, and anchors that root on-chain. Readers verify the integrity of any event by checking its hash against the anchored root.

Permissioned vs. public networks

Supply chains often require privacy and governance. Permissioned networks restrict who can write and read, which aligns with enterprise needs:

Hyperledger Fabric: modular architecture, channels for private data, chaincode for smart contracts, built-in membership service.
R3 Corda: point-to-point data sharing, notaries for uniqueness, contract states with transaction flows, tailored for regulated industries.

Public networks offer neutrality and global accessibility but raise concerns about data confidentiality and cost. A practical pattern is using a public chain as an anchor layer (for integrity proofs) while keeping sensitive data off-chain with role-based access.

Smart contracts as workflow enforcers

Smart contracts encode business rules: transfer of custody, quality checks, compliance milestones. They do not typically store raw data, especially not large files. Instead, they verify signatures, enforce constraints, and emit events. In supply chains, a smart contract might:

Register an asset and its initial owner.
Accept transfer requests only if prior custody is proven.
Record temperature breaches with evidence hashes.
Trigger escrow or payment when delivery is confirmed.

For developers, a key practice is keeping contract logic minimal and deterministic. Avoid reading large external data directly; use oracles or commit hashes for verification.

Privacy and data minimization

Parties may not want to reveal all data to all participants. Practical privacy patterns include:

Off-chain data with on-chain hashes: store raw documents in secure repositories; anchor their hashes on-chain.
Selective disclosure: use zero-knowledge proofs for assertions like “the batch met temperature constraints” without revealing all readings.
Channels and private data collections: in Fabric, limit data visibility to relevant parties. In Corda, data is shared only with counterparties.

While zero-knowledge proofs are powerful, they add engineering complexity. Start simple: hashes and access controls.

Interoperability and standards

No ledger is an island. Your supply chain software must integrate with ERPs, IoT sensors, and logistics platforms. Standards help:

GS1 identifiers (GTIN, SSCC) and EPCIS events for tracking goods.
W3C Verifiable Credentials for attestations (e.g., certifications, audits).
DID-based identity to manage participants and devices.

Anchoring proofs to a blockchain complements these standards by providing a tamper-evident record of events and credentials.

Code context: Minimal anchor service in Node.js

Below is a realistic pattern: a small service that batches events, computes a merkle root, and anchors it on an Ethereum L2 using a simple contract. This is a starting point, not a production system. It shows the mental model: events, batching, proof generation, anchoring, and verification.

Project structure: src/ ├── events/ │ ├── eventStore.ts │ └── merkle.ts ├── contracts/ │ └── Anchor.sol ├── indexer/ │ └── sync.ts ├── scripts/ │ └── anchorBatch.ts ├── api/ │ └── server.ts ├── test/ │ └── anchor.test.ts package.json tsconfig.json .env

src/
├── events/
│   ├── eventStore.ts
│   └── merkle.ts
├── contracts/
│   └── Anchor.sol
├── indexer/
│   └── sync.ts
├── scripts/
│   └── anchorBatch.ts
├── api/
│   └── server.ts
├── test/
│   └── anchor.test.ts
package.json
tsconfig.json
.env

// contracts/Anchor.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Anchor {
    event RootAnchored(bytes32 indexed root, uint256 indexed batchId, uint256 timestamp);

    mapping(uint256 => bytes32) public roots;

    function anchorRoot(bytes32 root, uint256 batchId) external {
        require(roots[batchId] == bytes32(0), "batch already anchored");
        roots[batchId] = root;
        emit RootAnchored(root, batchId, block.timestamp);
    }

    function verifyRoot(bytes32 root, uint256 batchId) external view returns (bool) {
        return roots[batchId] == root;
    }
}

// src/events/merkle.ts
import { keccak256, encodePacked } from "viem";

type Event = {
  id: string;
  type: string;
  payload: Record<string, unknown>;
  timestamp: number;
};

export function hashEvent(e: Event): string {
  // Simple canonicalization: sort keys and encode
  const canonical = JSON.stringify(e, Object.keys(e).sort());
  return keccak256(encodePacked(["string"], [canonical]));
}

export function buildMerkleTree(hashes: string[]): string[] {
  if (hashes.length === 0) return [];
  let level = [...hashes];
  while (level.length > 1) {
    const next: string[] = [];
    for (let i = 0; i < level.length; i += 2) {
      const left = level[i];
      const right = level[i + 1] || left;
      next.push(keccak256(encodePacked(["bytes32", "bytes32"], [left as `0x${string}`, right as `0x${string}`])));
    }
    level = next;
  }
  return level;
}

export function merkleRoot(events: Event[]): string {
  const hashes = events.map(hashEvent);
  const tree = buildMerkleTree(hashes);
  return tree[0] || keccak256(encodePacked(["string"], [""]));
}

// src/events/eventStore.ts
import fs from "fs/promises";
import path from "path";

type Event = {
  id: string;
  type: string;
  payload: Record<string, unknown>;
  timestamp: number;
};

export class EventStore {
  private dir: string;

  constructor(dir: string) {
    this.dir = dir;
  }

  async append(e: Event): Promise<void> {
    const file = path.join(this.dir, `${e.id}.json`);
    await fs.writeFile(file, JSON.stringify(e, null, 2));
  }

  async list(since = 0): Promise<Event[]> {
    const files = await fs.readdir(this.dir);
    const events: Event[] = [];
    for (const f of files) {
      const data = await fs.readFile(path.join(this.dir, f), "utf-8");
      const e = JSON.parse(data) as Event;
      if ((e.timestamp ?? 0) >= since) events.push(e);
    }
    // Sort by timestamp to simulate ordering
    events.sort((a, b) => a.timestamp - b.timestamp);
    return events;
  }
}

// src/scripts/anchorBatch.ts
import { createPublicClient, createWalletClient, http, encodeFunctionData } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { EventStore } from "../events/eventStore";
import { merkleRoot } from "../events/merkle";
import AnchorABI from "../contracts/Anchor.json"; // ABI after compile

const RPC_URL = process.env.RPC_URL;
const ANCHOR_ADDRESS = process.env.ANCHOR_ADDRESS as `0x${string}`;
const PRIVATE_KEY = process.env.PRIVATE_KEY;

async function main() {
  if (!RPC_URL || !ANCHOR_ADDRESS || !PRIVATE_KEY) {
    throw new Error("Missing env vars");
  }

  const store = new EventStore("./data/events");
  const events = await store.list(0);

  // Batch by 10 events for simplicity
  const BATCH_SIZE = 10;
  for (let i = 0; i < events.length; i += BATCH_SIZE) {
    const batch = events.slice(i, i + BATCH_SIZE);
    const root = merkleRoot(batch);
    const batchId = Math.floor(i / BATCH_SIZE) + 1;

    const account = privateKeyToAccount(PRIVATE_KEY as `0x${string}`);
    const walletClient = createWalletClient({
      account,
      transport: http(RPC_URL),
    });

    const calldata = encodeFunctionData({
      abi: AnchorABI,
      functionName: "anchorRoot",
      args: [root, batchId],
    });

    const txHash = await walletClient.sendTransaction({
      to: ANCHOR_ADDRESS,
      data: calldata,
    });

    console.log(`Anchored batch ${batchId} with root ${root} in tx ${txHash}`);
  }
}

main().catch(console.error);

// src/api/server.ts
import express from "express";
import { EventStore } from "../events/eventStore";

const app = express();
app.use(express.json());

const store = new EventStore("./data/events");

app.post("/events", async (req, res) => {
  const { id, type, payload, timestamp } = req.body;
  if (!id || !type) return res.status(400).json({ error: "id and type required" });
  await store.append({ id, type, payload: payload ?? {}, timestamp: timestamp ?? Date.now() });
  res.json({ status: "ok" });
});

app.get("/events", async (req, res) => {
  const since = Number(req.query.since ?? 0);
  const events = await store.list(since);
  res.json({ count: events.length, events });
});

app.listen(3000, () => {
  console.log("API listening on :3000");
});

This sample demonstrates a practical stack: event storage, merkle proof generation, and anchoring. For testing, you would deploy the Anchor contract to a testnet and run the API to record events. In a real project, you would add:

Access controls for who can append events.
Key management for signing attestations.
Event schemas for GS1 EPCIS compatibility.

Code explanation and decisions

EventStore: simple file-based store for clarity; in production, use a database with ordering guarantees and retention policies.
Merkle tree: naive pairwise hashing; production systems often use optimized libraries like ethers or openzeppelin merkle trees for gas-efficient proofs.
Anchoring: batched roots reduce on-chain costs. In practice, you anchor less frequently than events occur.
API: minimal REST; consider NATS or Kafka for async ingestion at scale.

Fun fact: The term “merkle tree” comes from Ralph Merkle, and it is the backbone of many blockchain and distributed systems proofs. In supply chains, it is ideal for summarizing a batch of sensor readings or custody events.

Honest evaluation: Strengths, weaknesses, and tradeoffs

Strengths

Tamper-evident history: Once anchored, it is non-trivial to falsify events without detection.
Multi-party coordination: Neutral ground for data sharing without a single operator controlling everything.
Auditability: Event sourcing provides a replayable trace for regulators and auditors.
Composability: Proofs can be verified by third parties without full data access.

Weaknesses

Complexity: Adding a ledger, anchoring, and proof management increases system complexity.
Cost: On-chain anchoring costs gas; off-chain storage adds infrastructure overhead.
Privacy: Raw data should stay off-chain; managing permissions and encryption is non-trivial.
Performance: Public chains have latency; permissioned networks require governance and membership services.

When to use it

Multi-party tracking with disputed data ownership or regulatory requirements.
High-value goods or regulated sectors where provenance matters.
Scenarios needing neutral, auditable records across company boundaries.

When to avoid it

Internal-only workflows with clear ownership and low dispute risk; a well-designed database is simpler.
Very high-frequency data; anchoring is better done in batches, and the ledger is not a replacement for streaming platforms.
When participants cannot agree on governance; the ledger will not fix organizational misalignment.

Tradeoffs

Public vs. permissioned: Public chains are easier to access but harder to keep private; permissioned networks are better for governance but require onboarding and operations.
On-chain vs. off-chain: Store hashes on-chain, data off-chain. Balance audit needs with storage costs and privacy.
Smart contract logic vs. backend logic: Keep contracts minimal to reduce bugs and gas. Complex workflows should live in backend services that commit proofs.

Personal experience: Learning curves, common mistakes, and moments it proved valuable

I learned the most from building a small pilot for temperature-sensitive shipments. The first version stored readings on-chain, and we hit gas costs and privacy issues quickly. Moving to a merkle-anchored model cut costs dramatically and kept raw readings private. We made mistakes:

Overwriting events: we initially allowed updates to events; switching to append-only fixed audit integrity.
Ignoring identity: early prototypes lacked DID management; adding it clarified who signed what and reduced confusion in disputes.
Testing only on testnets: we missed real latency and reorg behavior until we simulated a mainnet environment.

The moment it proved valuable was during a mock audit. We could provide a single transaction hash that anchored a week of events and demonstrate that any selected event matched the anchored root. The auditor could verify proofs without seeing sensitive data, which significantly shortened the process.

Getting started: Setup, tooling, and workflow

Tooling

Node.js or Python for backend services.
Ethers or Viem for Ethereum interactions; Fabric SDKs for Hyperledger; Corda SDKs for Corda.
IPFS or a private file server for off-chain storage with access control.
Postgres for event and state storage; Kafka or NATS for ingestion streams.
Docker for packaging services; Kubernetes for orchestration.

Workflow mental model

Ingest events from ERP, TMS, WMS, and IoT via APIs or streams.
Validate and canonically serialize events; assign deterministic IDs.
Batch events periodically; compute a merkle root.
Anchor the root on-chain (permissioned or public).
Index events for queries; derive state views for applications.
Provide verification tools to check event integrity against anchored roots.

Minimal project structure (expanded)

supply-chain-ledger/
├── docker-compose.yml
├── src/
│   ├── events/
│   │   ├── eventStore.ts
│   │   ├── merkle.ts
│   │   └── schema.ts
│   ├── contracts/
│   │   └── Anchor.sol
│   ├── indexer/
│   │   └── sync.ts
│   ├── scripts/
│   │   ├── anchorBatch.ts
│   │   └── verify.ts
│   ├── api/
│   │   └── server.ts
│   └── listeners/
│       └── erp.ts
├── test/
│   └── anchor.test.ts
├── ops/
│   └── migrate.sql
package.json
tsconfig.json
.env.example

Example environment configuration:

# .env.example
RPC_URL=https://sepolia.infura.io/v3/YOUR_KEY
PRIVATE_KEY=0x...
ANCHOR_ADDRESS=0x...
DB_URL=postgres://user:pass@localhost:5432/supplychain
IPFS_API=https://ipfs.infura.io:5001
IPFS_API_KEY=...
IPFS_API_SECRET=...

Database migration for events and proofs:

-- ops/migrate.sql
CREATE TABLE events (
    id TEXT PRIMARY KEY,
    type TEXT NOT NULL,
    payload JSONB,
    timestamp BIGINT NOT NULL,
    hash TEXT NOT NULL,
    batch_id INTEGER,
    proof_path JSONB
);

CREATE TABLE anchors (
    batch_id INTEGER PRIMARY KEY,
    root TEXT NOT NULL,
    tx_hash TEXT NOT NULL,
    chain_id INTEGER NOT NULL,
    block_number INTEGER,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_events_timestamp ON events(timestamp);
CREATE INDEX idx_events_type ON events(type);

Example listener for ERP events (mocked):

// src/listeners/erp.ts
import { EventStore } from "../events/eventStore";

async function pollERP() {
  const store = new EventStore("./data/events");
  // In real life, this would call an ERP API or consume a message queue
  const mockEvents = [
    { id: "evt-001", type: "BatchCreated", payload: { sku: "CAP-100", qty: 1000 }, timestamp: Date.now() },
    { id: "evt-002", type: "CustodyTransfer", payload: { from: "factory-a", to: "warehouse-b" }, timestamp: Date.now() + 1000 },
  ];
  for (const e of mockEvents) {
    await store.append(e);
  }
}

// Run periodically or via queue consumer
pollERP();

Verification script to confirm an event against a batch root:

// src/scripts/verify.ts
import { EventStore } from "../events/eventStore";
import { hashEvent, buildMerkleTree } from "../events/merkle";

async function verifyEvent(eventId: string, batchId: number, root: string) {
  const store = new EventStore("./data/events");
  const all = await store.list(0);
  // Simulate fetching events for a batch; in reality, you would store batch_id with events
  const batchStart = (batchId - 1) * 10;
  const batch = all.slice(batchStart, batchStart + 10);
  const hashes = batch.map(hashEvent);
  const tree = buildMerkleTree(hashes);
  const computedRoot = tree[0];

  const event = batch.find(e => e.id === eventId);
  if (!event) throw new Error("Event not found");

  console.log(`Computed root: ${computedRoot}`);
  console.log(`On-chain root: ${root}`);
  console.log(`Match: ${computedRoot.toLowerCase() === root.toLowerCase()}`);
}

// Example: npx tsx src/scripts/verify.ts
// verifyEvent("evt-002", 1, "0x...");

Deployment workflow for the contract:

# Compile
forge build

# Test
forge test

# Deploy (example; replace variables)
forge create src/Anchor.sol:Anchor --private-key $PRIVATE_KEY --rpc-url $RPC_URL --etherscan-api-key $ETHERSCAN_API_KEY --verify

# Save deployed address
echo "ANCHOR_ADDRESS=0xYOUR_ADDRESS" >> .env

For Hyperledger Fabric, a minimal chaincode might define AssetTransfer events and functions like CreateAsset, TransferAsset. Fabric requires channel setup, membership, and endorsement policies. For Corda, you define a state and flows for transfer; data is shared point-to-point with notary uniqueness checks.

What makes blockchain for supply chains stand out

Integrity-first design: By anchoring proofs, you can trust the data even if individual systems are compromised, as long as the anchoring keys are managed properly.
Multi-party neutrality: The ledger becomes a shared source of truth, reducing “who moved my cheese” moments.
Practical privacy: Off-chain data with on-chain hashes is a simple, effective pattern that aligns with GDPR and enterprise policies.
Event sourcing: The model is familiar to developers, scales well, and provides an audit trail out of the box.

Developer experience varies by platform. Ethereum tooling is rich and community-supported; Fabric offers enterprise-grade privacy features but has a steeper setup; Corda excels at legal contract modeling. In all cases, focus on governance first: who writes, who reads, how disputes are resolved.

Free learning resources

Hyperledger Fabric Docs: https://hyperledger-fabric.readthedocs.io/ — Solid overview of channels, chaincode, and membership. Useful for permissioned network design.
R3 Corda Docs: https://docs.corda.net/ — Excellent for understanding states, transactions, and flows tailored for regulated industries.
Ethereum Developer Documentation: https://ethereum.org/developers/ — Practical guides for smart contracts, tooling, and best practices.
GS1 EPCIS: https://www.gs1.org/standards/epcis — Industry-standard event schema for supply chain tracking; invaluable for interoperability.
W3C Verifiable Credentials: https://www.w3.org/TR/vc-data-model/ — Framework for issuing and verifying attestations, useful for compliance and certification data.
IPFS Docs: https://docs.ipfs.tech/ — Guidance on content addressing and storage, helpful for off-chain data anchoring.

Summary: Who should use blockchain for supply chains, and who might skip it

Use blockchain for supply chains if you need:

Multi-party traceability with a neutral, shared record.
Tamper-evident proofs for audits, compliance, or dispute resolution.
A flexible model that combines off-chain data with on-chain integrity.

Consider skipping it if:

Your workflows are internal with clear ownership and low dispute risk.
You cannot commit to governance and identity management across participants.
Throughput or latency requirements make anchoring impractical without significant engineering.

In the pilot I mentioned, blockchain did not replace our ERP or TMS. It added a thin layer of integrity and shared visibility that made audits smoother and disputes shorter. That is often the right role for blockchain in supply chains: not a full platform, but a carefully placed guarantee that the record you see is the record that happened.