By Brian Seong, based on an original idea by Bobbin

Introduction: The Paradox of Private Control

Most blockchains today aren't private. Balances, transfers, and counterparties are visible to anyone with a block explorer, which makes coordination easy, but turns every financial action into public metadata.

Privacy is now technically possible. Zero-knowledge (ZK) proofs let users prove transactions are valid without revealing the underlying data. Miden builds this into the execution layer itself: accounts execute locally, the chain stores only cryptographic commitments, and full state stays with the user.

But privacy creates a new problem. When no one can see the ledger, the coordination tools that blockchains and traditional finance rely on stop working. Multisig approvals assume shared state visibility. Fraud monitoring assumes readable balances. Compliance workflows assume an auditable trail. Remove the public ledger, and you need a fundamentally different way to coordinate, recover, and enforce policy.

This article explains how Miden solves that problem with Guardian — a coordination approach that restores backup, multi-device sync, safety controls, and compliance without reintroducing custody or surveillance.

Miden + Guardian provides a third path. Miden’s off-chain account model keeps account state local while the chain verifies correctness via proofs and stores only commitments, so you get privacy without giving up verifiability. Guardian is a coordination mechanism for private accounts, a set of responsibilities that any provider can implement to make Miden's privacy foundation usable in the real world: backup and multi-device recovery, shared-control coordination, safety policies (limits, delays, freezes), and compliance integration, without custody.

A concrete example makes the need for this service layer obvious. Imagine a corporate treasury team managing millions in assets. One night, a phishing attack compromises a signer’s hot key (Chainalysis, “North Korea Drives Record $2 Billion Crypto Theft Year…”, Dec 18, 2025). On a transparent chain, the team might notice unusual activity through on-chain monitoring and shared visibility. But with private-by-default accounts, there’s no public balance view and no browsable transaction history, only commitments. An attacker could attempt to drain funds quietly unless the account has strong off-chain safety and coordination.

This is the central shift in privacy-first systems: when surveillance goes away, coordination can’t depend on a readable public ledger. Today's shared-control patterns, multisigs, approvals, monitoring, all assume every participant can read the same on-chain state and build their next action on top of it. That shared visibility is the coordination surface. Remove it, and you need something else in its place. On Miden, the account state lives locally, hence the coordination surface moves off-chain provided by PSM.

Guardian begins as a backup + sync service, then expands into:

• a liveness and safety guardian (preventing state drift and silent failures),
• a policy engine (rate limits, delays, freezes),
• and an institutional rail for “banking without surveillance or blind trust,” enabling compliance and operational convenience without custody.

In the rest of this post, we’ll dive into PSM: what it is, how it works, and how it unlocks workflows from retail wallets to institutional banking rails.

Why Coordination Breaks Under Privacy: The Core Problem

Today’s blockchains force a false tradeoff between transparency and security. On public ledgers like Ethereum or Solana, assets are fully visible: balances, flows, and counterparties are open for anyone to scan. That visibility makes coordination easy, everyone can read the same state. But it also turns financial activity into public metadata.

Institutions work around this by pooling funds into omnibus wallets. Centralized exchanges and custodians hold billions behind a small set of keys. Operationally, it's convenient. But it creates honeypots. One breach can be catastrophic. The 2022 Ronin Network hack saw $625M stolen after attackers socially engineered four of nine threshold keys plus one validator key.

The result is a frustrating split. Either the chain exposes everything (inviting surveillance and front-running), or assets disappear into proprietary off-chain systems with no verifiability. Compliance is then bolted on after the fact, often relying on heuristics and analytics to flag suspicious activity post hoc. In practice, we sacrifice programmability and auditability to get privacy, turning crypto into something that looks uncomfortably close to opaque banking.

The issue isn’t that coordination is impossible. It’s that the obvious coordination tools each give up something essential. Managed key custody (the “institutional escrow” pattern) buys policy and ops, but sacrifices non-custody. On-chain multisig (the Safe-style model) preserves self-custody, but sacrifices privacy by making coordination ride on public state. And while MPC/TSS can hide keys, many practical schemes introduce interactive signing rounds and liveness dependencies that don’t fit asynchronous, consumer-grade workflows.

Miden offers a different foundation. Private accounts with verifiable correctness: account state stays off-chain, and the chain stores only commitments plus proof-verified updates. That avoids public surveillance and removes the need for omnibus custody.

But privacy alone doesn't solve coordination. That's where Guardian comes in. It shows that the tradeoffs described above are not fundamental. A carefully designed coordination layer can provide backup and recovery, policy-enforced co-signing, and institutional operational rails while preserving both privacy and non-custody.

Miden’s Private Account Model: A Quick Primer

Miden is a zero-knowledge (ZK) rollup designed for privacy and scalability. Unlike traditional blockchains, private execution happens locally on the user’s device.

• Local state management: each account holds its full state (balances, nonce, code, notes) off-chain.
• ZK proofs for verification: users generate a proof that the transition from old state S(n) to new state S(n+1) is correct.
• Chain storage: the network stores only a compact commitment (hash) to the new account state plus the proof; no raw state is revealed.

This model delivers strong confidentiality: shielding payroll flows, treasury positions, or OTC trade details. But it introduces a coordination nightmare.

Key terms (quick glossary)

To keep the rest of the post readable, here’s the vocabulary we’ll use:

• State (Miden): the current condition of the protocol at a point in time. Covering accounts, notes, and nullifiers (and their statuses). Concretely, operators maintain separate state databases for account commitments (and public account data), note commitments (and public notes), and the nullifier set used to prevent double-spends.
• Account (Miden): the primary entity in Miden. Essentially a smart contract that can hold assets, store data, and execute custom code. An account is composed of an ID, code, storage, a vault (assets), and a nonce (incremented on state updates to prevent replay and order transitions).
• Transaction (Miden): a state transition of a single account. A transaction takes one account plus zero or more input notes, executes as a Miden VM program, and outputs the same account with updated state plus zero or more new notes, along with a proof the transition was valid.
• Note (Miden): the primary message object through which accounts communicate in Miden’s UTXO/account hybrid model. A note can carry assets and arbitrary logic via a script (plus inputs), and is uniquely identified by a serial number. Notes may be stored publicly (full data on-chain) or privately (only the note hash on-chain), and are “spent” by consuming them in a transaction.
• Commitment: a hash/commitment that represents some private value or state without revealing it.
• Proof (ZK proof): a succinct cryptographic proof that a computation/state transition was valid without revealing the underlying private inputs.
• Client-side (local): data and computation that live on the user’s device (or the user’s chosen client environment) rather than on-chain. Its state-deterministic characteristic is secured by all computation running inside a zkVM to ensure its validity.
• Nullifier: a public value derived from a spent note that marks it as consumed, preventing double-spends without revealing the note itself.
• Delta: a compact, replayable description of “what changed” in an account’s local state which is used to sync, back up, and reconstruct state without shipping full snapshots. One useful model is a tuple (nullifiers_revealed, notes_created, nonce) representing the transition from one local snapshot to another. Deltas are encrypted under a key derived from the user’s master seed; Guardian stores ciphertext only.
• Candidate vs. canonical: candidate is an update that has been proposed/approved off-chain but not yet confirmed; canonical is the update that’s confirmed by the chain (e.g., via the committed state).

Notes and nullifiers

In note-based systems, value exists as encrypted notes, commitments to “amount + owner (and conditions).” Spending a note reveals a nullifier (deterministically derived from the note) that prevents double-spending while revealing nothing about the note’s contents. Critically, the chain doesn’t store “balances” in the clear; it stores commitments (to state and notes) and nullifiers (for spent notes) on-chain, while the full, rich note/account state lives client-side.

Miden is best understood as a UTXO/account hybrid: accounts execute locally and commit state transitions, while notes are the primary vehicle for moving value and data between accounts.

Coordination in Private Accounts

On a public chain, the ledger is a universally readable source of truth: every device and every signer can independently observe the latest state and build the next action on top of it. In a private account model, the canonical state still exists and it’s defined by the on-chain commitment. But it isn’t readable in a way that automatically keeps every device and signer up to date.

That creates a few practical frictions:

• State awareness and sync: the on-chain commitment pins the canonical state, but a device may not have the corresponding local state/deltas to match it if it falls behind.
• State divergence: If two devices/users have divergent states, only one state is the valid one, and only that user/device can propose a valid transaction.
• Withholding / availability: if updates (deltas) aren’t reliably shared, a lost device or offline signer can’t easily recover the latest private state needed to continue.

Public chains give you sync “for free” because the ledger is a readable source of truth for the current account state (e.g., balances/positions and the latest on-chain commitment that everyone can reference). In private accounts, that same “state” lives largely client-side, where the device needs the right local data (account state + relevant note updates/deltas) to match the canonical on-chain commitment. Therefore you need an explicit coordination layer that keeps parties aligned without reintroducing custody or surveillance.

This is PSM's origin story, a coordination layer that guarantees consistency without compromising privacy.

Phase I: Guardian as Backup and Synchronization Layer

In its simplest form, a Guardian provider acts as a "state guardian": an off-chain service that backs up account deltas and ensures all relevant parties stay synchronized. It's non-custodial. The provider can't move funds unilaterally. But it enforces liveness and consistency, laying the groundwork for more advanced features in later phases. OpenZeppelin is building a reference implementation in the open.

Base architecture

At a high level, Phase I is about one simple thing: letting you use the same private account across devices (and even across multiple signers) without handing your account to a custodian.

If you’ve ever migrated phones, lost a laptop, or tried to coordinate approvals in a team, you’ve seen the usual tradeoffs. Either you treat one device as the “truth” (and recovery could be painful), or you rely on a server that can see your full state (and privacy/non‑custody starts to erode).

Guardian is the middle path. Your devices keep the real private state locally, while the Guardian stores and relays deltas plus lightweight sync receipts. That’s enough to restore and synchronize state, and to make sure everyone is working off the latest canonical commitment, without giving the provider unilateral control.

Guardian visibility modes (and the operator threat model)

Guardian can run in two modes:

• Unencrypted (operator-visible): deltas/state updates are stored in plaintext. This is the most practical default today and enables add-ons like compliance, risk rules, monitoring, and customer support workflows.
• Encrypted (operator-blind): clients encrypt deltas before upload, so the Guardian stores and relays ciphertext only. This improves privacy against the operator, but limits what the Guardian can inspect/enforce without additional cryptography.

In both cases, the right threat model is honest-but-curious: the Guardian is expected to follow the protocol and availability guarantees, but may try to learn as much as it can from any data it is given. Encrypted mode minimizes what the operator can learn; unencrypted mode enables richer services at the cost of visibility.

How Transactions Flow

Transactions proceed through a clear, step-by-step process to ensure everything stays consistent and verifiable:

1. Local Execution: The user computes a transaction locally, generating a delta (e.g., a balance update).
2. Delta Submission: The user sends this delta to Guardian for acknowledgment.
3. Guardian Acknowledgment: it signs the transaction as a co-signer, designating it as a "candidate" state.
4. Proof and On-Chain Submission: The user (or Guardian in more advanced configurations) generates the ZK proof and submits it to the chain, updating the commitment.
5. Canonical Confirmation: Guardian monitors the chain; if the on-chain commitment aligns with the “candidate”, it confirms the state as "canonical" and distributes the delta to other devices or signers.
6. Mismatch handling: if the on-chain commitment doesn’t match the “candidate” update, the Guardian treats that “candidate” as rejected, fetches the canonical commitment, and instructs clients to resync/rebuild before trying again. (This isn’t “rolling back” the chain, it’s preventing clients from drifting onto an invalid local branch.)

‍

Multi-Device Example

For users juggling multiple devices, like a desktop and mobile, Guardian makes synchronization effortless. The desktop might execute a transaction, send the delta to Guardian for sign-off, and submit it to the chain. Guardian then propagates the canonical delta to the mobile device, which replays it locally to update its state, all without needing to query the chain directly, since it only holds commitments, not raw data.

Non-Custodial Multisig Setup

Guardian truly excels in multisig scenarios, where coordination is critical. A common configuration uses a 2-of-3 threshold embedded in the account's authentication code:

• Key 1: User's hot key for daily use.
• Key 2: User's cold key for recovery.
• Key 3: PSM's service key for enforcement.

This pattern has precedent. Argent pioneered a similar guardian model in 2020, where a trusted third party could co-sign recovery transactions without holding custody. The difference here is that PSM's guardian role is embedded in Miden's account code and enforced by ZK proofs, not by an on-chain multisig contract with visible state.

In normal operations, the hot key plus PSM's signature suffice, with Guardian verifying that the proposer is working from the latest state. For emergencies, the hot and cold keys alone can rotate out PSM, adjust policies, or even upgrade the account code (once protocol support arrives). This transforms Guardian into a "liveness guard," guaranteeing synchronization without granting it overriding power.

What happens when you lose a device?

Say Alice uses her Miden wallet on her phone and laptop. One day, her phone gets stolen.

Without a Guardian provider, she's in trouble. She has to dig out her cold backup and restore from her last checkpoint. Anything that happened since that backup? Gone. And if the attacker knows her PIN, her funds are exposed. Recovery could take days.

With a Guardian provider, it's a different story. Alice opens her laptop. It already has the latest state, synced through PSM. She kicks off a hot key rotation using her cold key, and just like that, the stolen phone is holding dead keys. The attacker can't do anything with them. Recovery takes minutes, not days. Funds lost: none.

In Phase I, Guardian tackles the essentials: backup for individual users, sync across devices, and coordination for basic multisigs. It is also setting the stage for smarter risk management in the phases ahead.

Phase II: Guardian as Security, Safety, and Compliance Brain

Once sync is solved, a natural question follows: where do you put policy enforcement?

The 2-of-3 architecture from Phase I turns out to be the answer. It achieves something no prior system offers: non-custodial policy enforcement. The Guardian provider holds one key but cannot move funds unilaterally, because it needs the user's key. The user holds one key but cannot bypass policy, because they need the Guardian provider's co-signature. And the cold key is the escape hatch: if the provider goes rogue or disappears, the user recovers independently.

This isn't novel cryptography. Threshold signatures have been around for decades. The insight is architectural: combining heterogeneous key holders with different roles inside a private execution environment produces compliance without custody. The Guardian provider can enforce rules, but can never take your money.

With that foundation, the Guardian provider becomes a policy engine. It sees deltas before co-signing, which means it can check them against whatever rules the account owner has configured.

Security controls

• Rate Limits: Users can configure outflows, such as $1k per day, to cap potential damage from a compromised hot key, similar to a credit card spending cap.
• Delayed Actions: Key rotations or high-value transactions might include a 24-hour timelock, during which other signers or Guardian can veto suspicious activity, mirroring bank fraud alerts.
• Emergency Freeze: In cases of immediate concern, users contact Guardian through a dashboard or call to pause signatures, buying time to rotate keys without Guardian gaining any ability to move funds.

Configurable Compliance

A Guardian provider chooses what to enforce, no compliance rule is mandatory. A bare-bones provider might do nothing beyond sync and co-signing. A provider targeting European regulated markets might enforce MiCA requirements and OFAC screening. A provider in Singapore might enforce MAS guidelines. A privacy-maximalist provider might run in encrypted mode and skip compliance entirely.

Compliance is a configuration choice, not a protocol constraint. The same Guardian specification supports all of these postures. What matters is that when a provider does enforce policy, it can do so at the co-signing layer without taking custody.

Because the provider sees every delta before co-signing, it can screen against sanctions lists like OFAC, flag unusual patterns, enforce whitelists of KYC'd counterparties, and check Travel Rule data.

For audits, the provider could maintain an encrypted trail of policy decisions. Each co-sign or refusal is committed. If a regulator asks "did you screen transaction X?", the provider can reveal that specific commitment and produce a ZK proof that the check occurred, without exposing the transaction itself. The regulator learns "this policy was enforced" without learning balances, counterparties, or amounts. This approach builds on prior work like zkKYC(Pauwels, 2021), which showed how identity verification can happen without the verifier learning the customer's identity.

Guardian providers can also handle identity attestations. After performing KYC, a provider mints a "compliance token" into the user's account. This is a ZK-proofable on-chain credential that says "this account has been verified" without revealing who verified it or what was checked.

Why on-chain? Convenience. If the attestation lives off-chain, every counterparty has to contact the provider to confirm the account's status. That creates a bottleneck and a privacy leak, since the provider learns who's checking on whom. With an on-chain token, any counterparty can verify compliance status permissionlessly by requesting a ZK proof from the account holder. No round-trip to the provider needed.

The tradeoff is that an on-chain token reveals that the account exists and holds a compliance credential, even though it doesn't reveal activity or balances. For high-privacy users who don't want even that level of visibility, an off-chain attestation mode is available, where the provider issues signed credentials that the user presents directly to counterparties.

‍

‍

Phase III: Guardian as Institutional Rail – Crypto Banks Without Custody

Now, scale Guardian to institutions. Imagine a bank like JP Morgan (as a placeholder) running Guardian as a service: users get private Miden accounts with bank-grade features, but non-custodial control. This setup allows institutions to provide value-added services while users retain ultimate ownership.

In institutional operation, the process includes:

• Onboarding: The bank handles KYC and sets up the 2-of-3 multisig incorporating their Guardian key.
• Delegated Proving: Users sign transactions locally and send them to Guardian, which takes on the heavy ZK computations and submits to the chain for a light client UX.
• Non-Custodial Guardrails: The bank can't move funds alone, as users hold hot and cold keys for overrides.

For batching and scalability, the Guardian provider acts as a settlement coordinator. It aggregates transactions from multiple users into batches and generates a single proof for the entire set, which the network verifies once. This is coordination, not sequencing. The provider doesn't reorder transactions (nonce ordering is deterministic), can't see note contents (encrypted), and can't inject its own transactions ahead of users. There is no MEV opportunity. The provider batches and settles, nothing more.

Ephemeral notes and netting take this further. When two users share the same Guardian provider, transfers between them don't need to hit the chain at all. Say Alice sends a payment to Bob, and Bob sends a payment to Carol. The provider creates ephemeral notes for each transfer. These are temporary: they exist only within the current batch, never committed to the chain's note tree or nullifier tree. When the settlement window closes, the provider nets all intra-provider flows and commits only the net positions on-chain.

In Miden, ephemeral notes (also called erasable notes) are created and consumed within the same batch or block. They enable atomic operations like direct transfers or swaps that appear as a single step, with no intermediate on-chain records and lower fees. If the provider fails mid-window, users still hold their signed notes and can submit them directly to the chain. No funds are lost, just the efficiency and privacy benefits of batching for that window.

This prevents double-spends within the block (via duplicate checks) but allows identical notes across different blocks if erased, reducing fees and accelerating settlements. For instance, turning an Alice-to-Bob transfer into an efficient, fee-optimized atomic mutation of both accounts. 

CLS Bank already processes $6.6 trillion in foreign exchange daily using netting. Clearinghouses have done this for decades. But they require full visibility into positions and custody over settlement accounts. PSM-based netting doesn't. The provider sees only encrypted deltas, holds no funds, and users keep control of their assets throughout. Same efficiency, without the custody tradeoff.

How does this compare to payment channels like Lightning? Lightning requires locking capital upfront into channels and both parties being online to receive payments. Guardian ephemeral notes require neither. Funds stay in the user's account until send time, and recipients don't need to be online. The tradeoff goes the other way: Lightning settles instantly, peer-to-peer. Guardian settles in batches, on a configurable window from one minute to one hour. Guardian is not a payment channel. It's a coordination layer for batch settlement, with the added benefit of auditable policy enforcement built in.

Portability ensures flexibility: Accounts are Miden-native, not bank-locked. Users rotate Guardian providers like phone numbers—competition on service, not custody. Banks manage risk/compliance, but users own assets cryptographically. No pooled honeypots, no blind trust—just verifiable rails.

‍

Real-World Use Cases: From Retail to Cross-Border

Guardian isn't just theoretical — it unlocks practical "crypto banks" for a range of high-stakes scenarios, blending privacy, security, and compliance in ways that traditional systems can't match. Let's dive into some concrete examples, showing how Guardian bridges the gap between everyday users and institutional heavyweights.

Retail and SME Banking

Before PSM: Retail users pick between self-custody wallets with no safety net, or custodial platforms that pool assets behind omnibus wallets. The FTX collapse showed what happens when custodians commingle user funds. Self-custody isn't much better for most people. One lost seed phrase and everything is gone.

With PSM: A small business owner or everyday consumer opens a non-custodial account through a Guardian provider. The provider handles KYC, configures the 2-of-3 key setup, and screens deposits for AML. From there, the experience feels like a normal bank account. Daily spending uses the hot key plus the provider's co-signature. Rate limits cap exposure. If fraud surfaces, the account owner contacts their provider to freeze co-signing and rotate keys.

The difference from traditional banking is structural: the provider never holds the funds. It can't rehypothecate, commingle, or lend out user assets, because it physically doesn't have them. Users get fraud detection, spending limits, and recovery — all the things people actually want from a bank — without the custody risk of centralized operators.

And because the account runs on Miden, all of this happens privately. The provider sees the deltas it co-signs, but no one else — not competitors, not other users, not chain observers — can see the account's balance, transaction history, or counterparties.

Products like Argent (3.6 million users) and Zengo (1.5 million users) have already proven demand for smart-contract wallets with guardian-style recovery. Guardian takes the model further: same convenience, but with private execution and configurable policy enforcement built into the coordination layer.

Tradeoff: Users depend on the provider for co-signing liveness. If the provider goes offline, the user falls back to hot + cold keys and switches providers.

Corporate Treasuries and DAOs

Before PSM: Corporate crypto treasuries typically use on-chain multisigs like Safe. Transparent, auditable — but every signer, threshold, and transaction is public. Competitors can monitor treasury size. Employees can see each other's compensation. Adversaries know exactly when large movements happen.

The institutional custody market shows the scale of the problem. Fireblocks has secured the transfer of over $6 trillion in digital assets. BitGo custodies assets for hundreds of institutional clients. Anchorage became the first federally chartered crypto bank. All of them rely on custodial models where the institution trusts the provider to hold and secure assets on their behalf.

With PSM: A 3-of-5 multisig runs privately with the provider as coordinator. Signers approve off-chain through the provider, which keeps everyone synced and enforces spending caps and approval thresholds. Imagine proposing a payroll run: each signer reviews and approves privately, the provider checks that the threshold is met and that all policy rules pass, then co-signs. Salaries, vendor payments, and strategic treasury movements stay confidential throughout.

When the board or regulators need visibility, the treasury produces ZK proofs — "payroll was executed within approved limits" or "total outflows this quarter were within budget" — without exposing individual line items or counterparties.

Guardian gives these institutions the operational controls they expect from Fireblocks or BitGo — multi-party approvals, policy enforcement, compliance — without requiring them to hand over custody. The provider coordinates. The institution keeps its keys.

Tradeoff: Coordination depends on the provider for state sync. Without it, signers need to coordinate manually, which is not very efficient but possible.

Payroll and HR Systems

Before PSM: Running payroll on public chains leaks individual salaries, bonuses, and contractor rates to anyone with a block explorer. Even with custodial solutions, the HR platform or payroll processor sees all the data and becomes a target. Companies either accept the transparency risk or fall back to traditional banking rails, giving up the benefits of programmable money entirely.

With PSM: Multiple approvers — cofounders, HR leads, finance teams — sign off on payment batches through the provider. The provider manages the workflow: syncing states across all approvers, enforcing caps, and preventing overpayments or unauthorized modifications. Each approver reviews and signs privately. The provider checks that the required threshold is met and that all policy rules pass before co-signing the batch.

Individual compensation stays private throughout. Nobody outside the approval chain sees what anyone earns. No employee data is exposed on-chain. No opaque HR software sits between the company and its funds.

When the board or regulators need proof that payroll ran correctly, the provider produces an aggregated ZK proof: "total payroll of $X was executed within approved budget limits, with all required approvals obtained." No individual amounts revealed. No employee names or compensation details leaked. Just verifiable proof that policy was followed.

Tradeoff: Batch processing adds some latency compared to instant individual payments. The approval workflow also requires signers to be available within a reasonable window.

OTC Trading and Prime Brokerage

Before PSM: OTC trading desks rely on custodial brokers or transparent on-chain settlement. Trust the broker with your assets and hope they don't get hacked or go insolvent. Or settle on-chain where your trade details, counterparties, and position sizes are visible to the entire market. Front-running and copycat trading are constant risks. The 2022 collapse of multiple prime brokers showed how quickly custodial counterparty risk can cascade.

With PSM: Trading desks and counterparties set up joint accounts through a provider. Each trade proposal flows through the provider, which checks compliance — sanctions screening, exposure limits, counterparty verification — before co-signing. Settlements are batched for efficiency.

Deal details stay private throughout. Neither party has to trust a custodian with their assets. Market observers can't see settlement data, so there's nothing to front-run or copy. The provider coordinates and enforces rules, but the assets stay in the participants' accounts at all times.

During volatile markets, the provider's risk controls limit exposure automatically. Rate limits, position caps, and counterparty whitelists all get checked at the co-sign layer before any settlement goes through.

Tradeoff: Settlement happens in batches rather than instantly. For time-sensitive trades, the batch window needs to be configured short. There's also counterparty risk during the batch window, though signed ephemeral notes provide a fallback if the provider fails mid-settlement.

Funds and Asset Managers

Before PSM: Fund managers using public chains face a brutal transparency problem. Every rebalance, allocation shift, and NAV change is visible on-chain. Competitors can reverse-engineer positions. Even using DeFi protocols like Aave or Morpho for yield strategies means broadcasting your entire playbook. Platforms like Coinbase Prime or Copper offer institutional custody and reporting, but they require handing over assets to a third party — and the fund's strategy is visible to the custodian.

With PSM: Portfolio updates flow through multisig with the provider enforcing investment mandates at the co-sign layer. Exposure limits, asset class restrictions, rebalancing constraints — all checked before the provider adds its signature. A fund manager can't accidentally (or intentionally) breach mandate limits because the provider won't co-sign a non-compliant transaction.

Internal allocations stay hidden from the market. No one outside the fund's signers can see what's in the portfolio or how it's moving. The fund's strategy stays proprietary.

When investors want proof of performance, or auditors need compliance verification, the fund produces ZK proofs on demand: NAV attestations, policy compliance certificates, or proof that mandate limits were respected over a given period. The auditor gets the facts they need without seeing the underlying positions or trading history. This is the difference between "trust us, we followed the mandate" and "here's a cryptographic proof that we did."

Tradeoff: In unencrypted mode, the provider sees portfolio deltas. For maximum confidentiality, encrypted mode is available — but it limits what the provider can enforce without additional cryptographic techniques. Fund managers need to decide where they sit on the privacy-vs-policy spectrum.

Cross-Border and Correspondent Banking

Before Guardian: Cross-border payments flow through correspondent banking chains. Multiple intermediaries, each taking a cut and adding delay. Settlement can take days. Privacy means using opaque intermediaries with no verifiability. Transparency means exposing client flows to every bank in the chain. SWIFT processes over $5 trillion daily through this system, and the inefficiencies are well documented.

With Guardian: Banks run interconnected providers that batch cross-border transactions across regions. Intra-provider flows net internally via ephemeral notes — Alice's bank in London and Bob's bank in Singapore both run PSM-compatible infrastructure, so the payment settles through coordinated netting rather than hopping through three correspondent banks.

Only net positions get committed to Miden for finality. Client data stays private throughout the entire flow. No intermediary in the chain sees the full picture.

When regulators or partner banks need assurance, ZK proofs of solvency or compliance are shared on demand — not raw transaction data. Settlement drops from days to hours. Fees drop because netting eliminates redundant on-chain transactions. And privacy works for both the banks and their clients.

Tradeoff: This requires multiple banks to adopt PSM-compatible infrastructure. Network effects take time to build. Early adopters get efficiency gains on internal flows, but cross-bank netting only kicks in once multiple institutions are on the network. Regulatory approval across jurisdictions adds complexity.
‍

‍

Technical Deep Dive: Guardian and Miden Authentication

‍

‍

For engineers building on Miden, PSM's integration with the protocol's authentication component is where the magic happens — it's the technical glue that ties off-chain coordination to on-chain verifiability. Let's unpack this step by step, starting from the basics of how transactions are handled and moving into more advanced concepts like state management and extensibility.

At the heart of PSM's role is its handling of TransactionSummary and deltas. Every transaction in Miden produces a summary that captures the essentials: the state deltas (changes to balances, nonces, or other account elements) and the updated nonce to prevent replays. Guardian stores these summaries off-chain, but crucially, it verifies them against any configured policies before providing its signature. This pre-signing check ensures that only compliant or safe updates proceed, all while keeping the heavy lifting local and private.

A key distinction Guardian introduces is between "candidate" and "canonical" states. When Guardian signs a transaction, it labels that version as a "candidate" — essentially a proposed update that's been vetted but not yet confirmed. After submission, Guardian monitors the chain for the updated commitment. If it matches the candidate, the state becomes "canonical," and Guardian propagates it to other devices or signers. But if there's a mismatch — say, due to a race condition or stale data — Guardian can trigger a challenge mechanism to discard or rollback the invalid state, maintaining consistency without relying on a central authority.

In multisig setups, Guardian enforces thresholds directly through Miden's account code. Here, Guardian functions as one of the signers in the authentication logic, where signatures are aggregated off-chain before being bundled into the ZK proof. The proof then verifies the entire context on-chain, ensuring the threshold (e.g., 2-of-3) was met without revealing individual signer details. This off-chain aggregation keeps things efficient and private, leveraging Miden's modular authentication to support complex policies.

Of course, Guardian isn't the only way to achieve sync — variants like fully peer-to-peer (P2P) synchronization are theoretically possible, where devices or signers exchange deltas directly. However, P2P demands all parties be online simultaneously, leading to poor user experience in real-world scenarios with intermittent connectivity or lost devices. Guardian trades a bit of decentralization for reliability, acting as a trusted-but-non-custodial relay that prioritizes uptime and ease of use.

Future Work

The current Guardian design assumes a single provider per account. That's practical for launch, but it concentrates trust in one operator. Several directions can reduce that trust over time:

Multi-Guardian federation: An account could register with multiple Guardian providers, requiring co-signatures from more than one. This distributes the coordination role so no single operator is a bottleneck or point of failure.

Decentralized Guardian via MPC: Instead of a single provider holding one key, a group of operators could collectively manage the Guardian key using multi-party computation. No individual operator ever sees the full key, and co-signing requires a threshold of operators to participate.

Hardware enclave integration for delegated proving: Users who can't generate ZK proofs locally (mobile devices, lightweight clients) could delegate proving to a provider running inside a TEE (trusted execution environment). The enclave guarantees that the provider executes the proof correctly without learning the inputs. The OZ reference implementation already supports reproducible builds for binary verification and TEE deployment.

Hardware enclave integration for verifiable batching: Similarly, the batching and netting process in Phase III could run inside an enclave, giving users cryptographic assurance that the settlement coordinator processed their transactions correctly — even in encrypted mode.

These are areas we're actively exploring. Each one builds on the existing Guardian architecture and could meaningfully reduce trust assumptions as the ecosystem matures. If any of these directions interest you, we'd love to hear from the community.

Conclusion: Building the Next Financial Infrastructure

As we've explored, private accounts on Miden open up a compelling vision of confidentiality and local control, but they're inherently fragile without a robust coordination mechanism. That's where Guardian steps in, transforming these accounts through a clear evolutionary path: beginning with Phase I's essential sync layer for backup and multi-device harmony, advancing to Phase II's intelligent security and compliance brain that embeds safeguards like rate limits and programmable audits, and culminating in Phase III's institutional rail that enables crypto banks without the pitfalls of custody. 

Far from being just another wallet add-on, Guardian emerges as a core primitive, empowering the creation of financial systems where compliance is woven in seamlessly, all while preserving user sovereignty.

This evolution delivers tangible wins across the board—users gain true autonomy over their assets, institutions access scalable rails for high-stakes operations, and regulators benefit from verifiable insights through zero-knowledge proofs, without invasive surveillance. It's a balanced third way that sidesteps the extremes of fully transparent chains or opaque custodial models.

If you're a builder, now's the time to experiment: integrate Guardian concepts into your wallets, custody solutions, or apps, and dive into the private multisig proof-of-concept at multisig.miden.xyz for a practical starting point. For institutions eyeing the future, move beyond traditional silos — pilot Guardian to unlock compliant, efficient crypto infrastructure, and join Miden Guardian operators to help mold this emerging landscape.

In the end, the era of programmable, private finance isn't some distant dream; it's arriving now, and Guardian is the key that makes it not just possible, but practical and powerful.

‍