Miden: The Institutional Operating Layer

Table of Contents

1. Introduction: The Limits of Public-Ledger Transparency

2. Practical Privacy: A Third Path

3. Miden Guardian: The Operating Layer for Institutional Finance

4. Mainnet Transition and Ecosystem Expansion

5. Conclusion: What Miden Must Prove as Institutional Financial Infrastructure

 

 

1. Introduction: The Limits of Public-Ledger Transparency

Public blockchains allow anyone to inspect the same ledger and verify transaction validity. This openness and verifiability established the trust foundation for code-based transactions and DeFi services. When financial services operate on a public ledger, however, the data disclosed for verification creates a new source of risk. Addresses are pseudonymous, but balances, counterparties, transaction timing, recurring patterns, and fund flows continue to accumulate under those pseudonyms. Combining exchange deposit and withdrawal records, identity-verification information, and social data can connect even historical transactions to a specific person or company.

Payroll, supplier payments, corporate treasury activity, and the on-chain operations of financial institutions are also exposed to public-data risks. Payroll records can reveal organizational structures and compensation systems, while supplier payments can expose supply chains and cost structures. Movements from corporate treasury wallets can disclose liquidity conditions and investment plans. On-chain activity by financial institutions may also offer clues about customer relationships and product strategies. As public data accumulates, the attack surface for targeted attacks, front-running, customer information breaches, and competitive intelligence leaks expands.

Institutional finance requires privacy that combines confidentiality with verifiability. Financial infrastructure must protect customer and corporate information while allowing institutions to verify transaction validity, asset-transfer conditions, internal approvals, and compliance with regulatory requirements. It must also support recovery after failures and maintain consistent state across multiple participants. Miden addresses this challenge through practical privacy and introduces Guardian to connect the operation of private accounts with institutional workflows.

 

2. Practical Privacy: A Third Path

Miden's practical privacy model preserves the distributed verification and reliability of blockchains while providing the confidentiality and regulatory compatibility that institutions require. It reduces the amount of financial data exposed externally and gives authorized personnel and auditors a path to verify transaction validity and compliance.

2.1 Financial Data Exposure on Blockchains

Public blockchains allow anyone to inspect the same ledger and view the amount, timing, sender and recipient addresses, and fund flows associated with individual transactions. Addresses appear as strings instead of legal names, but transaction records remain available and continue to accumulate. This openness supports collective verification while also exposing the details of financial activity to outside observers.

Source: Arkham

On-chain analytics demonstrate how these records can be connected in practice. Arkham clusters multiple addresses into entities representing people, companies, and institutions, then tracks each entity's holdings, transaction history, and major counterparties. An address that initially appears anonymous can be labeled as an institutional wallet, and its fund flows can be mapped, once public information and recurring transaction patterns are combined.

Institutional on-chain activity exposes an even broader range of operational information. Corporate treasury wallets can reveal cash flows, counterparties, and investment plans, while asset managers' transaction histories can disclose positions and order strategies. Connections between financial-institution addresses and customer wallets can also expose customer relationships, product structures, and fund flows. This information can lead to targeted attacks, front-running, customer information breaches, and competitive intelligence leaks.

Institutional privacy therefore requires access rights to be divided according to operational roles. Transaction parties and responsible staff need access to the data required for execution. Asset issuers and service operators need to verify that assets moved under the prescribed conditions, while auditors and regulators need to review approval procedures and regulatory compliance. This information should remain hidden from external observers by default. Institutions must reduce public disclosure while preserving a verification path for authorized parties. Public blockchains without this access structure are difficult to use for core institutional financial operations.

2.2 Regulatory and Audit Gaps in Absolute Privacy

Absolute privacy removes public exposure of transaction amounts, counterparties, account state, and fund flows and therefore provides strong confidentiality. It still leaves institutions without the access path needed to verify required facts and preserve audit evidence.

Institutional transaction procedures include customer eligibility, sanctions screening, asset-specific transfer restrictions, and internal approvals. After a transaction, suspicious-transaction reviews, regulatory reporting, and financial and internal audits continue. When the parties authorized to access relevant information and the method of verification are undefined, proving regulatory compliance and accountability becomes difficult.

Institutional privacy must allow authorized staff and auditors to confirm that a transaction was permitted, received the required approvals, and satisfied customer and asset conditions without publicly disclosing the full transaction. Miden's practical privacy places this verification path between full transparency and absolute privacy.

2.3 Miden's Practical Privacy

Miden is a zero-knowledge Layer 2 that implements this form of institutional privacy. The account holder's device executes a transaction and generates a zero-knowledge proof. The network verifies the proof and state commitment without re-executing the transaction's full details. This structure reduces the public exposure of financial data while confirming that required policies and transaction conditions were satisfied.

Miden structures transactions around accounts and notes. An account holds assets, programs, and current state. A note carries assets and the conditions for receiving them between accounts. Accounts and notes can be public or private. In the private model, the network records a commitment, a cryptographic digest representing the complete state or note data, instead of specific information such as balances and counterparties. A zero-knowledge proof then demonstrates that the private data produced a valid state transition.

The Miden network can verify state-transition validity without seeing the full account state or transaction details. Xangle's earlier report, Miden: An Invisibility Cloak for Privacy for All, covers the broader technical architecture, including accounts and notes, the actor model, and client-side execution.

This architecture leaves the complete private-account state and note data with the account holder. It reduces public exposure but creates new operating requirements for institutions. Compliance and audit personnel need controlled access to required records, multiple devices and account participants must share the same latest state, and account operations must recover after device loss or failure. Guardian is Miden's off-chain service for closing these state-management and institutional-control gaps.

 

3. Miden Guardian: The Operating Layer for Institutional Finance

Guardian is an off-chain service for operating private accounts within institutional workflows. Institutional on-chain accounts are commonly managed by treasury staff, approvers, and administrators. When a transaction changes account state, every participant needs the same latest state before the next approval or transaction can proceed. Using outdated state can cause a transaction to fail, while an unshared update can stop a joint-approval process. Guardian stores a snapshot of the complete account state and each subsequent change so that multiple devices and account participants use the same latest state.

The client executes transactions and generates proofs, while the account commitment recorded on the Miden network determines the final state. Guardian operates between the client and network to maintain continuity of private state and support recovery after device loss or failure. Its functions cover account-state management, joint approvals, failure recovery, access controls, and audit records. The following sections explain the structure behind these functions.

3.1 Guardian's Management of Private Account State

The account holder's authentication key and account state serve different roles in a Miden private account. The key authorizes transactions, while account state stores assets, programs, and the data required for the next transaction. The network records only a commitment that identifies the latest state, so the complete account state remains with the account holder. Losing this data can prevent account operations from resuming even when the holder still has the key, and a transaction can fail when different devices or participants use inconsistent state.

Guardian reduces this state-management burden and manages one service key used in a 2-of-3 multisignature account. It backs up the complete state when an account is connected and then stores each delta generated by subsequent transactions. Multiple devices and co-signers use Guardian to share the latest state finalized by the network. If a device is lost or local data is damaged, the account can be restored from the stored record.

A Guardian-linked account can require any two signatures from the account holder's Hot Key, Cold Key, and Guardian service key. A transaction is normally approved by the Hot Key and Guardian key. If Guardian becomes unavailable or must be replaced, the account holder uses the Hot Key and Cold Key to retain control of the account. The Guardian key cannot move assets on its own.

A Guardian-assisted state change proceeds in five steps. ① The client executes the transaction locally and creates a delta. ② The account participant signs the delta containing the previous and new commitments and sends it to Guardian. ③ Guardian verifies the request authority and state continuity, co-signs the delta, and stores it as a candidate state. ④ The client submits the zero-knowledge proof and account update to the Miden network. ⑤ When the same commitment is confirmed on the network, Guardian finalizes the candidate and distributes the latest state to other devices and participants. If confirmation does not arrive within the required period or the commitments differ, Guardian discards the candidate and the client rebuilds the transaction from the latest state.

3.2 Compliance and Asset Controls

Guardian's role begins with maintaining account-state continuity, and the resulting authentication and change records form a foundation for regulatory compliance. Institutional accounts involve multiple staff members and approvers, making it necessary to identify who may read account state and request changes, and which approvals preceded an asset transfer. Guardian manages these procedures through account-specific request authentication, joint-approval proposals, and audit records.

When a staff member requests an asset transfer from a corporate treasury account, Guardian first verifies the requester's authority with account-specific authentication information. The authenticated request becomes a joint-approval proposal and is delivered to the signers together with the same account state. Once the required signatures have been collected, the transaction advances, while the process from request to approval and state change remains in the audit record. Guardian can pause the process when anomalous activity is detected, allowing the institution to align asset movements with internal approval procedures and review the full process afterward.

Guardian's capabilities are designed to expand across three phases. The current Phase I supports state backup, synchronization, recovery, and co-signing. Phase II plans to add daily outflow limits, execution delays for large transactions, emergency freezes in suspected fraud cases, and checks against regulatory conditions such as MiCA and OFAC requirements. These controls would operate at the co-signing stage, stop transactions that do not meet the required conditions, and preserve the applied rules and results as audit evidence. Phase III targets financial infrastructure in which banks and infrastructure providers operate Guardian as an institutional service. The concept also includes batching transactions from many users and netting flows within the same provider through ephemeral notes.

3.3 Miden Wallet: The User Entry Point

While Guardian manages account state and joint-approval flows, Miden Wallet is the interface through which users access these functions. Users create accounts and approve transactions in the wallet. The client behind it executes transactions locally, generates proofs, submits them to the network, and updates account state. When Guardian is connected, state backup and recovery, synchronization across devices, and joint approvals can be handled within the same wallet flow. Miden Wallet is currently available as a Chrome extension, allowing users to test account creation, transfers, and client-side proving on the public testnet. The extension is publicly available, while a production service based on mainnet remains in preparation.

Miden Wallet for institutions is being developed to combine complex client-side execution and Guardian integration into one user flow. When transaction approval, joint approvals, account recovery after device replacement, and alerts for transactions that conflict with internal rules are connected inside the wallet, institutions need fewer separate operating tools. Hardware-key integration and Guardian migration can also become part of this wallet flow.

As mainnet and Guardian capabilities mature, Miden Wallet can expand from a testnet wallet into an integrated interface for institutional private accounts. Users would retain control of their assets while handling transaction execution, proof generation, state recovery, and joint approvals through one interface. Miden's roadmap and partnerships are broadening the foundation required to connect this user experience with financial services.

 

4. Mainnet Transition and Ecosystem Expansion

4.1 Roadmap and Post-Quantum Readiness

Miden has added mainnet-related functionality across successive versions. v0.12 introduced routing for delivering private notes to recipients and added ECDSA signatures. v0.13 separated block production from proof generation to increase throughput, expanded the Rust environment for contract development, and extended Agglayer bridge functionality. v0.14 introduced private multisignature accounts for joint management and programmable assets that allow issuers to define transfer conditions.

As of August 2026, the protocol and development tools have reached v0.15, and users can test key functions through the public testnet and Miden Wallet. Miden continues to develop its bridge and fee systems and the operating environments for Guardian and Wallet as it prepares for mainnet service. The next step is to connect these components into a single production service and establish security audits, failure recovery, and service levels that meet institutional requirements.

Miden is also preparing for cryptographic risks that could emerge from quantum computing. A sufficiently capable quantum computer could break existing public-key cryptography such as ECDSA, creating risks of forged signatures and asset theft. Post-quantum cryptography is designed to remain secure against these attacks.

Miden uses STARKs based on the security of hash functions to prove transaction execution and applies lattice-based RPO-Falcon512 signatures to authorize transactions for default accounts. Neither method relies on the discrete-logarithm problem that a quantum computer can solve efficiently, giving the core proving and default authentication paths protection against long-term quantum-computing risks. Miden accounts may still use ECDSA signatures for compatibility with existing wallets, while bridges, wallets, and network communications rely on separate cryptographic technologies.

4.2 Partnerships

Miden has formed partnerships across development, identity, institutional finance, and Guardian operations as it expands its private financial infrastructure. Its major publicly announced partnerships include:

• Lambda Class: Jointly develops Miden-based applications and independent ventures.
• Billions Network: Supports privacy-preserving identity verification that can confirm user eligibility without disclosing complete identity information.
• KODA: Signed an MOU covering institutional custody and compliant on-chain finance in Korea.
• Fuze Finance: Supports enterprise adoption of digital asset services in the Middle East and emerging markets.
• OpenZeppelin, Lambda Class, and Gateway: Participate as the first group of Guardian operators, with OpenZeppelin also having participated in Guardian development and security assessment.

Miden continues to recruit institutions to operate Guardian after announcing its first group and is also seeking potential operators in Korea. Early operators will run Guardian directly, test state management, joint approvals, and failure recovery, and help refine future operating standards.

4.3 Potential Institutional Financial Applications for Miden

Miden's potential applications emerge in financial activities that require the confidentiality of financial data together with approval procedures, regulatory conditions, and operational recovery. Private accounts and notes reduce public disclosure, programmable rules define conditions for asset movement, and Guardian helps multiple participants share the latest state and approval flow. This structure supports several potential institutional financial applications.

The first is private treasury and asset management with joint approvals. Corporate treasury teams and funds need to protect balances, positions, counterparties, and disbursement timing while maintaining role-based approval procedures. Miden private accounts record a commitment instead of the complete state, while programmable accounts and private multisignature define the permissions and signature combinations for requesters, reviewers, and final approvers. Guardian distributes the same latest state and change proposal to shared participants and supports recovery after device loss or failure. Institutions can therefore apply existing segregation-of-duties and joint-approval procedures to on-chain asset management without exposing sensitive treasury information.

The second is confidential payments and payroll. When recurring transfers accumulate on a public ledger, amounts and timing alone can reveal paydays, suppliers, and recurring payment relationships. Miden private notes carry the payment asset and recipient conditions, while the network records only a commitment to the details. When the recipient satisfies the conditions and consumes the note, the network verifies transaction validity with a zero-knowledge proof. Future Guardian compliance and asset-control functions could bring sanctions and anti-money laundering checks, delays for high-value payments, and emergency freezes into the same approval flow. Application rules could also incorporate dispute resolution and legal freeze and recovery procedures.

The third is programmable assets and regulated financial products. Issuers can define investor eligibility, jurisdictional restrictions, holding and transfer conditions, and redemption procedures in asset and account rules. For example, only eligible-investor accounts may consume an asset note, or transfers to specified jurisdictions and redemption timing may be restricted. With privacy-preserving identity, users can prove required qualifications without disclosing complete identity information, while the network verifies execution without viewing the source information or transaction details. Future integration of Guardian's joint approvals and records of compliance checks could combine the confidentiality and distribution controls required for private-market assets, fund interests, and regulated stablecoins.

These three applications have not yet been implemented as production services. They represent institutional financial services that could be developed from Miden's technical and operating architecture. Production deployment requires applications and compliance procedures tailored to each workflow, along with stable processing of real assets and payment flows across Miden mainnet and Guardian.

 

5. Conclusion: What Miden Must Prove as Institutional Financial Infrastructure

Miden presents a third path that reduces the default disclosure of financial data while preserving the verifiability of a public ledger. Private accounts and notes, local execution, and client-side proving separate transaction data from verification information. Programmable accounts and assets provide a foundation for internal approvals, transfer restrictions, and regulatory conditions.

Guardian helps institutions operate this privacy model continuously and use it under regulatory requirements. State backup and recovery, synchronization across devices, and joint approvals are the core functions that connect private accounts with financial operations. If the planned compliance and asset-control capabilities are implemented, Guardian could combine confidentiality, operational controls, and auditability within a single workflow.

Several validation requirements remain. Miden's potential will become concrete when settlement, bridges, the fee system, and Guardian operate reliably within one environment after mainnet launch. Guardian must also demonstrate availability, data integrity, recovery, and migration procedures under real operating conditions.

Miden's next task is to connect development, identity, Guardian operations, and regional financial partners within a single service flow. As mainnet stability and Guardian operating experience accumulate, and as financial applications incorporating regulatory requirements are used repeatedly, Miden's practical privacy could take a more concrete form as institutional financial infrastructure.