PROVE — Privacy-Preserving Battery Passport via Chained Zero-Knowledge Proofs

HackSummit Builder Challenge 2026 · Work Package 3 · Powered by SICPA

A cryptographic verification system for EU Battery Regulation compliance. PROVE uses chained zero-knowledge proofs to prove sustainability claims across a lithium supply chain — lithium sourcing, manufacturing efficiency, recycled content — without revealing any party's commercial secrets. A single proof verifies an entire supply chain with cryptographic certainty.

Quick Start

# Build (includes trusted setup on first run, ~5–10s)
cargo build --release

# Terminal 1 — lithium supplier service (port 3001)
cargo run --release -p supplier-service

# Terminal 2 — battery manufacturer service (port 3002)
cargo run --release -p manufacturer-service

# Terminal 3 — run demo (five scenarios)
./demo/scripts/demo_valid.sh

What This Solves

Under EU Battery Regulation 2023/1542 (enforced 2027), every battery must prove end-to-end sustainability. But each supply chain actor holds trade secrets:

• Supplier knows water usage, sourcing region, recycled content (competitive secrets)
• Manufacturer knows assembly efficiency, energy per cell (proprietary metrics)
• Regulator needs to verify all of it without accessing any raw data

Today's solution is paper + audits. This system replaces that with math.

How It Works

1. Supplier generates Proof₁ (Groth16 over BLS12-377)
   ├─ Private: water usage, recycled content
   ├─ Public: batch_id, claim ("sustainable")
   └─ Proves: data meets thresholds (water ≤ 2000 L/kg, recycled ≥ 10%)

2. Manufacturer receives Proof₁ + batch_id
   ├─ Generates Proof₂ (Groth16 over BW6-761)
   ├─ Recursively verifies Proof₁ is valid
   ├─ Checks: batch_id binds to this supplier's proof (no proof-swapping)
   ├─ Proves: assembly efficiency ≥ 70%
   └─ Returns: Proof₂

3. Regulator scans battery tag, reads batch_id
   ├─ Sends: (batch_id, claim, nonce) to manufacturer
   ├─ Receives: Proof₂
   └─ Verifies: Proof₂ integrity → VALID ✔ or INVALID ✗

Key property: the batch_id is cryptographically bound inside both proofs. A manufacturer cannot reuse a supplier's proof from a different batch — the ZKP system detects it.

Architecture

PROVE/
├── crates/
│   ├── zkp-core/              # Groth16 circuits + proving logic
│   ├── supplier-service/      # Lithium supplier (Axum, port 3001)
│   ├── manufacturer-service/  # Battery manufacturer (Axum, port 3002)
│   └── verifier-cli/          # EU regulator (CLI tool)
├── demo/scripts/              # Five end-to-end scenario demos
└── data/keys/                 # Trusted setup artifacts (generated on first boot)

Components

Component	Role
zkp-core	SupplierCircuit (real Groth16), ManufacturerCircuit (recursive, circuit defined; synthesis pending), proving/verification, serialization
supplier-service	HTTP server simulating a lithium supplier. Generates Proof₁ for pre-seeded batches, ships to manufacturer. Endpoints: /health, /vk, /proof1
manufacturer-service	HTTP server simulating a battery cell manufacturer. Receives Proof₁, validates constraints natively, returns Proof₂. Endpoints: /health, /vk_outer, /ingest, /verify
verifier-cli	CLI tool (EU regulator). Queries manufacturer, deserializes Proof₂, reports VALID/INVALID

Tech Stack

• ZKP: Arkworks 0.5.0 (Groth16, BLS12-377, BW6-761)
• Web: Axum + Tokio async runtime, Serde/JSON
• CLI: Clap, Colored, Indicatif spinners

Why this stack:

• Pure Rust, production-grade (used by Aleo, Espresso, Penumbra)
• Groth16: tiny proofs (~192 bytes), fast verification (milliseconds)
• BLS12-377 ↔ BW6-761: only standardized 2-chain enabling recursive Groth16 without expensive non-native arithmetic

Demo Scenarios (Five End-to-End Tests)

All demos are automated scripts. Build, start services, run scripts.

Demo	What It Tests	Expected Result
demo_valid.sh	Happy path: batch 0x42, clean supplier, efficient manufacturer	✔ VALID
demo_invalid_claim.sh	Batch 0x99: supplier data fails thresholds → no Proof₁ issued	✗ Cannot generate Proof₂ (404)
demo_proof_swap.sh	Manufacturer attempts to use another supplier's proof for batch 0x42	✗ batch_id mismatch detected (422)
demo_manufacturer_fail.sh	Batch 0xCD: supplier clean, but manufacturer efficiency 60% < 70% threshold	✗ Proof₂ generation aborts (422)
demo_forge.sh	Proof₂ tampered on the wire (hex corrupted with "zz")	✗ Deserialization fails (INVALID)

Each demo shows a different attack or failure mode cannot bypass the system.

Implementation Status

Proof	Circuit	System	Status
Proof₁	SupplierCircuit (BLS12-377)	Real Groth16	✓ Fully implemented & tested
Proof₂	ManufacturerCircuit (BW6-761)	Real Groth16 (recursive)	⚙️ Circuit defined; synthesis pending

In the current build, prove_manufacturer() performs the same constraint checks natively (batch_id binding, claim matching, efficiency threshold) and returns a deterministic mock Proof₂. The ManufacturerCircuit R1CS with full recursive verification gadgets is written and compiles — wiring it to Groth16::prove over BW6-761 is the next engineering step (deferred to post-hackathon due to memory/time constraints on BW6-761 proving).

Security Model

What the System Guarantees

• Soundness: if Proof₂ verifies, the entire supply chain satisfies the claim (cryptographic certainty)
• Zero-knowledge: no party's secret data (water usage, efficiency %) is revealed
• Proof binding: the same batch_id is committed inside both Proof₁ and Proof₂ — impossible to swap proofs across batches
• Freshness: each verification includes a random nonce, preventing proof caching/replay

What It Does NOT Guarantee

• Physical-to-digital binding: nothing stops a manufacturer from physically mislabeling a battery with batch 0x42's tag when it used lithium from another batch. This requires a physical anchor — exactly where SICPA's tamper-resistant authentication technology fits in.
• Mass-balance fraud: one supplier proof could theoretically be used to certify more batteries than the batch's lithium could produce. Mitigated by published batch commitments with mass bounds.
• Trusted setup risk: Groth16 requires a setup ceremony; a compromised setup allows proof forgery. Production deployment needs a multi-party ceremony (Powers of Tau) or a setup-free scheme (PLONK, STARKs).

The Honest Framing

This system does not eliminate fraud. It makes fraud detectable, attributable, and expensive — which is what regulation actually needs.

The protocol reduces the attack surface from "trust every document" to "trust one physical authentication moment" — where SICPA already operates.

Prerequisites

• Rust 1.75+ (stable)
• cargo (rustup)

Building from Source

cargo build --release

References

• ARCHITECTURE.md — full system design, proof chain mechanics, circuit definitions, implementation notes
• DELIVERABLES.md — detailed technical deliverables, proof systems, limitations, extensibility
• Demo scripts — ./demo/scripts/*.sh — runnable end-to-end scenarios

License

MIT