Status: Research and design. No code yet.
A reference and design document repo for a private-wallet-funding protocol on Aptos mainnet, modeled on Privacy Cash (Solana).
Let anyone fund an Aptos wallet with USDC from another Aptos source wallet, such that no on-chain observer can link the source to the destination. Tornado Cash for Aptos USDC. Public good, not a for-profit product.
- AIP-143 (Aptos's confidential assets framework) is the wrong tool for this. It hides transaction amounts; we need to hide the graph (source → destination linkage). Different problem, different crypto primitive.
- The right tool is a ZK commitment-nullifier pool. Pedersen commitments on deposit, Merkle tree accumulation, Groth16 ZK proofs on withdrawal. Exactly the Tornado Cash / Privacy Cash architecture.
- This does not depend on Aptos governance. USDC is a normal fungible asset — our pool contract holds it directly. We don't touch confidential APT at all. No dependency on Proposal #188.
- Regulatory posture is serious. Tornado Cash developers (Storm, Pertsev) are in criminal proceedings. Shipping requires a pseudonymous development pattern (like Privacy Cash's GitHub org: no location, no identified team, multisig upgrade authority, no hosted frontend under an identified entity).
- Primary reference implementation: Privacy Cash on Solana (
github.com/privacy-cash/privacy-cash). Anchor → Move port; Circom circuits reusable with minor changes; USDC-native instead of SOL.
research/— background research and technical analysis that informs the designdesign/— the concrete design for what we buildreference/— third-party code and docs we reference (Privacy Cash, Umbra, confidential_asset.move)legal/— open questions for a lawyer; regulatory analysis
research/01-problem-statement.md— what we're building and whyresearch/04-comparative-analysis.md— what Privacy Cash, Umbra, Railgun, Zcash, Aztec, Tornado each dodesign/architecture.md— the chosen architecturedesign/roadmap.md— phased build plan
- Not a company. Public-good protocol, not profit-seeking.
- Not using AIP-143. Framework restricts to APT and makes the wrong tradeoffs for this use case.
- Not a payment product. This is wallet-funding unlinkability, not interpersonal payments.
- Not retail-custody UX. No custom wallet. Users integrate via their existing Aptos wallets.
Shipping this is legally serious. US developers of mixer-style protocols have been prosecuted. Privacy Cash's operational pattern (pseudonymous GitHub org, multisig governance, no frontend under an identified entity) is the template that has survived. Before any code is written, the operational/legal structure must be decided.
See legal/compliance-notes.md for the open questions that need a qualified crypto attorney, not an AI.