Skip to main content
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).