Frequently Asked Questions

Why does privacy-preserving compliance matter?

Traditional compliance requires revealing personal data to every counterparty. Consider a user depositing to a DeFi protocol:

• The protocol learns their full identity (name, address, government ID)
• This data becomes a honeypot for breaches
• The user has no control over how data is stored or shared
• Every service they interact with accumulates more personal data

ZKC lets users prove they meet regulatory requirements without revealing the underlying data. The verifier learns "this user has valid KYC" but not "this user is John Smith at 123 Main St."

How is this different from just showing a credential?

Showing a credential reveals everything on it. ZKC enables selective disclosure:

• Traditional: "Here's my passport" — reveals name, DOB, nationality, photo, passport number
• ZKC: "I can prove I'm a citizen of an EU country" — reveals only the proven claim, nothing else

Anonymous is the default: the v2 anonymous profile exposes no holder-derived public handle. A verifier may request a scoped pseudonym through a signed, purpose-bound request, while the legacy globally linkable presentation is available only as an explicitly consented linkable profile.

Doesn't privacy conflict with compliance?

No. ZKC proves the same things that traditional compliance verifies, just without revealing unnecessary data:

When plaintext or broader disclosure is required, the same accountability rules apply: the verifier signs a purpose-bound request and the holder retains a receipt. ZKC can make a later purpose violation attributable; it cannot force a verifier to explain a silent refusal or prevent data from being re-evaluated after disclosure.

How do ZKC proofs work?

ZKC uses zero-knowledge proofs written in Noir and proven via UltraHonk. The flow:

1. Credential issuance: A trusted issuer (e.g., KYC provider) verifies the user off-chain and issues a signed credential
2. Authenticated request: A verifier signs an Authenticated Proof Request (APR) stating the predicates, trust policy, purpose, replay context, and presentation profile
3. Proof generation: After separate consent for each atomic predicate, the user's client generates a ZK proof (~3s) that their credential satisfies the requirements
4. Verification: The verifier checks the proof (~15ms) without seeing the credential
5. Receipt: The holder retains a Disclosure Receipt for the answered or refused request

The proof mathematically guarantees the claims are true, without revealing any data beyond what was requested.

What is "accumulator-based revocation"?

Credentials can be revoked (e.g., if a user fails re-verification). The challenge: how do you revoke without revealing which credential was revoked?

ZKC uses cryptographic accumulators — a data structure where a holder can prove active membership without revealing which credential is being checked. When a credential is revoked, it is removed from the active set; subsequent proofs must use a fresh witness.

Current issuer state is distributed as signed revocation metadata under a pre-pinned issuer key. Holders and verifiers reject stale, future, unsigned, or mismatched state, persist accepted checkpoints across restarts, and retain conflicting signed announcements as fork evidence instead of silently choosing one view. This is local fork detection, not global consistency: isolated, internally consistent histories remain undetected until their signed checkpoints are compared. Credential revocation affects only whether a counterparty accepts a proof; it never freezes or invalidates an underlying asset.

How is the verifier held accountable?

A conforming SDK refuses unauthenticated requests by default. The verifier signs an APR under a stable identity, the declared purpose is bound into the proof context, and the holder keeps a self-contained Disclosure Receipt. Hosted provers, proxies, indexers, and SDK operators are not allowed to require custody of those receipts.

The mechanism proves that a verifier key asked for a disclosure; named-entity weight still depends on continuity between that key and the real organization. It also cannot force the verifier to issue a signed explanation when it declines a user.

What proving system does ZKC use?

ZKC circuits are written in Noir, a domain-specific language for zero-knowledge proofs. Proofs are generated using UltraHonk over the BN254 curve via Barretenberg. The protocol specification is proving-system-agnostic — Noir's pluggable backend architecture allows alternative backends (including Halo 2) in the future.

What does "verifier-controlled trust" mean?

There is no central authority that decides which issuers are trusted. Instead:

• Each verifier publishes a trust policy listing which issuers they accept
• Users can query the registry to find verifiers that accept their credentials
• The registry provides discovery (find issuers) but not trust (decide which issuers are good)

This mirrors how compliance works in the real world: different exchanges and institutions have different requirements and trust different KYC providers.

What credentials does ZKC support?

ZKC defines seven non-exclusive, well-known reference credential schemas for interoperability. They are not a closed list and no issuer or predicate is privileged:

How does the jurisdiction proof work?

The jurisdiction proof uses set membership proofs. The verifier specifies either:

• Allowed list: "User must be resident of US, UK, or EU member states"
• Blocked list: "User must NOT be resident of sanctioned countries"

The proof demonstrates the user's jurisdiction is in the allowed set (or not in the blocked set) using a Merkle tree membership proof. The verifier never learns the user's actual jurisdiction — only that it satisfies the requirement.

Can proofs be aggregated?

Yes, with explicit consent for every atomic predicate. The initial aggregation circuit supports up to eight active proof slots and requires their proof context and holder binding to agree. It currently follows a simulated-recursion profile while backend-native recursive verification matures; aggregation does not turn a multi-predicate request into ambient or blanket consent.

How does ZKC integrate with ZKA?

ZKC credential binding keys and ZKA value-address keys use AFP-KDC v1.0.3 current registry metadata while preserving the immutable AFP-KDC v1.0.2 32-byte master-seed profile; they derive along separate paths. This means:

• Compliance proofs can be bound to shielded transactions without revealing identity
• The credential commitment and ZKA address are unlinkable without the seed
• The credential binding key is derived from the seed, not from the spending key

ZKC also works independently with other privacy-preserving systems: Namada, Penumbra, Ethereum L2s, or any protocol that uses shielded addresses.

How do ZKC, ZKM, and ZKA fit together?

The three protocols answer different questions. ZKC eligibility proves that a holder satisfies a predicate. ZKM authorization proves that a principal permitted an agent to perform a bounded action. ZKA settlement determines whether the resulting value transition is valid and settles.

A composed flow may require all three artifacts independently. A ZKC proof context can carry a future ZKM-defined integration profile, but context binding alone does not create a mandate, prove spend authority, or establish successful settlement. ZKC owns the zkc/* namespace and ZKM owns zkm/*.

What are the conformance levels?

Implementations can target different levels of ZKC support:

• ZKC-Core: KYC proofs and basic verification
• ZKC-Standard: Core + jurisdiction, accreditation, and source of funds
• ZKC-Full: Standard + tax compliance, sanctions clearance, and proof aggregation (the highest core level)

Core, Standard, and Full form a strictly monotonic ladder, each a superset of the one below. ZKC-Agent is not a rung above Full but an orthogonal extension profile: the agent API for automated compliance, layered on any claimed core level (typically Full).

What is the Agent API?

The ZKC-Agent extension profile adds an API for autonomous agents (AI or otherwise) to handle compliance programmatically:

• Auto-respond: Automatically generate proofs for trusted verifiers after validating their authenticated requests
• Policy-based: Configure maximum disclosure levels per proof type
• Pre-computation: Generate proofs in advance for anticipated requests
• Counterparty verification: Verify the other party's compliance before transacting

This enables agent-to-agent compliance where both parties can verify each other meets requirements without human intervention.

Who maintains ZKC?

ZKC is developed by Pyramidal as part of the Pyramidal ZK protocol family, alongside ZKA (Zero-Knowledge Agents). The specification is licensed under Apache 2.0 with a royalty-free patent non-assertion covenant for conformant implementations.