> ## 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.

# ShieldedPool Overview

The ShieldedPool is the primary destination for assets on Z. Assets deposited into the pool become private notes, balances and transfers inside the pool are cryptographically hidden, and interactions with utilities outside the pool happen via the Broadcaster and the RelayAdapter pattern, in a way that does not link back to a user's identity. For the cryptographic detail, see [Privacy architecture](/docs/shieldedpool/privacy-architecture). This page covers the user-facing view.

## Entering the ShieldedPool

### Stablecoins and other ERC-20 tokens

USDC and other ERC-20 tokens enter through the bridge from Ethereum, Arbitrum, or Base.

Shielded minting (private path):

* Deposit the source asset into the bridge contract on the source chain.
* Generate a Poseidon commitment off-chain. Only the commitment crosses the bridge; no recipient address is revealed.
* The wrapped form of the source asset is minted into a ShieldedMinter vault, not to any user address.
* Claim the note by proving ownership with a ZK proof.

A deposit on the source chain and the resulting position on Z are not linkable when shielded minting is used. An observer on the source chain sees that assets were locked and a commitment was created. They cannot link the commitment to any address on Z.

See [Shielded deposits and withdrawals](/docs/shieldedpool/deposits-withdrawals) for full detail.

### ZEC

ZEC enters Z via the ZEC SPV bridge. The goal is for ZEC to arrive already shielded inside the ShieldedPool as private notes, without an intermediate public address on Z. The ZEC SPV bridge is tracked on the roadmap.

## Inside the pool

* **Private balances.** A balance is a commitment in a Merkle tree. No address-to-balance mapping exists on-chain. No block explorer shows the balance.
* **Private transfers.** Assets can be sent to another ShieldedPool user without revealing the sender, the recipient, the amount, or the asset type. An outside observer sees that a ShieldedPool transaction occurred. Nothing more.
* **Application access via RelayAdapter.** The RelayAdapter pattern handles unshielding, execution, and reshielding output in one atomic transaction. The call reaches the adapter either via the Broadcaster (off-chain relay, pays gas, collects per-slot fees) or via self-relay (the user signs from their own wallet).

## Checking a balance

Shielded balances are not readable from the chain directly. They are committed as encrypted event data. A wallet scans ShieldedPool events and attempts decryption using the user's viewing key. Notes that belong to the user decrypt successfully; the balance is derived from those notes. No one else can read the encrypted event data.

## Exiting the pool

* **To an application, via the Broadcaster.** The RelayAdapter pattern handles unshielding, execution, and reshielding output in one atomic transaction. See [RelayAdapter pattern](/docs/shieldedpool/relay-adapter).
* **To a plaintext address.** Assets can be sent from the ShieldedPool to any public address. The recipient address and amount are visible on-chain. The ShieldedPool origin of the funds is not revealed.

## Viewing keys

A viewing key gives read-only access to shielded transaction history without spending authority. Users can share a viewing key with:

* A tax accountant, scoped to the relevant fiscal year.
* A regulator or auditor, scoped to specific transactions or a time range.
* An institutional compliance team, for full history within a defined scope.

A viewing key reveals: complete transaction history within its scope, all asset types and amounts, and current shielded balances.

A viewing key cannot: spend funds, view other users' activity, or selectively omit transactions within scope.

See [Privacy and compliance](/docs/shieldedpool/privacy-compliance).

## Where to go from here

* [Privacy architecture](/docs/shieldedpool/privacy-architecture): the cryptographic detail.
* [Shielded deposits and withdrawals](/docs/shieldedpool/deposits-withdrawals): deposit and withdrawal mechanics.
* [RelayAdapter pattern](/docs/shieldedpool/relay-adapter): how private application access works.
* [Privacy and compliance](/docs/shieldedpool/privacy-compliance): selective disclosure and compliance tooling.
