> 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/privacy-model.md).

# Privacy Model

This page defines exactly what Silo keeps private, what remains visible, and how privacy is enforced at each layer of the system. Silo provides privacy from the public by default. It does not provide anonymity from Silo itself, and it does not hide the existence of on-chain activity.

***

#### **What Is Private**

Sender-receiver linkage. Public blockchain observers cannot determine who paid who. When Alice sends a payment to Bob, Alice's deposit and Bob's withdrawal pass through a shared vault that pools funds from multiple users. Zero-knowledge proofs are used to verify Bob's right to withdraw without revealing which deposit corresponds to his withdrawal. There is no deterministic on-chain link between the two transactions.

**Receiver preferences**\
The receiver's payout configuration: their preferred chain, preferred asset, and payout wallet address(es) is never visible to the sender or to public observers. The sender only sees the receiver's username. All routing details are handled by Silo in the background.

**Routing details**\
The swap paths, bridge routes, and delivery mechanics used to execute a payment are not exposed to either party or to public observers. The sender does not know how the payment was delivered, and the receiver does not know what asset or chain the sender paid from.

**Wallet addresses between parties**\
The sender never sees the receiver's wallet address. The receiver never sees the sender's wallet address. The only identifier exchanged between parties is the username.

***

#### **What Is Not Private**

On-chain activity exists. Silo settles transactions on public blockchains. Deposits into shared vaults and withdrawals from shared vaults are visible on-chain as individual transactions. What is not visible is the link between any specific deposit and any specific withdrawal. An observer can see that a deposit occurred and that a withdrawal occurred, but cannot connect the two.

Sanctions screening and KYT checks are enforced. Every transaction is screened before Silo facilitates it. This is not optional and applies to all tiers. See Sanctions & KYT for details.

Silo maintains encrypted records. Every transaction generates an encrypted Payment Instruction containing the full details of the payment. This record is accessible to Silo's backend under defined access controls and supports disputes, audits, and regulatory compliance. See Payment Instructions for details.

Both parties receive redacted receipts. Each party receives a receipt showing the counterparty's username, the amount, the timestamp, and their own transaction hash. Receipts do not expose the other party's wallet address or transaction hash. See Redacted Receipts for details.

***

#### **How Privacy Is Enforced**

Silo's privacy model operates through **four layers** working together.

**The first layer is the username system**\
By replacing wallet addresses with usernames, Silo eliminates the most common source of on-chain doxxing. No wallet address is ever exchanged between sender and receiver. The username reveals nothing about the user's on-chain identity, balance, or transaction history.

**The second layer is receiver preferences**\
The receiver configures their preferred chain, preferred asset, and one or more payout wallets. The sender never sees any of these details. If the receiver lists multiple wallets, Silo distributes incoming payments across them using on-chain randomness. This means that even if an observer identifies one of the receiver's wallets, they cannot determine the full picture of what the receiver has received. Funds are spread across multiple addresses on a chain and asset the sender knows nothing about.

**The third layer is the shared vault**\
Funds from multiple users are pooled together in chain-specific USDC vaults. When a payment is deposited into the vault, it joins a pool of other users' funds. When the receiver withdraws, the funds come from the same pool. The larger the pool and the more active the vault, the stronger the privacy. Each additional participant increases the number of possible deposit-withdrawal pairings an observer would have to consider.

**The fourth layer is zero-knowledge proofs**\
At deposit time, a ZK commitment is generated that cryptographically binds a secret to the receiver's withdrawal address. At withdrawal time, a ZK proof verifies the receiver's right to withdraw without revealing which deposit is being claimed. This is what creates mathematical unlinkability between deposits and withdrawals, beyond just the practical obscurity provided by the pooled vault.

These four layers are embedded into the normal payment flow. There is no privacy mode to activate, no shielding or unshielding step, no secret note for the user to manage, and no waiting period for anonymity set growth. Every transaction is private by default with no additional action from the user.

<br>


---

# 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/privacy-model.md?ask=<question>&goal=<endgoal>
```

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