> For the complete documentation index, see [llms.txt](https://mixoor.gitbook.io/mixoor/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mixoor.gitbook.io/mixoor/about/audits/inversive-labs.md).

# Inversive Labs

The audit was conducted by [Inversive Labs](https://inversive.xyz/), an independent security research team specializing in blockchain infrastructure and smart contract security.

Audit report:\
📄[ Inversive – Mixoor Security Audit (February 2026)](https://drive.google.com/file/d/1IjBuZsCFwA_xfeq9tLbGxfalRIeHPZkq/view?usp=sharing)

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

<table><thead><tr><th>Finding</th><th width="106">Status</th><th>Notes</th></tr></thead><tbody><tr><td>Mint mismatch vulnerability</td><td>Fixed</td><td>Added strict mint and token address validation for SPL transfers.</td></tr><tr><td>Merkle root history DoS</td><td>Fixed</td><td>Root history expanded to 50 slots and minimum deposit introduced.</td></tr><tr><td>Relayer fee not paid for SPL withdrawals</td><td>Fixed</td><td>Withdrawal amount calculation corrected and relayer fee model adjusted.</td></tr><tr><td>Admin withdraw overreach</td><td>Fixed</td><td>Withdrawal accounting added to prevent abuse.</td></tr><tr><td>Unrestricted pool initialization</td><td>Fixed</td><td>Pool initialization authority moved to relayer logic.</td></tr><tr><td>Missing Merkle tree capacity check</td><td>Fixed</td><td>Leaf index bounds check added to prevent overflow.</td></tr><tr><td>Relayer griefing / missing authorization</td><td>Fixed</td><td>Relayer address verification added.</td></tr><tr><td>Root history window reduction</td><td>Fixed</td><td>Resolved as part of Merkle root handling improvements.</td></tr><tr><td>Double spend via failed refund vector*</td><td>Fixed</td><td>Admin refund vector removed, eliminating the exploit path.</td></tr><tr><td>Bit length constraint issue</td><td>Accepted</td><td>Requires circuit recompilation and new PoT ceremony.</td></tr></tbody></table>

{% hint style="info" %}
\**This function is admin-gated and only executed following manual review and verification of the underlying refund request.*
{% endhint %}

### 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.

{% hint style="info" %}
Mixoor remains committed to transparency and continuous security improvements as the protocol evolves.
{% endhint %}

Future versions will include:

* Expanded circuit validation
* Full multi-party trusted setup
* Removal of administrative recovery mechanisms
* Additional security reviews