> 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/how-silo-works/payments-flow.md).

# Payments 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. The backend handles multiple operations across routing, privacy, compliance, and settlement.

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

{% stepper %}
{% step %}

### 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.
{% endstep %}

{% step %}

### 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 (Curve or Uniswap on Ethereum) to swap to USDC before proceeding.
{% endstep %}

{% step %}

### 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 primary 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.
{% endstep %}

{% step %}

### 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.
{% endstep %}

{% step %}

### 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.
{% endstep %}

{% step %}

### Step 6 — Withdrawal initiated

Bob initiates a withdrawal by signing from his primary wallet (the first wallet in his receiver preferences). 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.
{% endstep %}

{% step %}

### 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).
{% endstep %}

{% step %}

### 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.
{% endstep %}

{% step %}

### 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.
{% endstep %}
{% endstepper %}

***

#### **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: screening, ZK commitment, vault deposit, account credit, ZK proof verification, and Payment Instruction storage, still apply.

***

#### **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).

<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.silopay.io/how-silo-works/payments-flow.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.