Inversive Labs
Fisrt Audit Released February 9th 2026
The audit was conducted by Inversive Labs, an independent security research team specializing in blockchain infrastructure and smart contract security.
Audit report: 📄 Inversive – Mixoor Security Audit (February 2026)
The review analyzed the Mixoor program logic, deposit and withdrawal flows, relayer interactions, Merkle tree implementation, and zero-knowledge circuit constraints.
Audit Scope
The audit covered the Mixoor protocol components including:
Solana program logic
Deposit and withdrawal instructions
Merkle tree root management
Relayer transaction flow
ZK circuit integrations
Administrative control mechanisms
Findings Overview
The audit identified multiple issues across different severity levels, including one critical vulnerability related to token mint validation.
All critical and high-severity issues were addressed prior to deployment, and the corresponding fixes are available in the public repository: https://github.com/SmithiiDev/mixoor
The remediation work was implemented in the commit ba45b35 addressing the audit findings.
Remediation Summary
Mint mismatch vulnerability
Fixed
Added strict mint and token address validation for SPL transfers.
Merkle root history DoS
Fixed
Root history expanded to 50 slots and minimum deposit introduced.
Relayer fee not paid for SPL withdrawals
Fixed
Withdrawal amount calculation corrected and relayer fee model adjusted.
Admin withdraw overreach
Fixed
Withdrawal accounting added to prevent abuse.
Unrestricted pool initialization
Fixed
Pool initialization authority moved to relayer logic.
Missing Merkle tree capacity check
Fixed
Leaf index bounds check added to prevent overflow.
Relayer griefing / missing authorization
Fixed
Relayer address verification added.
Root history window reduction
Fixed
Resolved as part of Merkle root handling improvements.
Double spend via failed refund vector*
Fixed
Admin refund vector removed, eliminating the exploit path.
Bit length constraint issue
Accepted
Requires circuit recompilation and new PoT ceremony.
Known Limitations and Design Tradeoffs
Trusted Setup (PTAU)
The current version of Mixoor uses an existing trusted setup configuration.
Performing a full multi-party Powers of Tau ceremony is planned for the final production version of the protocol. Due to the significant operational costs involved, this process is scheduled for the mature version of Mixoor once the protocol reaches production scale.
Administrative Withdrawal (Early-Stage Safety Mechanism)
In the current early-stage release, Mixoor includes a limited administrative withdrawal capability.
This mechanism exists strictly as a safety fallback during the initial testing phase of the protocol. In the unlikely event of a critical issue, it allows the team to recover user funds.
This functionality will be removed in the final non-custodial version of the protocol once the system has been fully validated in production.
Future versions will include:
Expanded circuit validation
Full multi-party trusted setup
Removal of administrative recovery mechanisms
Additional security reviews
Last updated