BSC Bridge (Deposit Side)
The bridge deposit happens on BSC — a normal EVM chain. Anything that signs secp256k1 works here.
| Wallet | Status | Notes | How |
|---|---|---|---|
| MetaMask (browser extension) | Supported | Native injection. Smoothest path. | Click "MetaMask" on /bridge |
| WalletConnect-compatible Trust, Rabby, OKX, Phantom (EVM mode), MetaMask Mobile, Ledger Live, ~50+ others |
Supported | QR code scan from any WC v2 wallet. | Click "WalletConnect" on /bridge |
| Ledger (hardware) connected via MetaMask / Rabby | Supported | Sign tx with hardware. Standard EVM tooling. | Connect Ledger to MetaMask, then connect MetaMask to /bridge |
| Coinbase Wallet / Brave Wallet / Any EIP-1193 injected wallet | Supported | Detected via window.ethereum — the "MetaMask" button auto-uses whichever EVM provider is injected. |
Standard EVM flow |
MXD Chain (Recipient + Native Wallets)
MXD chain uses Ed25519 or Dilithium5 — not secp256k1. Standard EVM wallets cannot sign MXD transactions. Today the only conformant client is the web wallet at /wallet.
| Wallet | Status | Notes | Reason |
|---|---|---|---|
| MXD Web Wallet (this site, /wallet) | Supported · Both algos | Ed25519 (MXD-02) and Dilithium5 (MXD-PQ-01) both fully implemented. Bit-exact against published test vectors. | Pure-JS via @noble/post-quantum + @scure/bip39; client-side keys, never leaves browser. |
| MetaMask (out of the box) | Not Supported | Cannot sign MXD transactions natively. | MetaMask only knows secp256k1 (EVM). MXD needs Ed25519 or Dilithium5. |
| MetaMask Snap (planned) | Planned | A MetaMask Snap could add MXD signing to MetaMask using your existing seed. Roadmap item. | Snaps API supports custom signers; @noble/post-quantum ML-DSA-87 works in Snap sandbox. |
| Ledger (native MXD app) | Future · Ed25519 only realistic | Ed25519 path is feasible (Solana/Polkadot apps prove it). Dilithium5 not realistic on current Ledger hardware (memory + perf). | Ledger Nano S+/X has ~30 KB RAM; ML-DSA-87 needs much more. |
| Phantom / Solflare (Ed25519 wallets for Solana) | Not Supported | They sign Ed25519, but expect Solana derivation path + tx format. Not directly usable. | Different BIP-44 coin type (501 vs 19800) and different tx serialization. |
| WalletConnect | Not applicable | WalletConnect is for EVM chains. MXD chain is not EVM. | WC negotiates EVM RPC methods; MXD's API is HTTP/JSON over a different shape. |
Can I Use the Same Seed Phrase for MetaMask and MXD?
Yes, technically — but they will be different accounts. A single BIP-39 mnemonic produces a single 64-byte seed; that seed can feed multiple HD trees with different derivation rules, and each tree gives independent keypairs:
m/44'/60'/0'/0/0— secp256k1 BIP-32 → MetaMask0x...address (BSC, ETH, etc.)m/44'/19800'/0'/0'— Ed25519 SLIP-10 → MXDmx...classical address (version0x32mainnet)m/44'/19800'/0'/0'with master"ml-dsa seed"— Dilithium5 → MXDmx...post-quantum address (version0x33)
All three keypairs derive from the same seed but the public keys are cryptographically independent — recovering one of them tells you nothing about the others. There is no single address that "is the same" in MetaMask and MXD.
Practical implication: if you reuse a seed across MetaMask and MXD Web Wallet, losing the seed compromises both wallets. Use a fresh seed for each isolated security domain.
Roadmap
| Item | Effort | When | Why |
|---|---|---|---|
| WalletConnect in /bridge | 2-3 days | Shipped | Mobile / no-extension users can now use the bridge from any WC v2 wallet. |
| MetaMask Snap for MXD signing | 2-3 weeks | Investigating | Reuse the MetaMask seed/UX; supports Ed25519 + Dilithium5 derivation inside Snap sandbox. |
| Mobile wallet (React Native) | 3-6 months | Post-traction | Reuses the existing JS wallet logic. Real engineering investment; gated on user demand. |
| Ledger native MXD app (Ed25519) | 1-2 months dev + Ledger review | Future | Hardware key storage for Ed25519 MXD wallets. Skip until ecosystem demand justifies it. |
| Ledger native MXD app (Dilithium5) | Unbounded | 2027-2028+ | Requires hardware with FIPS 204 support. NIST + vendors actively prototyping; no consumer device available today. |
For Wallet Integrators
If you're building a wallet that wants native MXD support, these are the normative specs:
- MXD-00 — Standards index. Read first.
- MXD-01 — Address format (addr32, version bytes, Base58Check).
- MXD-02 — Ed25519 BIP-39 + SLIP-10 derivation.
- MXD-03 — Signing & verification primitives.
- MXD-04 — Tx format + sighash.
- MXD-PQ-00 — PQ-Ready wallet conformance profile (optional).
- MXD-PQ-01 — Dilithium5 / ML-DSA-87 HD derivation.
Each spec has a *-test-vectors.json alongside it. A wallet that matches the vectors bit-exact is conformant.
Reference implementation: MXDNetwork/wallet-client (pure JS, no native dependencies).