Supply Chain Provenance

The Problem

Supply chains—whether physical goods, software artifacts, or digital credentials—rely on trust at every handoff:

• Did this product come from the claimed factory? Counterfeits enter at distributor level with forged paperwork
• Was this code written by the claimed developer? Unsigned commits can be tampered with; backdoors inserted undetected
• Has this batch been tampered with in transit? No cryptographic proof of custody chain—intermediaries can swap goods

Today’s supply chains use paper certificates, centralized databases, or blockchain-only solutions:

• Paper certificates are easily forged—counterfeit goods carry fake certificates that look legitimate
• Centralized databases create single points of failure and give database admins power to alter records
• Blockchain-only provides immutability but no identity layer—can’t prove who signed transactions, and all data is public (GDPR nightmare)

This isn’t a future problem:

• $4.3 trillion in counterfeit goods circulate annually because supply chains can’t verify origin (Global Brand Counterfeiting Report, 2025)
• SolarWinds, Log4Shell, XZ backdoor — software supply chain attacks succeeded because commits and artifacts weren’t cryptographically verified
• EU Digital Product Passport (2027) mandates verifiable provenance for products with tamper-proof, machine-readable records

Why It Matters Now

Regulators and customers demand proof:

• EU Digital Product Passport (2027): All products must carry verifiable provenance—origin, materials, sustainability claims
• SBOM requirements (US Executive Order 14028): Software buyers demand cryptographically signed Software Bill of Materials
• ESG reporting mandates: Carbon credits, conflict minerals, labor standards—all require tamper-proof supply chain records

The infrastructure exists: W3C Verifiable Credentials for handoff attestations, DIDs for participant identity, TRQP for real-time authority checks. The supply chains that adopt cryptographic provenance first will win on compliance, customer trust, and fraud prevention.

---

How Affinidi Enables Supply Chain Provenance

The key shift: Instead of trusting paper certificates or centralized databases, every supply chain participant gets a Decentralized Identifier (DID). Every handoff is a signed verifiable credential:

1. Origin proof - Manufacturer issues credential: “This product was produced at Facility X on Date Y”
2. Custody chain - Each handoff (manufacturer → distributor → retailer) adds a signed attestation
3. Real-time verification - Any party can verify the credential chain back to origin without contacting upstream parties
4. Tamper-evident - If any signature is invalid or missing, the chain is broken—counterfeit detected

All of this works offline—verify signatures without network access—and supports selective disclosure (prove product is authentic without revealing supplier pricing).

Technical Foundation

• Elements Services issues W3C Verifiable Credentials for:

  • Product origin (manufacturer DID + batch number + production date)
  • Handoff attestations (custodian A → custodian B with timestamp)
  • Software artifacts (commit hash + builder DID + CI pipeline signature)
  • Commit signatures (developer DID + commit SHA + timestamp)

• Trust Registry (TRQP) validates authority:

  • “Is this manufacturer authorized to produce this product?”
  • “Is this distributor authorized to handle this product category?”
  • “Is this developer authorized to commit to this repository?”

• DIDComm messaging encrypts handoff messages between supply chain participants—no central clearinghouse

• did:webvh identifiers for tamper-evident party identity—audit trails can time-travel: “Was this distributor authorized when the handoff occurred?”

Example Flow: Physical Product

[Factory produces batch #A123]
  ↓
Manufacturer (did:webvh:factory-abc) issues verifiable credential:
  - Product: Batch A123
  - Production Date: 2026-07-15
  - Facility: Factory ABC (Singapore)
  - Signature: [Manufacturer's DID signature]
  ↓
[Batch ships to Distributor]
  ↓
Distributor (did:webvh:distributor-xyz) receives batch, verifies credential:
  ✓ Manufacturer signature valid
  ✓ Trust Registry confirms: Factory ABC authorized for this product
  ↓
Distributor signs handoff attestation:
  - Received from: did:webvh:factory-abc
  - Received by: did:webvh:distributor-xyz
  - Timestamp: 2026-07-18
  - Signature: [Distributor's DID signature]
  ↓
[Batch ships to Retailer]
  ↓
Retailer (did:webvh:retailer-pqr) receives batch, verifies credential chain:
  ✓ Manufacturer signature valid
  ✓ Distributor signature valid
  ✓ Trust Registry confirms: both parties authorized
  ✓ Custody chain unbroken
  ↓
Customer scans QR code on product, sees full provenance:
  - Origin: Factory ABC (verified)
  - Handoffs: 2 (verified)
  - Current custody: Retailer PQR (verified)

What this means:

• Counterfeits blocked: Can’t forge DID signatures—fake products have invalid or missing credentials
• Offline verification: Retailer verifies credentials without contacting manufacturer
• Tamper-evident: If distributor alters credential, signature breaks—tampering detected
• Audit trail: Regulators query Trust Registry: “Was Factory ABC authorized to produce this product on July 15, 2026?”

---

Real-World Applications

Physical Supply Chain: Counterfeit Detection

Problem: Product moves through supply chain: Factory → Warehouse → Distributor → Retailer. Each handoff is paper-based or centralized database. Counterfeit products enter at distributor level with forged paperwork.

Solution: Each party signs handoff with DID. Verifiable credential includes: timestamp, product serial, custody transfer signature. Next party verifies signature before accepting custody.

Outcome:

• Retailer proves product authentic from factory—can show customers verified provenance
• Counterfeits blocked: Can’t forge DID signatures; fake products detected at first verification
• Compliance: EU Digital Product Passport requirement satisfied with machine-readable, tamper-proof records

---

Software Supply Chain: Commit & Artifact Signing

Problem: Developer commits code → CI builds artifact → Registry publishes. No commit signing = no proof developer authored it. Backdoor code inserted by attacker with stolen credentials—unsigned commits reach production.

Solution:

1. Developer signs commits with did:webvh (tamper-evident, time-travelable)
2. CI issues verifiable credential for build artifact:
   • Commit SHA it was built from
   • Builder identity (CI system’s DID)
   • Timestamp + signature
3. Production deployment verifies: commit signed? Artifact credential valid? Developer authorized?

Outcome:

• SolarWinds-style attacks blocked: Unsigned commits rejected; production only deploys verified artifacts
• SBOM compliance: Every deployed artifact has cryptographic proof of origin—commit chain → build → deployment
• Audit trail: Security teams query: “Which developer committed this? When was artifact built? Was builder authorized?”

---

Pharmaceutical: Anti-Counterfeiting

Problem: Drug batch moves through supply chain. Counterfeit drugs enter at distributor level—no way for pharmacy to verify origin at manufacturer.

Solution:

1. Manufacturer issues verifiable credential with batch number + production date + facility DID
2. Each handoff (manufacturer → distributor → pharmacy) adds signed attestation to credential chain
3. Pharmacy scans QR code on drug packaging, verifies credential chain back to manufacturer

Outcome:

• Counterfeit drugs detected: Signatures don’t match—pharmacy rejects batch, reports to authorities
• Patient safety: Pharmacies dispense only drugs with verified manufacturer provenance
• Regulatory compliance: FDA can audit full supply chain with cryptographic proof

---

Carbon Credits: Double-Counting Prevention

Problem: Carbon credit issued by offset project → traded on exchange → retired by corporation. No proof credit wasn’t double-counted or fabricated.

Solution:

1. Offset project issues verifiable credential with project DID + verification body signature
2. Each trade adds signed transfer record (seller DID → buyer DID)
3. Retirement logged on-chain with credential reference

Outcome:

• Auditors verify credit authenticity back to issuing project—no fabricated credits
• Double-counting impossible: Credential lifecycle tamper-evident; retired credits can’t be re-traded
• ESG compliance: Corporations prove carbon offset claims with cryptographic audit trail

---

Why Affinidi

	Affinidi Provenance	Paper Certificates	Centralized Databases	Blockchain-Only
Tamper-proof	✓ Cryptographic signatures	✗ Easily forged	✗ Admin can alter	✓ Immutable
Offline verification	✓ Verify without network	N/A	✗ Requires DB access	✗ Requires chain sync
Selective disclosure	✓ BBS+ ZK proofs	✗ All or nothing	✗ All or nothing	✗ All data public
Cross-org trust	✓ DIDComm, no shared DB	N/A	✗ Single DB owner	⚠ No identity layer
Regulatory compliance	✓ EU DPP compliant	✗ Not machine-readable	⚠ Region-locked	✗ Not GDPR-safe

What this means:

• Paper certificates are easily forged—no cryptographic verification
• Centralized databases create single points of failure and can be altered by admins
• Blockchain-only provides immutability but no identity (can’t prove who signed transactions) and puts all data public (privacy nightmare for supply chains with competitive pricing)

Affinidi provides cryptographic signatures + tamper-evident DIDs + offline verification + selective disclosure—the only architecture that scales supply chain trust without centralized databases or blockchain privacy trade-offs.

Proof It Works

• W3C Verifiable Credentials - Industry-standard provenance format
• BBS+ Selective Disclosure - Share only needed fields (e.g., “Product authentic” without revealing supplier cost)
• TRQP Integration - Real-time authority validation for supply chain participants
• Self-hostable - Deploy Trust Registry on your infrastructure, no central clearinghouse

---

Get Started

For Developers

Build your first provenance chain

Issue a product credential, sign a handoff, verify the credential chain—end-to-end in under an hour.

Start building →

---

For Supply Chain Teams

See a live demo of cryptographic provenance

Watch a product move through supply chain participants, see signatures verified, detect a counterfeit with broken credential chain.

Schedule demo →

---

For Enterprises

Custom deployment consultation

Integrate provenance credentials into your supply chain systems, connect to trust registries, configure handoff workflows.

Talk to an expert →

---

Related Resources

Technical Deep Dives

• Verifiable Credentials - How cryptographically signed credentials work
• Decentralized Identifiers (DIDs) - How supply chain participants get tamper-evident identities
• Trust Registries & TRQP - Real-time authority validation

Related Solutions

• Cross-Org Agent Trust - How agents prove identity across organizational boundaries
• Per-Agent Attribution - Audit trails that prove which agent did what

Case Studies

(Coming soon: Pharmaceutical supply chain provenance implementation)