A reserve claim packages a set of seal attestations and the registry context required to verify them. Claims are the unit a relying party — regulator, customer, counterparty — actually consumes.
Components of a claim
A reserve claim contains:
- A list of
(seal_id, lot_commitment, attestation)tuples. - A registry snapshot reference (Merkle root or content-addressed commitment) covering the relevant seal records and revocation list.
- A policy specification: what the claim asserts (e.g. "≥ 10,000 metric tons of urea fertilizer in jurisdiction X").
- An optional zero-knowledge proof aggregating the per-lot fields the prover wishes to hide. See ZK integration.
No double-counting
A naive system lets an operator count the same lot twice under two seals. CPHAR addresses this by binding each registered seal to a unique lot commitment and requiring that the registry's append-only log prevents two active bindings to the same commitment.
Verifiers must check this property explicitly. A signed attestation that points to a commitment also present under a different active seal is grounds to reject the claim.
Snapshot consistency
A claim is verified against a specific registry snapshot, not "the live registry." This makes verification reproducible and protects against time-of-check / time-of-use ambiguity. Auditors typically pin claims to snapshots that match their inspection cadence.
sequenceDiagram
participant P as Prover
participant R as Registry
participant V as Verifier
P->>R: Pin snapshot S at time t
R->>P: Snapshot commitment
P->>P: Gather attestations within freshness window
P->>V: Reserve claim referencing S
V->>R: Fetch S (or its commitment)
R->>V: S commitment + inclusion proofs
V->>V: Validate attestations against S
Assumptions
What this proves
- Each referenced seal was alive at the claimed time, signed a fresh challenge, and the registry snapshot lists no conflicting binding.
- The aggregate property (e.g. total mass) holds, conditional on the inspection records each lot commitment refers to.