Mirage Technical Model
Mirage is a coordination protocol for private stablecoin transfers. For users, the goal is a quick payment flow that feels familiar. For integrators and reviewers, the important detail is how that simple flow is settled without custody or a shared privacy pool.
Mirage separates a payment into three layers:
- Local intent creation: the user creates and encrypts payment instructions on their own device.
- Offchain coordination: the encrypted signal is broadcast to a network of Nomad nodes.
- Onchain settlement: a temporary escrow contract verifies execution and reimburses the node that completed the transfer.
The goal is not only to break the visible sender-recipient link. Mirage also avoids routing every user through the same public pool or contract.
Design Goals
Mirage is built around a few practical requirements:
- Simple send flow: the user should be able to enter a recipient, amount, and tip, then send.
- Fast settlement: execution targets seconds on supported L2s and under 90 seconds on Ethereum mainnet, depending on network conditions.
- Usage privacy: observers should not be able to reliably classify a transaction as privacy-protocol usage from public chain data alone.
- Stablecoin-native transfers: users send assets such as USDC without first moving into a separate privacy asset, appchain, or pool.
- No shared custody pool: each transaction uses its own temporary escrow, so user funds are not combined with unrelated users' funds.
- Verifiable contract variation: escrow code can vary across transactions while remaining deterministic and independently checkable.
- Compliance-aware orderflow: Mirage can screen user wallets and route orderflow to screened node operators without taking custody.
Core Components
Client
The client is the wallet, web app, or SDK integration that creates the user's payment intent. It prepares the recipient, amount, token, tip, escrow parameters, and any required compliance metadata. Sensitive details are encrypted locally before they are sent to the network.
Temporary Escrow
The escrow contract is the onchain settlement object for one transaction. It holds the user's funds and the node tip, allows the user to recover funds if the request is not accepted, and releases reimbursement only after a node proves it executed the requested transfer.
Each escrow is unique to a transaction. There is no shared pool address that every user must touch.
Azoth
Azoth creates verifiable variants of the same escrow logic. The purpose is not to hide unsafe code. The escrow logic is open source; Azoth helps avoid every escrow having the same simple bytecode signature while preserving a deterministic verification path for nodes.
Signal Network
A signal is an encrypted execution request. It contains the data a node needs to complete the transfer, but that data is not broadcast in plaintext. Signals move through a gossip network, where nodes sample work and spend compute to decrypt eligible requests.
Nomad Nodes
Nomad nodes provide the execution layer. A node verifies the escrow, posts a bond, sends the requested stablecoin transfer from its own liquidity, and then claims reimbursement plus the user tip after proving execution.
Nomad uses trusted execution environments for sensitive processing. That is a defense-in-depth choice, not a claim that hardware alone solves privacy. The escrow bond, onchain proof, screened operators, and optional multi-routing are also part of the trust model.
Compliance Certificate
When Mirage performs wallet screening, the result can be attached to the signal as encrypted metadata. Screened nodes can choose to process only requests that include valid compliance certificates, while Mirage still avoids taking custody of user funds.
Transaction Lifecycle
The user creates a payment intent
The client records the recipient, token, amount, tip, route settings, and compliance metadata.
The client deploys a temporary escrow
The user funds the escrow with the payment amount and the tip. The escrow is unique to the transaction, but still verifiable by anyone with the user-generated Azoth seed.
The client broadcasts an encrypted signal
The signal tells eligible nodes how to execute the payment, but only after decryption inside the node environment.
A node samples and decrypts the signal
The node evaluates whether the tip, amount, route, and liquidity requirements make the job worth accepting.
The node verifies the escrow and posts a bond
Verification protects the node from interacting with a malicious contract. The bond discourages dishonest or incomplete execution.
The node sends funds to the recipient
The transfer comes from node-controlled liquidity, so the recipient sees a standard stablecoin transfer rather than a direct payment from the sender.
The node proves execution
The node submits proof that the recipient received the expected transfer.
The escrow reimburses the node
After proof verification, the escrow releases the payment amount, returns the bond, and pays the tip.
If no node accepts the request, the user can withdraw from the escrow as long as a node has not already bonded to complete the transaction.
What Is Visible Onchain
| Visible event | What it does | Why it matters |
|---|---|---|
| Temporary escrow deployment | Creates a one-transaction settlement contract | There is no shared mixer or pool contract to tag |
| User deposit into escrow | Funds the payment and node tip | The deposit is not a direct transfer to the recipient |
| Node transfer to recipient | Delivers the requested stablecoin amount | It looks like a normal stablecoin transfer from another address |
| Node reimbursement from escrow | Pays back the executor after proof | The escrow validates execution before releasing funds |
This does not mean there is no observable activity. It means the public activity is not anchored to a single, well-known privacy protocol surface.
Trust Boundaries
- Users do not trust nodes with custody. Funds sit in the escrow until execution is proven or the user withdraws before acceptance.
- Nodes do not trust arbitrary escrows. They verify the escrow before posting a bond.
- Observers do not get a known privacy address. Mirage avoids routing every user through the same identifiable contract or pool.
- Confidential execution limits node visibility. Trusted execution environments reduce what node operators can access, and multi-routing can reduce what any single node learns.
- Compliance checks do not make Mirage custodial. Screening gates orderflow and node participation, while settlement remains onchain and non-custodial.
What Mirage Brings Together
Mirage's advantage comes from combining ideas that are usually separate:
- A fast wallet-style payment flow.
- Unique escrow contracts instead of shared pools.
- Stablecoin-native payments instead of volatile privacy assets.
- Offchain encrypted coordination with onchain proof-based settlement.
- Verifiable contract variation through Azoth.
- Confidential-computing liquidity executors through Nomad.
- Compliance-aware routing without turning the protocol into a custodian.
That combination is the core technical model: a simple private payment experience backed by verifiable settlement and a public-chain footprint closer to normal stablecoin activity.