> For the complete documentation index, see [llms.txt](https://docs.silopay.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.silopay.io/privacy/shared-vaults.md).
# Shared Vaults
Shared vaults are the core mechanism behind Silo's on-chain privacy. They are pooled, chain-specific smart contract vaults that hold funds from multiple users simultaneously. By combining many users' deposits into a single pool, the vault breaks the deterministic on-chain link between any individual deposit and any individual withdrawal.
***
#### **How Shared Vaults Work**
Each supported chain has its own shared vault (e.g., an Ethereum USDC vault, a Sui USDC vault). For same-chain payments, the sender's funds are deposited directly into the shared vault on that chain. For cross-chain payments, the sender's funds are burned on the source chain via CCTP and minted into the shared vault on the destination chain — funds do not pool on the source chain. In both cases, the funds join a pool alongside deposits from other users. When the receiver withdraws, the funds come out of the same pool. There is no on-chain way to determine which deposit corresponds to which withdrawal.
***
#### **Why Pooling Creates Privacy**
In a traditional crypto payment, Alice sends funds directly to Bob's wallet. Anyone who looks up either transaction on a block explorer can trace the exact flow: Alice's address sent X amount to Bob's address at Y time. The link between sender and receiver is fully visible on-chain.
With shared vaults, that direct link is broken. Alice's deposit goes into a pool with many other users' funds. When Bob withdraws, the funds come from the same pool, but on-chain, Bob's withdrawal could correspond to any deposit in the vault. There is no transaction hash, amount match, or timing correlation that deterministically connects Alice to Bob. Even blockchain analytics firms cannot link the two transactions with certainty.
The larger and more active the vault (more users, more deposits, more withdrawals), the stronger this privacy becomes. Each additional participant increases the anonymity set, the number of possible deposit-withdrawal pairings an observer would have to consider.
***
#### **Vault Architecture**
Vault contracts are fund-touching smart contracts. They are designed to be immutable once deployed, meaning the code that controls how funds enter and exit the vault cannot be changed after deployment. This protects users from the risk of contract upgrades that could alter fund-handling behavior.
Business logic contracts (routing, fee calculation, tier enforcement) are separate from the vault contracts and are upgradeable via proxy patterns. This separation allows the platform to evolve without compromising the security or immutability of the vault infrastructure.
***
#### **Deposits**
When a payment is initiated, any necessary swaps are completed first on the sender's chain. If Alice pays in ETH but the vault holds USDC, the swap happens before the deposit. The vault only receives the settlement asset (currently USDC). For same-chain payments, the funds are deposited directly into the local shared vault. For cross-chain payments, the funds are burned on the source chain via CCTP and minted into the shared vault on the destination chain.
A ZK commitment is generated before the vault deposit. Silo's backend computes a cryptographic hash that binds a randomly generated secret to the receiver's primary withdrawal address. The commitment and ZK proof are computed entirely off-chain, and only after this computation succeeds is the commitment data bundled into the on-chain transaction that executes the deposit. This commitment is what later enables the receiver to prove their right to withdraw without revealing which deposit the withdrawal corresponds to.
***
#### **Withdrawals**
Withdrawals require the receiver's wallet signature. Silo cannot withdraw funds on a user's behalf. The specific wallet that can trigger a withdrawal is the one that was cryptographically bound to the ZK commitment at deposit time. No other wallet can authorize the withdrawal.
When the receiver initiates a withdrawal, Silo generates a ZK proof that verifies the receiver's right to withdraw without revealing which deposit is being claimed. The proof is submitted to the smart contract, and the funds are released from the vault to the receiver's wallet (or wallets, if multi-wallet preferences are configured).
For cross-chain payments, CCTP bridging occurs at deposit time, not at withdrawal. By the time the receiver initiates their withdrawal, the funds are already sitting natively in the destination chain vault. The withdrawal is a simple same-chain release regardless of where the sender originally paid from.
***
#### **Non-Custodial Boundary**
Shared vaults create a temporary window where user funds sit in the vault between deposit and withdrawal. This is an important nuance in Silo's non-custodial design.
Silo is architecturally non-custodial: withdrawals are receiver-signed, and Silo cannot move funds on a user's behalf. Silo's control is limited to gating. Determining who can use the service, under what conditions, and up to what limits. Silo can refuse to facilitate a payment that fails policy checks, but it cannot seize, redirect, or withdraw funds from the vault.
The vault holding period, the time between when funds are deposited and when the receiver withdraws, is a known aspect of the architecture. During this period, funds are secured by the vault smart contract, not by Silo as an entity. The receiver can initiate withdrawal at any time by signing from their primary wallet (the first wallet in their receiver preferences).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.silopay.io/privacy/shared-vaults.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.