What Mirage keeps private
TL;DR
There is no useful single privacy score for a transfer. The sender, recipient, node operator, Mirage, and a public observer each begin with different information and need different information for the transaction to work.
- In a single transaction, the sender knows the recipient address. The recipient does not learn the sender address or that Mirage was used. A public observer learns neither the relationship between the sender and the recipient nor the fact that Mirage was used.
- In a batch transaction, the sender knows the complete batch. Each recipient learns only about their own transfer, not the sender or any other recipient. The public observer does not learn the members of the batch or the fact that Mirage was used. The total sum of the tokens on the escrow/sender side does not equal the individual transaction amounts on the recipient side, meaning that the transaction amounts are even less correlated.
- Node software decrypts transfer instructions only inside its trusted execution environment. The person operating the node does not receive the plaintext.
- Mirage relays the encrypted signal. Separate values may be used briefly for quotes or compliance checks, but Mirage does not receive or store a record of who paid whom, what they paid, or when.
Choose a scenario
| Scenario | The practical guarantee | Details |
|---|---|---|
| Single transaction | The sender knows the recipient; the recipient does not learn the sender. | Single Transaction Privacy |
| Batch transaction | The sender knows the full batch; every recipient is isolated from the sender and the other recipients. | Batch Transaction Privacy |
How to read the tables
The tables use four factual states. They are categories, not a ranking from bad to good.
| State | Meaning |
|---|---|
| Available | This party receives or observes the information in plaintext as part of normal operation. Example: a sender knows the recipient address they entered. |
| Not exposed | The protocol does not provide this information to this party. Example: a recipient’s incoming transfer does not contain the sender address. |
| Enclave-only | The information is processed in plaintext inside the TEE, but is not exposed to the node operator. Example: the enclave reads the recipient and amount to execute a transfer. |
| Not disclosed | The protocol does not affirmatively tell this party that a fact is true. Example: an ordinary incoming transfer does not tell the recipient that Mirage was used. |
“Available” does not imply that information is stored, combined with other fields, or available to every party. Each table explains the exact scope.
The shared privacy model
Across both scenarios:
- Transaction metadata is encrypted on the sender’s device.
- The API relays the encrypted signal without decrypting its contents.
- A Nomad node decrypts the signal only inside its trusted execution environment.
- The node pays the recipient from node-controlled liquidity.
- Public chain activity does not contain a direct sender-to-recipient transaction record.
The blockchain still contains observable activity. Sender-side escrow funding, recipient-side token transfers, token contracts, amounts, and timestamps can exist publicly. What Mirage prevents is their publication as one explicit transfer relationship.
Information shared elsewhere
Mirage cannot protect information disclosed outside the protocol. Messages, invoices, public wallet labels, screenshots, and shared receipts can reconnect details that Mirage kept separate.
Keep receipts private and share transaction context only with the people who need it.