# Accounts & Verification
Source: https://docs.silopay.io/accounts-verification
A Silo account is created with an email address, confirmed with a verification code. There is no password to remember and no seed phrase to store. The account is the identity layer that your username, receiver preferences, and verification level attach to. Your funds are never held in the account itself; they are always delivered to a wallet you control.
Creating an account starts you at the Personal tier with no identity verification required. You can immediately claim a username, set receiver preferences, and start sending and receiving peer-to-peer payments.
## **Setting Up**
Account setup is five steps. Every choice besides username can be changed later in settings.
1. **Choose your @username.** This is how people pay you. Letters, numbers, and underscores, 3 to 30 characters, with real-time availability checking as you type.
2. **Pick your preferred network.** The blockchain you want to receive payments on. Senders never see this choice; Silo routes to it automatically.
3. **Pick your preferred asset.** What you want to get paid in, from the whitelisted assets available on your chosen network. Senders never see this either.
4. **Add your payout wallet.** Where received funds are delivered. Connect a wallet directly (MetaMask, Phantom, Slush, and others) or enter an address manually; manual addresses are validated against your chosen network.
5. **Review and confirm.** A summary of your username, network, asset, and wallet before your account goes live.
## Payout Wallet Requirements
The payout wallet must be a self-custodial wallet that you control. Silo delivers funds to it, and only that wallet can authorize withdrawals from the shared vault.
If you enter an address manually, confirm that you hold its keys before continuing. Do not use an exchange wallet such as Coinbase, Binance etc. Funds sent to a wallet you do not control cannot be recovered by Silo.
## **Verification Levels**
Verification determines your tier, and each tier unlocks lower fees, higher limits, and additional capabilities. Transaction screening (KYT) is applied to every payment on every tier, including Personal.
**Personal** requires only the email used at signup. Personal accounts send and receive peer-to-peer payments with other Personal and Plus users. They cannot buy from merchants or receive payroll.
**Plus** requires KYC verification: a government-issued ID and a selfie, submitted through Sumsub. Verification typically completes within minutes. Plus unlocks lower fees, higher limits, buying from merchants, and receiving payroll.
**Business** requires KYB verification: business registration documents and beneficial ownership information, submitted through Sumsub. Business unlocks the lowest fees, the highest limits, and the ability to accept customer payments (Commerce sub-type) or send payroll (Payroll sub-type). The sub-type is selected during onboarding and locked to the account; businesses that need both can request a review to add a second sub-account.
Full details on fees, limits, and capabilities per tier are on the [Three-Tier System page](/three-tier-system). Note that cashing out to a bank account requires verification through the off-ramp flow regardless of your Silo tier; see [Cash Out](/cash-out).
| | Personal | Plus | Business |
| ------------------------ | ---------- | ----------------- | --------------------------- |
| Verification | Email only | ID + selfie (KYC) | Business registration (KYB) |
| Fees | Standard | Lower | Lowest |
| Limits | Standard | Higher | Highest |
| Peer-to-peer payments | ✓ | ✓ | ✓ |
| Buy from merchants | | ✓ | ✓ |
| Receive payroll | | ✓ | ✓ |
| Accept customer payments | | | ✓ |
| Send payroll | | | ✓ |
| Cash out to bank | ✓ | ✓ | ✓ |
## **Upgrading**
Upgrades are available from within your Silo account. When you initiate an upgrade, you are guided through the verification process for the [next tier](/three-tier-system). Your username, receiver preferences, and transaction history carry over, and the upgrade takes effect as soon as verification is approved.
# Cash Out
Source: https://docs.silopay.io/cash-out
Cash Out lets users turn crypto into cash delivered directly to their own bank account. The fiat side of cash out is provided by Bridge, a Stripe company, through Silo's interface. Bridge and its licensed partners perform the currency conversion and bank delivery; Silo does not hold, convert, or transmit fiat funds at any point. Cash out is available in eligible countries over local banking rails.
## **How It Works**
Setup is one-time: verify through Bridge, accept Bridge's terms of service, and link a bank account. Users who cash out are onboarded as customers of Bridge for the fiat services. Verification is required for all tiers, including Personal, because bank delivery requires full identity verification regardless of Silo tier. Individuals verify their identity; Business accounts complete business verification. After setup, cashing out takes a few steps: choose an asset and chain, enter an amount, select a delivery method, review the full fee breakdown, and confirm with a wallet signature. Bridge converts the crypto and delivers the proceeds to the linked bank account.
## **Delivery Methods**
Available rails depend on the bank account's country: ACH and wire in the United States, SEPA in the European Union, Faster Payments in the United Kingdom, SPEI in Mexico, PIX in Brazil, and Bre-B in Colombia. Delivery speeds range from near-instant to a few business days depending on the rail. The asset and chain combinations available for cash out are shown in the app and reflect current off-ramp support.
## **First-Party Only**
Cash out is restricted to the user's own bank account. The name on the bank account must match the verified identity or registered business. This is a deliberate compliance control: cash out cannot be used to deliver funds into a third party's bank account.
## **Fees**
Each cash out carries a total exchange fee of 0.25%. Non-USD delivery carries an additional FX fee, and certain assets carry an additional conversion cost. The full breakdown and the exact amount arriving in the bank are shown on the review screen before anything is confirmed. Note: cash out fees are subject to change.
## **Tracking**
Every cash out appears in payment history and progresses from Processing to Deposited. If a transfer fails on the banking side, the crypto is returned to the user's wallet and the history entry shows what happened, with support contact available.
# FAQ
Source: https://docs.silopay.io/faq
No. Silo is a payments platform. Users connect their existing wallets to Silo and maintain full control of their funds. Silo does not store, hold, or manage private keys.
No. Silo is non-custodial. Withdrawals require the receiver's wallet signature. Silo cannot move funds on a user's behalf. Silo's role is to facilitate payment routing and privacy, not to take custody of user funds.
No. Silo works with whatever wallet the user already has on any supported chain.
Silo routes payments based on the username entered by the sender. Users should verify the recipient's username before confirming a transaction. Because Silo is non-custodial and transactions settle on-chain, payments sent to the wrong username cannot be reversed by Silo.
No. The sender only sees your username. Your wallet address, payout chain, preferred asset, and routing details are never visible to the sender.
No. Silo uses shared vaults and zero-knowledge proofs to break the on-chain link between the sender's deposit and the receiver's withdrawal. Public blockchain observers cannot determine who paid who.
No. Silo provides privacy from the public, not anonymity from Silo itself. Silo maintains an encrypted audit trail (Payment Instruction) behind every transaction that records the full details of the payment. This record supports dispute resolution, regulatory compliance, and audit requirements. Users receive redacted receipts that confirm the transaction without exposing the other party's wallet details.
Tornado Cash is a permissionless mixing protocol with no compliance controls, no receipts, no username system, and no payments UX. Silo is a payments platform with privacy built in. Silo provides username-based payments, cross-chain delivery, redacted receipts, compliance screening, and an encrypted audit trail, none of which Tornado Cash offers.
Not at the Personal tier. Users can sign up with just an email and transact within defined limits. Higher tiers (Plus and Business) require identity verification and unlock lower fees, higher limits, and additional capabilities like commerce and payroll. See Three-Tier System for details.
Silo supports a whitelisted set of assets on each chain: major stablecoins and each chain's native asset. USDC is the settlement asset and the lowest-cost path. The whitelist will expand over time toward any asset with active DEX liquidity on its chain. See Supported Chains & Assets for the latest coverage.
Silo currently supports Ethereum, Sui, and Solana on testnet, with mainnet following audit completion. See Supported Chains & Assets for updates.
Silo charges a single per-transaction privacy fee: 30 bps (Personal), 25 bps (Plus), or 20 bps (Business). Network gas and swap fees are passed through at cost with no Silo markup. Cross-chain USDC transfers via CCTP carry \$0 Silo fee. See Fee Structure for full details.
It depends on the payment context. In peer-to-peer payments, the receiver absorbs the fee by default (with an optional Cover fee toggle for the sender). In commerce, the merchant always pays. In payroll, the employer always pays. See Three-Tier System for the full breakdown.
Yes. Cash Out delivers cash to your own linked bank account in eligible countries. The currency conversion and bank delivery are performed by Bridge, a Stripe company, and its licensed partners; Silo does not hold or transmit fiat. One-time verification and bank linking are required, and cash out is restricted to bank accounts in your own name. See Cash Out for details.
Business accounts with the Payroll sub-type add employees and contractors by Silo username or email invite, then pay everyone in a single batch with one wallet signature. Individual salary amounts are hidden on-chain, employees are credited their full amount, and the employer pays the fee. See [Payroll](/payroll) for details.
Silo does not custody funds or manage private keys. If a user loses access to their wallet, Silo cannot recover the funds. Wallet recovery depends on the user's wallet provider and their own backup procedures.
No. Silo can refuse to facilitate a payment that fails policy checks (sanctions screening, KYT). However, because withdrawals require the receiver's wallet signature, Silo cannot withdraw or move funds on a user's behalf. Silo's lever is gating (determining who can use the service and under what conditions), not fund control.
Silo does not serve sanctioned persons, addresses, or jurisdictions. Availability by jurisdiction will be detailed as the platform's regulatory posture is finalized with legal counsel.
# Fee Structure
Source: https://docs.silopay.io/fee-structure
Silo charges a single per-transaction fee called the privacy fee. This is Silo's only source of revenue. The rate depends on the user's account tier:
| | Personal | Plus | Business |
| ----------- | -------- | ------- | -------- |
| Rate | 30 bps | 25 bps | 20 bps |
| Minimum fee | \$0.30 | \$0.25 | \$0.20 |
| Fee cap | \$5.00 | \$50.00 | \$250.00 |
The privacy fee covers the cost of privacy routing, compliance screening, encrypted record storage, and platform infrastructure. It is an all-in fee, with no separate line item for privacy, compliance, or platform access.
Transaction limits and fee rates are illustrative and subject to change pending legal review.
## **What's Included in the Privacy Fee**
The privacy fee is the only fee Silo charges on payments. It covers: transaction routing, ZK commitment and proof generation, Payment Instruction encryption and storage, sanctions screening and KYT checks, and redacted receipt generation. There are no subscription fees, no account fees, no withdrawal fees, and no monthly minimums. Cashing out to a bank account carries a separate exchange fee, shown on the review screen before confirmation [(see Cash Out)](/cash-out).
## **Pass-Through Costs**
In addition to the Silo privacy fee, some transactions incur pass-through costs that Silo does not mark up or profit from.
**Network fees (gas):** the cost of executing transactions on-chain. These vary by chain and network conditions. Silo passes these through at cost.
**Swap fees:** if a payment requires an asset conversion (e.g., the sender pays in ETH but the receiver wants USDC), the swap is routed through available DEX liquidity (Curve, Uniswap, DeepBook, Jupiter, depending on the chain). Swap fees and slippage are passed through at cost with no Silo markup. The party whose asset choice triggered the swap bears the cost (see Three-Tier System for the full swap fee rule).
**Bridge fees (CCTP):** cross-chain transfers routed through Circle's Cross-Chain Transfer Protocol carry a \$0 Silo fee. CCTP is the primary bridge used for cross-chain USDC delivery.
## **The Lowest-Cost Path**
The cheapest possible transaction on Silo is a USDC-to-USDC payment on the same chain. In this scenario, the user pays only the Silo privacy fee (20-30 bps depending on tier) and the network gas cost. There is no swap fee and no bridge fee. As the transaction involves more complexity (asset conversion, cross-chain routing), pass-through costs increase accordingly, but the Silo privacy fee remains the same regardless of routing complexity.
## **Fee Responsibility**
Who pays the Silo privacy fee depends on the payment context. In peer-to-peer payments, the receiver absorbs the fee by default, with an optional Cover fee toggle for the sender. In commerce payments, the merchant always absorbs the fee. In payroll payments, the employer always pays the fee. Full details on fee responsibility, the Cover fee toggle, and swap cost allocation are covered on the [Three-Tier System page](/three-tier-system).
# Getting Started
Source: https://docs.silopay.io/getting-started
Create an account, claim your username, set your preferences, and make your first payment.
Provide an email address and confirm it with a verification code. No identity verification is required to get started. Personal tier accounts are active immediately.
Choose a unique username (e.g., @alice). This is your permanent payment identity across all chains. Once claimed, your username cannot be changed. Anyone can send you a payment using just this username.
Configure how you want to be paid: select your preferred chain, preferred asset, and one or more payout wallets. These preferences apply to every incoming payment, and you can update them at any time. For a detailed explanation, see [Usernames & Receiver Preferences](/usernames-receiver-preferences).
Connect any existing wallet on a supported chain. To send, enter the recipient's username and a dollar amount, choose which asset and chain to pay from, and confirm. One wallet signature is all that's needed. To request, share your username or generate a payment request QR code. Incoming payments are routed according to your saved preferences.
When you receive a payment, your Silo account is credited. Initiate a withdrawal by signing from your primary wallet (the first wallet in your receiver preferences). Funds are privately delivered to your wallet according to your preferences.
**What's next**
To understand the full payment flow under the hood, see [Payment Flow](/payment-flow). For fee tiers and verification levels, see [Three-Tier System](/three-tier-system). For how privacy works on every transaction, see [Privacy Model](/privacy-model).
# Glossary
Source: https://docs.silopay.io/glossary
**Cash Out:** Turning crypto into cash delivered to the user's own linked bank account. Currency conversion and bank delivery are provided by Bridge and its licensed partners; Silo does not hold or transmit fiat. Requires one-time verification and bank linking, and is restricted to first-party accounts. See Cash Out.
**CCTP (Cross-Chain Transfer Protocol):** Circle's protocol for transferring USDC natively between supported blockchains. Silo uses CCTP for cross-chain USDC delivery at \$0 Silo fee.
**Commerce (sub-type):** A Business tier account sub-type for businesses that accept payments from customers. The merchant always absorbs the Silo fee. Only Plus and Business users can send payments to Commerce accounts.
**Commitment:** A cryptographic hash that binds a secret and a withdrawal address together. Used in Silo's ZK layer to ensure that only the designated wallet can withdraw funds from the shared vault. The commitment is generated internally by Silo. Users do not interact with it directly.
**DeepBook:** A decentralized order book on Sui. One of the DEX routing options Silo uses for asset swaps on the Sui chain.
**Cover Fee Toggle:** An optional sender-side feature in peer-to-peer payments that allows the sender to cover the Silo privacy fee so the receiver gets the full amount. Off by default. Covers the Silo fee only, not swap fees. Not available in commerce or payroll flows. Sometimes referred to as a gross-up toggle.
**KYB (Know Your Business):** Identity verification for businesses, including business registration and beneficial ownership documentation. Required for Business tier accounts.
**KYC (Know Your Customer):** Identity verification for individuals, typically involving an ID and selfie. Required for Plus tier accounts.
**KYT (Know Your Transaction):** Real-time transaction screening that checks payment routes for risk signals. Applied to all transactions across all tiers.
**Payment Instruction:** An encrypted record built incrementally for every Silo transaction and finalized after the receiver withdraws. Contains the full details of the payment: sender identity, receiver identity, amounts, wallet addresses, routing details, compliance check results, and timestamps. Once finalized, encrypted using SEAL and uploaded to Walrus for permanent decentralized storage. Accessible only to Silo's backend under defined access controls. See Payment Instructions.
**Payroll (sub-type):** A Business tier account sub-type for businesses that pay employees or contractors. The employer always pays the Silo fee. Only Plus and Business users can receive payroll payments.
**Payroll Run:** A single batch payment from a Business account to selected employees and contractors, authorized and funded with one wallet signature. Individual amounts are carried in ZK commitments and are not exposed on-chain. See Payroll.
**Privacy Fee:** Silo's per-transaction fee. The only fee Silo charges. Covers privacy routing, compliance screening, encrypted record storage, and platform infrastructure. Rates vary by tier: 30 bps (Personal), 25 bps (Plus), 20 bps (Business).
**Receiver Preferences:** A set of account-level settings that determine how incoming payments are delivered: destination chain, preferred asset, and payout wallet(s). Configured once by the receiver and applied automatically to every incoming payment. See Usernames & Receiver Preferences.
**Redacted Receipt:** A privacy-preserving transaction confirmation provided to both sender and receiver after every payment. Shows the counterparty's username, amount, timestamp, and the user's own transaction hash, but does not expose the other party's wallet address or transaction hash. See Redacted Receipts.
**SEAL:** The encryption framework used to encrypt Payment Instructions before they are stored on Walrus. Ensures that transaction records are not readable without authorized access.
**Shared Vault:** A pooled, chain-specific smart contract vault where user funds are deposited during the payment process. By pooling multiple users' funds together, the vault breaks the deterministic on-chain link between individual deposits and withdrawals. This is the core mechanism behind Silo's on-chain privacy.
**Tier Gating:** The enforcement mechanism that controls which account tiers can participate in which payment types. Enforced at the routing layer. For example, Personal accounts cannot send to Commerce accounts or receive payroll. See Three-Tier System.
**Walrus:** Sui's decentralized storage layer. Silo uses Walrus to store encrypted Payment Instructions, ensuring records are durable, tamper-resistant, and not dependent on a single server.
**ZK Commitment:** See Commitment.
**ZK Proof:** A zero-knowledge proof submitted at withdrawal time that verifies the receiver's right to withdraw funds from the shared vault without revealing which deposit the withdrawal corresponds to. This is what creates on-chain unlinkability between sender and receiver.
# Overview
Source: https://docs.silopay.io/overview
Silo is a non-custodial crypto payments platform. It lets users send and receive cryptocurrency using a single username, with privacy built into every transaction and compliance enforced automatically.
The sender types a username and a dollar amount. Silo handles everything else in the background: asset conversion, chain routing, bridging, privacy, and compliance. The receiver gets paid in their preferred asset on their preferred chain, to the wallet of their choosing, without the sender ever needing to know those details.
No wallet addresses are exchanged between parties. No chain or asset coordination is required. No new wallet is needed. Silo works with whatever wallet the user already has.
Every transaction is private by default. Sender-receiver linkage is hidden from public blockchain observers. Both parties receive a redacted receipt that proves the payment occurred without exposing wallet addresses or transaction hashes from the other side.
Silo maintains a full encrypted audit trail behind every transaction. Sanctions screening and risk checks are applied automatically. The platform uses a three-tier verification system where higher verification unlocks lower fees and higher limits, while unverified users can still transact within defined thresholds.
Silo is currently live on testnet across Ethereum, Sui, and Solana. Mainnet launch follows the completion of smart contract audits. Silo launches with a whitelisted set of assets on each chain, including major stablecoins and each chain's native asset, with USDC as the settlement asset.
## Get Familiar with Silo
# Payment Flow
Source: https://docs.silopay.io/payment-flow
This page walks through what happens under the hood when a payment is made on Silo. The user experience is simple: type a username, enter an amount, confirm. Behind that, the backend handles multiple operations across routing, privacy, compliance, and settlement.
In short: the sender's payment is screened, swapped if needed, and deposited into a shared vault on the receiver's preferred chain. The receiver's account is credited, and they withdraw by signing from their designated wallet, backed by a ZK proof that hides which deposit the withdrawal corresponds to. An encrypted record of the full transaction is stored for compliance. The following example uses a cross-chain payment to illustrate the full flow. Same-chain payments follow the same sequence but skip the bridging step.
## **Example: Alice sends \$100 to @bob**
Alice holds USDC on Ethereum. Bob's receiver preferences are set to receive USDC on Sui, delivered to his designated wallet.
1. **Step 1: Payment intent.** Alice types @bob, enters \$100, and confirms the payment. This is the only action Alice takes. One signature from her wallet authorizes the transaction.
2. **Step 2: Screening and routing.** Silo screens the transaction against sanctions lists and runs KYT checks on the payment route. Simultaneously, Silo reads Bob's receiver preferences and determines the optimal delivery path: in this case, USDC on Ethereum needs to reach USDC on Sui, so a cross-chain bridge (CCTP) will be required. If Alice had been paying in a different asset (e.g., ETH), Silo would first route through a DEX aggregator (Uniswap on Ethereum) to swap to USDC before proceeding.
3. **Step 3: ZK commitment.** Silo's backend generates a random secret (a 32-byte string) and computes the ZK hash and ZK commitment. The commitment is a cryptographic hash that binds the secret to Bob's designated withdrawal address. This binding ensures that only Bob's specific wallet can later withdraw the funds, and it creates on-chain unlinkability between Alice's deposit and Bob's eventual withdrawal. The commitment and ZK proof are computed entirely off-chain. Only after this computation succeeds is the commitment data bundled into the on-chain transaction that executes the vault deposit. The secret is managed internally by Silo's backend. Bob never sees or handles it.
4. **Step 4: Vault deposit and cross-chain bridging.** Alice's USDC is sent into CCTP alongside the commitment data. On a cross-chain payment, the funds do not pool on the source chain. CCTP burns the USDC on Ethereum and mints it on Sui. The minted USDC is deposited into the shared Sui USDC vault, where it joins a pool of other users' funds. This pooling on the destination chain is what breaks the deterministic on-chain link between any individual deposit and any individual withdrawal. By the time Bob initiates his withdrawal, the funds are already sitting natively in the Sui vault. Same-chain payments skip the bridging step entirely and deposit directly into the local vault.
5. **Step 5: Account credited.** Bob's Silo account is credited \$100 in Silo's database. Bob can see the incoming payment in his account. At this point, the funds are in the shared vault on Sui, and Bob has a balance reflecting his credit.
6. **Step 6: Withdrawal initiated.** Bob initiates a withdrawal by signing from his designated wallet. This signature is required. Silo cannot withdraw funds on Bob's behalf. The withdrawal can only be triggered by the specific wallet address that was cryptographically bound to the commitment in Step 3.
7. **Step 7: ZK proof and settlement.** Silo generates a ZK proof that verifies Bob's right to withdraw without revealing which deposit the withdrawal corresponds to. The proof is submitted to the vault smart contract, and the funds are released from the Sui vault to Bob's wallet (or split across multiple wallets if Bob has configured multi-wallet preferences).
8. **Step 8: Payment Instruction stored.** After the withdrawal completes, Silo finalizes the encrypted Payment Instruction containing the full transaction details: sender identity, receiver identity, amounts, wallet addresses, routing path, ZK proof references, compliance check results, and timestamps for each stage. The Payment Instruction is encrypted using SEAL and uploaded to Walrus (Sui's decentralized storage layer) via a background process. This is the permanent, tamper-resistant audit trail that supports disputes, regulatory compliance, and internal review.
9. **Step 9: Funds delivered.** \$100 USDC arrives at Bob's wallet on Sui. Both Alice and Bob receive redacted receipts confirming the transaction. The payment is complete.
## **Same-Chain Payments**
If Alice and Bob are both on the same chain, the flow is identical except that Step 4 does not involve a CCTP bridge. The deposit settles directly into the local chain vault, and the withdrawal in Step 7 releases funds from that same vault. All other steps still apply: screening, ZK commitment, vault deposit, account credit, ZK proof verification, and Payment Instruction storage.
## **Payments Involving Asset Swaps**
If Alice pays with an asset other than the receiver's preferred asset (e.g., Alice sends ETH but Bob wants USDC), Silo routes through a DEX aggregator to swap the asset before depositing into the vault. The swap happens on the sender's chain as part of Step 2, before the funds enter the vault. Swap fees are passed through at cost to the party whose asset choice triggered the swap ([see Fee Structure for swap fee rules](/fee-structure)).
# Payment Instructions
Source: https://docs.silopay.io/payment-instructions
Every transaction on Silo generates a Payment Instruction. This is an encrypted record that contains the complete details of the transaction and serves as Silo's internal audit trail.
Payment Instructions distinguish Silo from pure privacy protocols. Privacy tools like Tornado Cash and Railgun provide on-chain unlinkability but maintain no record of who paid who. If a dispute arises or a regulator requests information, there is nothing to reference. Silo provides the same on-chain unlinkability while maintaining a structured, encrypted record behind every transaction that can support disputes, audits, and regulatory compliance.
## **What a Payment Instruction Contains**
Each Payment Instruction records the full context of a transaction: sender identity, receiver identity, the amount sent, the amount received, the asset and chain used by the sender, the asset and chain delivered to the receiver, all wallet addresses involved, routing details (swap paths, bridge used), ZK proof references, compliance check results, and timestamps for each stage of the transaction.
This is the complete record of the transaction.
## **How Payment Instructions Are Stored**
Payment Instructions are built incrementally throughout the payment lifecycle. As each step of the transaction is processed (deposit, routing, compliance checks, withdrawal), the relevant data is captured and stored securely in Silo's internal database. Once the receiver has completed their withdrawal, the full Payment Instruction is finalized, encrypted using SEAL, and uploaded to Walrus (Sui's decentralized storage layer) via a background process.
SEAL handles the encryption, ensuring the contents are not readable without authorized access. Walrus provides durable, decentralized storage so that records are not dependent on a single server or database. The combination means that Payment Instructions are tamper-resistant, durable, and encrypted at rest. They cannot be read by public blockchain observers, by other Silo users, or by anyone without authorized access through Silo's backend.
## **Who Can Access Payment Instructions**
Payment Instructions are accessible only to Silo's backend under defined access controls. Users do not see Payment Instructions directly. Instead, they receive redacted receipts (see Redacted Receipts) that contain a subset of the transaction details appropriate for each party.
Access to the full Payment Instruction is reserved for specific operational needs: dispute resolution between parties, regulatory or audit requests under applicable legal processes, and internal compliance review.
The access control framework is designed to balance two requirements. Users need privacy from the public and from each other. Regulators and auditors need the ability to verify that transactions are legitimate and compliant. Payment Instructions satisfy both by keeping the full record encrypted and access-controlled while giving users redacted, non-doxxing receipts.
## **Why This Matters**
The Payment Instruction system is what allows Silo to offer privacy and compliance simultaneously without treating them as a tradeoff. The on-chain layer provides unlinkability. The Payment Instruction layer provides accountability. Users get private transactions. Regulators get an auditable trail. Neither side has to compromise.
This architecture is also what separates Silo from custodial platforms. Custodial apps like Venmo and PayPal maintain internal transaction records, but those records exist because the platform controls the funds. Silo maintains encrypted records without taking custody. The audit trail exists independently of fund control.
# Payment Requests
Source: https://docs.silopay.io/payment-requests
Silo allows users to request payments using a QR code. The receiver enters the amount they want to receive, and Silo generates a QR code in one tap. The receiver shares that QR code with the sender, who scans it, confirms the payment, and sends.
The QR code contains the receiver's username and the requested amount. The sender does not need to manually type a username or figure out how much to send. They scan, confirm, and pay.
This flow follows the same routing logic as any other Silo payment. The sender chooses which asset and chain to pay from on their side. Silo reads the receiver's preferences and handles conversion, routing, and privacy automatically. The receiver gets paid according to their saved preferences, regardless of what the sender pays with.
Payment requests are useful for in-person transactions, invoicing, and any situation where the receiver wants to initiate the payment flow rather than waiting for the sender to look up their username and enter an amount manually.
# Payroll
Source: https://docs.silopay.io/payroll
Silo Payroll lets businesses pay employees and contractors in a single batch with one wallet signature, without handling a wallet address at any point. Payroll is available to Business tier accounts with the Payroll sub-type. Employees and contractors receive payroll on Plus or Business accounts (see Three-Tier System).
## **Adding People**
Employers add people by Silo username, or by email invite if the person is not on Silo yet, individually or via CSV import. Wallet addresses are never entered anywhere in payroll. Each person's payout details live in their own receiver preferences and are read fresh at pay time; the employer never sees them. Invited people appear as pending and become payable automatically once they finish setting up their account. Salaries are stored against each person as a recurring amount and can be edited at any time; changes apply to future runs only.
## **Running Payroll**
A payroll run is three steps: select the people to pay, review, sign once. The review screen shows every person, every salary, the Silo fee for each payment, and the grand total, along with the funding wallet and its balance. Final compliance screening runs on each individual payment before signing. Anyone who fails screening is held out of the run with the reason shown, and everyone else is paid; held people can be paid in a later run once the flag clears. A single wallet signature authorizes and funds the exact reviewed batch. After signing, a status board tracks each payment to completion, and completed runs are archived in payroll history.
## **Salary Privacy**
Individual salary amounts are never exposed on-chain. Salaries are carried in ZK commitments inside the shared vault, so a public observer cannot read a list of per-person amounts from the employer's payroll activity. Each employee then withdraws under the same unlinkability model as any other Silo payment. Employees cannot see each other's salaries, and neither can anyone watching the chain.
## **Fees and Delivery**
The employer always pays the Silo fee. Employees are credited their full agreed amount with no deductions. Withdrawal then follows each employee's own receiver preferences, and the standard swap rule applies: if the employee's preferred asset requires a conversion, that swap cost comes out of the received amount, the same as any other Silo payment. Employees who receive in USDC pay no swap cost.
## **Protections**
Payroll includes double-pay guardrails: anyone paid within the recent-pay window is flagged and skipped by select-all, and adding them anyway requires an explicit per-person confirmation. People included in a run that is still executing cannot be added to another run until their payment completes. Payroll payments are final once signed; funds belong to each person the moment they land. One-off payments such as bonuses or reimbursements are sent through the regular payment flow rather than a payroll run.
# Privacy Model
Source: https://docs.silopay.io/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 addresses) 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](/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](/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](/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, because 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.
## **What Silo Is Not**
Silo is not an anonymity tool. Silo knows who its users are (at varying levels depending on tier, from email at Personal tier to full KYC/KYB at Business tier). Silo maintains encrypted records of every transaction. The privacy Silo provides is from the public and from the counterparty, not from Silo itself or from legitimate regulatory processes.
Silo is not a mixer. While the shared vault model shares conceptual similarities with mixing protocols, Silo is a payments platform with compliance controls. Sanctions screening, KYT checks, tiered verification, and encrypted audit trails are built into every transaction. The goal is usable privacy for legitimate payments, not unaccountable fund movement.
## **Compared to Privacy Protocols**
Silo's privacy mechanism shares cryptographic foundations with standalone privacy protocols, but the experience is structurally different. There is no user-facing secret or note to save and lose: the ZK commitment is managed internally, and the receiver withdraws by signing with their wallet. There is no privacy ceremony: no shielding or unshielding step, no waiting period, and no relayer to interact with. Privacy is applied to every payment by default. Nothing sensitive passes between parties: the sender needs only a username, and no wallet address or secret is ever exchanged. And unlike standalone privacy tools, compliance screening, tiered verification, encrypted audit records, and redacted receipts are built into every transaction.
# Redacted Receipts
Source: https://docs.silopay.io/redacted-receipts
Every Silo transaction generates a redacted receipt for both the sender and the receiver. These receipts confirm that a payment occurred and provide each party with enough information to verify the transaction, without exposing the other party's wallet address, transaction hash, or routing details.
## **What the Sender Sees**
The sender's receipt shows: the amount they sent, the receiver's username, their own outbound transaction hash (proof that funds left their wallet), and the timestamp of the transaction.
The sender does not see the receiver's wallet address, the receiver's withdrawal transaction hash, or any details about how the payment was routed or delivered on the receiver's side.
## **What the Receiver Sees**
The receiver's receipt shows: the amount they received, the sender's username, their own inbound transaction hash (proof that funds arrived at their wallet), and the timestamp of the transaction.
The receiver does not see the sender's wallet address, the sender's deposit transaction hash, or any details about which asset or chain the sender paid from.
## **What Neither Party Sees**
Neither the sender nor the receiver sees the other's wallet address or the other's on-chain transaction hash. The only shared information is the username, the amount, and the timestamp. This means a receipt can be used to confirm that a payment took place, for record-keeping, expense tracking, or dispute purposes, without doxxing either party's on-chain identity.
## **Why This Matters**
Most crypto transactions today offer no receipt at all. A user can look up a transaction hash on a block explorer, but that reveals the full on-chain details to anyone who has the hash, including wallet addresses and balances. There is no built-in way to prove a payment occurred without exposing private information.
Privacy protocols have the opposite problem. Proving a transaction happened typically requires revealing the secret note, which compromises the privacy of the transaction entirely.
Silo's redacted receipts sit between these two extremes. They provide verifiable proof that a payment occurred, with enough detail to be useful for real-world purposes, while redacting the information that would expose either party's on-chain identity. This makes receipts practical for use cases like expense reporting, payroll records, tax documentation, and dispute resolution: scenarios where proof of payment is needed but full on-chain transparency is not.
## **Relationship to Payment Instructions**
Redacted receipts and Payment Instructions draw from the same underlying transaction data captured in Silo's database throughout the payment lifecycle. Receipts are generated and delivered to both parties as soon as the relevant transaction data is available. They do not depend on the Payment Instruction being finalized or uploaded to Walrus. The redacted receipt is a filtered view of the transaction record, tailored to show each party only the information relevant to them. The full Payment Instruction, once finalized and stored on Walrus, contains the complete unredacted record and remains encrypted and access-controlled on Silo's backend.
# Sanctions & KYT
Source: https://docs.silopay.io/sanctions-kyt
Silo enforces compliance checks at multiple points in the transaction lifecycle. These checks are designed to prevent the platform from being used to facilitate payments involving sanctioned entities, high-risk addresses, or illicit fund flows, while preserving the privacy and usability of the platform for legitimate users.
Compliance screening is not optional and cannot be bypassed by any tier. It applies equally to Personal, Plus, and Business accounts.
## **Sanctions Screening**
Silo screens against sanctions lists at two points: at onboarding (when a user creates an account) and at transaction time (before a payment is facilitated).
At onboarding, Silo checks the user's identity information and wallet address(es) against applicable sanctions lists. Users who are sanctioned persons, who register from sanctioned jurisdictions, or who connect sanctioned wallet addresses are blocked from using the platform.
At transaction time, Silo screens the payment before facilitating it. This includes checking the sender's address, the receiver's address, and the jurisdictions involved. If any element of the transaction matches a sanctioned entity or jurisdiction, Silo refuses to facilitate the payment.
Silo does not serve sanctioned persons, addresses, or jurisdictions. This is enforced programmatically, not by user trust.
## **KYT (Know Your Transaction)**
KYT is real-time transaction risk monitoring. While sanctions screening checks identities and addresses against static lists, KYT analyzes the transaction itself for risk signals: patterns, source of funds indicators, and behavioral flags that may suggest illicit activity.
Silo applies KYT checks to all transactions across all tiers. This includes checks on deposit routes (where the sender's funds are coming from) and withdrawal routes (where the receiver's funds are going). KYT is applied regardless of whether the user has completed KYC.
Transaction screening is provided by two independent blockchain intelligence providers: TRM Labs and CipherOwl. Silo runs dual providers deliberately. If one provider is unavailable, screening continues through the other, ensuring that every payment is screened before it is facilitated.
## **What Happens When a Payment Fails Screening**
If a payment fails sanctions screening or KYT checks, Silo refuses to facilitate the transaction. The payment is not routed, no funds enter the vault, and no Payment Instruction is created.
Silo's ability to block transactions is limited to the facilitation stage: the point before funds are deposited into the shared vault. Once funds are in the vault, withdrawals are governed by the smart contract and require the receiver's wallet signature. Silo cannot seize, redirect, or freeze funds that are already in the vault. This is a deliberate architectural boundary: Silo's compliance lever is gating (refusing to facilitate), not fund control.
## **Tier-Based Controls**
In addition to sanctions screening and KYT, Silo enforces tier-based velocity limits as a compliance control. Each tier has daily and monthly transaction caps (see Three-Tier System). Users who reach their tier limits are prompted to upgrade to a higher tier with additional verification.
These limits serve a dual purpose. They reduce the platform's exposure to unverified high-volume activity, and they create a natural incentive for users to complete identity verification in exchange for higher limits and lower fees.
## **Identity Verification**
KYC (for Plus accounts) and KYB (for Business accounts) are handled by Sumsub, an established identity verification provider. Silo does not build or maintain its own identity verification infrastructure. Verification requirements by tier are detailed on the Three-Tier System page.
## **Why This Matters**
The absence of compliance controls is what led to Tornado Cash being sanctioned by OFAC. Silo's compliance architecture is designed to position the platform on the opposite side of that line. Privacy from the public is a feature. Evasion of sanctions and money laundering controls is not.
By enforcing screening before facilitation, maintaining encrypted audit trails behind every transaction, and using tiered verification to gate volume, Silo is designed to make misuse difficult while keeping legitimate private payments simple.
# Security
Source: https://docs.silopay.io/security
Silo's smart contract architecture separates fund-touching contracts from business logic contracts. Vault contracts that interact with user funds are designed to be immutable once deployed. Business logic contracts (routing, fee calculation, tier enforcement) are upgradeable via proxy patterns, allowing the platform to evolve without compromising the security of fund-holding infrastructure.
Silo's privacy layer uses zero-knowledge proofs to create on-chain unlinkability between deposits and withdrawals. The ZK commitment and proof system ensures that withdrawals can only be executed by the designated wallet, and that no on-chain observer can link a specific withdrawal to a specific deposit.
Encrypted transaction records (Payment Instructions) are stored using SEAL encryption on Walrus, Sui's decentralized storage layer. This ensures that records are encrypted at rest, durable across decentralized infrastructure, and not dependent on a single server or database.
Cross-chain transfers are routed through CCTP (Circle's Cross-Chain Transfer Protocol), Circle's canonical burn-and-mint protocol for USDC transfers. Silo does not use third-party bridges with unaudited or experimental security models.
KYC verification is handled through Sumsub. Transaction screening (KYT) is handled through two independent providers, TRM Labs and CipherOwl, so screening remains available even if one provider is down. Silo does not build or maintain its own identity verification or transaction monitoring infrastructure. These functions are delegated to established, purpose-built providers.
**Audits**
Silo's smart contracts are undergoing security review. Audit reports will be published on this page when complete. Silo is committed to transparency around its security posture and will make all audit findings publicly available.
**Responsible Disclosure**
Information on Silo's responsible disclosure and bug bounty program will be published here when the program is live.
# Shared Vaults
Source: https://docs.silopay.io/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, but there is no on-chain way to determine which deposit corresponds to which withdrawal.
This commitment-and-nullifier shielded pool design is a well-established cryptographic pattern, implemented here inside a payments flow with compliance controls rather than as a standalone tool.
## **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. Any attempt at linkage is statistical inference, and the confidence of that inference falls as the pool grows.
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, binding a randomly generated secret to the receiver's designated withdrawal address. It is computed off-chain and bundled into the deposit transaction, and it is what later enables the receiver to prove their right to withdraw without revealing which deposit the withdrawal corresponds to. See ZK Layer for the full mechanism.
## **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 designated wallet.
# Silo 101
Source: https://docs.silopay.io/silo-101
## **What Silo Is**
Silo is a non-custodial crypto payments platform. It allows users to send and receive cryptocurrency using a single username, with transactions kept private from public blockchain observers and compliance checks enforced automatically in the background.
The user experience is simple: the sender enters a username and a dollar amount, then confirms the transaction. Silo reads the receiver's saved preferences and handles asset conversion, chain routing, bridging, and privacy automatically. The receiver gets paid in their preferred asset, on their preferred chain, to their chosen wallet. Neither party needs to share wallet addresses, coordinate chains, or perform any manual steps beyond the initial send.
Silo is not a wallet, not a blockchain, and not a custodial service. Users connect their existing wallets to Silo and maintain full control of their funds throughout the process.
## **The Problem**
Crypto payments today are broken in three ways.
First, they are confusing. Sending a payment requires knowing the recipient's wallet address (a long, error-prone string), which chain they want to receive on, and which asset they want. Even experienced crypto users send test transactions first because mistakes are irreversible. Name services like ENS help with addresses, but each one only works on its own chain, and they don't solve the chain or asset coordination problem.
Second, they are too public. Sharing a wallet address exposes the user's entire balance and transaction history to anyone who looks it up. Name services actually make this worse by creating a persistent, searchable identity tied to all on-chain activity. Physical crimes against crypto holders have escalated sharply, with documented incidents rising from 2 in 2016 to 87 in 2025, including kidnapping, extortion, home invasion, and robbery. Financial privacy from the public is becoming a safety issue.
Third, existing privacy tools are too complex for everyday use. Existing privacy protocols require users to learn unfamiliar processes: depositing into pools, managing secret notes, shielding and unshielding funds, and interacting with relayers. These tools were designed for privacy-focused technical users, not for people who simply want to send or receive a payment.
## **How Silo Solves It**
Silo replaces wallet addresses with a single username that works across all supported chains. Each user sets up receiver preferences once: their preferred asset, preferred chain, and destination wallet. Every payment sent to that username is automatically routed according to those preferences, regardless of what the sender is paying with or which chain they are sending from.
Privacy is applied by default to every transaction. Silo uses shared vaults and zero-knowledge proofs to break the on-chain link between sender and receiver. Public blockchain observers cannot determine who paid who. Neither party sees the other's wallet address or transaction hash. Both parties receive a redacted receipt that confirms the payment occurred without exposing private details.
Compliance is built into the transaction flow, not bolted on after the fact. Every transaction passes through sanctions screening and risk checks before it is facilitated. Silo maintains an encrypted audit trail (called a Payment Instruction) behind every transaction that can support disputes, audits, and regulatory requirements. Users interact with a three-tier verification system: higher verification unlocks lower fees and higher transaction limits, while unverified users can still transact within defined thresholds.
The entire process is non-custodial. Users connect their own wallets. Withdrawals require the receiver's wallet signature. Silo facilitates the payment routing and privacy layer, but does not take custody of user funds.
## **What Makes Silo Different**
Several products solve parts of this problem. Name services make addresses more readable but don't handle privacy, cross-chain delivery, or compliance. Privacy protocols hide on-chain activity but require complex user ceremonies and have no payments UX, no receipts, and no compliance layer. Custodial payment apps like Venmo and Cash App offer simple UX and username-based payments, but users give up control of their funds, and privacy depends on the platform rather than cryptography.
Silo combines username-based payments, cross-chain delivery, on-chain privacy, non-custodial architecture, compliance controls, and redacted receipts in a single platform. It sits between privacy maximalist tools and custodial convenience apps, offering usable privacy without requiring users to sacrifice simplicity or self-custody.
## **Where to Go Next**
For a detailed walkthrough of usernames and receiver preferences, see [**Usernames & Receiver Preferences**](/usernames-receiver-preferences). For the technical payment flow, see [**Payment Flow**](/payment-flow). For a deeper explanation of the privacy model, see [**Privacy Model**](/privacy-model). For compliance details, see [**Three-Tier System**](/three-tier-system).
# Supported Chains & Assets
Source: https://docs.silopay.io/supported-chains-assets
This page reflects Silo's current chain and asset support. It will be updated as new chains and assets go live.
## **Chains**
Ethereum: live on testnet.
Sui: live on testnet.
Solana: live on testnet.
Mainnet deployment follows the completion of smart contract audits. Additional chain support is planned and will be announced as integrations are completed.
## **Assets**
Silo launches with a whitelisted set of assets on each chain: major stablecoins, including USDC and USDT, and each chain's native asset (ETH on Ethereum, SUI on Sui, SOL on Solana). USDC is Silo's settlement asset and the lowest-cost path for transactions: no swap fees apply when both sender and receiver use USDC. Payments in any other whitelisted asset are swapped through DEX liquidity as part of the payment flow.
Over time, the whitelist expands toward any asset with active trading liquidity on its respective chain's DEXs. When new assets are added, this page will be updated to reflect which assets are available on which chains.
## **Bridge**
Cross-chain transfers are routed through CCTP (Circle's Cross-Chain Transfer Protocol). CCTP handles USDC bridging between supported chains at \$0 Silo fee. It is Circle's canonical burn-and-mint transfer protocol for USDC.
## **Swap Routing**
When a payment requires an asset conversion, Silo routes through available DEX liquidity on the relevant chain. Current routing integrations include Uniswap on Ethereum, DeepBook on Sui, and Raydium on Solana. Silo selects the best available route automatically. Swap fees and slippage are passed through at cost with no Silo markup.
# Three-Tier System
Source: https://docs.silopay.io/three-tier-system
Silo uses a three-tier account system that determines fee rates, transaction limits, and what types of payments a user can participate in. The tiers are Personal, Plus, and Business. Each tier is additive: every higher tier includes everything the previous tier can do, plus new capabilities.
The core design principle is that the sender never needs to think about tiers, fee logic, or payment types. They type a username and an amount, and Silo handles everything else. Tier logic, fee routing, and payment type enforcement all happen in the background.
## **Tier 1: Personal - 30 bps**
Personal accounts are for everyday users making payments to friends, family, or other individuals. No identity verification is required. Users sign up with an email address only.
Personal accounts can send and receive peer-to-peer payments with other Personal and Plus users. They cannot buy from merchants (Commerce accounts) or receive payroll payments. If a Personal user tries to pay a merchant, the system prompts them to upgrade rather than showing an error.
Transaction limits are \$2,000 per day and \$10,000 per month. Fee rate is the highest of the three tiers. Transaction screening (KYT) is applied to all payments.
## **Tier 2: Plus - 25 bps**
Plus accounts are for users who transact frequently and want lower fees and higher limits. KYC (identity verification) is required. Users verify with an ID and selfie through Silo's verification partner.
Plus accounts can do everything Personal accounts can do, and they also unlock two additional capabilities: buying from merchants (sending payments to Commerce accounts) and receiving payroll (receiving payments from Payroll accounts). Plus accounts cannot become a merchant or send payroll. Those require Business tier.
Transaction limits are \$50,000 per day and \$250,000 per month. Fee rate is lower than Personal tier.
## **Tier 3: Business - 20 bps**
Business accounts are for companies and operators who need to accept customer payments or send payroll. Full KYB (Know Your Business) verification is required, including business registration and beneficial ownership documentation.
Business accounts can do everything Plus accounts can do, plus two additional capabilities depending on their sub-type:
Commerce sub-type: for businesses accepting payments from customers. Online stores, marketplace sellers, service providers, and anyone invoicing clients. Only Plus and Business users can send payments to Commerce accounts. Personal users cannot.
Payroll sub-type: for businesses paying employees or contractors. Only Plus and Business users can receive payroll payments. Personal users cannot.
The sub-type (Commerce or Payroll) is selected during onboarding and locked to the account. Businesses that need both capabilities can request a review to add a second sub-account.
Transaction limits are \$500,000 per day and \$5,000,000 per month, with custom limits available. Fee rate is the lowest of the three tiers.
| | Personal | Plus | Business |
| ------------------------ | ---------- | ----------------- | --------------------------- |
| Fee | 30 bps | 25 bps | 20 bps |
| Verification | Email only | ID + selfie (KYC) | Business registration (KYB) |
| Daily limit | \$2,000 | \$50,000 | \$500,000 |
| Monthly limit | \$10,000 | \$250,000 | \$5,000,000 + custom |
| Peer-to-peer payments | ✓ | ✓ | ✓ |
| Buy from merchants | | ✓ | ✓ |
| Receive payroll | | ✓ | ✓ |
| Accept customer payments | | | ✓ |
| Send payroll | | | ✓ |
| Cash out to bank | ✓ | ✓ | ✓ |
Transaction limits and fee rates are illustrative and subject to change pending legal review.
## **Fee Responsibility**
Who pays the Silo fee depends on the payment context, not on a choice the sender has to make.
For peer-to-peer payments (Personal and Plus accounts), the receiver absorbs the fee by default. The fee is deducted from the amount received, not added on top of what the sender sends. The sender sees a transparency line beneath the amount field showing what the receiver will actually receive (e.g., "Jack will receive \$99.70"). An optional "Cover fee" toggle allows the sender to top up the payment so the receiver gets the full amount. The toggle is off by default.
For commerce payments (customer paying a merchant), the merchant always absorbs the fee. The customer pays exactly the amount they type. There is no Cover fee toggle. Fee direction is locked to the merchant. This mirrors how every major payment processor works.
For payroll payments (employer paying an employee), the employer always pays the fee. The employee receives their full agreed amount with no deductions. The employer sees a confirmation screen before submission showing the salary, the Silo fee, and the total debit. This mirrors traditional payroll processing.
| | Peer-to-peer | Commerce | Payroll |
| ---------------- | ------------------------ | ---------------- | -------------- |
| Who pays the fee | Receiver (by default) | Merchant | Employer |
| Sender pays | Amount typed | Amount typed | Amount + fees |
| Receiver gets | Amount minus fee | Amount minus fee | Full amount |
| Cover fee toggle | Optional, off by default | Not available | Not applicable |
## **Swap Fees**
Silo's fee structure separates two costs: the Silo platform fee (routed by the tier logic described above) and swap fees incurred when a payment requires an asset conversion.
The rule is straightforward: if a payment requires a swap because of either party's asset choice, the party whose choice triggered the swap bears the cost. If a sender holds ETH but the receiver wants USDC, the sender bears the ETH-to-USDC swap. If a sender sends USDC but the receiver's preference is set to ETH, the receiver bears the USDC-to-ETH swap out of the received amount. If both sides use USDC, there is no swap and no swap fee. USDC-to-USDC is the lowest-cost path.
The Cover fee toggle covers the Silo platform fee only. It does not cover swap fees. Swap costs always follow the "your choice, your cost" rule regardless of whether the sender enables Cover fee.
## **Tier Gating**
Tier restrictions are enforced at the routing layer, not the user interface. A Personal user cannot send to a Business account even if they know the username. The system checks the sender's tier against the receiver's account type before the payment is processed. If the interaction is not permitted, the user sees a prompt to upgrade, not a technical error.
This creates a natural upgrade path. Users who want to buy from merchants or receive payroll upgrade to Plus. Users who want to accept payments as a merchant or run payroll upgrade to Business. Each step requires more verification and unlocks more capability.
# Usernames & Receiver Preferences
Source: https://docs.silopay.io/usernames-receiver-preferences
## **Usernames**
Every Silo user creates a single universal username (e.g., @alice). This username is the only thing another person needs to send a payment. It works across all supported chains and wallets.
A Silo username is not a name service like ENS or others. Name services map a readable name to a specific wallet address on a specific chain, which means the sender still needs to know which chain the receiver is on, and anyone who looks up the name can see the linked wallet's full balance and transaction history. A Silo username does not expose any wallet address. It is a payment routing identity that points to the receiver's saved preferences, not to a public key.
Usernames are unique and permanent once claimed. They function as a single, chain-agnostic identifier across the entire platform.
## **Receiver Preferences**
Each Silo account stores a set of receiver preferences that determine how incoming payments are delivered. The receiver configures these once and can update them at any time. The preferences include:
**Destination chain:** which supported chain the receiver wants to be paid on (Ethereum, Sui, or Solana).
**Preferred asset:** which asset the receiver wants to receive, from the whitelisted assets available on their chosen chain.
**Payout wallet(s):** the wallet address or addresses where funds should be delivered. Receivers can list multiple wallets, in which case Silo uses on-chain randomness to split incoming payments across them. This adds an additional layer of privacy by distributing funds across several addresses rather than concentrating them in one.
These preferences are universal. They apply to every payment sent to that username, regardless of which chain or asset the sender is paying with. The sender never sees the receiver's preferences. They simply enter a username and a dollar amount, and Silo handles the rest.
## **How It Works in Practice**
When a sender pays @bob, they choose which asset and chain to send from on their side. Silo reads Bob's saved preferences and automatically handles any conversion or routing required to deliver the payment according to those preferences. If the sender pays in USDC on Ethereum but Bob's preferences are set to receive USDC on Sui, Silo routes the payment cross-chain without either party coordinating. If the sender pays in a different asset than the receiver wants, Silo swaps it automatically using available DEX liquidity.
The result is that neither party needs to coordinate chain, asset, or wallet details. The sender's only decision is how much to send. The receiver's preferences handle everything else.
![Username Routing (1)]()
## **Updating Preferences**
Receiver preferences can be changed at any time. When a receiver updates their destination chain, preferred asset, or payout wallets, all future payments to their username will automatically route according to the new settings. No action is required from anyone who has previously paid or will pay that user.
This is a single, universal withdrawal preference at the account level. There is no per-chain or per-asset configuration to manage. One account, one set of preferences, one withdraw flow.
# ZK Layer
Source: https://docs.silopay.io/zk-layer
Silo uses zero-knowledge proofs to create mathematical unlinkability between deposits and withdrawals in the shared vault. This page explains the cryptographic mechanism that powers that unlinkability: how commitments are generated, how proofs are verified, and why the system ensures that only the designated wallet can withdraw funds without revealing which deposit is being claimed.
## **How It Works**
Every Silo payment involves two cryptographic operations: a commitment at deposit time and a proof at withdrawal time. Both use the Poseidon hash function, a cryptographic algorithm optimized for zero-knowledge proof circuits (specifically ZK-SNARKs).
## **Commitment (Deposit)**
At deposit time, Silo's backend generates the commitment using the following equation:
```text theme={null}
commitment = Poseidon(amount, pubKey, blinding, recipientHash)
```
The inputs are:
**amount**: the exact token volume being deposited.
**pubKey**: a hash derived from a securely generated random private key, computed as Poseidon(privateKey).
**blinding**: a dynamically generated 32-byte entropy number. This ensures that even if multiple users deposit identical amounts bound to the same withdrawal address, their commitments remain entirely unique and untraceable.
**recipientHash**: the hashed representation of the designated withdrawal wallet address.
The commitment is computed entirely off-chain. Only after the computation succeeds is the commitment data bundled into the on-chain transaction that executes the vault deposit. The commitment is then added to an on-chain Merkle tree. The secret values (private key, blinding) are managed internally by Silo's backend. The user never sees or handles them.
## **Nullifier (Withdrawal)**
At withdrawal time, a nullifier is generated to prevent double-spending. The nullifier is computed as:
```text theme={null}
nullifier = Poseidon(commitment, leafIndex, signature)
```
The nullifier is submitted alongside a zero-knowledge proof that verifies the receiver's right to withdraw without revealing which deposit the withdrawal corresponds to. The proof demonstrates that the withdrawer knows the secret values bound to a valid commitment in the Merkle tree, without exposing those values or identifying which commitment is being claimed.
The smart contract verifies the proof and checks that the nullifier has not been used before. If valid, the contract consumes the nullifier and releases the funds. Because each commitment produces a unique nullifier, no deposit can be claimed twice. And because the nullifier reveals nothing about which commitment it corresponds to, the on-chain link between deposit and withdrawal remains broken.
## **What This Achieves**
The commitment-proof system creates three guarantees simultaneously.
First, only the designated wallet can withdraw. The commitment cryptographically binds the secret to a specific withdrawal address at deposit time. No other wallet can produce a valid proof, so no other wallet can trigger the withdrawal. This is what makes the system non-custodial: Silo facilitates the process but cannot move funds on a user's behalf.
Second, no observer can link a deposit to a withdrawal. The ZK proof verifies that the withdrawer has a valid claim against some commitment in the Merkle tree, but it does not reveal which one. An on-chain observer sees that a valid withdrawal occurred but cannot determine which deposit it corresponds to. This is what creates unlinkability: the mathematical guarantee that the deposit-withdrawal link is hidden, beyond just the practical obscurity of the pooled vault.
Third, no deposit can be claimed twice. The nullifier system ensures that each commitment can only be withdrawn once. The smart contract tracks consumed nullifiers and rejects any attempt to reuse one. This is the double-spend protection layer.
## **What the User Experiences**
None of this is visible to the user. There is no secret to save, no note to manage, no shielding or unshielding step. The sender types a username and amount. The receiver signs from their wallet to withdraw. All ZK operations happen in the background, managed entirely by Silo's backend. The user experience is identical to a simple payment. The cryptography is invisible.
## **Relationship to Shared Vaults**
The ZK layer and the shared vault work together but serve different functions. The shared vault provides practical privacy by pooling funds from multiple users. An observer cannot easily determine which deposit corresponds to which withdrawal because there are many possible pairings. The ZK layer provides mathematical privacy by ensuring that even with unlimited computational resources, the link between a specific deposit and a specific withdrawal cannot be proven. The vault provides practical obscurity; the ZK proof ensures the link cannot be derived from on-chain data.