Turn M Wallet into a product system the whole team can understand.
This site is the English source for internal development. It gives product owners the scope, frontend UI teams the interface direction, backend engineers the business objects and rules, chief engineers the system logic, marketing the narrative, brand teams the visual direction, and customer experience teams the user value.
Every team member should know exactly where to start.
This site is not a loose document archive. It is a role-based workbench with clear questions, deliverables, and review standards for each team.
Product Owner
Confirm scope, priorities, page entry points, MVP phases, and open product decisions.
View product boundaries Frontend UIFrontend UI
Understand page structure, component rhythm, status chips, asset marks, and navigation hierarchy.
View interface direction Product DesignProduct Designer
Turn identity, assets, payments, credentials, IBC, and Vault into one coherent user experience.
View design logic BackendBackend Engineer
Understand the boundaries for account, receipt, credential, invoice, policy, and audit objects.
View API needs Chief ArchitectChief Architect
Check whether modules, permissions, risk gates, and future expansion share one system logic.
View system logic MarketingMarketing
Explain in plain language that this is a trusted digital account, not a conventional wallet.
View narrative frame BrandBrand Team
Unify the M mark, FCA, USDF, MXCD Future, and the green identity system into one visual family.
View brand direction Customer ExperienceCustomer Experience
Identify the real advantages: trusted identity, recoverable wallet access, clear payments, complete records, and closed service loops.
View experience valueBuild the trusted account loop before adding complexity.
This section turns the product vision into a working release board. A module is not ready until the page, policy rule, backend object, receipt or audit event, and team handoff are all clear.
MID Account Spine
Verified MID, selected account, device session, passkey / biometric state, and MID Card binding.
MPC Daily Wallet
Daily signing, device share model, recoverable access, risk checks, cooling period, and security notices.
FCA / USDF Wallet
Primary FC Chain balances, receive, send, fee display, network state, and transaction receipt.
Pay and Receipts
QR contact, payment request, note, simple confirmation, receipt detail, and payment timeline.
IBC Company Account
Company account switcher, role checks, signed invoices, service payment, and company receipt archive.
Credential Center
MID card, address proof, tax number, IBC certificate, proof QR, and selective credential sharing.
Swap and Vault Card
Controlled FC ecosystem swap, quote policy, large-operation Vault signing, and protected asset flows.
External Assets
BTC, ETH, TRON, SOL, and BNB balance view, receive, send, confirmations, and risk prompts.
The product logic is simple: identity comes before financial capability.
Do not reduce M Wallet to an asset list. First help users understand their MID status, account context, and recovery posture. Assets, payments, IBC, credentials, and services should then appear as verified account capabilities.
MID Verified
The user owns or applies for a MID first. Sensitive actions and wallet recovery are linked to MID status, MID Card proof, account context, device session, and risk state.
Personal / IBC
The account is the container. Personal and company accounts carry different balances, roles, receipts, permissions, and service records.
Payments and Credentials
Verified identity unlocks payments, payment requests, Credential Center, official notices, and service payments.
MPC, Policy and Vault
Daily wallet control is recoverable through MID-based MPC policy; Swap, high-value payments, company reserves, credential sharing, and future MXCD require stricter policy rules and Vault Card protection.
More assets are not automatically better. The hierarchy must stay clear.
FCA, USDF, MXCD Future, and external assets serve different product roles. The interface should make those roles obvious instead of treating everything as a flat token list.
FCA
Native asset
FC Chain's native asset represents network fuel, infrastructure, and the ecosystem base. Its visual language should stay calm navy plus soft champagne.
USDF
Payment rail
A USD-denominated payment rail for early payments, service payments, and receipt-based settlement experience. It should feel stable, friendly, and easy to use.
MXCD Future
Policy gated
A future settlement asset concept with stronger sovereign characteristics. It should be presented as a future rail only, without implying formal availability today.
External Networks
Supported
BTC, ETH, TRON, Solana, and BNB Chain support balance view, receive addresses, and sending. They belong in the secondary wallet layer and should not enter Swap or dominate the product story.
Every page should revolve around account context and record keeping.
This is the core module map for development. Every module must answer: who is the user, which account is active, which actions are allowed, and what record is produced.
Home
MID status, account switching, balance overview, quick actions, pending requests, and official alerts.
Wallet
FCA, USDF, MXCD Future, external assets, receive, send, and Vault status.
Swap
USDF/FCA quote, rate, fee, policy check, confirmation, and receipt.
Pay
QR contacts, payment requests, notes, receipts, and confirmations without open-ended chat.
IBC
Company accounts, roles, invoices, receipts, service records, and company reserves.
Credential Center
Digital ID, driver license, address proof, tax number, company certificates, and proof QR.
Vault Card
NFC cold signing, high-value payments, company reserves, backup cards, and lost-card handling.
Broadcast
Official broadcasts, signature verification, renewal reminders, security alerts, and deep links.
Service Payment
Official invoices, payment rails, role verification, payment confirmation, and record archive.
Settings
Devices, Passkey, biometrics, limits, recovery method, and notification preferences.
Each feature needs one product, policy, data, and record definition.
Use this as the bridge between product design and engineering. If a row is incomplete, the feature is not ready for implementation.
user, mid, account, device_sessionmpc_policy, device_share, recovery_caseasset_balance, address, transaction, receiptcontact, payment_request, message, receiptswap_pair, quote, execution, policycompany, role, invoice, service_recordcredential, issuer, proof_request, consentmid_card, signing_payload, auth_eventvault_card, signing_session, protected_assetbroadcast, issuer_signature, notificationnetwork_adapter, external_address, chain_txUI direction: the ease of a modern bank wallet with the trust of an official identity system.
The interface should feel fresh, light, and trusted. It should not feel like an exchange, a heavy government portal, or a speculative crypto app.
MID Credential
Verified · Montserrat Digital ID
Total assets
Personal account · FC Chain
Payment request
Amina Joseph · 250 USDF · verified MID
Frontend UI Direction Interface
- Prioritize stable navigation: Home, Wallet, Pay, IBC, and MID.
- Use compact 8px-radius cards for assets, credentials, invoices, and receipts.
- Keep status chips consistent: Verified, Future, Policy, Due, Signed.
- Use the new soft FCA and USDF icons instead of heavier dark versions.
Product Design Direction Experience
- Each page should state identity and account context before functionality.
- Pay is structured payment communication, not social messaging.
- Credential Center can learn from Apple Wallet while preserving official identity trust.
- Vault Card should explain signing protection, not look like a normal bank card.
Brand Direction Brand
- The M mark belongs to M Wallet and the future MXCD green glass identity asset.
- FCA expresses infrastructure: navy, slate, and champagne.
- USDF expresses friendly payment: terracotta, coral, and soft champagne.
- Avoid heavy metal, black exchange styling, casino chips, and purple Web3 cues.
Customer Experience Value CX
- Users know the payment counterparty has been verified, reducing fraud anxiety.
- Service payments form a complete loop: invoice, signature, payment, and receipt.
- Personal and company accounts stay separate, reducing operational confusion.
- High-value actions require Vault Card, making security concrete and understandable.
The backend is not just wallet APIs. It is an identity-bound account system.
The core engineering objects are not tokens alone. They are user, MID, account, MPC policy, recovery case, credential, invoice, receipt, policy, and audit event.
user_id, mid_id, credential status, device sessionrecovery_case_id, device shares, MID Card proof, risk scoreaccount_id, account type, roles, policy profileEach team's working focus should be explicit enough to review.
These cards are the working checklist for each team when reviewing this guide.
Product Owner Scope
- Keep MVP focused on MID, Personal/IBC account, FCA/USDF, payment request, receipt, and Credential Center.
- Move MXCD Future, complex multichain flows, open chat, and advanced exchange into later phases.
- Define empty, error, permission, and success states for every page.
Backend Engineer API
- Account-level authorization is a prerequisite for every sensitive endpoint.
- Payments, external asset sends, Swap, credential sharing, MPC recovery, and Vault signing must create a receipt or audit event.
- Quote, invoice payment, recovery case, and signing session flows must support idempotency.
Chief Architect Architecture
- Check whether every module uses one shared account model.
- Check whether IBC, Vault, and Credential Center can scale as independent services.
- Check whether policy gates can cover future MXCD and official services.
Marketing Narrative
- Main story: a trusted digital account, not a conventional crypto wallet.
- For users: verified identity makes payments, services, credentials, and company accounts simpler.
- For government and partners: identity, receipts, official notices, and service payments form a closed loop.
The product should be reviewed through real user paths, not only modules.
These journeys show how identity, account context, payment, credentials, and records work together. They are also a practical checklist for product, design, backend, QA, marketing, and customer experience teams.
New MID Holder Activates Wallet
The user verifies MID, binds MID Card, creates the daily MPC wallet, receives FCA / USDF, and sees the first receipt.
- MID status confirmed
- Passkey, biometric, and MID Card bound
- MPC daily wallet enabled
- FCA / USDF receive address created
- First transaction receipt stored
Verified Payment Between Users
Two MID users add each other by QR, exchange a structured payment request, add a note, pay in USDF or FCA, and keep receipts.
- QR contact created
- Verified MID badge shown
- Payment request and note sent
- Payment confirmed with policy check
- Receipt available to both users
IBC Company Pays Official Invoice
A company operator switches to the IBC account, opens a signed invoice, passes role checks, pays, and archives the service receipt.
- Company account selected
- Role permission checked
- Official invoice signature verified
- USDF / FCA payment completed
- Receipt attached to company record
User Recovers Wallet After Losing Device
The user proves MID ownership, uses MID Card and risk checks, passes the recovery policy, and restores wallet access without exposing private keys.
- Recovery case opened
- MID holder and MID Card proof verified
- Risk score and cooling period applied
- New device share established
- Security notifications and audit trail created
User Shares an Official Proof
The user opens Credential Center, selects address proof or tax number, reviews the sharing scope, and generates a limited proof QR.
- Credential validity checked
- Sharing scope and expiry shown
- User confirms consent
- Proof QR generated
- Sharing record stored
Large Operation Requires Vault Card
A high-value send, company reserve movement, or protected swap triggers Vault policy and asks the user to tap the NFC Vault Card.
- Risk threshold reached
- Signing payload previewed
- Vault Card tap requested
- Signature verified
- Transaction and audit record finalized
Marketing narrative and experience value must match product logic.
External storytelling can be simpler, but it must not drift away from the internal product logic: MID-first, verified account, trusted payment, official records.
One-sentence Narrative
M Wallet turns a verified MID into a trusted digital account for payments, credentials, company services, and secure asset control.
Real Advantage
Users do not lose assets just because they forgot a seed phrase or lost a device. MID-based MPC recovery keeps wallet access recoverable while still controlled by strict identity and risk checks.
Narrative Boundaries
Do not present M Wallet as a high-yield wallet, trading tool, speculative stablecoin product, or already approved sovereign currency system.
Activation Metrics
MID verification completion, wallet creation completion, MID Card binding, MPC recovery setup, Passkey and biometric binding rate.
Payment Metrics
First receive, payment request creation, payment completion, receipt view rate.
Service Metrics
IBC account binding, official invoice open rate, service payment completion, receipt export rate.
Recommended build order: stabilize the trusted account loop first.
This is not a signal to build every feature at once. First prove the product logic with a working loop, then expand into complex assets and advanced security.
Identity and Account
MID status, account switching, FCA/USDF balances, receive, basic receipts, and notification entry.
Payment Layer
QR contacts, payment requests, payment notes, receipts, confirmation messages, and Pay timeline.
IBC Services
Company accounts, role rules, official invoices, service payments, and company receipt archive.
Advanced Control
Controlled Swap, Vault Card, external asset view/receive/send, and future MXCD policy gate.
Open decisions should move from discussion into ownership.
This log keeps unresolved questions visible without letting them blur the product direction. Each item has a recommended default, risk, owner, and next action.
Start by role, then use the full reference library.
This is no longer a plain file list. It is the working navigation for the M Wallet team, giving product, design, engineering, brand, market, government, and customer experience teams a shared way into the same product logic.
Recommended Use
Read this team guide first to understand the product north star, then enter the role-specific references. Every reference stays paired in EN / Chinese, with English as the source site and Chinese as the mirror for internal and external communication.
Version Status
The current package covers product logic, screen storyboard, function manual, engineering spec, interactive prototype, government architecture, asset marks, and ecosystem brand.
Product Owner
Confirm scope, MVP phase, permission rules, core flows, and open decisions before splitting PRD work.
Product Design and Frontend UI
Use the screen storyboard and interactive prototype to understand layouts, states, and scenarios for each feature page.
Backend and Chief Engineering
Use the engineering spec to organize accounts, MID, MPC, credentials, receipts, audit trails, and permission models.
Brand and Visual Assets
Review M Wallet, FCA, USDF, MXCD, and ecosystem relationships so asset hierarchy and mark usage stay consistent.
Government and Market Narrative
Use the government architecture page to align external language around MID-first, trusted accounts, official services, compliance boundaries, and future policy gates.
Customer Experience and Operations
Use the manual and storyboard to explain the user advantages: identity recovery, receipts, official notices, credential center, and secure signing.
Complete Reference Library
Use this library when you need a specific EN / Chinese paired document.