M Wallet green glass mark
M Wallet Team Development Guide
Internal alignment website

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.

MID-first FC Chain rails IBC account Credential cards Vault Card Official services
Role-based entry

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 logic

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.

Identity

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.

Account

Personal / IBC

The account is the container. Personal and company accounts carry different balances, roles, receipts, permissions, and service records.

Capability

Payments and Credentials

Verified identity unlocks payments, payment requests, Credential Center, official notices, and service payments.

Control

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.

Asset hierarchy

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
FCA asset mark

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
USDF asset mark

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
MXCD future mark

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
External network asset mark

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.

Functional modules

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.

Entry

Home

MID status, account switching, balance overview, quick actions, pending requests, and official alerts.

Money

Wallet

FCA, USDF, MXCD Future, external assets, receive, send, and Vault status.

Exchange

Swap

USDF/FCA quote, rate, fee, policy check, confirmation, and receipt.

Payment

Pay

QR contacts, payment requests, notes, receipts, and confirmations without open-ended chat.

Business

IBC

Company accounts, roles, invoices, receipts, service records, and company reserves.

Identity

Credential Center

Digital ID, driver license, address proof, tax number, company certificates, and proof QR.

Security

Vault Card

NFC cold signing, high-value payments, company reserves, backup cards, and lost-card handling.

Official

Broadcast

Official broadcasts, signature verification, renewal reminders, security alerts, and deep links.

Service

Service Payment

Official invoices, payment rails, role verification, payment confirmation, and record archive.

Control

Settings

Devices, Passkey, biometrics, limits, recovery method, and notification preferences.

Design direction

UI 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.

9:41MID
M Wallet app icon
M WalletMID verified account

MID Credential

Verified · Montserrat Digital ID

Total assets

$2,847.90

Personal account · FC Chain

FCA
FCANetwork fuel
128.4
USDF
USDFPayment rail
2,250
Send
Request
Swap
Receive
Scan

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.
Engineering view

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.

Domain
Core Objects
Required Checks
Required Output
Identity
user_id, mid_id, credential status, device session
MID active state, trusted device, and step-up requirement
Verification state, audit event, credential lifecycle
MPC Recovery
recovery_case_id, device shares, MID Card proof, risk score
MID holder proof, device risk, cooling period, review status
New device share, recovery audit trail, security notifications
Account
account_id, account type, roles, policy profile
Personal or IBC match, role permission, account status
Account context, permission result, risk message
Wallet
Balances, assets, network status, receive addresses, send transactions
Asset availability, network state, address validation, fee policy, limits, and risk controls
Balance view, receive address, send state, confirmation count, receipt, audit event
Payment
Contact, payment request, note, receipt, confirmation
Verified contact state and allowed message type
Structured message, payment status, receipt
IBC
Company, role, invoice, service record, receipt
Company status, role permission, invoice signature
Company record, payment receipt, service archive
Vault
Vault Card, signing session, protected assets
Signing payload, NFC card, biometric signal, card status
Signing result, transaction broadcast, audit record
Role playbooks

Each 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.
Narrative and metrics

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.

Build roadmap

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.

Phase 1

Identity and Account

MID status, account switching, FCA/USDF balances, receive, basic receipts, and notification entry.

Phase 2

Payment Layer

QR contacts, payment requests, payment notes, receipts, confirmation messages, and Pay timeline.

Phase 3

IBC Services

Company accounts, role rules, official invoices, service payments, and company receipt archive.

Phase 4

Advanced Control

Controlled Swap, Vault Card, external asset view/receive/send, and future MXCD policy gate.

Open decisions

These decisions should be settled before PRD and engineering planning.

They do not block the guide, but they will shape the next product specification and technical design.

USDF Boundary

Unify legal disclosure, reserve language, and the relationship between USDF and future MXCD across product and marketing materials.

IBC Launch Scope

Decide which services enter the first release: registration, renewal, certificates, address proof, or tax number services.

Vault Card Timing

Decide whether MVP includes binding entry or presents Vault Card as an advanced security concept first.

External Asset Capability

View, receive, and send are the baseline for any supported external asset. Decide launch networks, send limits, fee policy, confirmation rules, and risk controls; external-chain Swap remains out of scope.

Official Broadcast Console

Define publisher identity, signature verification, priority, deep links, and audit records.

Credential Launch Cards

Decide whether MID, Address Proof, Tax Number, and IBC Certificate should launch before Driver License.

Handoff files

Use these files as the next entry points for team work.

This guide is the overview. Product, visual, engineering, and government-facing materials remain available as deeper references.