# M Wallet Product Function Manual (Product Owner Edition) Version: 2026-04-26 Purpose: Align product owners, design leads, backend leads, chief engineers, marketing, brand, and customer experience teams on product scope, page logic, functional priority, and acceptance standards. Related files: - `M_Wallet_Product_Function_Manual_EN.html`: English web version of this function manual - `M_Wallet_Product_Function_Manual.html`: Chinese web version - `M_Wallet_Product_Function_Manual.md`: Chinese Markdown source - `M_Wallet_Team_Development_Guide.html`: English team development guide - `M_Wallet_Team_Development_Guide_ZH.html`: Chinese team development guide mirror - `M_Wallet_Screen_Flow_Storyboard.html`: full paginated visual storyboard - `MID_Wallet_Product_Concept.html`: interactive product concept prototype - `M_Wallet_Detailed_Page_Spec_For_Engineering.html`: detailed page specification for engineering - `M_Wallet_Product_Architecture_Government_Use_Case.html`: government / investor narrative version --- ## 1. Product Positioning M Wallet is not just a crypto wallet, and it is not merely an asset tool for trading. Its core positioning is: **Starting from MID / Digital ID, M Wallet places verified identity, financial capability, company accounts, public services, credential cards, and secure signing capability into one trusted account system.** The product narrative should always follow this order: 1. The user first owns or applies for a MID digital identity. 2. After MID verification, the user receives personal wallet, payment, asset, credential, and service-payment capabilities. 3. If the user owns an IBC company identity, the user can switch to a separate IBC company wallet account. 4. High-value assets, company reserves, and future MXCD-related capabilities are protected by Vault Card and policy rules. One-sentence product expression: > M Wallet is a MID-first digital account that connects verified identity, trusted payments, company services, credentials, and secure asset control. --- ## 2. Product Principles ### 2.1 Identity First Every important operation must be associated with: - `user_id` - `mid_id` - `account_id` - current device session - risk status - audit record The page experience must reflect this logic. Users should not first see "coins"; they should first understand who they are, how far their identity is verified, and which account they are currently operating. ### 2.2 Accounts Are Containers The product should include at least the following account types: | Account type | Purpose | Notes | |---|---|---| | Personal Account | Personal assets, payments, credentials | Default home account | | IBC Account | Company wallet, invoices, receipts, service records | Bound to company registration and role permissions | | Vault Account | Protection for high-value assets and company reserves | Cold signing triggered by an independent Vault Card | | Merchant / Agent Account | Future service providers, agents, merchants | Future extension | Product design must make it clear which account the user is operating, especially so Personal and IBC actions are never confused. ### 2.3 Payment Communication Is Structured Messaging, Not Open Chat Payment communication supports only: - adding verified contacts - payment requests - payment notes - receipts - simple confirmation messages The MVP should not include open-ended chat. This avoids uncontrolled content moderation, fraud, compliance, and customer support burden. ### 2.4 Receipts Are Core Records Every key action should produce a record: - payment receipt - Swap receipt - service-payment receipt - IBC invoice payment receipt - credential sharing record - Vault Card signing record - official broadcast read / acknowledgement record When designing any new feature, product owners should ask: should this action create a receipt or audit event? ### 2.5 Future Capabilities Must Be Policy-Isolated MXCD, Montserrat stablecoin, government service payments, and similar capabilities must be expressed as future / policy-gated / subject-to-approval. The product must not imply that they are already legal tender, official currency, or authorized settlement instruments. Recommended wording: > USDF is the USD-denominated payment rail of the FC Chain ecosystem, intended for early digital payment use cases and designed to remain capable of future interoperability with a regulated Montserrat dollar-denominated settlement asset such as MXCD, subject to all applicable approvals and policy decisions. Operational meaning: > USDF should be presented as an FC Chain ecosystem payment rail for early USD-denominated digital payment scenarios, with future interoperability reserved for approved Montserrat dollar-denominated settlement assets such as MXCD, subject to applicable approvals, regulation, and policy decisions. ### 2.6 MID Card, MPC Wallet, and Vault Card Are Three Distinct Capability Layers M Wallet security and signing capabilities should not be described only as "hot wallet / cold wallet." The product should clearly distinguish three capability layers: | Capability layer | Positioning | Main use | Notes | |---|---|---|---| | MID Card | Basic identity and signing card | Identity authentication, login confirmation, basic signing, account binding | MID Card itself is an NFC card and can store private-key material or secure credential material for authentication and basic wallet signing | | MPC Wallet | Daily wallet key architecture | Daily payments, receiving, account recovery, device-coordinated signing | Reduces single private-key risk and is suitable as the foundational in-app wallet capability | | Vault Card | High-value cold signing card | Large assets, company reserves, future high-security scenarios | Not the same as MID Card and must not be confused with a small-balance card or basic identity card | Product expression principles: - MID Card is part of the foundational wallet capability, not an extra "small-balance card." - MID Card handles identity authentication and basic signing, helping the user prove "I am the lawful holder of this MID." - MPC Wallet handles daily wallet security and recovery without requiring users to understand complex private-key concepts. - Vault Card protects high-value assets and company reserves through cold signing for higher-risk operations. - The UI must clearly distinguish `MID Card` from `Vault Card`; their colors, copy, and trigger scenarios should not be mixed. ### 2.7 Core MPC Wallet Difference: Recovery Through MID Identity MPC Wallet is a key M Wallet capability that differentiates it from ordinary digital currency wallets. Ordinary wallets usually ask users to store a seed phrase; if users lose a device, forget the seed phrase, or delete a wallet by mistake, they may permanently lose their digital assets. M Wallet should not make users bear that irreversible risk. Instead, through MID holder identity authentication, MID Card, device risk checks, MPC policy signing, and a rigorous recovery process, users can securely recover lost wallet capability. Product value: - Users do not lose digital assets simply because they forgot seed phrases, deleted the app by mistake, or lost devices. - Wallet recovery is based on MID holder identity, not a customer-support "password reset." - The recovery process must be rigorous, secure, and auditable, without weakening asset-control security. - After successful recovery, the system should establish a new device share or signing policy rather than exposing the old private key. Recovery principles: | Principle | Product requirement | |---|---| | Identity first | Before recovery, confirm that the user is the lawful MID holder | | Multi-factor verification | MID Card, Passkey / biometric, device risk, and official records can be combined | | No private-key exposure | Recovery must not expose the complete private key to the user, customer support, frontend, or server | | Policy-gated | High-risk recovery requires a cooling period, manual review, or higher-level authentication | | Fully audited | Every recovery step must create an audit event and security notification | --- ## 3. Core Users and Roles ### 3.1 Personal Users Goals: - complete MID verification - hold FCA / USDF - use MID NFC Card for basic authentication and signing - use MPC Wallet for daily payments and recovery - scan QR codes to add contacts - initiate payment requests or payments - store digital credentials - receive official notifications - use Vault Card to protect large assets Main entry points: - Home - Wallet - Pay - MID / Credential Center - Notifications ### 3.2 IBC Company Users Goals: - manage company wallet - pay company service fees - view company invoices and receipts - manage company roles - store company certificates - use Vault Card to manage company reserves Recommended roles: | Role | Permissions | |---|---| | Owner | Full control, payments, approvals, Vault operations | | Director | Payment approvals, service applications, receipt viewing | | Agent | Service applications, document submission, designated record viewing | | Accountant | Read-only accounting, receipt export | ### 3.3 Government / Registry / System Broadcast Operators Goals: - send official broadcasts - issue service invoices - verify credentials - attach receipts to service records - remind users about renewal, verification, risk, or policy updates These roles do not necessarily appear in the foreground of the first App release, but the product logic should reserve space for backend systems. --- ## 4. Assets and Payment Rails ### 4.1 FCA Positioning: - FC Chain native asset - network fuel - foundational ecosystem asset - usable for certain fees or network operations Design recommendation: - Color: soft navy / slate blue + champagne silver - Feeling: infrastructure, reliability, technical foundation - Avoid: excessive heaviness, excessive black, speculative tone, overdone metallic style ### 4.2 USDF Positioning: - USD-denominated payment rail inside the FC Chain ecosystem - primary stable payment unit for early user payments and service fees - reserves space for future interoperability with MXCD or other approved settlement assets Design recommendation: - Color: terracotta / coral / rose-burgundy + soft champagne - Feeling: stable, payment-friendly, relaxed, approachable - Avoid: casino-chip feeling, strong gold, speculative stablecoin tone ### 4.3 MXCD Future Positioning: - future Montserrat stablecoin / settlement asset concept with stronger sovereign characteristics - currently expressed only as a future / policy-gated rail inside the product Design recommendation: - use the green glass M mark - show `Future`, `Policy-gated`, and `Subject to approval` - do not show available balance unless future policy is explicit ### 4.4 External Assets Initial support scope: - BTC - ETH - TRON - Solana - BNB Chain Capability boundaries: - support balance display - support receive address and QR generation - support sending external-chain assets - support transaction status, network fee, confirmations, and failed-state display - support receipt and audit event - do not support Swap between external assets - do not support cross-chain bridge aggregation - do not support DEX aggregation or speculative trading features Design principles: - External assets should not take over the Home narrative. - They should live in the Wallet page under "Supported networks" or "External assets." - FC Chain rails (FCA / USDF / MXCD Future) must remain the primary hierarchy. - If an external asset appears in the "supported" list, it must not only support viewing and receiving; it must also support sending. Otherwise, user assets can enter but cannot properly leave, creating an incomplete experience. --- ## 5. Information Architecture Recommended bottom navigation: | Tab | Meaning | Main functions | |---|---|---| | Home | Home | MID status, account switching, asset overview, quick actions | | Wallet | Wallet | FCA, USDF, MXCD Future, External assets, Swap, Vault | | Pay | Pay | Scan QR to add friends, payment requests, notes, receipts | | IBC | Company account | Company wallet, roles, invoices, receipts, service records | | MID | Identity center | Digital ID, MID Card, driver license, address proof, tax number, certificates | Secondary entry points: - Notifications / Official Broadcast - Settings and Recovery - Service Payment - Receipt Detail - MID Card - MPC Wallet - Vault Card Global components: - current account switcher: Personal / IBC - MID verification status - MID Card status - MPC Wallet status - notification entry - scan entry - receipt entry - security status prompt --- ## 6. Page Function Manual ### 6.1 Home: MID-first Home Page goal: When users open the App, they should immediately know: - whether their MID is valid - which account they are in - what available balances they have - what they can do now - whether there are pending payments, official notifications, or service items Core modules: - top user identity area: avatar, MID Verified, notifications - account switcher: Personal / IBC - MID Credential card - total assets and main changes - compact FCA / USDF asset cards - quick actions: Send, Request, Swap, Receive, Scan - Latest verified payment request - Official Broadcast / Security alert summary Key actions: - switch accounts - open payment - open scan - open Swap - view receipt - view official notification States: - wallet not created - MID not verified - MID under review - MID verified - pending payment request - unread official broadcast - IBC Account available Product acceptance: - Users can understand current identity status and account status within 3 seconds. - Personal / IBC switching is clear and prevents paying from the wrong account. - Quick actions should not exceed 5 primary buttons. - Unverified users see verification guidance, not full payment capability. --- ### 6.2 Wallet: Assets and Payment Rails Page goal: Show the primary FC Chain ecosystem assets and supported external networks while keeping FCA / USDF in the primary hierarchy. Core modules: - Primary FC Chain rails - FCA - USDF - MXCD Future - Swap entry - Receive / Send entry - External assets - BTC - ETH - TRON - SOL - BNB - View / Receive / Send status - MID Vault Card module - network status and fee prompts Key rules: - FCA and USDF are first-screen primary assets. - MXCD displays only as Future / Policy-gated. - External assets appear as supported networks and should not make the product look like an exchange. - External assets support view, receive, and send. If an external network does not yet support sending, it should not be shown as an available asset in the production wallet. - External asset sending must include chain-type confirmation, address-format validation, network-fee estimation, arrival confirmations, pending / failed states, and receipt records. - External assets do not enter the Swap pool and do not support swaps between external-chain assets. - Large sends should trigger Vault Card or higher-level verification. Product acceptance: - Users understand that FCA is the native asset and USDF is the payment rail. - Users do not mistakenly believe MXCD is already formally available. - Users can view balances, receive, and send supported BTC / ETH / TRON / SOL / BNB. - External assets appear only as support capabilities; they do not dominate the product or turn it into an exchange. --- ### 6.3 Swap: Controlled Exchange Page goal: Support controlled exchange between FC Chain ecosystem currencies and introduced ecosystem currencies. The MVP prioritizes USDF / FCA. The product goal of Swap is to serve the closed-loop FC ecosystem, not to provide external-chain token swap, cross-chain trading, or bridge aggregation. Core modules: - From asset - To asset - Amount - Quote - Rate - Fee - Route - Policy check - Preview - Receipt MVP support: - USDF -> FCA - FCA -> USDF Future support: - exchange between new currencies inside the FC ecosystem - approved partner or introduced ecosystem currency exchange - MXCD-related exchange, which must be policy-gated Explicitly not included: - swap between external-chain assets such as BTC / ETH / TRON / Solana / BNB Chain - cross-chain bridge aggregation - DEX aggregation - high-leverage or speculative trading features Key rules: - Quotes must have an expiration time. - Execute must use an idempotency key. - Large Swap requires Vault Card. - Every Swap must produce a receipt. - Swappable assets must come from product allowlists and policy configuration. - External assets do not enter the Swap pool even if they support viewing, receiving, or sending. Product acceptance: - Users see rate, fee, expected arrival, and policy status before confirmation. - Expired quotes cannot be executed. - After successful Swap, receipts can enter History / Receipt Detail. - Users do not understand M Wallet as a traditional digital currency trading wallet. --- ### 6.4 Pay: QR Contacts and Payment Communication Page goal: Let users add verified contacts through QR and form structured communication around payments. Core modules: - QR Scan - Verified contact card - Payment request - Payment note - Receipt - Confirmation Allowed message types: - `contact_card` - `payment_request` - `payment_note` - `receipt` - `confirmation` Not included: - open-ended chat - arbitrary image / file sending - group chat - voice - socialized emoji behavior Key rules: - Payment requests must bind amount, asset, payee, and expiration time. - Notes must bind to a payment or receipt. - Receipts must bind to an on-chain or ledger transaction. - Unverified contacts cannot initiate formal payment requests. Product acceptance: - Pay feels like payment collaboration, not social chat. - Every message can be categorized into one business type. - After payment completion, Receipt is generated automatically and can be shared or archived. --- ### 6.5 IBC Account: Company Wallet Account Page goal: Provide an independent account space for IBC companies to manage company funds, invoices, roles, and service records. Core modules: - company identity header - company status - Operating wallet - Vault reserve - Roles - Invoices - Receipts - Service applications - Renewal reminders Roles: - Owner - Director - Agent - Accountant Core flow: 1. User MID is verified. 2. User creates or binds an IBC company. 3. System assigns a company account. 4. Owner configures roles. 5. Company receives an official invoice. 6. Authorized role pays. 7. System generates a receipt and attaches it to the company record. Key rules: - IBC payments must check company roles. - Official invoices must have signature verification. - Large company payments require Vault Card. - Company receipts must support export. Product acceptance: - Users clearly understand this is a company account, not a personal account. - Every company payment has an invoice, authorizer, payment rail, and receipt. - Accountant can view and export but cannot pay. --- ### 6.6 Credential Center Page goal: Store users' important digital cards and certificates in a way similar to Apple Wallet. Card types: - MID Digital ID - Driver License - Address Proof - Tax Number - IBC Certificate - Good Standing Certificate - future government or official credentials Card states: - Pending review - Verified - Expiring soon - Renewal required - Revoked - Archived Key actions: - view card - share limited proof - generate proof QR - apply for renewal - attach to IBC service Key rules: - Credential sharing requires user confirmation. - Proof should have an expiration time. - Revoked credentials cannot continue to be shared. - Every sharing action should create an audit record. Product acceptance: - Users understand certificates as easily as Apple Wallet cards. - Status colors and actions for different credentials are clear. - Credential sharing clearly displays the sharing scope. --- ### 6.7 MID Card: Basic NFC Identity and Signing Card Page goal: Make MID Card clear as M Wallet's foundational identity and signing capability. MID Card itself is an NFC card that can store private-key material or secure credential material for identity authentication, account binding, login confirmation, and basic wallet signing. It is not a small-balance card and not a high-value asset cold-wallet card. Its core value is that users own a touchable, verifiable, signable hardware credential for their MID identity. Core modules: - MID Card status - NFC card binding - Identity authentication - Basic signing - Device pairing - Recovery relationship - Signing history Typical uses: - User proves possession of the MID Card through NFC tap. - During new-device binding or account recovery, MID Card acts as a strong authentication factor. - During basic wallet operations, MID Card can participate in signing or authentication confirmation. - During credential sharing or important account operations, MID Card can provide identity confirmation. Key rules: - MID Card and Vault Card are two different product concepts. - MID Card is a foundational wallet and identity authentication capability and should appear in MID / Credential Center / Security settings. - MID Card should not be described as a high-value asset cold wallet and should not be designed as a "small-balance wallet." - In-card private keys or secure credential material must not be exposed to the App, frontend, or server. - Lost card, replacement, unbinding, and reissue flows must all create security notifications and audit records. Product acceptance: - Users understand MID Card as "my digital identity card," not an ordinary bank card. - Users understand that NFC tap is an authentication and signing action, not a card-payment action. - The product clearly explains the difference between MID Card and Vault Card. --- ### 6.8 Vault Card: NFC Cold Wallet / High-Value Signing Card Page goal: Provide Tangem-like NFC card cold-wallet capability for large assets, company reserves, and future high-security scenarios. Vault Card is the high-value asset protection layer, not the foundational MID Card and not a daily small-balance wallet. Core modules: - Primary Vault Card - Backup Cards - Protected assets - Tap-to-sign flow - Lost card flow - Signing history Signing flow: 1. User initiates a large operation. 2. System displays a human-readable payload. 3. User confirms with biometric. 4. User taps NFC Vault Card. 5. Card signs. 6. App broadcasts the transaction. 7. System generates receipt and audit record. Key rules: - Card private keys must not be exposed. - Before tap, the user must understand the signing content. - Lost cards must be disableable. - Backup card binding requires higher-level authentication. Product acceptance: - Users understand Vault Card as security protection, not an ordinary bank card. - Users do not confuse Vault Card with MID Card. - Large operations have a clear pre-signing preview. - Lost-card and backup-card flows have clear entry points. --- ### 6.9 Official Broadcast: Official Broadcasts and Notifications Page goal: Provide a trusted notification channel for government, registry, or system operators. Notification types: - Official broadcast - Payment request - IBC invoice - Credential renewal - Security alert Key modules: - signature status - issuer - priority - target account - Action deep link - read status Key rules: - Official notifications must verify signatures. - Notifications with failed signatures must be isolated or warned. - High-priority notifications can be pinned. - Notifications should deep link to payment, IBC, credential, or security pages. Product acceptance: - Users can distinguish official notifications from ordinary payment reminders. - Official notifications are not designed as advertising messages. - Every actionable notification has a clear next step. --- ### 6.10 Service Payment: Official Service Payment Page goal: Complete the closed loop from official invoice to payment, receipt, and service-record archive. Core modules: - Invoice summary - Issuer signature - Accepted assets - Account / role check - Payment confirmation - Receipt - Service record Typical scenarios: - IBC annual renewal - company registration service - certified document application - certificate renewal - future government service payment Key rules: - Only invoices with verified signatures can be paid. - IBC invoices must check roles. - After successful payment, the receipt is attached to the service record. - Payment APIs must support idempotency key. Product acceptance: - Users see invoice source and signature status. - Users know whether they are paying with FCA or USDF. - After payment, receipts can be exported, shared, or entered into IBC record. --- ### 6.11 Settings and Recovery: Security Settings Page goal: Manage devices, authentication methods, limits, recovery methods, notification preferences, and export controls. Core modules: - Trusted devices - MPC Wallet status - MID Card binding - Passkeys - Biometrics - Payment limits - Swap limits - Recovery methods - Backup Vault Cards - Notification preferences Key rules: - Device removal requires step-up authentication. - Raising limits should have a cooling period or approval. - Changing recovery methods should trigger security notifications. - Exporting sensitive information must record audit events. Product acceptance: - Users can manage devices and recovery methods. - Higher-risk actions are not hidden inside ordinary settings. - Security events appear in notifications and audit records. --- ### 6.12 MPC Wallet: Daily Wallet Key Architecture Page goal: Build M Wallet's daily wallet capability on MPC architecture, reduce single private-key risk, and let MID holders securely recover wallet capability through rigorous identity authentication and policy flow if they lose devices, delete the wallet by mistake, or forget a traditional seed phrase. MPC Wallet is the underlying daily wallet capability inside the App and should not be understood by users as an additional asset account. Core modules: - MPC wallet status - Device key share - Server / policy co-signing - Identity-based recovery - Recovery case status - Step-up authentication - Signing policy - Cooling period - Key rotation - Audit events Typical uses: - Daily small payments are signed by MPC Wallet. - If users lose a device or delete the App by mistake, they can use MID Card, Passkey, biometric, device risk checks, and recovery policy to establish a new device share. - If users forget a traditional seed phrase, they do not directly lose digital assets, because recovery is based on MID holder identity and MPC policy rather than a phrase solely stored by the user. - For high-risk or large operations, MPC Wallet first performs policy checks and then escalates to MID Card or Vault Card. - IBC Account can later extend into a multi-role, multi-approval MPC signing model. Key rules: - A single device should not independently control the complete private key. - Users do not need to understand or personally store a seed phrase; the product should turn recovery into an explainable, verifiable, auditable identity recovery flow. - Before wallet recovery, the system must confirm that the user is the lawful MID holder and check MID status, MID Card status, device risk, and recovery policy. - High-risk recovery should support cooling periods, manual review, limit freeze, or temporary read-only mode. - After recovery, the system should establish a new device share or signing policy and must not expose the old private key. - MPC signing policy must record audit events. - Recovery, new-device binding, and key rotation must trigger security notifications. - MPC Wallet is the daily wallet foundation; Vault Card is the high-value cold signing capability. The two must not be confused. Product acceptance: - Users feel that the wallet is recoverable and protected, not frightening because of seed phrases. - Users know that "recover wallet" is not a casual customer-service reset, but a process completed jointly by MID identity and security policy. - Backend teams can clearly distinguish daily MPC signing, MID Card identity signing, and Vault Card cold signing. - Every critical key-state change has an audit record and user notification. --- ## 7. Core User Flows ### 7.1 New User Entry 1. User opens M Wallet. 2. User checks MID verification status. 3. If the user has no MID, guide application or binding. 4. Guide MID NFC Card binding. 5. Establish MPC Wallet daily signing capability. 6. After MID approval, create Personal Account. 7. Display FCA / USDF wallet capability. 8. Guide Passkey / biometric setup. 9. Enter Home. ### 7.2 Payment Request 1. User enters Pay. 2. User scans MID QR or selects a verified contact. 3. User selects Payment Request. 4. User enters amount and asset, such as USDF. 5. User adds a structured note. 6. User sends the request. 7. Counterparty confirms payment. 8. Receipt is generated. ### 7.3 Pay Official Service Invoice 1. User receives Official Broadcast or IBC invoice. 2. User opens Service Payment. 3. System verifies issuer signature. 4. User selects payment rail: USDF or FCA. 5. System checks personal or IBC role permission. 6. User confirms payment. 7. System generates receipt. 8. Receipt is attached to the service record. ### 7.4 IBC Company Account Payment 1. User switches to IBC Account. 2. User views company invoice. 3. System displays payable roles. 4. Owner / Director confirms. 5. Large payment triggers Vault Card. 6. Payment succeeds. 7. Receipt is archived to company record. ### 7.5 Vault Card Large Signing 1. User initiates a large transfer or company reserve operation. 2. System determines that Vault Card is required. 3. User views the human-readable payload. 4. User confirms with biometric. 5. User taps NFC Card. 6. Card signs. 7. App broadcasts the transaction. 8. System generates receipt and audit event. ### 7.6 MID Card Basic Authentication and Signing 1. User enters MID / Security page. 2. System displays MID Card binding status. 3. User taps MID NFC Card. 4. App verifies card possession status and signature response. 5. System confirms that the user is the lawful holder of this MID. 6. User can complete new-device binding, basic wallet signing, credential sharing confirmation, or account recovery steps. 7. System generates authentication record or signing audit event. ### 7.7 MPC Wallet Identity Recovery 1. User loses device, deletes wallet by mistake, or cannot access the original device. 2. User selects Recover M Wallet on a new device. 3. System requires MID identity verification. 4. User taps MID NFC Card and passes Passkey / biometric or other step-up verification. 5. System checks MID status, card status, device risk, recent abnormal operations, and recovery policy. 6. Low-risk recovery can enter automated recovery; high-risk recovery enters cooling period, manual review, or temporary read-only mode. 7. MPC Wallet establishes a new device share or signing policy. 8. System sends security notifications to old devices, bound email / notification channels, and the official audit system. 9. After recovery, the user re-enters the wallet, while high-risk assets or large operations may continue to require Vault Card. ### 7.8 External Asset Receiving and Sending Receive flow: 1. User enters Wallet. 2. User selects one supported asset among BTC / ETH / TRON / SOL / BNB. 3. User selects Receive. 4. System displays the corresponding network, receive address, QR, minimum deposit prompt, and confirmation explanation. 5. After arrival, the asset displays pending / confirmed status. 6. System generates a deposit record and receipt / audit event. Send flow: 1. User enters Wallet and selects an external asset. 2. User selects Send. 3. System requires chain-type confirmation to avoid address and network mismatch. 4. User enters or scans the recipient address. 5. System completes address-format validation, risk check, balance check, and network-fee estimation. 6. User confirms amount, fee, estimated arrival time, and risk prompt. 7. Small sends use MPC Wallet + biometric / passkey; large or high-risk sends trigger Vault Card or higher-level verification. 8. App broadcasts the transaction. 9. System displays pending, confirmed, or failed status. 10. After sending, system generates receipt and audit event. ### 7.9 Credential Sharing 1. User enters Credential Center. 2. User selects a certificate, such as Address Proof. 3. User selects sharing scope. 4. System displays recipient and expiry. 5. User confirms. 6. System generates proof QR or proof token. 7. System records the sharing event. --- ## 8. Permission and Risk Rules | Operation | Minimum requirement | Product behavior | |---|---|---| | View balance | Logged-in device session | Display normally | | Small payment | MID active + MPC Wallet + biometric/passkey | Payment confirmation | | Basic identity signing | MID active + MID Card NFC tap | Show authentication success and signing record | | Wallet recovery | MID active + MID Card + MPC recovery policy + risk check | Recovery flow, cooling period, or review status | | External asset receive | Logged-in device session + asset enabled + network available | Show chain, address, QR, risk prompt | | External asset send | MID active + MPC Wallet + biometric/passkey + network fee policy + risk check | Send confirmation, pending status, on-chain confirmations, receipt | | Swap USDF/FCA | MID active + quote policy | Show quote and policy check | | Ecosystem currency Swap | MID active + whitelist policy + quote policy | Show whitelist, quote, and policy check | | External-chain asset Swap | Not supported | No entry point | | IBC invoice payment | Company role + signed invoice | Show role verification | | Large transfer | Biometric + Vault Card | Tap-to-sign | | Credential sharing | Credential verified + user consent | Show sharing scope and expiry | | Modify recovery method | Step-up authentication | Security prompt | | Official broadcast | Issuer signature verified | Show verified issuer | --- ## 9. MVP Scope Recommendation ### Phase 1: Identity and Account Foundation Must complete: - MID status display - MID Card NFC binding and basic authentication - MPC Wallet foundational key architecture - MID identity-based wallet recovery flow - Personal Account - account switching framework - FCA / USDF balance display - Receive address - basic receipts - notification entry Not included yet: - complex multi-chain bridge - open chat - advanced DeFi - real MXCD trading ### Phase 2: Payment Collaboration Must complete: - QR verified-contact add - Payment request - Payment note - Receipt - Confirmation - Pay conversation list ### Phase 3: IBC and Service Payment Must complete: - IBC Account - Role policy - Signed invoice - Service Payment - Receipt attached to company record - Credential attachment ### Phase 4: Advanced Security and Expanded Rails Must complete: - Controlled Swap - MPC Wallet advanced policy - Vault Card signing - Backup card - External asset view / receive / send without external-chain swap - Future MXCD policy gates --- ## 10. Product Owner Delivery Checklist Before any feature enters design or development, the product owner must complete: - user story - page entry - account type - supported roles - displayed data - allowed operations - forbidden operations - empty state - loading state - error state - security rules - whether a receipt is generated - whether an audit event is generated - whether MID Card is required - whether MPC Wallet policy signing is required - whether wallet recovery is involved - whether recovery requires a cooling period or manual review - whether official signature is required - whether Vault Card is required - whether external-chain assets are involved - whether external assets support the full receive-and-send loop - whether future policy gates are involved Page-level acceptance template: ```text Page name: User role: User goal: Entry: Primary button: Secondary button: Required data: States: Risk rules: MID Card: MPC Wallet: Wallet recovery: Swap scope: External asset scope: Receipt / audit: MVP required: Design notes: Backend dependencies: ``` --- ## 11. Design Language Recommendation Overall direction: - MID-first - Fresh official fintech - relaxed but trustworthy - like a modern bank wallet, not an exchange - like Apple Wallet for credentials, but not copied - as clear and approachable as Wise / Monzo while keeping M Wallet's own green and official identity feeling Color: - primary green: `#86AD4D` - background: ivory / pale sage - FCA: soft navy / sage-slate / champagne silver - USDF: terracotta / coral / rose-burgundy / soft champagne - MXCD Future: green glass / sovereign glow Components: - card radius should stay around 8px - status chips should be concise - do not use large black surfaces - do not use casino-style gold-coin language - do not use purple Web3 gradients - do not let asset icons overpower identity status --- ## 12. Key Metrics Activation metrics: - MID verification completion rate - wallet creation completion rate - first Passkey / biometric binding completion rate Payment metrics: - first USDF / FCA received - first payment request creation rate - payment request completion rate - Receipt view rate IBC metrics: - IBC account creation or binding rate - official invoice open rate - IBC service payment completion rate - Receipt export rate Credential metrics: - Credential card count - Proof QR generation count - credential renewal completion rate Security metrics: - MID Card binding rate - MID Card basic signing success rate - MPC Wallet recovery completion rate - MPC Wallet recovery review rate - post-recovery security event rate - MPC signing failure rate - Vault Card binding rate - large-operation Vault signing success rate - recovery method setup rate - security alert acknowledgement rate --- ## 13. Open Decisions Product owners must confirm before PRD: 1. Launch regions, exchange relationship, and fee strategy for FCA and USDF. 2. Legal disclosure copy and reserve / settlement wording boundaries for USDF. 3. Display level for MXCD Future: only in Wallet, or also in Service Payment. 4. Initial IBC service scope: registration, renewal, certificates, address service, tax number service, and which ones come first. 5. Whether Vault Card has an MVP binding entry or opens only in Phase 4. 6. How MID Card in-card security material, issuance process, reissue process, and device recovery rules are defined. 7. Which threshold strategy, recovery strategy, cooling period, and device collaboration model MPC Wallet uses. 8. Under which risk conditions wallet recovery is automatically approved, manually reviewed, temporarily read-only, or rejected. 9. Which external asset networks launch first, including sending limits, fee strategy, confirmation rules, and risk controls; supported assets must provide a complete view, receive, and send loop. 10. Which backend system issues official broadcasts and how signature verification rules are defined. 11. Initial Credential Center cards: whether MID Digital ID, Address Proof, and Tax Number should be prioritized over Driver License. --- ## 14. Recommended Product Priority If the team builds only one demoable version with complete logic, the recommended order is: 1. Home: MID Verified + account switcher + balances + quick actions 2. MID Card: NFC card binding + authentication + basic signing 3. MPC Wallet: daily key management, recovery, and device signing model 4. Wallet: FCA / USDF / MXCD Future + external networks 5. Pay: QR contact + payment request + receipt 6. Credential Center: MID card + address proof + tax number + IBC certificate 7. IBC Account: company wallet + invoice + receipt 8. Service Payment: signed invoice -> USDF payment -> receipt 9. Swap: USDF / FCA quote and receipt, limited to FC ecosystem and introduced ecosystem currencies 10. Vault Card: tap-to-sign concept and protected assets 11. Notifications: official broadcast and security alerts 12. Settings: trusted devices, limits, recovery --- ## 15. Final Product Judgment Criteria Product owners can use these six questions to judge whether the design direction is correct: 1. Can users immediately understand that this is a MID-first wallet, not an ordinary crypto wallet? 2. Do users clearly understand the difference between Personal Account and IBC Account? 3. Are the roles of FCA, USDF, and MXCD Future clearly distinguished? 4. Do all payment, service, credential, MID Card, MPC Wallet, and Vault operations have receipt or audit event coverage? 5. Can users recover the wallet through a rigorous MID identity-based recovery flow instead of permanently losing assets because they forgot a seed phrase? 6. Does the product look like trusted digital identity financial infrastructure rather than a speculative trading tool? If all six answers are "yes," this product direction is valid.