# 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.