Q3 2026 Security & Compliance$1.18B stolen across 107 incidents. Main drivers: supply chain, smart contracts, keys.
Get the report →

Audit name:

[L1] Mina | Mina Guard | Aug2026

Date:

Oct 14, 2026

Table of Content

→Introduction
→Audit Summary
→System Overview
→Risks
→Findings
→Appendix 1. Severity Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Mina team for the collaborative engagement that enabled the execution of this Blockchain Protocol Security Assessment.

MinaGuard is a multisignature asset-management application built on Mina Protocol. It allows groups of owners to manage MINA through configurable approval thresholds and supports hierarchical SubVaults with independent governance. The product combines an o1js smart contract, a web client, a backend indexer, and an offline signing CLI for air-gapped approval workflows.

Document

NameBlockchain Protocol Review and Security Analysis Report for Mina
Audited BySofiane Akermoun
Approved ByTanuj Soni
Websitehttps://minaprotocol.com/→
Changelog16/09/2026 - Preliminary Report
13/10/2026  - Final Report
PlatformMina
LanguageTypeScript, o1js
TagsMultisig Wallet, Governance
Methodologyhttps://docs.hacken.io/methodologies/blockchain-protocols→

Review Scope

Repositoryhttps://github.com/zksecurity/mina-guard→
Commitd847b6bec2f971e42c6de58538da1e17c6b24bd4

Audit Summary

10Total Findings
10Resolved
0Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

{FindingsVulnSeverityStatusTable}

Documentation quality

  • The repository includes detailed security-model, contract-architecture, deployment, and offline-signing documentation.

  • The code is very well documented, and the critical parts are clearly explained.

Code quality

  • The codebase is generally well structured, strongly typed, and divided into contract, client, backend, and offline-signing components.

  • Security-critical logic is implemented correctly across the contract, web client, backend, and offline CLI.

Architecture quality

  • The RootVault/SubVault model and propose–approve–execute workflow provide clear separation between governance and execution.

  • The architecture relies heavily on a centralized event indexer for reconstructing security-critical state, creating availability and integrity risks for every client.

Test coverage

  • bun test --coverage reports 96.27% function coverage and 98.95% line coverage; branch coverage is unavailable.

  • Permission-vector validation, foreign-account preconditions, malicious prover inputs, indexer poisoning, client display consistency, concurrent workflows tests are provided..

System Overview

MinaGuard is a hierarchical multisignature vault system built on Mina Protocol. The system includes an o1js smart contract, a web client, a backend indexer, and an offline signing CLI.

Smart contracts The on-chain system is implemented by contracts/src/MinaGuard.ts. Each RootVault and SubVault is a separate deployment of the same MinaGuard zkApp contract. A RootVault has no parent, while a SubVault is bound to one RootVault; SubVaults cannot create further descendants.

The contract stores the owner commitment, approval threshold, proposal nonce, approval and vote-nullifier Merkle roots, parent relationship, and SubVault lifecycle state. Owners authorize content-bound proposals through signatures. Once enough approvals are recorded, a corresponding proven execute* method applies the operation.

LOCAL proposals govern the vault on which they are recorded. REMOTE proposals are recorded and approved on a RootVault, then executed on the designated SubVault. Supported operations include MINA transfers, owner and threshold changes, delegation, SubVault creation and funding, fund recovery, destruction, and enabling or disabling SubVault-local governance.

Web client and proving worker The web application handles vault creation, proposal review, wallet interaction, witness reconstruction, proof generation, and transaction submission.

Backend indexer The backend processes contract events and reconstructs vault ownership, proposals, approvals, execution status, and RootVault/SubVault relationships for the web client.

Offline signing CLI The CLI imports bundles exported by the web application, displays the operation to an air-gapped signer, reconstructs and proves the transaction, and returns a signed transaction for online submission.

Risks

Deployment integrity: Vault security depends on deploying the expected verification key, permission vector, and initial state. These values should be verified on chain before funds are deposited.

Deployment key handling: The zkApp account private key exists during deployment. Its generation, storage, transfer, and destruction require a defined operational procedure.

Protocol upgrades: A Mina hard fork may invalidate existing proofs or verification keys. Migration must be completed before activation if backward compatibility is not preserved.

Indexer dependency: The hosted application relies on an application-operated indexer. Outages, delays, or inconsistent indexed state may cause the interface to present stale information.

Offline signing: Air-gapped signers depend on transported bundles and the accuracy of the confirmation screen. Bundle provenance and integrity must be managed operationally.

Findings

F-2026-1929Vault Creators Can Retain Hidden Withdrawal Authority Outside the Multisig
Status
fixed
Severity

Critical
F-2026-1930Unbound Parent State Allows Permissionless Destruction of Any SubVault
Status
fixed
Severity

Critical
F-2026-1921Retained zkApp Account Key Can Bypass Vault Governance After a Transaction-Version Upgrade
Status
fixed
Severity

High
F-2026-1930Permissionless Vault Event Injection Can Poison Client State and Halt the Global Indexer
Status
fixed
Severity

High
F-2026-1926Unrecognized txType Can Rewrite the Offline Approval Screen While Signing a Transfer
Status
fixed
Severity

Medium
F-2026-1922Immutable Vaults Lack an Upgrade and Emergency Migration Lifecycle
Status
fixed
Severity

Medium
F-2026-1934CREATE_CHILD Approval Flows Omit the SubVault Governance Configuration
Status
fixed
Severity

Medium
F-2026-1926Pre-Creating a Vault Account Causes Its Deployment to Fail
Status
fixed
Severity

Low
F-2026-1930Unbound SubVault State Allows Invalid Remote Proposals and Approvals to Be Recorded
Status
fixed
Severity

Low
F-2026-1920Documentation Overstates Verification Key Immutability
Status
fixed
Severity

Observation
Code
―
Title
Status
Severity
F-2026-1929Vault Creators Can Retain Hidden Withdrawal Authority Outside the Multisig
fixed

Critical
F-2026-1930Unbound Parent State Allows Permissionless Destruction of Any SubVault
fixed

Critical
F-2026-1921Retained zkApp Account Key Can Bypass Vault Governance After a Transaction-Version Upgrade
fixed

High
F-2026-1930Permissionless Vault Event Injection Can Poison Client State and Halt the Global Indexer
fixed

High
F-2026-1926Unrecognized txType Can Rewrite the Offline Approval Screen While Signing a Transfer
fixed

Medium
F-2026-1922Immutable Vaults Lack an Upgrade and Emergency Migration Lifecycle
fixed

Medium
F-2026-1934CREATE_CHILD Approval Flows Omit the SubVault Governance Configuration
fixed

Medium
F-2026-1926Pre-Creating a Vault Account Causes Its Deployment to Fail
fixed

Low
F-2026-1930Unbound SubVault State Allows Invalid Remote Proposals and Approvals to Be Recorded
fixed

Low
F-2026-1920Documentation Overstates Verification Key Immutability
fixed

Observation
1-10 of 10 findings

Findings like these can secure your blockchain.

Appendix 1. Severity Definitions

Severity

Description

Critical
Vulnerabilities that can lead to a complete breakdown of the blockchain network's security, privacy, integrity, or availability fall under this category. They can disrupt the consensus mechanism, enabling a malicious entity to take control of the majority of nodes or facilitate 51% attacks. In addition, issues that could lead to widespread crashing of nodes, leading to a complete breakdown or significant halt of the network, are also considered critical along with issues that can lead to a massive theft of assets. Immediate attention and mitigation are required.

High
High severity vulnerabilities are those that do not immediately risk the complete security or integrity of the network but can cause substantial harm. These are issues that could cause the crashing of several nodes, leading to temporary disruption of the network, or could manipulate the consensus mechanism to a certain extent, but not enough to execute a 51% attack. Partial breaches of privacy, unauthorized but limited access to sensitive information, and affecting the reliable execution of smart contracts also fall under this category.

Medium
Medium severity vulnerabilities could negatively affect the blockchain protocol but are usually not capable of causing catastrophic damage. These could include vulnerabilities that allow minor breaches of user privacy, can slow down transaction processing, or can lead to relatively small financial losses. It may be possible to exploit these vulnerabilities under specific circumstances, or they may require a high level of access to exploit effectively.

Low
Low severity vulnerabilities are minor flaws in the blockchain protocol that might not have a direct impact on security but could cause minor inefficiencies in transaction processing or slight delays in block propagation. They might include vulnerabilities that allow attackers to cause nuisance-level disruptions or are only exploitable under extremely rare and specific conditions. These vulnerabilities should be corrected but do not represent an immediate threat to the system.
  • Severity

    Critical

    Description

    Vulnerabilities that can lead to a complete breakdown of the blockchain network's security, privacy, integrity, or availability fall under this category. They can disrupt the consensus mechanism, enabling a malicious entity to take control of the majority of nodes or facilitate 51% attacks. In addition, issues that could lead to widespread crashing of nodes, leading to a complete breakdown or significant halt of the network, are also considered critical along with issues that can lead to a massive theft of assets. Immediate attention and mitigation are required.

    Severity

    High

    Description

    High severity vulnerabilities are those that do not immediately risk the complete security or integrity of the network but can cause substantial harm. These are issues that could cause the crashing of several nodes, leading to temporary disruption of the network, or could manipulate the consensus mechanism to a certain extent, but not enough to execute a 51% attack. Partial breaches of privacy, unauthorized but limited access to sensitive information, and affecting the reliable execution of smart contracts also fall under this category.

    Severity

    Medium

    Description

    Medium severity vulnerabilities could negatively affect the blockchain protocol but are usually not capable of causing catastrophic damage. These could include vulnerabilities that allow minor breaches of user privacy, can slow down transaction processing, or can lead to relatively small financial losses. It may be possible to exploit these vulnerabilities under specific circumstances, or they may require a high level of access to exploit effectively.

    Severity

    Low

    Description

    Low severity vulnerabilities are minor flaws in the blockchain protocol that might not have a direct impact on security but could cause minor inefficiencies in transaction processing or slight delays in block propagation. They might include vulnerabilities that allow attackers to cause nuisance-level disruptions or are only exploitable under extremely rare and specific conditions. These vulnerabilities should be corrected but do not represent an immediate threat to the system.

Appendix 2. Scope

The scope of the project includes the following components from the provided repository:

Components in Scope

zkApp circuit **contracts/src/****

  • MinaGuard.ts

  • constants.ts

  • index.ts

  • list-commitments.ts

  • memo.ts

  • storage.ts

  • utils.ts

Air-gapped signer **offline-cli/src/****

  • build-tx.ts

  • index.ts

  • summary.ts

  • wasm-shim.ts

Browser signing TCB

  • ui/lib/multisigClient.worker.ts

  • ui/lib/multisigClient.ts

  • ui/lib/offline-signing.ts

Protocol dependency

  • ui/deps/o1js submodule (mina-signer)

Assets in Scope

Access Control - Access Control
Documentation - Documentation
Key Management - Key Management
build-tx.ts - build-tx.ts
Data Validation - Data Validation
mina-client.ts - mina-client.ts
multisigClient.worker.ts - multisigClient.worker.ts
offline-cli - offline-cli
page.tsx - page.tsx
useContractTxLock.ts - useContractTxLock.ts
indexer.ts - indexer.ts
routes.ts - routes.ts
proposal-record.ts - proposal-record.ts
offline-signing.ts - offline-signing.ts
summary.ts - summary.ts

Appendix 3. Additional Valuables

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer