Fertilizer Reserve Lots

Scenario

A national fertilizer reserve operator stores urea (46-0-0) across five warehouses in two jurisdictions. The operator wants to prove to a regulator that aggregate reserves exceed a published threshold, without revealing per-warehouse balances or supplier identities.

Actors

Operator ReserveCo

Owns the urea inventory, operates the warehouses, holds the seal devices, and produces the reserve claim.

Inspector Approved third-party agency

Verifies quantity (weight), grade (lab analysis), and container condition at sealing time. Independent of ReserveCo.

Registry operator Reserve Authority

Maintains the append-only registry, publishes snapshots to a transparency log, exposes the auditor read API.

Verifier Regulator

Consumes the reserve claim, checks the ZK proof, and confirms the threshold and snapshot reference.

Auditor Independent statutory auditor

Performs cyclical re-inspection on a statistically sampled subset of lots and validates registry inclusion proofs.

Reserve unit

Each reserve unit is a 1-tonne polypropylene bulk bag of urea, palletized and stored under climate control. Lot identification follows the inspector's container numbering plus a content-addressed commitment over the inspection record.

Seal type

Tamper-responsive Ed25519 seals with:

Mesh enclosure that severs key access on cutting or drilling
Internal accelerometer for movement logging
USB-C interface for in-warehouse challenges; LoRa fallback for periodic remote attestation

Provisioning includes a firmware measurement that is registered alongside the public key.

Registry fields

Field	Example	Notes
`seal_id`	`seal_01HZX...`	Unique per device
`public_key`	`ed25519/...`	Registered at provisioning
`firmware_measurement`	`sha256:...`	Re-checked on each attestation
`lot_commitment`	`sha256:...`	Hash of inspector record
`material_class`	`urea_46_0_0`	Public taxonomy field
`mass_kg`	(committed)	Hidden by ZK aggregation
`warehouse_id`	(committed)	Hidden by ZK aggregation
`status`	`active`/`broken`/`retired`	Updated by registry

Attestation flow

sequenceDiagram
  participant I as Inspector
  participant O as Operator
  participant Reg as Registry
  participant V as Regulator
  participant S as Seal

  I->>O: Inspection record (weight, grade, container)
  O->>Reg: Bind seal_id to lot commitment
  Reg->>O: Snapshot S₁
  V->>O: Request reserve claim ≥ 10,000 t
  O->>S: SealChallenge × N seals
  S->>O: SealAttestation × N signatures
  O->>O: Build ZK aggregate proof over S₁ and signatures
  O->>V: Reserve claim + ZK proof
  V->>Reg: Verify snapshot S₁ in transparency log
  V->>V: Validate proof, confirm threshold

Privacy options

The operator can publish the claim under three levels of disclosure:

Full disclosure — per-seal attestations and lot details revealed.
Lot-level commitment, public totals — commitments and aggregate mass revealed; individual lot fields hidden.
ZK threshold proof — only the threshold and snapshot are revealed; the verifier learns nothing about individual lots beyond the proof's validity.

For routine regulatory disclosure the operator uses option 3. For an annual statutory audit the auditor uses the audit interface and gets option 1 under a confidentiality agreement.

Failure cases

Seal alarm during transit. Tamper response disables the key. Lot is removed from active set. The operator must re-inspect and re-seal before re-entry.
Snapshot drift. Verifier pins snapshot S₁ but the operator computes the proof against S₂. Verifier rejects the claim and demands a consistent snapshot reference.
Lot double-binding. Operator attempts to register two seals against the same lot commitment. Registry refuses the second binding; auditor sees the rejected event in the audit log.
Off-book lots. CPHAR cannot detect lots the operator never registered. Disclosure obligations must come from regulation and re-inspection sampling.