Single transaction privacy
TL;DR
The sender knows the recipient address because they enter it. The recipient receives a normal token transfer and does not learn the sender address, the sender–recipient relationship, or that Mirage was used.
The status labels describe access during the transaction, not a privacy score. See How to read the tables for their definitions.
Sender point of view
Takeaway: The sender sees the complete transfer they are creating. This is necessary knowledge, not a privacy weakness.
| Information | Status | What this means |
|---|---|---|
| Recipient address | Available | The sender enters the destination address. |
| Sender address | Available | The sender connects and uses their own wallet. |
| Token | Available | The sender chooses the token. |
| Amount | Available | The sender chooses the amount. |
| Sender–recipient relationship | Available | The sender knows who they intend to pay. |
| Transaction timing and status | Available | The sender sees submission, progress, and completion. |
| Mirage usage | Available | The sender chose to use Mirage. |
Recipient point of view
Takeaway: The recipient sees a normal incoming transfer and its details, but the transfer does not identify the sender or disclose that Mirage was used.
| Information | Status | What this means |
|---|---|---|
| Recipient address | Available | The recipient sees funds arrive at their own address. |
| Sender address | Not exposed | The incoming transfer comes from node-controlled liquidity, not the sender wallet. |
| Token | Available | The received token is visible in the wallet and onchain. |
| Amount | Available | The recipient sees the amount they received. |
| Arrival time | Available | The incoming transfer has a public timestamp. |
| Sender–recipient relationship | Not exposed | Nothing in the transfer links the recipient to the sender wallet. |
| Mirage usage | Not disclosed | The transfer looks like an ordinary token transfer and does not announce Mirage usage. |
Node operator point of view
Takeaway: Node software receives encrypted metadata and decrypts it inside the enclave to execute the transfer. The person operating the node does not receive the plaintext transaction details.
| Information | Status | What this means |
|---|---|---|
| Sender address | Enclave-only | Available to the trusted execution environment as required for verification, not exposed through the operator interface or logs. |
| Recipient address | Enclave-only | Decrypted inside the enclave to construct the recipient transfer. |
| Token | Enclave-only | Decrypted inside the enclave to select the asset used for execution. |
| Amount | Enclave-only | Decrypted inside the enclave to construct the transfer. |
| Sender–recipient relationship | Enclave-only | The enclave processes the assigned transfer; the operator does not receive the readable relationship. |
| Mirage usage | Available | The operator knows they are running a Mirage node; this reveals nothing about the transaction contents. |
Mirage point of view
Takeaway: Mirage relays the encrypted signal but never sees its decrypted contents. Addresses used for compliance and values used for quoting are handled separately, are never joined into a transfer relationship, and are not stored as a transaction record.
| Information | Status | What this means |
|---|---|---|
| Encrypted signal | Available | Mirage can relay the ciphertext but cannot read the transaction metadata inside it. |
| Sender address | Available | Used separately for compliance and authorization, then not stored as part of a transaction record. |
| Recipient address | Available | Used separately for compliance, never received together with the sender as a transfer relationship, and not stored as one. |
| Token and amount | Available | Isolated values are used to produce the quote; they are not received or stored in relation to the addresses or other metadata. |
| Sender–recipient relationship | Not exposed | Mirage never receives a plaintext record joining the two addresses. |
| Transaction time and status | Not exposed | Mirage does not retain a sender-linked transaction history. |
In other words, Mirage does not have a record of who transferred funds to whom, how much they sent, why they sent it, or when the transaction happened.
Public observer point of view
Takeaway: A public observer can inspect both sides of onchain activity, but the chain does not identify them as one transaction or confirm that Mirage was used.
| Information | Status | What this means |
|---|---|---|
| Sender address | Available | Sender-side wallet and escrow activity are public. |
| Recipient address | Available | Visible as the destination of a normal node transfer. |
| Token, amount, and time | Available | These are public on each individual onchain event. |
| Sender–recipient relationship | Not exposed | No direct transfer or public record joins the sender to the recipient. |
| Mirage usage | Not disclosed | No shared pool or stable signature affirmatively labels the activity as Mirage usage. |
| Transaction purpose | Not exposed | No purpose is recorded or published by Mirage. |
The boundary of this guarantee
The sender must know the recipient address to create a single transaction. Single transactions therefore protect the sender from the recipient and separate the parties publicly; they do not hide the recipient from the sender.
Information shared outside Mirage, such as a message, invoice, wallet label, or receipt, can still identify the parties.