---
# System prepended metadata

title: Compliant Private Stablecoin on Miden — Working Design Document

---

# Compliant Private Stablecoin on Miden — Working Design Document

> **Status:** Draft / working doc  
> **Participants:** Miden, M0, Predicate, external compliance counsel  
> **Audience:** Technical + product + legal/regulatory  
> **Purpose:** Shared design space for a **$-pegged, privacy-preserving, compliant stablecoin** on Miden.

This is a **living document**. It will contain open questions, alternatives, and half-baked ideas. Please add comments, `TODO:`s, and counter-proposals inline.

---

## 1. Goal & Scope

### 1.1 What we are trying to build

We want users to be able to:

- Hold a **$-pegged stablecoin** issued by **Moonpay** via **M0** in **private Miden accounts**.
- Transfer this stablecoin **privately by default** using Miden [private notes](https://docs.miden.xyz/miden-base/note#note-storage-mode).
- Do this in a way that is **legally, regulatorily, and operationally acceptable** for:
  - Moonpay, 1Money, etc as the issuer
  - M0 as the platform,
  - Predicate as compliance infra provider,
  - Institutions operating in the **US** and **EU** (at minimum).

High-level requirements:

- **Privacy:** End-users can use the private stablecoin on private notes on Miden.
- **Compliance:** Issuer, Miden, and M0 can satisfy regulatory (AML / CTF / KYC) obligations and avoid “Tornado-style” regulatory outcomes.
- **Programmability:** Compliance logic should be **programmable at the asset level** using Miden’s programmable asset model (faucet callbacks).
- **Evolvability:** We assume a **training-wheels** approach: start with conservative controls and gradually increase privacy and decentralization as we gain confidence.

### 1.2 What “compliance” might mean here

It is not 100% clear to me what a compliant stablecoin is. Is USDC on Ethereum mainnet compliant? 

This needs to be refined by a legal counsel or Predicate, but roughly:

- **KYC / KYB**
  - Asset issuer must KYC/KYB purchasers in primary issuance
  - Clients after primary issuance might only be subject to risk-based analysis (to be analyzed) 

- **AML / CTF**
    - Asset issuer needs to follow BSA and maintain an AML program, including overseeing the circulation of assets
    - Asset issuer needs to file SARs reports as required
    - Asset issuer and Miden need to limit high-risk users (e.g. major exploits, terrorist financing) from picking up and utilizing the asset in secondary markets. This is more of a principles-based approach
    - Miden needs to ensure that appropriate AML/CFT settings are put in place in any centralized points
  - Ability to **screen counterparties and flows** against:
    - Sanctions lists (OFAC, EU, UN, etc.).
    - Known hacks, scams, mixers, high-risk services.
  - Ability to **detect suspicious patterns** and file SARs / STRs where required.
  - Ability to **avoid commingling** with clearly illicit funds.

- **Issuer controls**
  - At minimum:
    - Ability to **blocklist** certain addresses / accounts.
    - Ability to **freeze / pause** the asset or specific positions.
  - For Miden, this likely maps to:
    - Ability to **refuse transfers** (e.g., faucet callback returns `false`).
    - Ability to **refuse redemptions / burns** or disable new minting.

- **Auditability / disclosure**
  - Ability to **reconstruct flows** for:
    - Regulated intermediaries (custodians, exchanges, M0 itself),
    - Regulators or auditors under lawful process.
  - This can leverage **view keys / selective disclosure / ZK proof chains** rather than full transparency.

> **Open questions (to refine with counsel / issuer)**
> - Which concrete regulatory regimes do we need to comply with? (e.g., US MSB rules, travel rule, MiCA, AMLD6/AMLR, etc.)
> - Do we require **full KYC** for all users, or only for certain tiers / limits?
> - How much **ex ante control** is required (blocklists, policy engine) vs **ex post auditability**?
> - What is the minimal set of issuer powers regulators will insist on (freeze, clawback, list control, etc.)? [freeze]

---

## 2. Background: Privacy & Compliance Design Space

### 2.1 Frameworks we’re referencing

We adopt the **Types of Privacy / Compliance Enforcement / Disclosure Rules** framework from the Inco + Predicate report *“Navigating Privacy and Compliance in Blockchain Systems”*[1]

Key axes (very compressed):

- **Types of privacy**
  - Pseudonymity → Confidentiality → Anonymity → Fully private.
- **Layer of enforcement**
  - Asset / Application / Protocol (chain).
- **Point of enforcement**
  - Deposit / transfer / withdrawal.
- **Compliance mechanism**
  - Programmatic policies, KYC/KYB, PoI/ASP, auditor keys, lineage, etc.
- **Disclosure rules**
  - Who can see what (user, voluntary third party, involuntary third party, protocol), and **how viewing rights are controlled** (pre-defined vs programmable).

We should explicitly place **“M0 private stablecoin on Miden”** somewhere in this design space later in the doc.

### 2.2 Other projects and reference architectures

This section is deliberately short; we can extend with more detail if useful.

#### 2.2.1 Aleo + USDCx

- **What it is**
  - Aleo and Circle are launching **USDCx**, a private, USDC-backed stablecoin on Aleo using Circle’s xReserve infrastructure [2]  
  - Fully redeemable into “normal” USDC 1:1 on supported chains.

- **Privacy model**
  - Aleo is a **fully private L1**; notes inside Aleo hide (encrypt) senders, receivers, and amounts using ZK proofs  
  - Public chains only see deposit/withdraw events via the **Verulink** bridge; inside Aleo, transfers are private (encrypted).

- **Compliance model (high-level)**
  - Compliance is primarily enforced at the **bridge / app layer**:
    - Programmatic policies at deposit into Aleo  
    - Rate limits, delay windows, risk-based controls on bridging.
    - Probably also some freeze capabilities and visibility for the issuer
  - Disclosure: users can share view keys for audits; governance has adopted guidance (e.g., ARC-100) on best practices for bridges  

> **Why relevant for us:** example of a **major issuer** (Circle) endorsing “private but compliant” design: enforcement at **boundary (bridge)** + strong **selective disclosure** inside private environment.

#### 2.2.2 Confidential / auditor-view designs (Solana Token-2022, AvaCloud eERC20)

- **What they do**
  - Token-2022: **confidential transfers** on Solana (amounts encrypted); optional **auditor key** that can decrypt balances [3]  
  - AvaCloud eERC20: similar design on EVM: balances and amounts encrypted; issuer can appoint / rotate **auditors** with view-only power  

- **Pattern**
  - **Asset-level confidentiality**, **asset-level compliance** via:
    - Auditor keys (view-only, not enforcement),
    - Issuer-controlled policy over who can audit.

> **Why relevant:** shows a path where the stablecoin **itself carries the compliance hooks** (auditors, controls) independent of specific dApps.

#### 2.2.3 PoI / ASP / privacy pools

- Protocols like **Railgun**, **Privacy Pools** etc. use **proof-of-innocence** or **association sets**:
  - Users prove that funds **do not intersect** with a bad set, or **do belong** to a curated good set, using ZK proofs, without revealing full history  
- These systems often:
  - Enforce compliance at **deposit and withdrawal**, while inner transfers remain private.
  - Use semi-centralized **curators** for lists.

> **Why relevant:** gives us a language for compliance that is **more nuanced than a static blacklist** (e.g., “your funds are in the clean set curated by X”).

#### 2.2.4 Regulatory / theory papers

- **“Privacy-Protecting Regulatory Solutions Using Zero-Knowledge Proofs”** (Burleson/Korver/Boneh) discusses:
  - Using ZKPs for **selective disclosure** to meet AML / CTF requirements without full transparency [4]  
- Other work (e.g., zkFi, Derecho, MIT/BoE digital pound report) explores:
  - Middleware architectures,
  - Selective de-anonymization,
  - Design of **viewing keys and audit trails**  

> **TODO:** Once we have a concrete strawman, we should explicitly map it against these patterns: what we reuse vs where Miden’s model is different.

---

## 3. How a Compliant Private Stablecoin Could Work on Miden

### 3.1 Miden primitives we rely on (very high level)

We assume the following:

- **Notes / assets**
  - Assets live in **notes**; notes can be consumed / created privately, with ZK proofs verifying correctness. This is pretty similar to Aleo / Aztec, only notes can be consumed in Miden.
- **Programmable assets / faucets**
  - Each asset has an **issuing faucet** that can be invoked on transfer / mint / burn.
  - Transfers can require a **callback into the faucet** which:
    - Sees some subset of transaction data (to be specified),
    - Runs arbitrary logic,
    - Returns `true` (allow) or `false` (reject) [it can return up to 16 Felts].

Ref: Miden programmable asset discussion. (https://github.com/0xMiden/miden-base/discussions/1068)

### 3.2 Roles and responsibilities

- **Moonpay / 1Money (issuer)**
  - Issues the **Miden-native representation** of the stablecoin.
  - Meets offchain obligations.
  - Ultimately responsible for regulatory compliance as issuer.

- **M0 (stablecoin platform)**
  - Maintains reserves and infra to issue the stablecoin.

- **Predicate (compliance infra)**
  - Provides **policy engine** and **real-time risk attestation**.
  - Potentially also curates/operates **association sets**, block/allowlists, and other onchain policy artifacts.

- **Miden protocol**
  - Provides **execution + privacy**.
  - Provides the programmable asset hooks (faucet callback).

- **Compliance expert(s) / counsel**
  - Translate regulatory requirements into concrete **policy primitives** and **documentation** (what reports we can produce, etc.).

### 3.3 Strawman: Asset-level enforcement via faucet callback

**Idea:** Stablecoin is a Miden programmable asset; every transfer calls back into the **M0 stablecoin faucet**, which in turn queries Predicate / onchain state to decide whether to allow the transfer.

Rough flow:

1. **User constructs a private transfer** of M0-USD on Miden.
2. During execution, the VM:
   - Invokes the **faucet callback** with:
     - Some metadata about the transfer (structured note tags, risk attestation, etc.).
3. The faucet logic:
   - Checks:
     - **Blocklist / allowlist** membership,
     - Optional **Predicate policy attestation** (e.g., signed message that “this transfer complies with policy vX”),
     - Optional **limits** (velocity, per-address caps, etc.).
   - Returns `true` or `false`.
4. If `true`, transaction is valid; if `false`, transaction fails and notes are not created / consumed.

This makes the **asset itself** the enforcement point, regardless of wallet or dApp.

5. For every transaction, there is always a proof. That means, also the faucet callback is proven to be true, if the transaction succeeds.

#### 3.3.1 What does the faucet actually see?

On option is:

- **Metadata-rich**
  - Faucet sees:
    - Pseudonymous sender/receiver identifiers,
    - Asset type (fixed: stablecoin),
    - Transfer amount (possibly bucketed / thresholded),
    - Optional jurisdictional flags / account types.
  - Faucet can implement more nuanced policy (e.g., velocity limits, per-jurisdiction rules), at the cost of more data being visible to the issuer / Predicate.

> **Open design question:**  
> What is the **minimum metadata** the faucet must see to satisfy compliance, and what can be kept **purely private** while remaining acceptable to regulators?

### 3.4 Where and how we enforce compliance

Using the Inco+Predicate framework, a first placement (to debate) might be:

- **Types of privacy**
  - Inside Miden: target **“fully private”** (sender, receiver, amount all hidden from the public).
  - At the **edges** (mint / redeem from non-private chains): likely only **pseudonymous** or **confidential**.

- **Layer of enforcement**
  - **Asset level:** faucet logic for transfers, mints, burns.
  - **Application level:** wallet / on-ramp enforcing UX rules (e.g., no unsigned transfers, forcing policy attestation).
  - **Boundary level:** when bridging or redeeming off Miden, additional checks may apply (e.g., KYC’d exchange).

- **Point of enforcement**
  - **Deposit / mint into Miden private pool**
    - Strong policy checks (KYC, AML screening, risk scoring).
  - **Transfers inside Miden**
    - Faucet callback ensures policy invariants (e.g., no blocked parties, limits).
  - **Withdrawal / redemption**
    - Additional checks (e.g., higher scrutiny for large redemptions, travel rule data).

- **Compliance mechanism candidates**
  - **Programmatic policies (Predicate)**
    - Real-time risk checks at mint / transfer.
  - **Blocklist / allowlist**
    - Enforced in faucet; semantics TBD (account-based, key-based, tag-based).
  - **Association sets / PoI**
    - For some flows, users may prove funds **belong to a “clean” set** rather than rely solely on a blocklist.
  - **KYC / identity**
    - Possibly used at mint / redemption, with **ZK attestations** used inside Miden to avoid re-exposing identity.

> **Open questions**
> - Do we want **mandatory KYC** for all holders, or tiered (e.g., anonymous small holdings vs fully-KYC’d larger holdings)?
> - Do we want to support **PoI / ASP-style proofs** as a first-class mechanism, or is that out of scope for v1?
> - How much of the policy logic should be **onchain in the faucet** vs **offchain in Predicate’s policy engine** (with signed attestations)?

### 3.5 Disclosure / auditability model

We need a story for:

- **User self-view**
  - Users must be able to see their balances and history (already in Miden model).

- **Voluntary third-party disclosure**
  - Users (or regulated intermediaries acting for them) should be able to:
    - Share **view keys** or **exported histories** to auditors, accountants, tax advisors.
    - Provide **ZK proofs** that payments/auth holdings satisfy certain properties (e.g., “all funds originated from KYC’d accounts”, “no interaction with sanctions list X”).

- **Involuntary disclosure under lawful process**
  - M0 and/or Predicate may need the ability to:
    - Perform **targeted investigations** when given an identifier (account, note tag, etc.) and legal authority.
    - Produce AML reports backed by **cryptographically sound evidence** (e.g., derived from onchain state + proofs).

This is where we need to map Miden’s **viewing key / audit key** story:

> **Open questions**
> - Miden does not support **view keys** at note / account level natively. Data is stored offchain. Is this needed?
> - Do we need a separate **“regulator view”** capability (e.g., auditor keys analogous to Token-2022 / eERC20), or can we get far enough with user-/intermediary-provided proofs?
> - How do we avoid recreating a **centralized panopticon** while still satisfying enforcement needs?

### 3.6 Is “just a blocklist” sufficient?

One key question for v1:

> **Is an issuer-controlled blocklist (and ability to pause) sufficient to call this “compliant” for US / EU, at least initially?**

Dimensions:

- **Pros**
  - Mirrors current USDC-style controls on transparent chains.
  - Simple mental model: Predicate can freeze assets associated with sanctioned entities or clear abuse.
  - Easier to implement quickly inside Miden via faucet callback.

- **Cons**
  - In a **fully private** environment, it becomes harder to:
    - Identify which notes/accounts belong to bad actors **without** more metadata or external proofs.
    - Demonstrate to regulators that the issuer is doing sufficient **AML risk management**, not just freezing addresses after the fact.
  - If the blocklist is **mostly empty** (because Miden is new / small), regulators might see this as **compliance theater** unless backed by a clear risk-based rationale.

> **Open questions for compliance expert + Predicate**
> - What **minimum controls** beyond a simple blocklist are expected?
>   - e.g., transaction monitoring rules, velocity checks, association-set logic, enhanced due diligence for certain counterparties.
> - Can we credibly argue for a **phased rollout**:
>   1. Phase 0: basic blocklist + pause + full KYC at mint/redemption.
>   2. Phase 1: add Predicate policy engine integration (risk-scored policy decisions on faucet callback).
>   3. Phase 2: introduce PoI / ASP-style sets, richer view/audit tooling.
> - How do we **document and communicate** this as a **risk-based program**, not just a tech feature?

---

## 4. Next Steps (for all parties)

**For Miden:**

- Specify exactly:
  - What the **faucet callback interface** looks like (inputs/outputs, what metadata is accessible).
  - How **note tags** and programmable assets can encode compliance-relevant information.

**For Asset Issuer:**

- Define initial **risk appetite** and **jurisdictional scope**.
- Outline:
  - On/Off-ramp partners,
  - KYC model,
  - Reporting obligations.

**For Predicate:**

- Propose:
  - A **concrete policy schema** for M0 stablecoin on Miden (e.g., JSON representation of rules).
  - A **signing / attestation format** that the faucet can verify.
  - Options for **association sets**, blocklists, and how they are updated onchain.

**For compliance expert:**

- Validate:
  - Whether the **strawman control set** is realistic for US/EU regulators.
  - Where additional controls / documentation are needed (e.g., Travel Rule, record-keeping, SAR filing processes).

---

## 5. Appendix / References

[1] Inco + Predicate — *Navigating Privacy and Compliance in Blockchain Systems* (2024)  
[2] Aleo + Verulink + USDCx press and docs  
[3] Solana Token-2022 confidential transfer docs; AvaCloud eERC20 docs  
[4] Burleson, Korver, Boneh — *Privacy-Protecting Regulatory Solutions Using Zero-Knowledge Proofs* (a16z crypto, 2022)  

> **TODO:** Once we converge on a baseline design, add:
> - A one-page **“placement in the framework”** diagram for the Miden stablecoin.
> - Concrete **sequence diagrams** for: mint, private transfer, redemption, and audit flow.
