Batch transaction privacy

TL;DR

The sender knows the complete batch. Each recipient sees only their own transfer and does not learn the sender address, the other recipients, their amounts, or that the transfer belonged to a batch.

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 creates the batch, so they know every recipient and transfer row. Batch privacy protects recipients from one another; it does not hide them from the sender.

Information	Status	What this means
Sender address	Available	The sender connects and uses their own wallet.
Recipient addresses	Available	The sender enters or uploads the complete recipient list.
Tokens and amounts	Available	The sender defines every row in the batch.
Complete batch membership	Available	The sender knows which recipients belong to the batch.
Sender–recipient relationships	Available	The sender knows every intended transfer relationship.
Transaction timing and status	Available	The sender sees the batch submission and each completion.
Mirage usage	Available	The sender chose to use Mirage.

Recipient point of view

Takeaway: A recipient sees only their own ordinary incoming transfer. Nothing in it reveals the sender, the other recipients, or the existence of a batch.

Information	Status	What this means
Own recipient address	Available	The recipient sees funds arrive at their own address.
Own token and amount	Available	The recipient sees what they received.
Own arrival time	Available	Their incoming transfer has a public timestamp.
Sender address	Not exposed	The incoming transfer comes from node-controlled liquidity, not the sender wallet.
Other recipient addresses	Not exposed	No recipient list is included with the transfer.
Other tokens and amounts	Not exposed	A recipient receives no information about the other rows.
Batch membership	Not disclosed	The transfer looks like an ordinary individual transfer and does not announce that it was part of a batch.
Mirage usage	Not disclosed	The transfer does not announce that Mirage was used.

Node operator point of view

Takeaway: Node software receives encrypted batch metadata and decrypts only its assigned work inside the enclave. The operator does not receive readable recipients, amounts, tokens, or relationships.

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.
Assigned recipient addresses	Enclave-only	Decrypted inside the enclave only for the routes this node executes.
Assigned tokens and amounts	Enclave-only	Decrypted inside the enclave to construct the assigned transfers.
Sender–recipient relationships	Enclave-only	Processed inside the enclave; not delivered to the operator as readable transaction metadata.
Complete batch membership	Enclave-only	The enclave can process the assigned batch signal. Optional routing can divide work across independent nodes, but the operator receives no plaintext recipient list.
Mirage usage	Available	The operator knows they run a Mirage node; this reveals nothing about the batch contents.

Mirage point of view

Takeaway: Mirage relays encrypted batch signals without decrypting them. Addresses used for compliance and values used for quoting are handled separately, never assembled into batch rows, and not stored as a transaction record.

Information	Status	What this means
Encrypted batch signal	Available	Mirage can relay the ciphertext but cannot read the rows inside it.
Sender address	Available	Used separately for compliance and authorization, then not stored as part of a batch record.
Recipient addresses	Available	Checked separately for compliance; never received linked to the sender or assembled into a stored recipient list.
Tokens and amounts	Available	Isolated values are used for quoting; they are not stored together with addresses or batch relationships.
Sender–recipient relationships	Not exposed	Mirage never receives plaintext rows joining a sender, recipient, token, and amount.
Complete batch membership	Not exposed	The encrypted signal is not decrypted into a recipient list by Mirage.
Transaction timing and status	Not exposed	Mirage does not retain a sender-linked batch history.

In other words, Mirage does not have a record of who was paid in the batch, who paid them, what each person received, why they were paid, or when.

Public observer point of view

Takeaway: A public observer sees aggregate sender-side activity and separate recipient-side transfers, but no authoritative map connecting them into one batch.

Information	Status	What this means
Sender address	Available	Sender-side wallet and aggregate escrow activity are public.
Recipient addresses	Available	Each appears separately as the destination of a normal node transfer.
Tokens, amounts, and times	Available	Public for each individual onchain event.
Sender–recipient relationships	Not exposed	No public record maps the sender to the individual recipients.
Complete batch membership	Not disclosed	The chain does not label which recipient transfers belong to the same batch.
Mirage usage	Not disclosed	No shared pool or stable signature affirmatively labels the activity as Mirage usage.

Why batch amounts are harder to correlate

The sender funds aggregate batch requirements, while recipients receive separate transfers. The sender-side value therefore does not correspond to one recipient amount. Different tokens, amounts, execution addresses, and route timing add further separation.

This does not make individual token transfers or timestamps invisible. It prevents the chain from providing a direct sender-to-recipient list or an authoritative statement that the recipient transfers belong together.

The boundary of this guarantee

The sender created the batch and therefore knows every recipient, token, and amount. Batch privacy isolates the recipients from the sender wallet and from one another; it does not hide recipients from the person paying them.