Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

The Usage Privacy Challenge

One of the core ideas behind Mirage is that private payments should still feel normal.

Many crypto privacy systems focus on link privacy: hiding which sender paid which recipient. That matters, but users also care about the payment experience. They want to send stablecoins quickly without stepping into a process that feels risky, unfamiliar, or hard to explain.

Why This Matters for Users

If a privacy protocol has one recognizable pool, asset, bridge, or contract, observers can label every address that interacts with it. For normal users, that can make privacy feel like a tradeoff: get more confidentiality, but make the wallet look unusual.

That is not a mainstream payment experience. A business paying a contractor, a DAO paying a contributor, or a person sending stablecoins should not need to think about pool timing, special denominations, or whether a public contract label will follow their wallet.

Mirage's Approach

Mirage addresses this by changing both the user flow and the public footprint of a private payment:

  • Simple send flow: the user enters recipient, amount, and tip, then sends.
  • No shared pool: each transaction uses its own temporary escrow.
  • Verifiable contract variation: Azoth lets escrows vary without removing the node's ability to verify them.
  • Private coordination: sensitive payment instructions move as encrypted signals instead of public payment instructions.
  • Independent execution: a Nomad node sends the recipient a normal stablecoin transfer from node-controlled liquidity.
  • Proof-based reimbursement: the escrow pays the node only after execution is proven.

The result is not an invisible blockchain transaction. The result is a faster, simpler private payment whose public record is not centered on one known privacy pool.

What Observers See

An observer may see a temporary contract deployment, a deposit, a normal stablecoin transfer to the recipient, and a later reimbursement. Those events can have many plausible explanations in public-chain activity.

What they do not see is the classic mixer footprint: a user entering the same public pool as everyone else and later withdrawing from that known pool.

Practical Boundary

Mirage's goal is usage privacy under realistic observation. Timing, amount patterns, network behavior, contract deployment patterns, and implementation bugs can still create metadata. This is why Mirage combines product UX, encrypted signals, verifiable contract variation, confidential-computing nodes, multi-routing, compliance controls, and ongoing privacy research rather than relying on a single mechanism.

For the full system flow, see Technical Model.