How Mirage works

Mirage differs significantly from other privacy solutions in its architecture and design choices. This page covers the key ideas behind Mirage and explains how the core protocol functions.

The core idea

Mirage separates the source of a transfer from its destination. You fund a one-time escrow, then privately tell a Nomad node whom to send funds to. The node delivers the funds from its own liquidity and receives reimbursement only after proving that the transfer arrived.

Your transfer instructions are encrypted on your device. Mirage relays the encrypted signal without reading it, and the node opens it only inside its trusted execution environment.

Single transfers

What happens

1. You create the transfer. Choose the recipient, token, and amount. These details are prepared and encrypted on your device.
2. You fund a temporary escrow. The escrow holds the transfer amount and fee while the request is active. It is unique to this transaction, not a shared pool.
3. A node delivers the transfer. The node verifies the escrow, then sends funds to the recipient from separate node-controlled liquidity.
4. The node proves delivery. The escrow checks the proof before reimbursing the node and paying its tip.

The recipient does not need Mirage. They receive an ordinary token transfer at their existing address, without a direct transfer from your wallet.

What remains separate

The sender-side escrow funding and recipient-side delivery are separate public events. The blockchain does not publish a record saying that they are the two sides of one transaction. The recipient sees what arrived, but the incoming transfer does not identify the sender wallet or announce that Mirage was used.

The sender still knows the recipient because they entered the address. See Single Transaction Privacy for the complete point-of-view breakdown.

Batch transfers

A batch uses the same separation model for several transfers at once. You create one list containing each recipient, token, and amount, then fund a single escrow for the combined requirements. The encrypted batch is delivered without publishing a recipient list, and multiple Nomad nodes can fulfill different rows at the same time.

What changes in a batch

1. One escrow covers the batch. Sender-side funding reflects the combined requirements rather than one recipient's amount.
2. Nodes can work together. The batch can be divided across several Nomad nodes, with each node fulfilling its assigned rows.
3. Recipients are isolated from one another. Each recipient receives their own transfer from node-controlled liquidity and does not receive the other rows.
4. Delivery is still proven. Each participating node proves its delivery, and the escrow reimburses only successfully fulfilled work.

What recipients learn

Each recipient sees their own address, token, amount, and arrival time. They do not learn the sender address, the other recipients, the other amounts, or that their transfer belonged to a batch. The transfer also does not announce that Mirage was used.

The sender necessarily knows the complete batch because they created it. A public observer can see individual onchain events, but the chain does not provide an authoritative map connecting the sender to the recipients or grouping the recipient transfers into one batch.

See Batch Transaction Privacy for the full point-of-view breakdown, or Send to Several People for the step-by-step guide.

Built-in recovery

If no node accepts a transfer, you can cancel and recover the escrow funds while there is no active node reservation. If one or more reservations are active, each node must complete its assigned work and prove delivery or let its reservation expire.

Learn how to handle an interrupted transfer in Cancel or Recover a Transfer. Developers and technical readers can follow the full escrow, bond, proof, and reimbursement sequence in the Technical Model.