A zero-knowledge proof lets the pool verify a private state transition without receiving its private witness. The witness includes the input notes, ownership material, membership paths, and data used to construct the outputs.

What the proof establishes

The proof binds these properties together. A client cannot present one amount for value conservation and an unrelated amount in the audit record while satisfying the specified relation.

What the proof does not establish

The proof does not decide whether its root is still accepted, whether another transaction has spent its inputs, whether a public account authorized funding, or whether policy permits settlement. Pool contracts and compliance authorization provide those checks.

Cryptographic construction

The engineering design assigns a distinct role to each mechanism: Recipient records and audit records serve different readers and use separate key roles. Neither an encrypted record nor its decryption key substitutes for the owner’s spending witness. The field-encryption construction is protocol-specific. Proof consistency establishes that records were constructed according to the relation; it is not, by itself, a proof of encryption security. The construction is not presented as standardized ECIES or AEAD.

Validation and randomness

Security depends on canonical field and scalar encodings, valid curve points and subgroup membership, consistent parameters, and fresh randomness. Recipients validate recovered records against their authentication data and state leaves before accepting notes. Incorrect randomness or reused encryption material can undermine confidentiality even if the surrounding transaction flow is correct.

Setup and verifier trust

Groth16 relies on circuit-specific setup material. Proof soundness depends on the correct relation, verification key, and setup assumptions. Verification of the wrong relation can invalidate ownership or conservation guarantees. The engineering paper specifies verifiable setup artifacts and controlled verifier changes. Artifact publication and operational governance must be verified separately; the use of Groth16 alone does not establish that a setup ceremony or independent security audit has been completed.