> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zprotocol.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Privacy & Compliance

Privacy and compliance are often framed as opposites. They are not. A well-designed privacy system gives the user control over disclosure: the cryptography prevents involuntary disclosure, and a separate mechanism allows voluntary disclosure when the user chooses. The ShieldedPool is built around this distinction. This page describes the compliance-supporting features.

## Entry screening

Funds entering the ShieldedPool can be screened at the deposit boundary. The screening is configurable per integration: an institutional integrator can require that deposited funds carry a clean provenance proof; a user-facing wallet can apply lighter screening or none at all.

Entry screening uses standard EVM tooling for the source-side address (blocklist checks, sanctions screening, transaction provenance analysis) applied before the deposit contract accepts the funds. Funds that fail screening are rejected at the deposit boundary; the rejection is on the source chain (where the address is public), not after entry to the pool.

Z does not impose mandatory screening on all deposits. Integrators choose their screening posture.

## Withdrawal screening

Withdrawals from the pool to public addresses can be screened similarly. An integrator can configure withdrawal addresses to require a clean recipient, an attested association set, or other criteria appropriate to the integrator's regulatory posture.

The screening operates on the public side: the recipient address, the amount, and any visible context. The user's in-pool history remains private; screening checks the destination, not the source within the pool.

## Privacy pools and association-set proofs

The privacy pools construction allows a user to prove that their funds are associated with a specific "good" set without revealing which member of that set they are. For example, a user might prove that their deposit originated from one of a set of regulated exchanges, without revealing which exchange.

The association set is a Merkle tree of approved deposits. The user proves in zero-knowledge that their note's deposit is included in the tree. The proof reveals membership in the set; it does not reveal which specific deposit.

The construction is useful for integrators who want to demonstrate clean provenance for compliance purposes without sacrificing the privacy property that makes the pool valuable.

## Selective disclosure via viewing keys

Viewing keys are the primary voluntary-disclosure mechanism. A user shares a viewing key with a recipient (a tax accountant, a regulator, an auditor) and the recipient gains read access to history within the key's scope.

Scope is configurable:

* **Time-bounded scope.** The viewing key reveals transactions only within a specified date range.
* **Asset-bounded scope.** The viewing key reveals transactions involving only specific asset types.
* **Counterparty-bounded scope.** The viewing key reveals transactions with specific counterparties.

A scoped viewing key cannot reveal transactions outside its scope, even to the holder of the key. The cryptography is the enforcement; there is no trust dependency on Z.

What a viewing key reveals (within scope): all transactions, asset types, amounts, counterparties (where the counterparty is also a ShieldedPool address derivable from the same key holder's history), and balances.

What a viewing key does not reveal: transactions outside its scope, the user's spending key, or other users' activity.

## Institutional integration

Institutions integrating the ShieldedPool typically combine several of the above:

* Mandatory entry screening on deposits from corporate treasury addresses, using their compliance vendor's screening.
* Privacy pools association-set proofs to demonstrate that institutional funds remained within a regulated subset of the pool.
* Scoped viewing keys issued to internal audit teams and to external auditors as part of normal financial controls.

The combination gives the institution real privacy for ordinary operations and real compliance for the moments when compliance is required. It is the difference between operating in a panopticon and operating with reasonable confidentiality plus voluntary, scoped disclosure.

## Design properties

A few principles that govern the privacy-and-compliance design:

* **Cryptographic enforcement, not policy.** The privacy guarantee is in the math, not in Z's operational posture. Z cannot reveal what it does not know.
* **Voluntary disclosure, not surveillance.** Disclosure is a user choice. The system does not impose disclosure on users who have not chosen it.
* **Scope discipline.** Disclosure is scoped. A user disclosing a year of transactions for tax purposes does not also disclose ten years.
* **No backdoors.** The compliance features are constructions on top of the cryptographic primitives, not exceptions to them.

## Related reading

* [ShieldedPool overview](/docs/shieldedpool/overview)
* [Privacy architecture](/docs/shieldedpool/privacy-architecture)