Technical FAQ
What are the main attack vectors against Mirage?
One risk is that observers could attempt to identify privacy usage by analyzing smart contract patterns or transaction behavior on-chain. Mirage mitigates this by using unique escrow contracts and obfuscated bytecode, making transactions appear similar to ordinary activity and reducing the ability to reliably detect privacy usage.
Another potential risk is that malicious actors could attempt to access or extract private transaction data from nodes that process user requests. Mirage addresses this on multiple levels. At the infrastructure layer, only nodes operated within high-security, certified data centers, such as IBM Cloud, are permitted to join the Mirage network, eliminating the physical access attack vector entirely. At the computational layer, sensitive operations are processed inside trusted execution environments (TEEs), which isolate computation and prevent operators or external parties from accessing decrypted transaction data. Finally, users can enable multi-routing, which forwards transactions through multiple independent nodes across separate routing paths (similar to Tor) so that even if a single node were compromised, an attacker could not reconstruct the full transaction without cooperation from all other nodes involved, significantly raising the bar for any coordinated attack.
Finally, there is the general risk of vulnerabilities within node infrastructure or software. Mirage is designed so that transaction execution is verified on-chain through escrow contracts and cryptographic proofs, ensuring that nodes only receive rewards after a transaction has been successfully completed.
Can funds be lost if Mirage breaks or is halted?
No, users can at any point in time withdraw their funds from the escrow contract, as long as the funds have not been processed by a node yet.
Can bad actors run a Mirage node to steal funds or disclose private transactions?
Mirage attempts to mitigate this risk through several mechanisms:
- Nodes must provide liquidity and post security deposits
- Escrow contracts verify that payments were executed correctly before releasing funds
- Transaction requests are processed inside trusted execution environments (TEEs)
- Mirage only works with node operators that have passed compliance screening
These mechanisms aim to prevent nodes from stealing funds or extracting private transaction details.
How secure is Mirage?
Mirage combines several security mechanisms, including:
- Encrypted transaction signals
- Trusted execution environments for node processing
- Deterministic verification of escrow contract bytecode
- On-chain verification of transaction execution
Together, these mechanisms are designed to protect transaction privacy, prevent unauthorized access to sensitive data, and ensure that transactions are executed correctly without requiring trust in any single intermediary.
Has Mirage been audited?
Mirage has not yet undergone a formal security audit. We are actively evaluating audit options.
For components like Azoth, which are under continuous development, we use formal verification and fuzz testing to ensure determinism and semantic equivalence across versions, guarantees that point-in-time audits are generally not suited to provide for a continuously evolving codebase.
One important architectural distinction: Mirage does not rely on shared pools or shared contracts. Each user's funds are held in their own escrow contract for the duration of a transaction, which typically completes or is canceled within minutes. A vulnerability could not be used to drain a collective pool or impact users beyond those in an active transaction at that moment.
Does Mirage have a bug bounty program?
Yes. Mirage runs a bug bounty program with rewards up to $25,000 for critical vulnerabilities in released versions of Azoth and Nomad, and researcher grants of up to $5,000 for independent privacy analysis.
See Bug Bounty and Researcher Grants for full details.