A Simple Example
Let's say Alice wants to send 100 USDC to Bob privately.
The Flow

- Open the Mirage app
- Enter Bob's address and the amount (100 USDC)
- Add a small tip (2 USDC) to incentivize a node to execute the transfer
- Hit send
That is the product experience Mirage is aiming for. A private payment should not feel like a research project, a bridge flow, or a multi-day wait.
Behind the scenes, Mirage separates Alice's private intent from the public transfer Bob receives. Instead of Alice sending directly to Bob, a Mirage node sends Bob 100 USDC from node-controlled liquidity. Alice's escrow later reimburses that node after it proves the transfer happened.
Step 1: Setting Up the Escrow
When Alice hits send, her client deploys a small temporary escrow contract. Alice does not need to manage this manually; it is part of the payment flow.
- The escrow is unique to Alice's transaction.
- It is not a shared pool used by many unrelated users.
- Its code can vary through Azoth, while remaining deterministic and verifiable.
- It controls when funds can be reimbursed, withdrawn, or paid as a tip.
Alice's wallet deposits into this escrow:
- 100 USDC (the amount she wants Bob to receive)
- 2 USDC (a small tip to reward whoever completes the transfer)
At the same time, Alice's client encrypts her instruction:
"Send 100 USDC to Bob's address. The executor earns 2 USDC after proving execution."
That encrypted message is broadcast to the Mirage node network as a signal. To Alice, this still feels like one payment request.
Step 2: A Node Picks Up the Job
The encrypted signal moves through the network. Nodes sample signals and spend compute to decrypt eligible requests.
Once a node successfully decrypts Alice's request inside a confidential computing environment, it checks whether it can complete the job.
Before executing, the node verifies the escrow and posts a security deposit. This matters for both sides:
- Alice does not need to trust the node with custody.
- The node does not need to trust a random unverified contract.
- The bond discourages incomplete or dishonest execution.
The node then sends 100 USDC to Bob from node-controlled liquidity. This is the key public moment: Bob receives a standard stablecoin transfer from another address, not a direct transfer from Alice and not a withdrawal from a known privacy pool.
Step 3: The Node Gets Reimbursed
The node just sent 100 USDC to Bob out of their own pocket. Now they need to get paid back from Alice's escrow contract:
- The node submits proof that they sent 100 USDC to Bob
- The escrow contract verifies the proof and confirms Bob received exactly 100 USDC
-
The contract releases payment:
- 100 USDC (reimbursement for what they sent Bob)
- Their security deposit (returned in full)
- 2 USDC (their tip for executing the transaction)
The node earns the 2 USDC tip. Bob receives 100 USDC. Alice has completed a private payment without sending directly to Bob or entering a shared pool.
If no node accepts Alice's signal, Alice can withdraw from the escrow as long as a node has not already bonded to execute the transfer.
Why This Provides Privacy
Let's step back and look at what an observer sees when analyzing the blockchain:
Transaction 1: Alice deployed a contract and deposited some USDC into it
Interpretation: could be an escrow, bot, application helper contract, business agreement, or another ordinary contract interaction.
Transaction 2: Some random address sent Bob 100 USDC
Interpretation: a normal stablecoin payment.
Transaction 3: Another random address later withdrew funds from Alice's contract
Interpretation: contract settlement or reimbursement activity.
There is visible activity, but it is not the standard footprint of a mixer or privacy pool. The node's transfer to Bob looks independent from Alice's escrow activity, and Mirage avoids using a shared public privacy contract that every user must touch.
For the full system view, see Technical Model.