For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

Finding
Status
Notes

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.

*This function is admin-gated and only executed following manual review and verification of the underlying refund request.

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.

Mixoor remains committed to transparency and continuous security improvements as the protocol evolves.

Future versions will include:

  • Expanded circuit validation

  • Full multi-party trusted setup

  • Removal of administrative recovery mechanisms

  • Additional security reviews

Last updated