Table of Contents

1. Privacy: The Missing Infrastructure Layer for Institutional Web3

2. The Architectural Limits of Legacy Privacy Chains

3. Miden’s Breakthrough: A New Architecture for Private and Scalable Execution

4. How Miden Achieves This: The Architecture Behind ZK-Native Privacy and Scale

5. A New Class of Applications Enabled by Miden

6. Closing Thoughts: Can ZK-Native Execution Become the Next Foundation Layer?

1. Privacy: The Missing Infrastructure Layer for Institutional Web3

With more than 590 million crypto holders worldwide, over 16 million exchange users in Korea, and the approval of Bitcoin and Ethereum ETFs, the surface-level indicators suggest Web3 may have already reached mass adoption. Yet true mass adoption only materializes when the vast liquidity held by traditional finance and institutional players begins flowing meaningfully into Web3 markets. That shift has not happened. Institutions and governments still face material barriers that prevent them from entering the ecosystem at scale.

Even the basic act of purchasing and holding crypto creates significant friction for institutions. Acquiring assets through centralized exchanges (CEXs) starts with a corporate account, which is an obstacle in itself. In Korea, corporate accounts only became available at select exchanges in 2025. Overseas, institutions must navigate stringent requirements including KYC/AML checks, ultimate beneficial ownership (UBO) verification, and explicit documentation of trading intent before an account can be opened. Even after onboarding, building sizable positions introduces market impact risks that make desired execution prices difficult to achieve, while the trading activity itself becomes visible to the market.

https://x.com/arkham/status/1969111431426592944?s=20

Shifting to decentralized exchanges (DEXs) offers no simple alternative. A fully on-chain architecture means that all trade data is public, and large orders trigger even more severe slippage and volatility than on CEXs. Operational and regulatory burdens—wallet management, key custody, network fees—add another layer of complexity that most institutions are structurally unequipped to handle.

The absence of institutional-grade custody, accounting, and trading infrastructure further compounds the issue. Deploying billions of dollars directly on-chain remains impractical. Accordingly, many financial institutions in the U.S. and Europe continue relying on indirect exposure—ETFs, structured trust products—rather than directly holding or transacting in crypto assets.

Regulatory and operational gaps alone do not explain the full story. A deeper issue lies in the radical transparency of on-chain environments, which makes it difficult for institutions to satisfy risk-management requirements and legal obligations simultaneously. Because all transactions are publicly visible in real time, institutional portfolio adjustments risk exposing trading strategies, total asset size, and even client-related activity. This visibility stands in direct conflict with strict financial-privacy and data-protection regimes such as GDPR and AML/KYC.

The structural limitation is clear: blockchains operate as public ledgers with no privacy. For institutions to enter Web3 in a meaningful way, the infrastructure must provide privacy guarantees that preserve transactional integrity while satisfying compliance and security mandates. Privacy, therefore, is not a secondary feature; it is the foundational prerequisite for institutional capital to operate on-chain.

Transparency remains one of blockchain’s core virtues, enabling trust in decentralized systems. Yet for institutions, that same transparency translates into privacy leakage and security vulnerabilities. Three problems emerge in practice:

1) The dilemma between compliance and data protection

Institutions must safeguard client identities and transaction details when managing or holding assets on behalf of clients. Under GDPR and other financial-data protection frameworks, any leakage of customer information can result in significant legal sanctions. Blockchains, however, record every transaction on a publicly visible ledger. Operating directly on-chain therefore places institutions in immediate regulatory jeopardy. To deploy client capital on-chain while maintaining transaction integrity, institutions need a privacy-preserving infrastructure that keeps sensitive information confidential.

2) The paradox where protecting privacy is itself considered a regulatory violation

Efforts to preserve privacy can trigger the opposite problem. When institutions employ privacy chains or mixer services to shield transaction flows, regulators may interpret that behavior as a breach of anti-money laundering (AML) requirements. Major privacy assets such as Zcash and Monero have already been delisted from major EU and U.S. exchanges, and Tornado Cash was sanctioned by the U.S. Treasury’s OFAC, resulting in service shutdowns and even criminal charges against its developers. Institutions are effectively trapped in a structural paradox: revealing data risks regulatory violation, while hiding data risks regulatory violation.

3) Market-level risk from position exposure

A further dimension of risk emerges at the market level. Institutions that open large on-chain positions reveal their trades in real time, making them prime targets for adversarial strategies. Traditional finance mitigates this through dark pools or OTC trading, where order flow and trade intent remain confidential. On-chain environments lack such protections; timestamps, amounts, and addresses remain fully transparent.

https://x.com/lookonchain/status/1928259143120630038?s=20

A concrete example occurred in May 2025 on Hyperliquid’s futures market, when a well-known trader, Wynn, disclosed his position and was subsequently hit by a coordinated liquidation attack from large short sellers. The incident illustrates how easily on-chain transparency erodes information asymmetry and enables market manipulation.

Balancing privacy protection with regulatory compliance is not optional for institutions, it is foundational. Progression into a next-generation institutional Web3 ecosystem depends on establishing a privacy layer that is both lawful and auditable.

Despite many attempts, existing privacy chains and dApps have struggled to achieve institutional trust due to limitations in scalability, interoperability, and governance. Miden is explicitly designed to address and overcome the structural shortcomings inherent in both traditional blockchains and earlier privacy-focused architectures.

2. The Architectural Limits of Legacy Privacy Chains

Existing privacy chains have made meaningful attempts to strengthen transaction anonymity and privacy guarantees, but significant limitations remain in finality, execution models, and interoperability.

2-1. The Scalability–Privacy Trade-Off

Privacy chains rely on computationally intensive cryptographic techniques, such as zero-knowledge proofs (ZK), MPC, and FHE, to conceal user information and transaction details. These techniques deliver strong privacy guarantees, yet they also increase transaction size and elevate the computational burden required for block production and verification. The result is a structural limit on scalability.

Zcash illustrates this constraint clearly. Built as a Bitcoin fork with zk-SNARK–based shielded transactions layered on top, Zcash retains Bitcoin’s conservative consensus parameters (2MB block size, 75-second block time) while carrying the additional proving overhead of ZK cryptography. Under this architecture, increasing block size or meaningfully reducing block time is infeasible. Consequently, real throughput remains around 5–6 TPS when operating primarily with shielded transactions, and only about 20 TPS even when public transactions are included. Zcash demonstrates how enhancing privacy directly translates into restricted scalability.

Monero, which adopts privacy as a default property, runs into a similar bottleneck. Its combined use of ring signatures, RingCT, and Bulletproofs+ delivers strong anonymity but simultaneously enlarges transaction data and intensifies verification costs. With a fixed block time of 120 seconds, throughput is structurally constrained. Average network statistics, 70–80KB block size and roughly 2KB per transaction, mean that only a few dozen transactions fit into a single block, translating to an effective throughput of roughly 0.2–0.4 TPS. Monero’s dynamic block-size model theoretically allows higher throughput, but verification overhead and stability concerns prevent meaningful scaling on mainnet. These constraints naturally cause fees to rise during periods of congestion.

Taken together, stronger privacy invariably amplifies execution costs and reduces processing speed. Existing privacy chains have been unable to fully escape this structural trade-off between privacy intensity and performance.

2-2. The Functional Limits of Transfer-Only Privacy Chains

https://x.com/sandeepnailwal/status/1985748281314669053?s=20

Polygon CEO Sandeep recently noted that “If Zcash is private Bitcoin, Miden is private Ethereum,” a comparison that captures a long-standing limitation of most privacy chains: the design focus has overwhelmingly centered around simple value transfers. Zcash, for instance, is built as a fork of Bitcoin and thus lacks a native smart contract execution environment, making it ill-suited for handling complex on-chain logic. The high computational cost of shielded transactions further slows execution and increases fees. As a result, Zcash delivers strong privacy but functionally operates as little more than a “private version of Bitcoin.”

Miden introduces a fundamentally different model. Its architecture supports on-chain smart contract execution while maintaining privacy, enabling far more than basic asset transfers. Developers can implement sophisticated application logic within a fully private environment, expanding the design space for DeFi, payments, and other advanced use cases. This positions Miden as a new category of privacy-enhancing infrastructure; one that unifies strong privacy guarantees with general-purpose smart contract capabilities, a combination that earlier privacy chains were unable to offer.

2-3. Centralized Execution Dependencies Undermining Privacy

Many privacy chains incorporate centralized components—relayers, trusted setups, or centralized key-management schemes—to deliver privacy functionality. These elements simplify early implementation but introduce structural weaknesses that eventually erode both the trustworthiness of the network and the effectiveness of its privacy guarantees.

https://home.treasury.gov/news/press-releases/jy0916

Tornado Cash illustrates this risk clearly. Its anonymous-transfer mechanism depended on relayers, intermediary executors responsible for submitting withdrawal transactions on behalf of users, shielding their wallet addresses in the process. After OFAC sanctions in the United States, frontend access was blocked and relayer activity diminished sharply, degrading both usability and accessibility. The episode demonstrates how any centralized component embedded within a privacy system becomes a single point of pressure: external enforcement can cripple functionality overnight.

Centralized execution models also create an additional privacy failure mode. When a separate party is responsible for re-executing user transactions, even partial leakage of transaction details becomes possible, fundamentally contradicting the goals of a privacy-preserving chain.

Miden avoids this category of vulnerability entirely. Transactions are executed locally by users, and only ZK proofs of correct execution are submitted to the network. No validator, sequencer, or intermediary ever re-executes the transaction, and no party gains visibility into the underlying data. The architecture allows Miden to achieve privacy, decentralization, and scalability simultaneously, without the inherent trade-offs that centralized execution models impose.

2-4. The Interoperability Gap in Legacy Privacy Architectures

Most privacy chains operate as standalone L1s or appchains, which leaves them largely isolated from the broader ecosystem. Assets and transaction data generated within these chains cannot move freely to networks such as Ethereum or Polygon, creating a structural disconnect between privacy and liquidity. The consequence is clear: users gain privacy only by sacrificing usability, liquidity depth, and ecosystem reach.

Miden removes this limitation at the architectural level through integration with Agglayer. Its combination of client-side execution and ZK-proof–based validation preserves privacy while still allowing direct connectivity to major Web3 ecosystems, including Ethereum. This approach eliminates the isolation problem that has long burdened privacy chains and enables both privacy and interoperability to coexist natively.

In effect, Miden introduces an architecture where finality, decentralization, liquidity, and interoperability reinforce, rather than contradict, one another. Traditional privacy-first chains were forced to abandon several of these properties as the price of privacy; Miden shows that the full set can be achieved simultaneously.

3. Miden’s Breakthrough: A New Architecture for Private and Scalable Execution

Numerous privacy chains have launched over the past decade, yet none have meaningfully unlocked institutional adoption. Earlier sections outlined the structural limitations of existing solutions, such as constraints in finality, execution models, and interoperability. Miden enters as a new ZK-native Layer 2 built to address these shortcomings at the architectural level. Backed by robust technical foundations and an innovative model known as Client-side Execution, Miden aims to deliver privacy and scalability simultaneously. This section examines the key differentiators that enable that goal.

3-1. Team, Technology, and Polygon’s ZK Advantage

Miden originated as a ZK-based privacy Layer 2 incubated within Polygon Labs, evolving from technology initially developed inside the broader Polygon ecosystem into a standalone platform. After spinning out through Polygon’s Agglayer program, the project secured $25 million in Seed funding led by tier-1 venture firms including Andreessen Horowitz (a16z crypto), 1kx, and Hack VC.

Polygon today maintains one of the industry’s most comprehensive ZK stacks. The ecosystem has acquired and integrated multiple ZK projects—including zkEVM, Mir, and Miden, allowing it to support fast proving, high scalability, and privacy. Its in-house proving systems, Plonky2 and Starky, underpin efficient ZK rollups; Plonky2 remains one of the fastest recursive proving systems in the market and powers both Polygon’s zkEVM and Miden.

The team behind Miden is equally notable.Co-founder Azeem Khan previously led ecosystem expansion and business strategy at Polygon Labs, and later co-founded the Layer 2 project Morph, serving as COO. He now oversees operations and partnerships at Miden, driving ecosystem and commercialization strategy.

Technical development is led by Bobbin Threadbare, formerly an engineer in Facebook (Novi)’s cryptography research division, where he worked on systems related to the Move VM and ZK-STARKs. He now architects the MidenVM and STARK prover, shaping the project’s technical direction.

The result is a team anchored by veterans from Meta, Polygon, and other major technology and blockchain organizations; supported by a deep bench of ZK experts. Strong talent, strong investors, and strong underlying technology form one of Miden’s most compelling advantages.

3-2. Four Levels of Privacy

Privacy in blockchain can generally be framed across four levels.

Level 0 represents the default state of most blockchains today, where no privacy exists. Transparency is treated as a core property of the system, meaning every piece of information recorded on-chain is visible to everyone. As noted earlier, this absence of privacy has become one of the most significant barriers preventing genuine Web3 mass adoption, especially for institutions.

Level 1 corresponds to the baseline privacy provided by banks, card companies, and payment processors. When a customer sends funds or completes a payment, only the two parties involved—and the intermediaries such as banks or payment networks—can see the transaction details. No one else has access to that information.

Level 2 describes transactions where only the transacting parties themselves can know the details. A real-world analogy is a face-to-face cash payment: only the buyer and the seller are aware of the exchange, and the information is not recorded anywhere outside their personal ledgers.

Level 3 represents the strongest form of privacy: users can see only their own data. Even when a transaction occurs, the recipient cannot identify who the sender was. Users know only the transactions they have sent or received, and only their own asset state. This paradigm, where each individual has exclusive visibility and control over their own data, is the ultimate privacy model that Miden aims to achieve.

3-3. Client-Side Execution

Achieving the Level 3 privacy model that Miden targets is fundamentally impossible under the traditional on-chain execution paradigm used by existing blockchains. Networks such as Bitcoin and Ethereum execute every transaction directly on-chain, exposing both the execution process and its results to the public. Anyone can inspect this data, and on-chain analytics platforms like Arkham and Chainalysis augment it with off-chain intelligence to map addresses to real-world identities and reveal capital flows. The consequence is a structural privacy failure where not only balances and transaction histories, but also users’ strategic behaviors, become observable.

The root cause lies in the requirement that every node must execute and verify every transaction. Execution traces are exposed by design, eliminating privacy, and the serialized processing model imposes hard limits on throughput and cost efficiency. Network congestion leads to execution bottlenecks and spikes in gas costs; symptoms inherent to this architecture.

Parallel-execution chains such as Solana, Sui, and Aptos alleviate some of the performance and cost pressure, yet they do not address the privacy flaw: nodes still inspect and execute user transactions directly, meaning privacy remains unattainable.

Miden reconstructs this execution model entirely. Instead of having the network execute user transactions, Miden shifts execution to the user’s device through its Client-Side Execution architecture. Users run their transactions locally, generate the corresponding ZK proof, and submit only that proof to the network. Validators simply verify the proof rather than re-executing the underlying logic. This design delivers both the scalability benefits of parallelism and strong privacy guarantees.

A closer look highlights how radically this differs from the traditional flow. Historically, the transaction pipeline followed:

[User creates transaction → Network executes → Network verifies → Block produced]

Miden replaces the execution stage entirely with local processing:

[User creates transaction → Executes locally → Generates ZK proof locally → Network verifies only the proof → Block produced]

Execution and proving occur on the client side, while the network merely checks proof validity before including the transaction in a block. Nodes no longer inspect user transactions or view the raw state transitions they produce. Only the ZK proof—asserting that “this transaction was executed correctly”—is visible.

This architecture delivers two fundamental advantages:

• Scalability
  • The most computationally intensive component of transaction processing, execution, is offloaded from the network to individual users, dramatically reducing node workload.
  • With the network responsible only for proof verification, TPS increases substantially.
• Privacy
  • Users retain all execution data locally, exposing only commitments and ZK proofs to the network.
  • No disclosure of which data was accessed or which logic was executed is required.

The result is a system that achieves what conventional blockchains could not: meaningful scalability and strong privacy at the same time. By redesigning the execution model from first principles, Miden resolves a structural limitation fundamental to earlier blockchain architectures.

4. How Miden Achieves This: The Architecture Behind ZK-Native Privacy and Scale

Miden achieves simultaneous privacy, scalability, and interoperability through client-side execution because it abandons the legacy blockchain paradigm in which every node re-executes every transaction. In its place, Miden introduces a fundamentally different state model built on three pillars: off-chain execution, on-chain verification, and minimal state commitments.

To realize this architecture, Miden adopts an Actor model, integrating three core components—Accounts, Notes, and Agglayer—to construct an entirely new category of Layer 2.

At the heart of Miden’s design, the Actor model has long been a foundational paradigm for scaling parallel and distributed systems. Each independent entity (an “Actor”) maintains its own state and communicates with others strictly through message passing. An Actor cannot directly modify another Actor’s state; any influence must be mediated through messages.

This separation of state removes the need to globally order all transactions or to merge state into a single monolithic structure. As a result, actors can execute independently, enabling true parallelism.

In Miden, an Account, functionally similar to a wallet address, serves as the Actor. Each Account maintains its own state, code, and storage privately; only the owner can view or modify it. Communication between Accounts occurs through Notes, which follow a UTXO-inspired design.

4-1. Accounts and Notes: The Core State Primitives

Accounts and Notes are structured as follows:

An Account consists of: ID, Nonce, MidenVM code, Storage, and Assets.

• ID — A unique identifier for the account. It enables tracking of ownership and state transitions.
• Nonce — A sequential counter preventing replay attacks. It increases with each processed transaction, ensuring correct ordering.
• MidenVM code — The logic associated with the account, executed within MidenVM. It defines permissions, verification behavior, and state-transition rules.
• Storage — The persistent state tied to the account, stored as key–value data. This contains the long-term state of the contract.
• Assets — The asset list held by the account. It can include FT, NFT, and custom asset types.

A Note consists of: Script, Inputs, Serial Number, and Assets.

• Script — The execution logic validated when the Note is consumed. It defines who may consume the Note and under what conditions.
• Inputs — The parameters supplied when running the Script. They support signature checks, condition validation, and domain-specific logic.
• Serial Number — A unique value derived upon consumption. It prevents double-spending by ensuring each Note can be used only once.
• Assets — The assets held within the Note. Assets move from an Account into a Note and return to an Account once the Note is consumed.

4-2. Transaction Flow in Miden: Local Execution, On-Chain Verification

The way transactions are generated and processed in Miden differs fundamentally from traditional L1s and existing L2s. The comparison below highlights the distinction:

• L1: The user directly sends a transaction to Ethereum.
• L2: The user sends the transaction to the L2; the L2 executes and batches user transactions, generates a ZK proof, and submits the proof upstream.
• Miden: The user executes the transaction locally, generates the ZK proof locally, and sends only the proof and commitments to the L2. The L2 then aggregates these proofs into a final batch proof.

On L1, user transactions are exposed in raw form, offering no privacy. Because every transaction must be executed and stored directly on-chain, scalability remains fundamentally constrained. Existing L2s improve L1 privacy by submitting only proofs upstream; however, their sequencers still see all user transactions because they execute and validate them directly. As a result, full transaction visibility persists at the L2 operator level.

Miden eliminates this visibility entirely. Users execute their transactions locally and submit the resulting ZK proofs themselves. Even the operator of the L2 cannot see the underlying transaction contents. The network’s only responsibility is verifying proofs, which significantly improves scalability.

A more detailed look at the transaction flow in Miden is shown below:

1. User A holds 100 ETH and wants to send 10 ETH to User B.

2. User A generates a Note representing “Send 10 ETH to B” and executes this transaction locally. During this process, A updates their account state and generates a ZK proof confirming that the Note and state transition were handled correctly.

3. User B executes a local transaction consuming A’s Note and receives the 10 ETH. B updates their own account state locally and generates a ZK proof for this consumption event.

All transactions created by A and B, along with their ZK proofs, are then submitted to the Miden network. Validators verify the proofs without ever seeing the underlying Note data—such as transfer amounts or recipient addresses. As a result, only A and B know the actual contents of the transaction. This encapsulates the essence of Miden’s Client-side Execution model.

https://github.com/0xMiden/miden-vm, Execution / Proof Generation Time on a Single Core

Both transaction execution and ZK proof generation run on the user’s local hardware (CPU/GPU). In a typical single-core PC environment, execution itself completes in under one second, while proof generation takes roughly three seconds on average. As transaction complexity increases, the computational load rises, and proof-generation time expands accordingly.

Miden continues optimizing the system to ensure that transactions can be generated smoothly even on mobile devices. Proof generation on mobile currently takes about twenty seconds, and the goal is to reduce this to approximately five seconds by mainnet.

To further improve the user experience, Miden also offers a Delegated Proving option, which allows users to outsource proof generation to an external server. With this mode, overall latency drops to under one second. In this case, the user relinquishes some privacy only with respect to the proving server, while privacy remains fully preserved against the network and all other users.

4-3. Agglayer as the Connectivity Layer for Privacy-Preserving L2s

Miden operates on Polygon’s Agglayer. Agglayer serves as a unifying layer that aggregates ZK proofs generated by multiple L2s and appchains into a common network, enabling heterogeneous chains to interact as seamlessly as if they belonged to a single system.

Launching Miden on Agglayer provides a crucial advantage: despite being a privacy-preserving L2, it natively gains direct connectivity to Ethereum and the broader L2 ecosystem. This design sidesteps the “liquidity isolation” problem that has historically constrained privacy chains and allows Miden to absorb initial liquidity from Agglayer, significantly reducing liquidity fragmentation.

Because all Miden transactions are executed locally and only ZK proofs and state commitments are posted on-chain, Agglayer is able to guarantee global state coherence. Commitments generated on Miden can be merged with state transitions from other chains without conflict. The architectural responsibilities are cleanly divided: Miden provides privacy and scalability, while Agglayer provides interoperability and liquidity routing.

https://x.com/Agglayer/status/1981345330777247933?s=20

A total of 18 chains are currently connected or slated for integration with Agglayer, including Polygon PoS, Katana, X Layer, and IoTeX, with Sentient and LitecoinVM scheduled to join soon.

This connectivity prevents Miden from becoming isolated from the broader ecosystem; an issue that has historically limited usage of privacy-focused L1s. Workflows where privacy-sensitive logic executes on Miden while public-facing operations run on other L2s become seamless. In effect, Miden does not function as a “closed privacy chain” but rather as a privacy execution layer integrated into the entire Agglayer network. This architecture allows Miden to overcome the structural isolation and fragmentation that constrained earlier generations of privacy chains.

4-4. Developer Experience: Why Rust + MidenVM Expand the Design Space

Miden is built not on the EVM but on its own virtual machine, MidenVM, and therefore uses Rust rather than Solidity as its primary development language. The decision to depart from the EVM and adopt a custom VM rests on two core reasons.

First, the EVM is fundamentally inefficient for generating ZK proofs.

The EVM was never designed with zero-knowledge proving in mind, and its execution architecture aligns poorly with the constraints of ZK systems. Proving EVM transactions requires substantial computational overhead, causing proof-generation time to increase sharply. Because Miden’s core model depends on users executing transactions and generating proofs directly on their own devices, PC or mobile, this workflow is practically infeasible within an EVM environment. MidenVM, by contrast, is designed from first principles for ZK proving. Its architecture is optimized for client-side execution and local proof generation, making these operations efficient and naturally integrated into the system.

Second, Miden aims to provide an unconstrained development environment and a superior developer experience.

Rust provides memory safety, a robust type system, high performance, and a rich library ecosystem—qualities that make it exceptionally well-suited for complex application development and ZK-centric logic. MidenVM aligns tightly with Rust’s structural strengths, enabling developers to write safer, more predictable code. Without the limitations inherited from the Solidity/EVM execution model, Miden offers a far more flexible and expressive developer experience.

This design choice comes with an explicit trade-off: existing EVM-based dApps cannot be ported directly onto Miden. As a result, Miden must develop its own native application ecosystem from scratch. The team has intentionally chosen long-term innovation over short-term compatibility, prioritizing the full realization of ZK’s potential and the expansion of a new design space rather than inheriting constraints from the EVM. By foregoing EVM compatibility, Miden gains the freedom to construct an execution environment tailored specifically for ZK-native architectures, positioning itself as a platform optimized for the next generation of decentralized applications.

5. A New Class of Applications Enabled by Miden

Miden’s client-side execution model and its Note-based Actor architecture unlock categories of on-chain applications that were either extremely difficult, or structurally impossible, to build on traditional blockchain designs. The benefits are most pronounced in financial applications that simultaneously require privacy, scalability, deterministic execution integrity, and MEV resistance. The following sections examine how Miden’s design fundamentally improves these application classes.

5-1.Private Payments: Native Confidential Transfers

1-to-1 Payments

A 1-to-1 payment in Miden is executed entirely on the client side. The user updates their Account state locally and submits only a ZK proof of correct execution to the network. Balance deductions, recipient validation, and Note creation occur according to the Account’s code, all within the user’s local environment. On-chain, only a commitment and a proof verifying correctness are recorded. As a result, no sensitive information, such as who sent funds to whom, how much was transferred, what each Account’s balance is, is ever exposed. Because each Account operates independently and in parallel, high transaction volumes do not create bottlenecks. Gas handling and key management can be abstracted away inside the application layer, enabling a payment user experience comparable to Web2 fintech apps.

For example, suppose A wants to send 1 ETH to their friend B. A runs, in their local environment, the execution that says “subtract 1 ETH from my wallet and deliver it to B,” and this process produces a digital envelope (Note) that only B can open. A then sends this envelope to B, and B opens it locally to update their balance from 0 ETH → 1 ETH. On-chain, the only information recorded is a proof showing that “the envelope created by A was valid and B received it correctly”; none of the underlying details, such as who sent funds to whom, or how much was transferred, are exposed. As a result, A and B can move assets quickly and safely, similar to using a familiar remittance application, without revealing their transaction histories or balances. Because each account executes independently and in parallel, and without interfering with others, even large numbers of simultaneous transfers do not congest the network or force it to process transactions sequentially.

1-to-N Payments

1-to-N payments work by generating multiple digital envelopes (Notes) in a single execution. The sender runs, in their local environment, the logic that says “divide my balance among N recipients by these respective amounts,” and this execution produces several Notes, each corresponding to a specific recipient. After this step, the sender submits only a single ZK proof to the network verifying that the execution was processed correctly. Privacy is particularly important in this context, because in situations such as corporate payroll or reward distribution, exposing individual payment amounts or recipient identities would directly reveal sensitive information. With Miden, large-scale transfers can be executed without exposing any underlying payment details, enabling both individuals and organizations to manage payments far more safely.

For example, suppose a company wants to pay salaries to 1,000 employees. On a traditional public blockchain, the company would need to submit 1,000 separate transactions, and in the process every employee’s salary amount and wallet address would become publicly visible. This not only exposes internal corporate information but also reveals highly sensitive personal financial data.

In Miden, the company’s Account performs a single local execution that generates 1,000 salary Notes, and on-chain only one ZK proof and a single commitment remain, stating that “the total payment amount was deducted and all Notes were created correctly.” Employees then consume their respective Notes locally to update only their own balances. If the company later needs to undergo an audit or regulatory review, it can selectively provide a ZK proof confirming that the payroll was executed correctly—without disclosing any individual employee’s information.

5-2. Private DeFi: Confidential Orderflow & Perpetual Markets

Private Orderbook DEX

In Miden, each order is represented as a Note. A user creates a Note locally with the conditions specifying “how much I want to buy or sell at what price,” and posts it to the orderbook. By default, Notes submitted to the orderbook are public. Users who prefer not to disclose their orders can leverage an Obfuscation layer that relays orders on their behalf. The layer submits the order without exposing the user’s Note directly, allowing order updates while fully hiding the user’s wallet address and order details. This mechanism enables private trading without revealing price levels, order sizes, or strategic intent.

For example, suppose trader A submits a limit order stating “Sell 1 ETH for 3,000 USDC.” A creates a Note with these conditions locally and posts it to the orderbook. If trader B wants to execute the order, they run a local execution that says “consume this Note,” and then submit the corresponding proof, completing the trade. Fast and low-cost order updates become possible under this structure, and when necessary, users can maintain full privacy over their orders by relying on the Obfuscation layer while still trading entirely on-chain.

Private Perpetual Markets

In Miden, each perpetual market is implemented as a single Account, and participants open, close, or adjust positions via Notes. Position modifications, funding payments, and liquidation logic are all defined within the Account’s code. Users update their positions by executing the relevant logic locally and generating proofs. The network never sees position sizes, leverage, or liquidation risk; it only verifies whether the Perp Account’s state transition adheres to the rules defined in its code. Even during heavy trading activity, the operator can batch hundreds of position adjustments into one local execution and submit a single proof, resulting in extremely high scalability. When the Market Account is configured as private, only a commitment of the global market state is posted on-chain, while the positions of individual participants remain hidden.

For example, in a BTC perpetual market, A expects the price to rise and deposits 1,000 USDC to open a long position, while B expects a decline and deposits 1,000 USDC to open a short. Each user generates the relevant Notes by executing the position-opening logic locally, and the Perp Account consumes these Notes to update the overall market state. When the price later moves and funding payments must be exchanged, the operator can process hundreds of position changes and funding settlements in a single local execution and submit only one proof. External observers see only that “the Perp Market updated positions according to its rules,” without gaining any insight into which participant holds which position or how large those positions are.

5-3. Private Multisig Treasury

In Miden, a Treasury is not a simple wallet; it is implemented as a private smart account that embeds an organization’s asset-management policies directly into code. The Treasury Account defines rules in MidenVM such as “large expenditures require approval from at least two signers,” “certain assets cannot be withdrawn before 30 days,” and “any spending that exceeds the monthly budget cap is automatically rejected.” Every spending action initiated from this account must pass these rules before a Note can be created or consumed. Users construct spending transactions by executing the Treasury’s code locally and then submit a ZK proof verifying that the execution adhered precisely to the defined policies.

Because account states in Miden are fully private, multisig participants cannot directly view each other’s latest state. This creates uncertainty around questions such as “which proposal is currently active,” “who has already signed,” or “whether the state I’m seeing is the latest version.” To address this, Miden introduces a system under development called PSM (Private State Management), an off-chain layer that safely synchronizes the essential state and transaction information among signers. By using PSM, signers can share the same state without exposing sensitive details externally and can carry out the multisig approval workflow correctly.

For example, suppose a company creates a Treasury on Miden with a 2-of-3 multisig rule and a daily spending limit of 50,000 USDC. If it needs to pay 20,000 USDC for operating expenses, the three signers first use PSM to confirm that they are all viewing the same latest state. Once this is verified, one signer submits a spending proposal, and two signers review and approve it locally, adding their signatures. After two signatures have been collected, PSM submits a ZK proof to the network showing that the approval followed the Treasury policy exactly. On-chain, only the facts “two signers approved” and “the spending did not exceed the daily limit” are recorded. The actual payment details remain private.

Beyond these representative cases, many other applications, such as identity verification or voting, are possible, and the nature of blockchain ensures that anyone can build innovative decentralized applications on top of Miden.

6. Closing Thoughts: Can ZK-Native Execution Become the Next Foundation Layer?

Miden introduces a new execution environment that brings together privacy, scalability, and smart contracts, yet it also faces challenges. The most significant among them is regulation. A network offering complete anonymity is likely to encounter friction with regulatory frameworks and creates substantial hurdles for early operations and adoption. While interpretations of privacy regulation have shifted gradually, such as partial easing of the restrictions on Tornado Cash blacklists, clear standards remain absent. Under these conditions, launching a new network as a “fully private chain” from the outset carries considerable risk.

User experience introduces another layer of difficulty. Because Miden executes all logic and generates ZK proofs locally, mobile environments may experience noticeable latency. The team aims to reduce proof-generation time, from roughly 20 seconds today to around 5 seconds by mainnet, and lessen UX friction by offering a delegated proving option that allows users to offload proof generation to external servers when necessary.

Given these practical constraints, Miden does not adopt a fully private model at launch. Instead, it begins with a Web2-like Phase 1, where operators can still view transaction data. The approach minimizes regulatory exposure and provides a stable foundation for early ecosystem development. After establishing core layers of security, compliance, and UX in Phase 1, Miden intends to expand gradually toward Phase 3, a state approaching full privacy.

The blockchain landscape today is crowded with PoW and PoS L1s, while L2s continue to proliferate without clear differentiation, intensifying competition. In this environment, a new chain must offer a strong ecosystem, a robust community, or a clearly defined technical advantage to gain meaningful traction. Miden’s lack of EVM compatibility may create challenges for early ecosystem development, yet its ZK-native execution model and client-side execution architecture provide a fundamentally distinct competitive edge. If Miden can overcome the limitations outlined above, it holds the potential to establish itself as a new standard built on privacy and local execution—much as EVM chains became the prevailing standard in earlier phases of blockchain evolution.