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 | |
|---|---|
| Name | Blockchain Protocol Review and Security Analysis Report for Mina |
| Audited By | Sofiane Akermoun |
| Approved By | Tanuj Soni |
| Website | https://minaprotocol.com/→ |
| Changelog | 16/09/2026 - Preliminary Report |
| 13/10/2026 - Final Report | |
| Platform | Mina |
| Language | TypeScript, o1js |
| Tags | Multisig Wallet, Governance |
| Methodology | https://docs.hacken.io/methodologies/blockchain-protocols→ |
Document
- Name
- Blockchain Protocol Review and Security Analysis Report for Mina
- Audited By
- Sofiane Akermoun
- Approved By
- Tanuj Soni
- Website
- https://minaprotocol.com/→
- Changelog
- 16/09/2026 - Preliminary Report
- 13/10/2026 - Final Report
- Platform
- Mina
- Language
- TypeScript, o1js
- Tags
- Multisig Wallet, Governance
Review Scope | |
|---|---|
| Repository | https://github.com/zksecurity/mina-guard→ |
| Commit | d847b6bec2f971e42c6de58538da1e17c6b24bd4 |
Review Scope
- Commit
- d847b6bec2f971e42c6de58538da1e17c6b24bd4
Audit Summary
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 --coveragereports 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
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1929 | Vault Creators Can Retain Hidden Withdrawal Authority Outside the Multisig | fixed | Critical | |
| F-2026-1930 | Unbound Parent State Allows Permissionless Destruction of Any SubVault | fixed | Critical | |
| F-2026-1921 | Retained zkApp Account Key Can Bypass Vault Governance After a Transaction-Version Upgrade | fixed | High | |
| F-2026-1930 | Permissionless Vault Event Injection Can Poison Client State and Halt the Global Indexer | fixed | High | |
| F-2026-1926 | Unrecognized txType Can Rewrite the Offline Approval Screen While Signing a Transfer | fixed | Medium | |
| F-2026-1922 | Immutable Vaults Lack an Upgrade and Emergency Migration Lifecycle | fixed | Medium | |
| F-2026-1934 | CREATE_CHILD Approval Flows Omit the SubVault Governance Configuration | fixed | Medium | |
| F-2026-1926 | Pre-Creating a Vault Account Causes Its Deployment to Fail | fixed | Low | |
| F-2026-1930 | Unbound SubVault State Allows Invalid Remote Proposals and Approvals to Be Recorded | fixed | Low | |
| F-2026-1920 | Documentation Overstates Verification Key Immutability | fixed | Observation |
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:
Scope Details | |
|---|---|
| Repository | https://github.com/zksecurity/mina-guard→ |
| Commit | d847b6bec2f971e42c6de58538da1e17c6b24bd4 |
| Whitepaper | N/A |
| Requirements | https://github.com/zksecurity/mina-guard/tree/d847b6bec2f971e42c6de58538da1e17c6b24bd4/docs→ |
| Technical Requirements | https://github.com/zksecurity/mina-guard/tree/d847b6bec2f971e42c6de58538da1e17c6b24bd4/docs→ |
Scope Details
- Commit
- d847b6bec2f971e42c6de58538da1e17c6b24bd4
- Whitepaper
- N/A
Components in Scope
zkApp circuit **contracts/src/****
MinaGuard.tsconstants.tsindex.tslist-commitments.tsmemo.tsstorage.tsutils.ts
Air-gapped signer **offline-cli/src/****
build-tx.tsindex.tssummary.tswasm-shim.ts
Browser signing TCB
ui/lib/multisigClient.worker.tsui/lib/multisigClient.tsui/lib/offline-signing.ts
Protocol dependency
ui/deps/o1jssubmodule (mina-signer)
Assets in Scope
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.