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

# Shielded deposits and withdrawals

This page describes the mechanics of getting assets into and out of the ShieldedPool.

## Deposit patterns

There are three deposit patterns. Each makes a different trade-off between simplicity and privacy.

### Direct shielded deposit

The user (or a wallet on their behalf) deposits an ERC-20 token directly into the ShieldedPool's deposit contract along with a Poseidon commitment computed off-chain. The commitment encodes the asset, the amount, and the recipient's spending public key, plus randomness.

The deposit contract:

1. Pulls the tokens from the depositor's address into the pool's vault.
2. Verifies the commitment matches the deposit amount and asset.
3. Anchors the commitment in the global Merkle tree.

After the deposit is confirmed, the recipient can claim the note by scanning the chain for their commitment and proving ownership in a subsequent transaction. The on-chain link between the depositing address and the resulting in-pool position is the deposit transaction itself.

This pattern is the simplest. It works for any wallet that can sign an ERC-20 approval and a deposit.

### Shielded minting via vault

A more private deposit pattern uses a ShieldedMinter vault. The depositor sends tokens to the vault contract; the vault mints the wrapped representation directly into the ShieldedPool rather than to a user address. Only the commitment crosses the on-chain boundary.

From the chain's vantage point:

* The vault received tokens. The vault is a public contract; many depositors share it.
* A new commitment was added to the Merkle tree.
* The two events are not cryptographically linked.

For an outside observer, the deposit is correlated with the commitment only by timing and amount, and even those correlations weaken proportionally to the rate of deposits through the vault. This is the recommended pattern for users who want the strongest privacy on entry.

### Bridged shielded deposit (ZEC)

For ZEC, a future SPV bridge will allow deposits to arrive already shielded inside the ShieldedPool without an intermediate public address on Z. This is the ZEC-specific pattern. The roadmap tracks status.

## Withdrawal patterns

There are two withdrawal patterns.

### Withdrawal to a public address

A shielded note can be spent to a public address on the host EVM chain. The withdrawal transaction includes:

* Inputs: the shielded notes being spent (referenced by Merkle inclusion proof, with nullifiers published).
* Outputs: the public address receiving funds, plus any change as a new shielded note.
* A zero-knowledge proof that the input amounts and the output amounts balance.

The recipient address and the amount are visible on-chain. The ShieldedPool origin is visible (because the funds came from a ShieldedPool contract). The specific in-pool history of the funds (which deposit they ultimately trace back to) is not visible.

### Withdrawal via RelayAdapter

A shielded position can be used inside a utility (Z Trade, Z Lend, or any utility that integrates the RelayAdapter pattern) without ever appearing at a public address. The RelayAdapter pattern is documented separately; see [RelayAdapter pattern](/docs/shieldedpool/relay-adapter).

This is the pattern that makes private activity work: a user holding a shielded USDC position can swap on Z Trade or lend on Z Lend without first withdrawing to a public address.

## ZEC-specific patterns

A future ZEC SPV bridge will support direct shielded deposits and withdrawals of ZEC between Z's ShieldedPool and Zcash's main chain. The bridge uses FROST signatures for the withdrawal authorization. Both the bridge and the withdrawal mechanism are tracked on the roadmap.

## Fees and gas

Deposits and withdrawals incur the underlying gas cost of the host EVM chain. The Broadcaster, when used, pays gas on the user's behalf and is reimbursed inside the transaction (for in-pool transactions) or via a separate fee mechanism (for entry/exit). The user does not need to hold the chain's native gas token to interact with the pool through a Broadcaster.

## Related reading

* [ShieldedPool overview](/docs/shieldedpool/overview)
* [Privacy architecture](/docs/shieldedpool/privacy-architecture)
* [RelayAdapter pattern](/docs/shieldedpool/relay-adapter)
* [Privacy and compliance](/docs/shieldedpool/privacy-compliance)