Track privacy-preserving receipt and compliance proof extensions #99

Context

The ACK roadmap already mentions advanced privacy-preserving techniques such as zero-knowledge proofs, and ACK-Pay receipts are currently modeled as verifiable payment evidence. A useful next step would be to track how privacy-preserving receipt/compliance proofs could fit into ACK without forcing one proving system or making the core protocol heavy.

Proposed scope

Keep this as a small design track first:

1. Document the extension points where a receipt may reference privacy-preserving proof material.
2. Define the minimum metadata shape needed to describe an external proof without embedding verifier-specific payloads in ACK core.
3. Clarify which claims are good candidates for selective disclosure or ZK-style proofs, for example:
   • payment satisfied a request without exposing unrelated wallet/account data
   • policy checks passed before signing
   • spend limit or merchant category constraints were satisfied
   • compliance/KYA/KYC attestations were valid at execution time
4. Add a non-normative example once the metadata shape is stable.

Non-goals

• Do not pick a proving system in ACK core.
• Do not require ZK proofs for normal ACK-Pay receipt verification.
• Do not replace the existing Verifiable Credential receipt model.

Why this matters

Agent payments often need auditability and compliance evidence, but agents should not reveal more identity, wallet, or policy data than necessary. A small extension pattern would let ACK integrations compose with external proof systems while keeping the base ACK-Pay flow simple and interoperable.

I would be happy to help with a first docs-only PR if this direction matches the maintainers' intended roadmap.