MIST.cash ER - Private Enterprise Payment Rails
MIST ER is a compliant privacy layer on top of USDG on Arbitrum. Zero-knowledge transfers stay hidden from the public, readable by the auditor of the reserve, and private even against quantum attackers.
ビデオ
テックスタック
説明
LIVE URL: er.mist.cash
The problem: public chains broadcast your books
Every stablecoin payment on a public chain shows your payroll, suppliers and treasury to competitors. Today's privacy tools fix that by also locking out regulators, so a business can't use them. The EU AMLR (Art. 79, applies from 10 July 2027) bans anonymity for regulated entities. It does not ban confidentiality. MIST is built for that gap: confidential to the public, provable to the auditor.
The vision: one protocol, many compliance postures
Funds are tagged by the compliance rules they follow, not mixed into one global pool.
Chamber: the state engine. It verifies ZK proofs and keeps the note tree and nullifiers. It never holds funds.
Reserve: an isolated vault with its own compliance rule set (KYC, AML/KYT, screening, auditor key). It holds only its own pool.
Middleware (roadmap): custom settlement logic and private state for DeFi integrations.
Why separate reserves matter:
When illicit funds enter: a monolithic pool gets blacklisted as a whole, hitting compliant users too. In MIST only that one reserve is affected; the others are fully disconnected.
KYT trust scores: bots score
Transferevents. In MIST, funds in KYC reserves keep a high trust score across fintechs instead of inheriting a mixer's low one.Private transfers inside the protocol draw on the entire MIST anonymity set. Exits use the reserve's anonymity set.
Example deployments on one network: a KYC Reserve (every member KYC'd), an AML-only Reserve (every wallet passes KYT), and an Unregulated Reserve (only proof of ownership needed). All of them settle through the same Chamber and the same verifier.
Compliance features
Live:
Registered-member reserves: each reserve keeps a Merkle tree of members. A spend must prove membership, and its outputs are encrypted to the reserve's key, so the manager can see who transacted and what moved.
Per-transaction auditor commitments: every spend publishes a tx commitment ID plus encrypted commitments (Poseidon2 Hash-and-Add). An auditor opens only the transactions they hold keys for, with no global viewing key.
Deposit screening (KYT): each reserve can name a screener. Deposits wait in a queue until approved or rejected, and the depositor can always reclaim a rejected deposit.
Manager-signed registration: an EIP-712
ManagerSigRegistrartoday. It can be swapped for a ZK-proof registrar later without changing the circuit.Auditor dashboard: shows registered users, KYC records (demo) and every deposit, transfer and withdrawal, decoded and checkable against the chain row by row.
Fixed-width commitments: every transaction emits the same number of slots, so policy shape (record count, travel-rule presence) never leaks.
Private zkState lookups: reserve rules are read inside the proof without revealing which reserve, index or value was used.
Specified:
Entry proofs: KYC membership, jurisdiction check, ZK passport.
Amount and travel-rule constraints: per-reserve limits and an IVMS101 payload above a threshold.
By design: reserves cannot add exit proofs that would take custody away from users.
Competitive landscape
Protocol | Compliance model | PQC proofs | PQC privacy | Architecture |
|---|---|---|---|---|
MIST.cash | KYT + AML + custom provider rules | No (Groth16) | ✅ Yes | Modular, built for institutional finance and DeFi |
STRK20 | Deposit screening (FPI) | ✅ Yes (STARK) | No (ECDH) | StarkWare unified pool on Starknet, DeFi composable |
Railgun | Private Proofs of Innocence (origin) | No (Groth16) | No | DeFi-native shielded pool with optional screening |
0xbow | ASP screening + deposit KYT | No (Groth16) | Yes, No auditor | Single Ethereum pool governed by the ASP rulebook |
Zcash | Viewing keys only (optional, all-or-nothing) | No (Halo 2) | No, targeted ~2027 | Sovereign L1, quantum-recoverable notes |
Aztec | Builder DIY (no native pool rules) | No (UltraHonk) | No spec, ECDH | Programmable private contracts, alpha |
Zama | Programmable app-level logic | ✅ Yes (FHE) | ✅ Yes (LWE) | Hides amounts, not addresses |
MIST is the only entry that combines configurable compliance for each reserve with post-quantum privacy, and it hides both amounts and counterparties.
Quantum safety
Safe against quantum attackers:
Note commitments, nullifiers and Merkle trees use Poseidon2, a hash function. Grover only gives a square-root speedup, so security margins hold.
Commitment encryption is a Hash-and-Add symmetric stream cipher on Poseidon2. There is no elliptic-curve key agreement to break.
Reserve key exchange uses the X-Wing hybrid (ML-KEM-768, FIPS 203 + X25519). It stays safe if either half holds.
Proof privacy: Groth16 is perfectly zero-knowledge, so proofs reveal nothing, even to an unbounded adversary.
⚠️ Proof soundness still rests on Groth16 over BN254 pairings. A quantum attacker could forge future proofs.
What this means: transaction history recorded today can't be decrypted later. No ECDH or ElGamal sits on the privacy path, so harvest-now-decrypt-later attacks don't work. Soundness is the one remaining classical assumption. The roadmap moves it to hash-based proving, building on the founder's ZK-recursion research (CHES 2026 submission, 38%+ less recursion overhead).
Contracts:
Chamber: 0x547d16C6DCc2C7Da42cf8D4f1d9Bf345557C30e1
Reserve: 0x7A2473649dA5F83fee516625E8563023A0422F94
Registrar: 0x268dde7946489f38b2ff54C9523C7c91977407e2
Verifier: 0xa6e9203193EAC92C43Fe67700a591132272729F6
Token (USDG): 0xFFC95faa3d63Cde504a05B567C600B78C0b41892