> 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/comparison-to-privacy-protocols.md).
# Comparison to Privacy Protocols
Silo is sometimes compared to existing privacy protocols because it uses shared vaults and zero-knowledge proofs to break on-chain transaction linkage. The underlying privacy mechanism shares conceptual similarities with tools like Tornado Cash and Railgun. However, Silo is a payments platform with privacy built in, not a standalone privacy tool. The differences are significant across scope, user experience, and compliance.
***
#### **Tornado Cash**
Tornado Cash is a fully permissionless mixing protocol on Ethereum. Users deposit a fixed denomination of a single asset into a pool, receive a secret note, and later withdraw from the pool using that note. The note is the only proof of deposit. If lost, the funds are unrecoverable. Tornado Cash operates on a single chain per pool, supports only fixed denominations, and has no compliance controls, no receipts, no username system, no cross-chain capability, and no payments UX. Users manage the full deposit-wait-withdraw cycle manually. Tornado Cash was sanctioned by OFAC in 2022 due to the absence of any compliance gating. Typical fees are approximately 33 bps, paid to relayers on withdrawal.
#### **Railgun**
Railgun provides on-chain privacy through a shielded balance system. Users shield tokens into a private balance, transact privately within that balance, and unshield to withdraw. The protocol charges approximately 25 bps on both shielding and unshielding, totaling roughly 50 bps per full cycle. Railgun has introduced some compliance-oriented screening, but it remains a single-chain privacy tool rather than a payments platform. There are no usernames, no cross-chain delivery, no receipts, and no payment request flow. Users must understand the shield/unshield model to use it.
#### **Aztec**
Aztec is a privacy-focused Layer 2 on Ethereum that uses zero-knowledge rollups to provide private transactions. It is infrastructure-level technology, not a user-facing payments product. Aztec provides cryptographic foundations for privacy but requires users to understand L2 mechanics. There is no payments UX, no username system, no cross-chain delivery, and no receipt mechanism.
#### **Zcash**
Zcash is a privacy-focused blockchain with optional shielded transactions. Users can send between shielded addresses to achieve on-chain privacy. However, Zcash is a separate chain with its own token (ZEC), which limits its utility for users who want to transact in stablecoins or other assets. There is no username system, no cross-chain delivery, no compliance layer, and no receipt mechanism. Privacy also requires both parties to use shielded addresses, which is not the default behavior for most Zcash users.
***
### **How Silo Differs**
Silo is designed as a payments layer that works across multiple chains and assets, not a privacy tool bound to a single chain or token. Users are not required to move to a specific blockchain, hold a specific asset, or use a Silo-provided wallet. They connect their existing wallets on any supported chain and transact using a single username. Silo handles routing, conversion, and privacy across chains automatically.
Beyond this architectural difference, five specific areas separate Silo from privacy protocols.
1. First, there is no user-facing secret or note. Privacy protocols typically generate a secret at deposit time that the user must save and manage. If it is lost, the funds are lost. Silo manages the ZK commitment internally. The user signs with their wallet to withdraw. There is nothing to save, nothing to lose.
2. Second, there is no privacy ceremony. Privacy protocols require users to explicitly shield funds, wait for the anonymity set to grow, then unshield. Silo embeds privacy into the normal payment flow. Every transaction is private by default with no additional steps.
3. Third, no wallet addresses or secrets are exchanged between parties. The sender only needs the receiver's username. They never see a wallet address, and no secret note passes between sender and receiver.
4. Fourth, Silo includes compliance controls. Sanctions screening, transaction risk checks, tiered verification limits, and encrypted audit trails are built into the transaction flow. Users who complete verification unlock lower fees and higher limits. This is a fundamental architectural difference from protocols like Tornado Cash, which have no compliance gating.
5. Fifth, Silo provides redacted receipts. Privacy protocols have no receipt mechanism. A user cannot prove a Tornado Cash transaction occurred without revealing the secret note. Silo's redacted receipts allow both parties to prove a payment happened, with the amount, timestamp, and counterparty username visible, without exposing wallet addresses or transaction hashes from the other side.
---
# 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/comparison-to-privacy-protocols.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.