Selective Disclosure for Payment Evidence: A Valid Proof Is Not a Complete Payment Record

Start with the exact mechanism, not the umbrella term

In the current OpenZeppelin design, selective-disclosure proofs are generated client-side and verified off-chain. The prover may be a holder, sender, or auditor depending on the proof variant. The disclosure recipient supplies a public key and a fresh nonce for the request.

For event-based disclosures, the proof bundle includes a circuit identifier, an event reference, the proof itself, and disclosure ciphertext. Verification is not just a proof check. The verifier independently resolves the referenced on-chain event and relevant account or auxiliary state, constructs the public inputs, selects the verification key that matches the stated circuit_id, verifies the UltraHonk proof, and only then decrypts the disclosed value.

That reconstruction step is the part not to skip. If the verifier accepts event or account inputs supplied by the prover instead of rebuilding them from the named source, the proof is no longer properly bound to that event.

For review, it helps to separate four things:

1. Proof validity: did the proof verify under the expected circuit, key, and public inputs?
2. Technical event/state binding: did the verifier independently resolve the named event or account state that the proof is supposed to describe?
3. Claim scope and completeness: what exact positive statement was proven, and what other events or facts may still be omitted?
4. Business truth: does the technical event correspond to the right invoice, order, beneficiary, legal entity, settlement state, refund history, or reconciliation record?

The first two are technical checks. The third tells you how far the claim goes. The fourth lives in the underlying business record and still needs human review.

“Payment verified” is usually too broad

The specification does not define one generic “payment verified” proof. It defines several narrower scopes.

A D-recipient proof can establish the amount paid to the relevant on-chain recipient for a named transfer-family event. A D-sender proof can establish the amount sent to an on-chain recipient. A D-auditor proof can disclose an amount for an event within the auditor’s scope. A D-balance proof can establish a current confidential balance value or a balance predicate. Aggregate variants can prove an exact or threshold statement across a finite, explicitly enumerated set of events.

That matters because each variant answers a different question.

There is one more boundary: authority. For a SpenderTransfer, a sender-side proof establishes the spender’s transfer. It does not by itself establish that the owner’s delegation was valid or sufficient for the business purpose. If that authority matters, delegation evidence is a separate question.

Keep the identifiers separate too. For event proofs, the technical reference is ref_E = (tx_hash, op_index, event_index). A finance system may have its own payment, instruction, order, invoice, or provider identifier. They may belong to the same business story, but they are not the same reference.

Hidden does not mean irrelevant

The whole point of selective disclosure is to reveal less.

In this mechanism, transfer amounts and balances can remain confidential while sender and recipient addresses remain visible. The intended recipient can learn the disclosed amount or predicate without receiving a blanket view of every confidential value.

That minimization is useful. It also creates a simple review problem: the holder is not a complete-history source. A valid holder-generated proof can establish one selected positive statement while other events remain undisclosed.

So I would never translate:

not disclosed → not material

Those hidden events may still matter to completeness, refunds, reversals, authority, net exposure, business purpose, or reconciliation. If the decision requires completeness, a selected holder proof is not enough on its own.

And decryption does not solve the retention problem. A narrow disclosure does not enforce narrow retention. Once the intended recipient has plaintext, the cryptographic mechanism does not prevent that recipient from storing, forwarding, or leaking it. So data minimization has two separate questions: what had to be disclosed, and what should be retained afterward.

The verifier still has a trust model

A proof can be valid without making the whole conclusion trustless.

The verifier must trust the expected circuit definition and the verification-key set associated with the circuit_id. The specification treats the verification-key set as a trusted input. Using a key for a maliciously altered circuit can lead to a false statement being accepted as valid.

Source resolution is another dependency. RPC or indexer infrastructure has to return the event or account state needed to reconstruct the public inputs. If an indexer is involved, completeness and ingestion freshness are evidence questions, not backend trivia.

For auditor-produced proofs, the verifier must resolve the auditor key version that was active at the event ledger. If that historical key cannot be resolved, the review should not silently substitute a current key.

So “the proof passed” is not enough to record. The reviewer also needs the circuit, key, source, event or state, recipient request, and relevant version that the verification relied on.

Time means different things for different proofs

A common mistake is to give every proof a generic “valid until” field.

The exact selective-disclosure specification reviewed here does not define a credential-style expiry timestamp, revocation list, or status-list model for these proofs.

Recipient binding works differently: the disclosure recipient supplies a public key and a fresh nonce. The proof is bound to that recipient and request. That is request binding, not “expiry” or “revocation.”

Balance proofs behave differently. For D-balance, the verifier reads the current balance commitment. If the account state changed after the proof was generated, the old proof fails against the new state and has to be regenerated.

Historical event proofs have another time model. A proof can remain a valid statement about the referenced historical event even if the current economic outcome has changed. A later refund, reversal, correction, or reconciliation exception can make the old proof insufficient for today’s finance question without making the original event statement cryptographically false.

So historical proof validity and current business status belong in separate fields.

The proof still needs a business link

The protocol can bind a proof to an on-chain event. It does not know whether that event corresponds to the right invoice, purchase order, API obligation, supplier, payroll item, customer refund, or internal approval chain.

If a finance workflow treats the referenced transfer as a payment, the reviewer may still need a separate chain of references:

technical event reference → payment/instruction ID → invoice/order/resource reference → expected beneficiary → expected asset and amount → later refund/reversal/correction → reconciliation status → exception owner

That is the practical split: selective disclosure can reduce how much technical data the reviewer receives, while the business record carries the context the proof was never designed to contain.

Where a valid proof can still go wrong in review

A compact proof can fail a review even when the cryptography is sound.

A stale D-balance proof can fail because the live state changed. A historical event proof can be misused as a statement of current economic status. A wrong verification key can validate the wrong proposition. A proof can become detached from its intended transaction if the verifier skips independent event resolution.

Other failures happen outside the proof math: a selected holder proof can omit material events; an on-chain address can be mistaken for a verified legal entity; a SpenderTransfer can be mistaken for proof of owner authorization; an indexer gap can make source reconstruction incomplete; and a recipient can retain or disclose plaintext after successful decryption.

These are different problems. They should not end up compressed into one “proof valid / proof invalid” flag.

Selective Disclosure Proof Scope Matrix

Do not store recipient private keys, holder viewing keys, auditor secret keys, proof witnesses, API credentials, seed phrases, unrelated PII, or full histories when a stable reference and narrow disclosed value are sufficient.

What this does not prove

The question I would leave with is:

What exactly did the proof establish, against which source, at what point in time — and what underlying record still has to be opened before the decision is complete?