Methodology
Conceptual synthesis and comparative architecture analysis of zero-knowledge proofs, verifiable credentials, revocation, verification, and governance.
Abstract
Public blockchains make transaction verification widely accessible while creating persistent visibility into financial activity. Compliance processes often respond by collecting and duplicating identity data. This paper examines whether zero-knowledge proofs, verifiable credentials, and selective disclosure can verify defined compliance facts without exposing unnecessary personal information. It combines cryptographic standards, public-ledger privacy research, and architecture analysis. The evidence supports technical feasibility for predicate proofs and data-minimized credentials, but not a claim that zero knowledge can replace identity proofing, legal judgment, monitoring, or governance. A workable model separates issuer, holder, verifier, policy, credential status, and on-chain proof verification. Privacy is treated as controlled disclosure, not immunity from lawful accountability.
Keywords: privacy-preserving compliance; zero-knowledge proofs; verifiable credentials; selective disclosure; privacy-preserving KYC; on-chain identity
Research question
Can financial systems verify eligibility and compliance without unnecessarily exposing personal information?
Introduction
A public ledger can verify that a transaction followed consensus rules while revealing a durable graph of addresses, balances, and interactions. A traditional compliance process can identify a customer while distributing copies of passports, addresses, and screening records across many firms.
These systems optimize different objectives and both can create unnecessary exposure. Privacy-preserving compliance asks a narrower question: what is the minimum evidence needed for a particular decision, and can that evidence be verified without transferring the entire underlying record?
Review approach
This paper uses a narrative evidence review and conceptual architecture analysis. It examines the NIST Privacy-Enhancing Cryptography project, the W3C Verifiable Credentials Data Model 2.0, Nadler and Schär’s empirical and policy analysis of Tornado Cash, and current primary documentation. It does not present a new cryptographic construction, benchmark proof systems, or offer a legal interpretation for a particular jurisdiction.
Privacy, anonymity, and verification
Privacy is control over information and context. Anonymity concerns whether an activity can be linked to an identity. Compliance concerns whether a defined rule and evidence requirement are satisfied.
These properties can coexist in different degrees. A regulated provider may know a customer’s identity while a counterparty learns only that an eligibility check was completed. A public transaction may be pseudonymous while its history remains linkable.
Nadler and Schär show why public ledgers create legitimate demand for privacy. Once an address is connected to an entity, its wider history can become visible. Their Tornado Cash analysis also documents illicit use and argues against two extremes: unconditional rejection of every privacy protocol and acceptance without inquiry.
Zero-knowledge proofs
NIST defines a zero-knowledge proof as a way to establish the truth of a statement without revealing additional information used to establish it. In a proof of knowledge, the prover demonstrates knowledge of a secret witness consistent with a public statement.
Financial examples include proving that:
- age exceeds a threshold;
- a credential was issued by an accepted authority;
- a value lies below or above a limit;
- a transaction conserves value under private inputs; or
- a mandate authorizes an action within a bound.
The proof establishes the encoded relation. It does not prove that the issuer verified real-world inputs correctly, that the policy is lawful, or that a credential belongs to the person presenting it unless those properties are part of the system.
Verifiable credentials
W3C Verifiable Credentials 2.0 defines issuers, holders, and verifiers. An issuer makes claims, a holder stores and presents them, and a verifier evaluates the presentation under its policy.
This division supports data minimization. Instead of each service repeating full identity proofing, a holder can present a credential or derived proof. Selective disclosure can reveal chosen attributes. Predicate proofs can reveal that a condition holds without revealing the underlying value.
Trust remains explicit. The verifier decides which issuers it accepts and for which claims. Credentials need securing mechanisms, expiry, status, and revocation. Decentralized identifiers are optional; using one does not make the issuer trustworthy.
A compliance-proof architecture
A practical architecture has six parts.
The issuer performs identity proofing or another authoritative check. The holder controls the credential. The verifier defines the evidence required for an action. The policy expresses the predicate. The status mechanism indicates whether the credential remains valid. The proof verifier, possibly a smart contract, checks the cryptographic result.
These roles should not collapse into one provider without disclosure. Otherwise, a system advertised as decentralized may allow one organization to issue, observe, verify, revoke, and correlate every credential use.
On-chain verification should receive only the proof and public inputs needed for the decision. Personal documents and full credentials should not be published to an immutable ledger.
Privacy-preserving KYC
KYC is not one boolean. It can include identity, beneficial ownership, risk classification, source-of-funds inquiry, monitoring, and recordkeeping. Different institutions and transactions require different evidence.
Zero-knowledge and credentials are most useful when a decision can be reduced to a stable, auditable predicate. “A recognized provider completed identity proofing and this credential is current” is more tractable than “this transaction is not suspicious,” which requires context and judgment.
The architecture should allow escalation. A verifier may accept a minimal proof for routine activity and request additional evidence under a defined, lawful process. Privacy-preserving compliance is selective disclosure under governance, not a promise that identity can never be disclosed.
Revocation and authorization
Credentials and delegated permissions change. A person may lose eligibility, a credential may be compromised, or an agent’s mandate may expire.
Revocation checks can undermine privacy if an issuer learns every place a credential is presented. Status lists and privacy-preserving mechanisms can reduce direct “phone home” behavior, but list size, update frequency, and correlation metadata still matter.
Authorization should be purpose-bound. A proof that a user passed KYC does not authorize every transaction. A separate mandate can define asset, amount, destination, time, and revocation.
Correlation and metadata risk
Selective disclosure can fail in practice when a unique credential identifier, signature, timestamp, or rare attribute combination appears repeatedly. W3C guidance warns about identifier-, signature-, metadata-, and validation-based correlation.
Unlinkable proofs reduce some signals but do not remove network addresses, browser identifiers, transaction timing, or application logs. Privacy must be evaluated across the full workflow.
Performance and implementation constraints
Proof systems differ in proof size, generation time, verification cost, setup, and cryptographic assumptions. A circuit can faithfully enforce the wrong policy or contain a bug. Specialized implementations require independent review and careful parameter management.
On-chain verification incurs fees and exposes public inputs. Off-chain verification reduces ledger cost while changing audit and trust properties. Batching may improve performance and enlarge the consequence of one error.
Credential schemas and issuer policies must also interoperate. Cryptographic compatibility without semantic agreement can prove that an attribute exists while institutions disagree about what it means.
Privacy versus accountability
Nadler and Schär’s voluntary-disclosure proposal for mixer users illustrates a middle path. A user can disclose a proof connecting a withdrawal to a deposit to a selected counterparty while keeping the link from the general public. The counterparty can assess the transaction graph as though the mixer had not broken the public link.
This approach is not complete compliance. It relies on voluntary presentation, does not establish identity by itself, and may not address funds received from others. Its value is conceptual: evidence can be disclosed to an accountable verifier without disclosing it to everyone.
Design and policy implications
Define the minimum statement before choosing cryptography. Document issuer trust and evidence. Separate identity proofing from transaction authorization. Provide current status and revocation without routine correlation. Keep personal data off public ledgers. Test replay, stolen credentials, stale status, colluding verifiers, and metadata leakage.
Compliance policy should remain reviewable by accountable humans. A proof verifier should not silently convert an uncertain legal category into an irreversible transfer.
Claims, credentials, and identifiers
A privacy-preserving system should begin with the claim required for a decision. “This account passed a specified eligibility policy at time T” is narrower than disclosing a passport, address, date of birth, and screening file. Data minimization reduces the information copied across firms and the harm if a verifier is compromised.
Selective disclosure lets a holder reveal chosen attributes from a credential. A zero-knowledge proof can go further by proving a predicate without revealing the underlying value. A range proof can show that an age or balance exceeds a threshold. A membership proof can show inclusion in an approved set. An eligibility proof can combine predicates defined by a policy. These proofs show that a statement follows from committed inputs; they do not establish that the original inputs were truthful.
Verifiable credentials provide signed assertions from an issuer to a holder, which can present them to a verifier. Decentralized identifiers can help locate verification material or express identifier control, but “decentralized” does not mean that every issuer is trustworthy or that an identifier maps uniquely to a legal person. W3C standards define interoperable data and verification models; they do not decide which institution is authorized to attest a regulated fact.
Issuer, holder, and verifier trust
The issuer is responsible for evidence collection and the meaning of the credential. If an issuer accepts forged documents, uses an outdated sanctions list, or misclassifies jurisdiction, a mathematically valid proof can preserve the error. Governance must define approved issuers, assurance levels, audit, liability, and removal.
The holder controls presentation but may share credentials, keys, or proof material unless the design binds them appropriately. Strong device or account binding can reduce sharing while increasing recovery and surveillance risks. Binding should be proportionate to the decision rather than assumed for every credential.
The verifier controls the policy and can request excessive claims even when the proof system supports minimization. A privacy-preserving format does not prevent a service from making broad disclosure a condition of access. Accountability therefore needs policy review, purpose limitation, retention rules, and a record of which claim was requested.
Jurisdiction and sanctions claims
Jurisdiction is rarely a pure fact about one identifier. It may depend on residence, incorporation, service location, investor status, or transaction context. A credential can attest to a defined proposition, but the verifier must ensure that the proposition matches the applicable rule. Encoding “permitted jurisdiction” without a versioned policy hides legal interpretation inside a boolean.
Sanctions screening is also time-sensitive and context-dependent. A proof that an identity was not matched against one list yesterday does not establish that the person is not sanctioned today, that beneficial owners were screened, or that transaction monitoring is unnecessary. Privacy-preserving screening may reduce repeated disclosure, but false positives, aliases, list updates, and legal disclosure duties remain.
The proof should bind the policy identifier, list version, issuer, subject, verifier or audience where appropriate, and freshness window. This makes the scope inspectable and prevents a verifier from presenting an old proof as a current universal clearance.
Revocation, expiry, freshness, and replay
Credentials become invalid because an underlying fact changes, an issuer withdraws an assertion, a key is compromised, or the credential expires. Revocation registries can expose status, but naive registries may reveal which credential a person holds or allow repeated correlation. Privacy-conscious status mechanisms can use accumulators, short-lived credentials, or non-identifying status lists, each with operational trade-offs.
Expiry limits how long a credential can be relied upon without reissuance. Short validity improves freshness but increases issuer availability and holder burden. Long validity reduces operational cost while allowing stale facts to persist. The interval should follow the volatility and consequence of the claim.
A proof can be valid and still replayed in the wrong transaction. Binding it to a verifier challenge, nonce, purpose, chain, and deadline reduces reuse. The verifier must consume or record the nonce atomically. Publishing a reusable proof on-chain can allow observers to copy it or correlate all uses.
Linkability and metadata leakage
Zero knowledge protects the witness defined by the circuit; it does not hide all surrounding data. Wallet addresses, transaction timing, gas payer, network location, credential issuer, verifier contract, and repeated pseudonyms can reveal patterns. A unique nullifier can stop double use while also linking actions if reused across contexts.
Designers must decide which correlation is necessary. A regulated service may need to detect repeated use within one program without linking activity across unrelated services. Pairwise identifiers or domain-specific nullifiers can support that separation, but recovery and multi-device use become harder.
Metadata minimization should cover logs and operations as well as proofs. Debug systems should not store witnesses, full credentials, or unnecessary identity attributes. Audit records can retain policy version, issuer, verification result, timestamp, and authorized access without retaining the underlying document.
On-chain and off-chain verification
On-chain verification provides a shared, deterministic result that contracts can consume. It also makes verifier logic, calls, timing, and often proof data public. Gas cost and block limits constrain complex circuits. Upgrading a verifier can create governance and compatibility risk.
Off-chain verification can protect transaction details and support more complex policies, but users and contracts must trust the verifier's signed result or an attestation network. Availability, key management, and audit logs become critical. A hybrid design may verify a proof off-chain and place a short-lived, purpose-bound authorization on-chain.
Neither location resolves legal accountability. An authorized party must remain able to explain the policy, identify the responsible issuer and verifier, handle correction, and respond to valid legal process. Privacy should limit unnecessary disclosure, not make responsible operation impossible.
Performance, circuits, and interoperability
Proof generation can require substantial computation or memory, especially on mobile devices or for complex policies. Verification may be cheaper but still material on-chain. Trusted setup requirements, proving-system assumptions, specialized hardware, and library security affect the risk profile.
Circuit complexity increases with policy detail, credential formats, signature verification, revocation checks, and multiple issuers. Bugs can accept invalid proofs or reject legitimate users. Circuits and parameters need review, versioning, test vectors, and a controlled upgrade process. A change in policy may require a new circuit rather than a configuration edit.
Interoperability requires more than using a W3C credential envelope. Systems must agree on schemas, semantics, issuer assurance, cryptographic suites, status checking, presentation exchange, and error handling. Bridging formats can weaken privacy if the bridge sees every credential or maps stable identifiers across domains.
Attack and operational failure scenarios
Attackers may compromise an issuer key, steal a holder wallet, exploit a verifier contract, generate a proof against an obsolete policy, or force a fallback that requests full documents. An availability attack against a revocation service can either deny legitimate users or tempt operators to skip status checks. Recovery procedures can become the weakest path if they bypass credential binding.
Operational failures include clock disagreement, expired status data, unsupported proof versions, lost holder keys, inaccessible issuers, and inconsistent policy rollout. Fail-closed behavior protects the service but can exclude legitimate users. Fail-open behavior preserves access while accepting unverified risk. Systems should define which failures permit delay, limited service, manual review, or denial.
Disclosure under lawful process remains possible where applicable. A minimized system may keep identifying evidence with the issuer or another authorized party rather than every verifier. Governance should specify who can disclose, under what authority, what is logged, and how erroneous records are corrected.
Future research and design implications
Research should compare proof-generation time, verification cost, failure rates, revocation latency, linkability, issuer concentration, and user recovery across architectures. Legal and operational studies should test whether minimized proofs satisfy particular obligations in particular jurisdictions rather than treating “compliance” as one universal predicate.
Design should make the verified claim visible in human-readable form. Users and reviewers need to know the issuer, policy version, freshness, audience, and consequence of failure. A green check mark without that context converts cryptographic assurance into unjustified institutional trust.
Praxifi's interest in privacy-aware authorization provides a disclosed design context. It is not evidence that a Praxifi implementation satisfies legal or technical requirements. Such a claim would require jurisdiction-specific review, implementation audit, adversarial testing, and operational evidence.
Comparative assurance model
Conventional compliance centralizes documents with each verifier, creating repeated disclosure and large data stores. Federated identity can reduce repetition but concentrates correlation and availability in an identity provider. Holder-controlled credentials distribute presentation while relying on approved issuers and secure recovery. Zero-knowledge presentations can minimize attributes further, at the cost of specialized cryptography, policy encoding, and more complex status checks.
The appropriate model depends on the claim. A low-risk age threshold may justify a short-lived predicate proof. A high-risk institutional onboarding decision may require beneficial-ownership evidence, records, and ongoing monitoring that cannot be compressed into one boolean. Minimization means collecting what the decision requires, not forcing every decision into the smallest possible proof.
Assurance should be layered: evidence quality at issuance, control of the holder key, cryptographic validity, current status, correct policy interpretation, and accountable verifier operation. A failure in any layer can invalidate the practical conclusion while the proof itself remains valid.
Open research questions
Open questions include privacy-preserving beneficial-ownership screening, secure recovery without cross-service correlation, status checking during issuer outage, and audit methods that reveal policy compliance without reconstructing full user histories. Usability studies must test whether people understand what they prove and whether consent is meaningful when a service requires the proof.
Independent implementations should be benchmarked for proving time, memory, verification cost, accessibility, revocation latency, and metadata leakage. Research should also examine governance failure: compromised issuers, incorrect legal interpretations, emergency disclosure, and coordinated exclusion by a small issuer set.
Those institutional questions remain decisive.
Limitations
The paper does not benchmark ZKP systems or assess compliance with a specific law. Production evidence in financial KYC remains limited. Standards continue to evolve. The Tornado Cash case involves mixers and cannot represent every privacy-preserving finance design.
Conclusion
Financial systems can verify some compliance facts with less disclosure. Zero-knowledge proofs and verifiable credentials provide credible technical tools for predicate proofs, selective disclosure, and minimized on-chain verification.
They do not remove the need for trustworthy issuers, current status, policy, legal interpretation, and accountability. Privacy-preserving compliance is best understood as a governed evidence architecture: reveal what the decision requires, to the party authorized to decide, for the period in which the evidence remains valid.
Later evaluations should measure disclosure reduction alongside reliability, revocation, and accountability.
References
- National Institute of Standards and Technology. “Privacy-Enhancing Cryptography: Zero-Knowledge Proof.” Updated 2026-07-01. https://csrc.nist.gov/projects/pec/zkproof
- World Wide Web Consortium. 2025. Verifiable Credentials Data Model v2.0. https://www.w3.org/TR/vc-data-model/
- Nadler, Matthias, and Fabian Schär. 2023. “Tornado Cash and Blockchain Privacy: A Primer for Economists and Policymakers.” https://doi.org/10.20955/r.105.122-36
Conflict disclosure
PraxiHub is associated with Praxifi. The author may hold roles or ownership interests in Praxifi, whose broader research interests include privacy-preserving verification and financial automation. No implementation from Praxifi was tested.
Publication history
Draft version 0.1, prepared 2026-07-30. Not peer reviewed.