AX Wallet is a client-sovereign P2P escrow architecture designed for mobile money corridors across emerging markets. Every user who opens the app generates a Zcash unified address (u1…) as their default wallet identity. The ZEC balance card sits first on the home dashboard. The unified address contains both a transparent receiver and an Orchard shielded receiver.
This is not a wallet that “supports ZEC” alongside twelve other chains. The Zcash unified address is the wallet. Users who downloaded the app to trade stablecoins in P2P markets walk away with a shielded-capable ZEC address by default. Over time, diaspora remittances, personal savings, and cross-border transfers naturally migrate to the asset users already see every day in their own wallet. The wallet does not force ZEC settlement — it makes ZEC the asset users already have.
The architecture is a template, not a single product. The escrow and consensus layer is corridor-agnostic. Adding a new country requires roughly 40 lines of Dart configuration — no contract deployment, no backend provisioning, no infrastructure changes. Four initial corridors serve as the proof of concept. The architecture itself is the product.
How P2P Escrow Works
The coordination layer operates entirely peer-to-peer with no centralized servers. Merchants broadcast trade offers to a Waku content topic over Tor. Users discover offers via narrow topic subscription, filtered by corridor (country), currency, stablecoin, and direction. Counterparties negotiate rate and terms in an encrypted Waku direct channel.
When terms are agreed, the locking party’s funds go into a single-use EIP-1167 escrow clone deployed via CREATE2. Each trade gets its own ephemeral contract address. No shared escrow pool exists to freeze, seize, or subpoena. The master factory contract holds zero tokens, zero mutable storage, and has zero admin keys. It is a pure deployment utility.
Fiat transfers happen entirely outside the app — through the user’s mobile money or banking app. AX Wallet coordinates the cryptographic proof of payment, not the payment itself. A dual-rail consensus protocol handles two scenarios:
- Bank transfers use a memo match. The fiat sender types a short natural phrase like “debt paid.” The app auto-appends a date-and-minute timestamp. The fiat receiver verifies the exact memo string in their banking app and confirms with one tap.
- Mobile money uses a mutated amount match. The app adds a unique integer offset to the transfer amount, for example, 30,000 KES becomes 30,014 KES. The fiat receiver verifies the exact mutated amount in their mobile money app and confirms receipt.
Once settlement is confirmed, the clone verifies the consensus proof cryptographically, releases funds atomically, zeroizes every internal storage slot back to zero, and executes selfdestruct. Zero persistent on-chain footprint per trade. The clone address becomes dead code the moment settlement completes.
Architecture
All network traffic routes through Tor SOCKS5 at 127.0.0.1:9050. Critical on-chain data uses 2-of-3 endpoint consensus — three independent lightwalletd or RPC endpoints queried simultaneously, majority result accepted within milliseconds. The Rust native core handles key derivation, ECDSA signing, memo hash computation, Waku transport, and ZK proving — all isolated from the Dart heap.
Flutter (Dart) Frontend
↕ FFI
Rust Native Core
↕ Tor SOCKS5 (all traffic through 127.0.0.1:9050)
├── lightwalletd ── Zcash balance sync (2-of-3 endpoint consensus)
├── Waku ── P2P discovery, encrypted chat, consensus signature relay
└── BSC RPC ── StatelessConsensusFactory → EIP-1167 Clones
On-Device: SQLCipher (256-bit AES) + Secure Enclave / StrongBox TEE
ZK Privacy: fee_vault.noir · prove_memo_knowledge.noir · swap_intent.noir
Waku content topics reveal corridor metadata to relay nodes — country, currency, token symbol, and trade direction. This is required for pub/sub routing and cannot be hidden from relay nodes. IP addresses are Tor-masked. Routing PeerIDs rotate per trade session. The privacy boundary is published and accepted: relays see what corridor you are trading in but not who you are or where your packets originated.
Fiat payment routing data — bank account numbers, mobile money numbers, Pix keys — flows exclusively as unstructured plaintext in the encrypted in-app chat. The app never parses, validates, or indexes this data. No dedicated form fields for payment routing exist anywhere in the UI. After settlement, all trade data including chat history and routing text is zeroized and purged from the local SQLCipher database on a 12-hour timer. An Instant Clear button provides immediate cryptographic erasure of all finalized trade data.
Corridors
Initial focus covers four Wave 1 corridors: Nigeria (NGN via Opay, Palmpay, bank transfer), Kenya (KES via M-Pesa, bank transfer), Ghana (GHS via MTN MoMo, Vodafone Cash), and Brazil (BRL via Pix). Both Cash-In (fiat to crypto) and Cash-Out (crypto to fiat) directions are supported. The architecture is designed to expand to additional corridors through configuration alone — no contract changes, no backend work.
Research Docs
The full architecture, threat model, corridor analysis, technical stack specification, and UX wireframes are documented here:
GitHub Tree: ax-wallet/axwallet-core-research at main · AX-Wallet/ax-wallet · GitHub
The repo contains six specification documents. README.md is the master plan covering protocol flow, privacy boundaries, the retention engine, and regulatory analysis. STACK.md covers cryptographic primitives, smart contract invariants, ZK circuit specifications, memory budgets, and gas budgets. MARKET_RESEARCH.md contains corridor data, regulatory landscape by country, user personas, and addressable market analysis from the perspective of the un-documented. UX_WIREFRAMES.md is the full UI specification with layout invariants, color tokens, onboarding flow, and accessibility standards. CORRIDOR_MAINTENANCE_GUIDE.md is the community runbook for adding new fiat corridors. DSI_BRIDGE_SPEC.md covers cross-chain ECDSA signature compatibility for multi-chain escrow.
Everything is open-source under the MIT License.
Feedback
This is pre-implementation research. The architecture is fully specified but nothing has been built yet — which means nothing is locked in.
If you read through the docs and have thoughts — features you would want to see, concerns about the approach, corridors you think should be prioritized, components you would contribute to, anything at all — reply here, open an issue on the repo, or start a Discussion. The specification is detailed enough that specific, technical feedback is possible. The project is early enough that directional feedback is equally valuable.