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.