7Block Labs
Blockchain Technology

ByAUJay

Supply chain blockchain consulting: Designing Traceability Without Vendor Lock-In

Summary: A practical blueprint for decision‑makers to design cross‑enterprise traceability that meets 2025–2027 regulatory deadlines while remaining chain‑agnostic, data‑portable, and resistant to platform lock-in. You’ll get concrete architecture patterns, standards to adopt, and implementation checklists with real‑world examples.

Why this matters now

If you’re exploring blockchain for supply‑chain traceability, 2025–2027 is a regulatory crunch:

  • FDA FSMA 204 (U.S.) requires interoperable tracking for foods on the Food Traceability List, originally due January 20, 2026; FDA has proposed a 30‑month extension to July 20, 2028. (fda.gov)
  • The EU’s new Ecodesign for Sustainable Products Regulation (ESPR) entered into force on July 18, 2024, laying the foundation for Digital Product Passports (DPPs) to be rolled out via product‑specific acts from 2025 onward. (commission.europa.eu)
  • EU Battery Regulation 2023/1542 mandates battery passports for EV/industrial/LMT batteries placed on the EU market from February 18, 2027. (eur-lex.europa.eu)
  • EU Deforestation Regulation (EUDR) application was postponed by 12 months: large/medium operators by December 30, 2025; micro/small by June 30, 2026 (Commission guidance updated 2025). (environment.ec.europa.eu)
  • U.S. Uyghur Forced Labor Prevention Act (UFLPA) enforcement expects importers to produce granular chain‑of‑custody and payment documentation during applicability reviews. (cbp.gov)

At the same time, barcodes are upgrading: retailers aim for “Ambition/Sunrise 2027,” where point‑of‑sale scanners read GS1‑compliant 2D barcodes (GS1 DataMatrix or GS1 Digital Link QR). This makes on‑pack identifiers a gateway into digital traceability—if you design your data model right. (gs1.org)

The risk: many traceability platforms tie you to their cloud, data schemas, and ledger. This guide shows how we at 7Block Labs design open, portable traceability that you can move, verify, and extend—without re‑platforming every two years.


Design objective: verifiable traceability without lock‑in

Traceability has three hard problems: identifiers, events, and evidence.

  • Identifiers must be globally resolvable (the same IDs work across ERPs, MES, WMS, and scanners).
  • Events must be shareable without rewriting when partners or regulators change tools.
  • Evidence must be verifiable years later regardless of the original vendor or chain.

Here’s the concrete stack we recommend.


1) Use open identifiers you can scan and resolve anywhere

  • Adopt GS1 identifiers end‑to‑end: GTIN/SGTIN for products, SSCC for logistics units, GLN for locations. Expose them as GS1 Digital Link URIs so each code can:
    • scan at retail POS (2D barcode), and
    • resolve to product or compliance data via standard web links. (gs1.org)
  • Prepare for “Ambition/Sunrise 2027”: ensure your hardware and label specs support GS1 2D codes; dual‑mark with EAN/UPC during transition. (gs1.org)

Why it avoids lock‑in: the identifier lives in an open namespace (GS1), not a proprietary database key. Any system can resolve or map it.


2) Model all supply‑chain activity as EPCIS 2.0 events

  • Use GS1 EPCIS/CBV 2.0 as your canonical event model. It adds:
    • JSON/JSON‑LD syntax and a REST API,
    • sensor/IoT fields for cold chain and condition monitoring,
    • Digital Link URI support for identifiers. (gs1.org)
  • Stick to the five EPCIS 2.0 event types: ObjectEvent, AggregationEvent, TransformationEvent, TransactionEvent, and AssociationEvent (new in 2.0). (developers.evrythng.com)

Why it avoids lock‑in: EPCIS 2.0 is an open, widely‑adopted interchange. If a vendor goes away, you export JSON‑LD and move on.

Practical tip:

  • Create a “minimal viable EPCIS profile” for your sector (e.g., food, apparel, EV batteries) with a fixed set of bizStep/disposition code lists, required/optional fields, and a conformance test. Publish it internally and require it in partner contracts.

3) Make entities verifiable using W3C DIDs and VCs 2.0

  • Represent organizations, facilities, and even lines or devices with Decentralized Identifiers (DIDs)—a W3C Recommendation since 2022. (w3.org)
  • Issue attestations as W3C Verifiable Credentials (VC) 2.0—a W3C Recommendation (May 15, 2025), with standardized cryptographic suites and JOSE/COSE support. (w3.org)
  • For online exchange, use OpenID for Verifiable Presentations (OpenID4VP) 1.0 (final July 9, 2025) and OpenID for Verifiable Credential Issuance (OID4VCI) to interoperate with mainstream OAuth/OIDC stacks. (openid.net)

Why it avoids lock‑in: credentials are portable and independently verifiable; you can move wallets, registries, or vendors without breaking the model.


4) Sign evidence with DSSE/in‑toto, don’t bury it in a database

  • Package documents (e.g., bills of lading, lab results, supplier declarations) in DSSE envelopes with in‑toto statements; verifyable with Sigstore tooling or any DSSE library. (github.com)
  • Track relevant security advisories (e.g., 2024 Sigstore‑Go endless‑data CVE) and enforce bounds/quotas in verifiers. (advisories.gitlab.com)

Why it avoids lock‑in: your signed artifacts are self‑describing and verifiable outside any SaaS. You can store them anywhere (S3, on‑prem, IPFS) and still validate.


5) Store data off‑chain with content addressing; anchor proofs on‑chain

  • Use IPFS for content addressing with CIDs (immutable, hash‑based identifiers). When a doc changes, the CID changes, providing tamper evidence. Use IPNS/DNSLink for mutable pointers. (docs.ipfs.tech)
  • Anchor batches of EPCIS event hashes (or Merkle roots) periodically to a public ledger for auditability. For cost control, prefer Ethereum L2s after Dencun (EIP‑4844 “blobs”)—they provide orders‑of‑magnitude cheaper data availability for rollups and anchoring. (ethereum.org)

Why it avoids lock‑in: content addressing decouples storage from verification. You can switch clouds or pinning providers without changing IDs.


6) Choose a chain‑agnostic orchestration layer

  • Use Hyperledger FireFly as a “supernode” to coordinate on‑chain/off‑chain flows, tokenization, and private data exchange across multiple chains—without rewriting your app for each ledger. FireFly exposes event streams, namespaces per network, connectors for EVM chains, and multiparty flows for B2B privacy. (hyperledger.github.io)
  • Where private/permissioned networks are required (e.g., consortia, TEEs), deploy Hyperledger Besu (EVM‑compatible) or Hyperledger Fabric; both are mature, Apache‑licensed, and widely used. (besu.hyperledger.org)

Why it avoids lock‑in: you can change or add ledgers (L1/L2/permissioned) while keeping the same app, keys, and APIs.


7) Align with chain‑of‑custody and barcode migration programs

  • Map your chain‑of‑custody to ISO 22095 (mass balance, segregation, identity preserved, book‑and‑claim). Then encode how each model is evidenced (EPCIS Transformation/Association events + VCs). (iso.org)
  • Prepare for GS1 “Ambition/Sunrise 2027” by validating POS scanner readiness, print quality, and data payloads (lot, expiry, serial) in both GS1 DataMatrix and Digital Link QR. (gs1.org)

What this looks like in practice

Example A: EU battery passports (2027)

  • Data model: batches and cells identified with GS1 keys (where feasible) and linked to a per‑battery Digital Link URI. Events (mining → refining → cell → pack → vehicle) are EPCIS 2.0 Transformation/Aggregation.
  • Evidence: supplier due‑diligence and CO2 per process step issued as W3C VCs, delivered via OpenID4VP to the passport backend.
  • Storage: evidence docs go to IPFS; CIDs listed in the passport record. Hashes are periodically anchored to Ethereum L2 (blob transactions) via FireFly. (ethereum.org)
  • Real‑world signal: Volvo, working with Circulor, launched a battery passport ahead of the EU mandate; their system traces sources, recycled content, and carbon footprints and makes a consumer‑friendly view available via QR. (reuters.com)
  • Obligation: EU Regulation 2023/1542 requires a passport for EV/industrial/LMT batteries from February 18, 2027. (eur-lex.europa.eu)

Example B: FSMA 204 for food (U.S.)

  • FSMA 204 requires maintaining and sharing Key Data Elements (KDEs) across Critical Tracking Events (CTEs). Represent KDEs as EPCIS 2.0 Object/Aggregation/Transformation events and share via REST. (fda.gov)
  • Barcodes: embed GTIN+lot+expiry in GS1 2D codes; distributors scan and automatically emit EPCIS events. (gs1us.org)
  • Evidence: temperature logs as sensor extensions; lab results as DSSE‑signed docs linked by CIDs.
  • Compliance timing: original 2026 compliance; FDA has proposed extension to July 20, 2028—design your program to hit 2026, but plan for extended supplier onboarding. (fda.gov)

Example C: UFLPA import documentation (U.S.)

  • Expect to deliver detailed transaction, participant, and payment/transport evidence “produced in the ordinary course of business.” Issue supplier credentials (e.g., facility verification, material origin) as W3C VCs; bundle trade docs in DSSE envelopes, and maintain a searchable map of custody events (EPCIS). (cbp.gov)

Example D: EUDR commodity traceability (EU)

  • Capture farm/plot geolocations and harvest events as EPCIS with geospatial extensions; represent land‑use legality and deforestation‑free attestations as VCs.
  • Keep evidence portable (CIDs) and submit regulator‑required data via EU IT systems as they roll out. Timelines now large/medium by Dec 30, 2025 and micro/small by Jun 30, 2026. (environment.ec.europa.eu)

Emerging practices we advise in 2025–2026

  • Minimize on‑chain data; maximize on‑chain proofs. L2 blob space (EIP‑4844) makes anchoring cheap while you keep sensitive data off‑chain. (ethereum.org)
  • Standardize presentations, not just schemas: adopt OpenID4VP/OID4VCI so any partner with mainstream OAuth tools can request/issue credentials—no special SDK required. (openid.net)
  • Separate identity from registry: DIDs + VCs for identity and claims; EPCIS repositories for events; IPFS/S3 for artifacts; ledgers for proofs. You can swap any layer later.
  • Multi‑ledger anchoring policies: hash rollups daily to two different public networks (e.g., Ethereum L2 and Bitcoin via a third‑party anchoring service) to reduce dependency risk.
  • “Supplier‑last‑mile” kits: provide pre‑built mobile/web capture apps that emit EPCIS 2.0 and DSSE‑signed docs—even offline—then sync via FireFly to your chosen ledgers. (hyperledger.github.io)
  • Chain‑of‑custody clarity: explicitly choose the ISO 22095 model per product (identity‑preserved vs. segregated vs. mass balance vs. book‑and‑claim) and reflect it in Transformation/Association events. (iso.org)

Technology choices that keep you portable

  • Orchestration: Hyperledger FireFly for multi‑chain eventing, token operations, and B2B data exchange. It isolates your app from chain specifics and gives you namespaces per network. (hyperledger.github.io)
  • Public/consortium chains:
    • Ethereum L2s (for anchoring/proofs and public auditability). Dencun (Mar 13, 2024) added EIP‑4844 blobs to cut L2 costs and reduce permanent calldata growth. (blog.ethereum.org)
    • Hyperledger Besu (EVM) or Fabric for permissioned networks and regional data residency. (besu.hyperledger.org)
  • Identity and credentials: W3C DIDs + VCs 2.0; OpenID4VP/OID4VCI for exchange; pick JOSE/COSE or Data Integrity cryptosuites aligned with W3C VC 2.0. (w3.org)
  • Evidence and artifacts: DSSE/in‑toto with Sigstore types; store via IPFS with CIDs; pin via multiple providers. (github.com)
  • Data model: EPCIS 2.0/CBV 2.0 JSON‑LD with a published conformance profile; require Digital Link URIs for identifiers. (gs1.org)

Concrete pitfalls to avoid (we see these weekly)

  • “Blockchain‑first” design that writes raw traceability data on‑chain. You’ll hit privacy, cost, and change‑management issues. Keep data off‑chain; anchor proofs on‑chain.
  • Proprietary IDs and opaque schemas. If you can’t export your data as EPCIS 2.0 JSON‑LD with GS1 Digital Link URIs, you’re locking yourself in. (gs1.org)
  • Hard‑wiring to one ledger. Use FireFly or equivalent orchestration and sign artifacts independently; the anchoring network can change over time. (hyperledger.github.io)
  • Ignoring barcode migration. Your on‑pack strategy must anticipate Sunrise 2027; test scanner readiness and label specs now. (gs1.org)
  • Treating identity as a central directory. Use DIDs/VCs; avoid central bottlenecks that become single points of commercial or regulatory failure. (w3.org)

Costing and scalability notes you can take to your CFO

  • Anchoring model: hash 10,000 EPCIS events into a Merkle root every 15 minutes; publish to one or two L2s via blob transactions. Post‑Dencun, this approach reduces cost by orders of magnitude compared to legacy calldata approaches, and blobs auto‑expire while proofs remain verifiable. (ethereum.org)
  • Storage: IPFS CIDs give deduplication and multi‑cloud optionality; pin hot data with two providers and cold‑archive in your S3/Glacier tier. (docs.ipfs.tech)
  • Sustainability: Ethereum’s move to Proof‑of‑Stake reduced energy consumption dramatically vs. PoW; if sustainability reporting is in scope, L2 anchoring over PoS aligns with climate KPIs. (ethereum.org)

90‑day action plan (startup or enterprise)

  • Weeks 1–3:
    • Map regulatory scope (FSMA/EUDR/ESPR/Battery/UFLPA) against your SKUs and lanes.
    • Decide ISO 22095 model per product line. (iso.org)
  • Weeks 2–6:
    • Draft your EPCIS 2.0 profile (event types, required KDEs, bizSteps).
    • Stand up a FireFly sandbox and two chain connectors (one L2, one testnet). (hyperledger.github.io)
  • Weeks 4–8:
    • Issue your first VCs (supplier/site credentials) and test OpenID4VP flows with a pilot trading partner. (openid.net)
    • Implement DSSE signing for two documents (e.g., lab result, bill of lading) and publish to IPFS; anchor daily Merkle roots. (github.com)
  • Weeks 6–10:
    • Print/scan pilots with GS1 Digital Link QR or GS1 DataMatrix; validate POS and warehouse scanner compatibility. (gs1.org)
  • Weeks 8–12:
    • Run a mock recall (food) or mock customs audit (UFLPA) using only exported EPCIS 2.0 JSON‑LD + VCs + DSSE bundles to prove vendor independence. (fda.gov)

What “good” looks like by Q4

  • All partners can emit and consume EPCIS 2.0 via REST; data validation passes your profile tests. (gs1.org)
  • Every critical document is DSSE‑signed and content‑addressed; you can verify outside your platform. (github.com)
  • Credentials (sites, certifications, batch attestations) are VCs 2.0 and presented via OpenID4VP to your portals/regulators. (w3.org)
  • Anchoring policies run on schedule to two independent networks; switching a network requires no app changes. (hyperledger.github.io)
  • Your packaging roadmap is aligned to Sunrise 2027 and has confirmed scanner readiness across key retailers. (gs1.org)

Real‑world proof points

  • Volvo’s battery passport, built with Circulor, demonstrates consumer‑visible traceability and regulator submissions ahead of the 2027 EU mandate. (reuters.com)
  • Hyperledger FireFly, Besu, and Fabric continue to serve as neutral, open foundations across industries for multi‑party coordination without single‑vendor dependency. (hyperledger.github.io)
  • Dencun’s EIP‑4844 makes frequent low‑cost anchoring viable at scale; you don’t need to choose between public auditability and budget. (ethereum.org)

Bottom line

Design your traceability program as if you’ll have to migrate platforms in two years—because you might. If you:

  • standardize IDs (GS1 Digital Link),
  • use EPCIS 2.0 for events,
  • issue proofs as W3C VCs and DSSE‑signed artifacts,
  • store off‑chain with content addressing, and
  • anchor on‑chain via a chain‑agnostic orchestrator,

you’ll meet 2025–2027 compliance deadlines while preserving your freedom to change vendors, clouds, and ledgers without losing history or trust.

If you want a fast, lock‑in‑resistant pilot, 7Block Labs can help you stand up this stack in weeks, not months—complete with conformance tests, packaging specs for Sunrise 2027, and a regulator‑ready evidence trail.

Like what you're reading? Let's build together.

Get a free 30‑minute consultation with our engineering team.

Related Posts

7BlockLabs

Full-stack blockchain product studio: DeFi, dApps, audits, integrations.

7Block Labs is a trading name of JAYANTH TECHNOLOGIES LIMITED.

Registered in England and Wales (Company No. 16589283).

Registered Office address: Office 13536, 182-184 High Street North, East Ham, London, E6 2JA.

© 2025 7BlockLabs. All rights reserved.