M Wallet 功能手册（产品负责人版）

1. 产品定位

M Wallet 不是一个单纯的加密钱包，也不是只服务交易的资产工具。它的核心定位是：

以 MID / Digital ID 为起点，把认证后的身份、金融能力、公司账户、公共服务、凭证卡片和安全签名能力放进同一个可信账户系统。

产品叙事顺序应始终保持：

1. 用户先拥有或申请 MID 数字身份。
2. MID 通过认证后，用户获得个人钱包、支付、资产、凭证、服务缴费等能力。
3. 如果用户拥有 IBC 公司身份，则可以切换到独立的 IBC 公司钱包账户。
4. 高价值资产、公司储备、未来 MXCD 相关能力由 Vault Card 和政策规则保护。

一句话产品表达：

M Wallet is a MID-first digital account that connects verified identity, trusted payments, company services, credentials, and secure asset control.

2. 产品原则

2.1 身份优先

所有重要操作都必须关联：

• user_id
• mid_id
• account_id
• 当前设备会话
• 风险状态
• 审计记录

页面上也要体现这个逻辑：用户不是先看币，而是先看到“我是谁、我被认证到什么程度、我现在正在使用哪个账户”。

2.2 账户是容器

产品内至少存在以下账户类型：

产品设计上必须让用户清楚当前正在操作哪个账户，尤其是 Personal 和 IBC 之间不能混淆。

2.3 支付沟通是结构化消息，不是普通聊天

支付沟通功能只支持：

• 添加验证联系人
• 付款请求
• 付款备注
• 收据
• 简单确认消息

MVP 不做开放式聊天，避免内容风控、诈骗、合规和客服负担失控。

2.4 收据是核心记录

所有关键动作都应产生记录：

• 付款收据
• Swap 收据
• 服务缴费收据
• IBC 发票付款收据
• 凭证分享记录
• Vault Card 签名记录
• 官方广播阅读/确认记录

产品负责人在设计任何新功能时都要问：这个动作是否应该形成收据或审计事件？

2.5 未来能力必须政策隔离

MXCD、Montserrat stablecoin、政府服务支付等能力必须以“未来 / 政策门控 / 待批准”的方式表达，不能暗示已经是法币、官方货币或已获授权结算工具。

建议表述：

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.

中文产品表达：

USDF 是 FC Chain 生态内的美元计价支付轨道，用于早期数字支付场景，并为未来与经批准的 Montserrat dollar-denominated settlement asset（例如 MXCD）保持互操作能力预留空间。相关能力以适用审批、监管和政策决定为准。

2.6 MID Card、MPC Wallet 和 Vault Card 是三层不同能力

M Wallet 的安全和签名能力不能只用“热钱包 / 冷钱包”来描述。产品应明确区分三层能力：

产品表达原则：

• MID Card 是基础钱包能力的一部分，不是额外的“零钱包卡”。
• MID Card 负责身份认证和基础签字，帮助用户证明“我是这个 MID 的合法持有人”。
• MPC Wallet 负责日常钱包的安全与恢复，不要求用户理解复杂私钥概念。
• Vault Card 负责高价值资产和公司储备的冷签名保护，适合更高风险操作。
• UI 上必须明确区分 MID Card 与 Vault Card，二者颜色、文案和触发场景都不应混用。

2.7 MPC Wallet 的核心差异：通过 MID 身份恢复钱包

MPC Wallet 是 M Wallet 区别于普通数字货币钱包的重要能力。普通钱包通常把助记词交给用户保存，一旦用户丢失设备、忘记助记词或误删钱包，就可能永久失去数字资产。M Wallet 的目标不是让用户承担这种不可逆风险，而是通过 MID 持有者身份认证、MID Card、设备风险检查、MPC 策略签名和严格恢复流程，让用户可以安全找回丢失的钱包能力。

产品价值：

• 用户不会因为忘记助记词、误删 App 或丢失设备而直接失去数字资产。
• 钱包恢复基于 MID 持有者身份，而不是客服人工“重置密码”。
• 恢复过程必须严谨、安全、可审计，不能降低资产控制安全性。
• 恢复成功后，应重新建立新的设备份额或签名策略，而不是暴露旧私钥。

恢复原则：

3. 核心用户与角色

3.1 个人用户

目标：

• 完成 MID 认证
• 持有 FCA / USDF
• 使用 MID NFC Card 完成基础认证和签字
• 使用 MPC Wallet 完成日常付款和恢复
• 扫码加联系人
• 发起付款请求或付款
• 存放电子凭证
• 接收官方通知
• 使用 Vault Card 保护大额资产

主要入口：

• Home
• Wallet
• Pay
• MID / Credential Center
• Notifications

3.2 IBC 公司用户

目标：

• 管理公司钱包
• 支付公司服务费用
• 查看公司发票和收据
• 管理公司角色
• 存放公司证书
• 使用 Vault Card 管理公司储备

角色建议：

3.3 政府 / 注册机构 / 系统广播方

目标：

• 发送官方广播
• 发布服务发票
• 验证凭证
• 附加收据到服务记录
• 提醒续费、认证、风险或政策更新

这些角色不一定出现在第一版 App 的前台，但产品逻辑要为后台系统预留。

4. 资产与支付轨道

4.1 FCA

定位：

• FC Chain 原生资产
• 网络燃料
• 基础生态资产
• 可用于部分费用或网络操作

设计建议：

• 颜色：柔和 navy / slate blue + champagne silver
• 感受：基础设施、可靠、技术底座
• 避免：过重、过黑、投机感、过度金属感

4.2 USDF

定位：

• FC Chain 生态内美元计价支付轨道
• 早期用户支付和服务缴费的主要稳定支付单位
• 为未来与 MXCD 或其他经批准结算资产互操作预留空间

设计建议：

• 颜色：terracotta / coral / rose-burgundy + soft champagne
• 感受：稳定、支付友好、轻松、亲和
• 避免：赌场筹码感、强烈金色、投机稳定币感

4.3 MXCD Future

定位：

• 未来主权特征更强的 Montserrat stablecoin / settlement asset 概念
• 当前产品中只作为 future / policy-gated rail 表达

设计建议：

• 使用绿色玻璃 M 标
• 显示 Future、Policy-gated、Subject to approval
• 不显示可用余额，除非未来政策明确

4.4 外部资产

初期支持范围：

• BTC
• ETH
• TRON
• Solana
• BNB Chain

能力边界：

• 支持余额展示
• 支持生成收款地址和 QR
• 支持发送外部链上资产
• 支持交易状态、网络费用、确认数和失败状态展示
• 支持收据和 audit event
• 不支持外部资产之间的 Swap
• 不支持跨链桥聚合
• 不支持 DEX 聚合或投机交易功能

设计原则：

• 外部资产不应抢占首页叙事
• 应放在 Wallet 页的 “Supported networks” 或 “External assets” 区域
• FC Chain rails（FCA / USDF / MXCD Future）要保持主层级
• 一个外部资产如果进入“已支持”列表，就不能只支持展示和接收；必须同时具备发送能力，否则用户资产进入后无法正常离开，会形成不完整体验

5. 信息架构

建议底部导航：

辅助入口：

• Notifications / Official Broadcast
• Settings and Recovery
• Service Payment
• Receipt Detail
• MID Card
• MPC Wallet
• Vault Card

全局组件：

• 当前账户切换器：Personal / IBC
• MID 认证状态
• MID Card 状态
• MPC Wallet 状态
• 通知入口
• 扫码入口
• 收据入口
• 安全状态提示

6. 页面功能手册

6.1 Home：MID-first 首页

页面目标：

让用户一打开 App 就知道：

• 我的 MID 是否有效
• 我现在在哪个账户
• 我有哪些可用余额
• 我现在可以做什么
• 有没有待处理付款、官方通知或服务事项

核心模块：

• 顶部用户身份区：头像、MID Verified、通知
• 账户切换：Personal / IBC
• MID Credential 卡片
• 总资产和主要变化
• FCA / USDF 小资产卡
• 快捷操作：Send、Request、Swap、Receive、Scan
• Latest verified payment request
• Official Broadcast / Security alert 摘要

关键操作：

• 切换账户
• 打开付款
• 打开扫码
• 打开 Swap
• 查看收据
• 查看官方通知

状态：

• 未创建钱包
• MID 未认证
• MID 审核中
• MID 已认证
• 有待处理付款请求
• 有未读官方广播
• IBC 账户可用

产品验收：

• 用户能在 3 秒内理解当前身份状态和账户状态。
• Personal / IBC 切换清晰，不会误付款到错误账户。
• 快捷操作不超过 5 个主按钮。
• 未认证用户看到的是认证引导，而不是完整支付能力。

6.2 Wallet：资产与支付轨道

页面目标：

展示 FC Chain 生态主资产和外部网络支持，同时保持 FCA / USDF 的主层级。

核心模块：

• Primary FC Chain rails
• FCA
• USDF
• MXCD Future
• Swap 入口
• Receive / Send 入口
• External assets
• BTC
• ETH
• TRON
• SOL
• BNB
• View / Receive / Send 状态
• MID Vault Card 模块
• 网络状态和费用提示

关键规则：

• FCA 和 USDF 是第一屏主资产。
• MXCD 只显示 Future / Policy-gated。
• 外部资产作为支持网络，不应让产品看起来像交易所。
• 外部资产支持展示、接收和发送；如果某条外部网络尚未具备发送能力，就不应在正式钱包中显示为可用资产。
• 外部资产发送必须有链类型确认、地址格式校验、网络费用预估、到账确认数、pending / failed 状态和收据记录。
• 外部资产不进入 Swap 兑换池，不做外部链上资产之间的兑换。
• 大额发送应触发 Vault Card 或更高等级验证。

产品验收：

• 用户能理解 FCA 是原生资产，USDF 是支付轨道。
• 用户不会误以为 MXCD 已经正式可用。
• 用户可以对已支持的 BTC / ETH / TRON / SOL / BNB 完成余额查看、收款和发送。
• 外部资产只作为支持能力出现，不喧宾夺主，也不会让产品变成交易所。

6.3 Swap：受控兑换

页面目标：

支持 FC Chain 生态内货币和我们引入的生态货币之间的受控兑换，MVP 优先支持 USDF / FCA。Swap 的产品目标是服务 FC 生态闭环，不是做外部链上货币 swap 或跨链交易聚合器。

核心模块：

• From asset
• To asset
• Amount
• Quote
• Rate
• Fee
• Route
• Policy check
• Preview
• Receipt

MVP 支持：

• USDF -> FCA
• FCA -> USDF

未来支持：

• FC 生态内新增货币之间的兑换
• 经审核引入的合作方或生态货币兑换
• MXCD 相关兑换，必须政策门控

明确不做：

• BTC / ETH / TRON / Solana / BNB Chain 等外部链上资产之间的 swap
• 跨链桥聚合
• DEX 聚合
• 高杠杆或投机交易功能

关键规则：

• Quote 必须有过期时间。
• Execute 必须使用 idempotency key。
• 大额 Swap 需要 Vault Card。
• 每次 Swap 必须产生收据。
• 可兑换资产必须来自产品白名单和政策配置。
• 外部资产即使支持展示、接收或发送，也不进入 Swap 兑换池。

产品验收：

• 用户在确认前看到汇率、费用、预计到账和政策状态。
• 过期 quote 不可继续执行。
• Swap 成功后收据可进入 History / Receipt Detail。
• 用户不会把 M Wallet 理解成传统数字货币交易钱包。

6.4 Pay：扫码联系人与支付沟通

页面目标：

让用户通过 QR 添加已验证联系人，并围绕付款形成结构化沟通。

核心模块：

• QR Scan
• Verified contact card
• Payment request
• Payment note
• Receipt
• Confirmation

允许消息类型：

• contact_card
• payment_request
• payment_note
• receipt
• confirmation

不做：

• 开放式聊天
• 图片/文件随意发送
• 群聊
• 语音
• 表情社交化

关键规则：

• 付款请求必须绑定金额、资产、收款方和到期时间。
• 备注必须绑定到付款或收据。
• 收据必须绑定链上或账本交易。
• 未验证联系人不能发起正式付款请求。

产品验收：

• Pay 看起来像支付协作，不像社交聊天。
• 每条消息都能归类到一种业务类型。
• 付款完成后自动生成 Receipt，并可分享或归档。

6.5 IBC Account：公司钱包账户

页面目标：

为 IBC 公司提供独立账户空间，管理公司资金、发票、角色和服务记录。

核心模块：

• 公司身份头部
• 公司状态
• Operating wallet
• Vault reserve
• Roles
• Invoices
• Receipts
• Service applications
• Renewal reminders

角色：

• Owner
• Director
• Agent
• Accountant

核心流程：

1. 用户 MID 已认证。
2. 创建或绑定 IBC 公司。
3. 系统分配公司账户。
4. Owner 配置角色。
5. 公司收到官方发票。
6. 授权角色付款。
7. 系统生成收据并附加到公司记录。

关键规则：

• IBC 付款必须检查公司角色。
• 官方发票必须有签名验证。
• 大额公司付款需要 Vault Card。
• 公司收据必须支持导出。

产品验收：

• 用户清楚这是公司账户，不是个人账户。
• 每笔公司付款都有发票、授权人、付款轨道和收据。
• Accountant 可以查看和导出，但不能付款。

6.6 Credential Center：认证中心

页面目标：

像 Apple Wallet 一样存放用户的重要数字卡片和认证证书。

卡片类型：

• MID Digital ID
• Driver License
• Address Proof
• Tax Number
• IBC Certificate
• Good Standing Certificate
• 未来其他政府或官方凭证

卡片状态：

• Pending review
• Verified
• Expiring soon
• Renewal required
• Revoked
• Archived

关键操作：

• 查看卡片
• 分享有限证明
• 生成 proof QR
• 申请续期
• 附加到 IBC 服务

关键规则：

• 凭证分享必须用户确认。
• Proof 应有过期时间。
• Revoked 凭证不能继续分享。
• 每次分享都应产生审计记录。

产品验收：

• 用户能像使用 Apple Wallet 卡片一样理解证书。
• 不同凭证的状态颜色和操作清晰。
• 分享凭证时明确显示分享范围。

6.7 MID Card：基础 NFC 身份与签名卡

页面目标：

把 MID Card 作为 M Wallet 的基础身份与签名能力表达清楚。MID Card 本身是一张 NFC 卡，可存储私钥或安全凭证材料，用于身份认证通过、账户绑定、登录确认和基础钱包签字。

它不是零钱包卡，也不是高价值资产冷钱包卡。它的核心价值是让用户拥有一个可以触碰、可以验证、可以签字的 MID 身份硬件凭证。

核心模块：

• MID Card status
• NFC card binding
• Identity authentication
• Basic signing
• Device pairing
• Recovery relationship
• Signing history

典型用途：

• 用户通过 NFC tap 证明自己持有该 MID Card。
• 用户绑定新设备或恢复账户时，MID Card 作为强认证因子。
• 用户进行基础钱包操作时，MID Card 可参与签字或认证确认。
• 用户分享凭证或进行重要账户操作时，MID Card 可作为身份确认能力。

关键规则：

• MID Card 与 Vault Card 是两个不同产品概念。
• MID Card 是基础钱包和身份认证能力，应该出现在 MID / Credential Center / Security 设置中。
• MID Card 不应被描述为高价值资产冷钱包，也不应被设计成“零钱包”。
• 卡内私钥或安全凭证材料不可暴露给 App、前端或服务器。
• 丢失、换卡、解绑、补发都必须产生安全通知和审计记录。

产品验收：

• 用户能理解 MID Card 是“我的数字身份卡”，不是普通银行卡。
• 用户能理解 NFC tap 是认证和签字动作，不是支付刷卡动作。
• 产品能清楚说明 MID Card 和 Vault Card 的区别。

6.8 Vault Card：NFC 冷钱包 / 高价值签名卡

页面目标：

提供类似 Tangem 的 NFC 卡片式冷钱包能力，用于大额资产、公司储备和未来高安全场景。Vault Card 是高价值资产保护层，不是基础 MID Card，也不是日常零钱包。

核心模块：

• Primary Vault Card
• Backup Cards
• Protected assets
• Tap-to-sign flow
• Lost card flow
• Signing history

签名流程：

1. 用户发起大额操作。
2. 系统显示 human-readable payload。
3. 用户通过生物识别确认。
4. 用户 tap NFC Vault Card。
5. 卡片签名。
6. App 广播交易。
7. 系统生成收据和审计记录。

关键规则：

• 卡片私钥不可暴露。
• Tap 前必须让用户看懂签名内容。
• 丢失卡片必须可禁用。
• 备份卡绑定需要更高等级认证。

产品验收：

• 用户理解 Vault Card 是安全保护，不是普通银行卡。
• 用户不会把 Vault Card 与 MID Card 混淆。
• 大额操作有明确的签名前预览。
• 卡片丢失和备份流程有清晰入口。

6.9 Official Broadcast：官方广播与通知

页面目标：

给政府、注册机构或系统提供可信通知渠道。

通知类型：

• Official broadcast
• Payment request
• IBC invoice
• Credential renewal
• Security alert

关键模块：

• 签名状态
• 发行方
• 优先级
• 目标账户
• Action deep link
• 阅读状态

关键规则：

• 官方通知必须验证签名。
• 签名失败的通知必须隔离或警告。
• 高优先级通知可以置顶。
• 通知应能跳转到付款、IBC、凭证或安全页面。

产品验收：

• 用户能区分官方通知和普通付款提醒。
• 官方通知不被设计成广告消息。
• 每条可执行通知都有明确下一步。

6.10 Service Payment：官方服务缴费

页面目标：

完成从官方发票到付款、收据、服务记录归档的闭环。

核心模块：

• Invoice summary
• Issuer signature
• Accepted assets
• Account / role check
• Payment confirmation
• Receipt
• Service record

典型场景：

• IBC 年度续费
• 公司注册服务
• 证明文件申请
• 证书更新
• 未来政府服务缴费

关键规则：

• 只有签名验证通过的发票可以付款。
• IBC 发票必须检查角色。
• 支付成功后收据附加到服务记录。
• 付款接口必须支持 idempotency key。

产品验收：

• 用户看到发票来源和签名状态。
• 用户知道使用 FCA 还是 USDF 支付。
• 支付完成后收据可导出、分享或进入 IBC record。

6.11 Settings and Recovery：安全设置

页面目标：

管理设备、认证方式、限额、恢复方式、通知偏好和导出控制。

核心模块：

• Trusted devices
• MPC Wallet status
• MID Card binding
• Passkeys
• Biometrics
• Payment limits
• Swap limits
• Recovery methods
• Backup Vault Cards
• Notification preferences

关键规则：

• 删除设备需要 step-up authentication。
• 提高限额应有冷静期或审批。
• 修改恢复方式应触发安全通知。
• 导出敏感信息必须记录审计事件。

产品验收：

• 用户能管理设备和恢复方式。
• 风险较高操作不会被隐藏在普通设置里。
• 安全事件会出现在通知和审计记录中。

6.12 MPC Wallet：日常钱包密钥架构

页面目标：

把 M Wallet 的日常钱包能力建立在 MPC 架构上，降低单点私钥风险，并让 MID 持有者在丢失设备、误删钱包或忘记传统助记词的情况下，仍可通过严格身份认证和策略流程安全恢复钱包。MPC Wallet 是 App 内日常钱包的底层能力，不应被用户理解成一个额外资产账户。

核心模块：

• 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

典型用途：

• 用户进行日常小额付款时，由 MPC Wallet 完成签名。
• 用户丢失设备或误删 App 时，通过 MID Card、Passkey、biometric、设备风险检查和恢复策略重新建立设备份额。
• 用户忘记传统助记词时，不会因此直接失去数字资产，因为恢复依据是 MID 持有者身份和 MPC 策略，而不是一串由用户自行保管的词。
• 高风险或大额操作由 MPC Wallet 先执行策略检查，再升级到 MID Card 或 Vault Card。
• IBC Account 可以在未来扩展为多角色、多审批的 MPC 签名模型。

关键规则：

• 单一设备不应独立控制完整私钥。
• 用户不需要理解或独自保管 seed phrase，产品应把恢复体验做成可解释、可验证、可审计的身份恢复流程。
• 钱包恢复前必须确认用户是合法 MID 持有者，并检查 MID 状态、MID Card 状态、设备风险和恢复策略。
• 高风险恢复应支持冷静期、人工复核、限额冻结或临时只读模式。
• 恢复完成后应重新建立新的设备份额或签名策略，不应暴露旧私钥。
• MPC 签名策略必须记录审计事件。
• 恢复、新设备绑定、key rotation 都必须触发安全通知。
• MPC Wallet 是日常钱包基础能力，Vault Card 是高价值冷签名能力，二者不可混淆。

产品验收：

• 用户感受到钱包可恢复、可保护，而不是被 seed phrase 吓住。
• 用户知道“找回钱包”不是客服随便重置，而是由 MID 身份和安全策略共同完成。
• 后端能清楚区分日常 MPC 签名、MID Card 身份签字和 Vault Card 冷签名。
• 每次关键密钥状态变化都有审计记录和用户通知。

7. 核心用户流程

7.1 新用户进入

1. 打开 M Wallet。
2. 查看 MID 认证状态。
3. 如果没有 MID，引导申请或绑定。
4. 引导绑定 MID NFC Card。
5. 建立 MPC Wallet 日常签名能力。
6. MID 通过后创建 Personal Account。
7. 显示 FCA / USDF 钱包能力。
8. 引导设置 Passkey / biometric。
9. 进入 Home。

7.2 付款请求

1. 用户进入 Pay。
2. 扫描 MID QR 或选择已验证联系人。
3. 选择 Payment Request。
4. 输入金额和资产，例如 USDF。
5. 添加结构化备注。
6. 发送请求。
7. 对方确认付款。
8. 生成 Receipt。

7.3 支付官方服务发票

1. 用户收到 Official Broadcast 或 IBC invoice。
2. 打开 Service Payment。
3. 系统验证 issuer signature。
4. 用户选择支付轨道：USDF 或 FCA。
5. 系统检查个人或 IBC 角色权限。
6. 用户确认付款。
7. 系统生成 receipt。
8. Receipt 附加到服务记录。

7.4 IBC 公司账户付款

1. 用户切换到 IBC Account。
2. 查看公司发票。
3. 系统显示可付款角色。
4. Owner / Director 确认。
5. 大额付款触发 Vault Card。
6. 付款成功。
7. 收据归档到公司记录。

7.5 Vault Card 大额签名

1. 用户发起大额转账或公司储备操作。
2. 系统判断需要 Vault Card。
3. 用户查看 human-readable payload。
4. 用户用生物识别确认。
5. 用户 tap NFC Card。
6. 卡片签名。
7. App 广播交易。
8. 系统生成 receipt 和 audit event。

7.6 MID Card 基础认证和签字

1. 用户进入 MID / Security 页面。
2. 系统显示 MID Card 绑定状态。
3. 用户 tap MID NFC Card。
4. App 验证卡片持有状态和签名响应。
5. 系统确认用户是该 MID 的合法持有人。
6. 用户可完成新设备绑定、基础钱包签字、凭证分享确认或账户恢复步骤。
7. 系统生成认证记录或签字审计事件。

7.7 MPC Wallet 身份恢复

1. 用户丢失设备、误删钱包或无法访问原设备。
2. 用户在新设备上选择 Recover M Wallet。
3. 系统要求用户完成 MID 身份验证。
4. 用户 tap MID NFC Card，并通过 Passkey / biometric 或其他强化验证。
5. 系统检查 MID 状态、卡片状态、设备风险、近期异常操作和恢复策略。
6. 低风险恢复可以进入自动恢复流程；高风险恢复进入冷静期、人工复核或临时只读模式。
7. MPC Wallet 重新建立新的设备份额或签名策略。
8. 系统向旧设备、绑定邮箱/通知渠道和官方审计系统发送安全通知。
9. 恢复完成后，用户重新进入钱包，但高风险资产或大额操作可继续要求 Vault Card。

7.8 外部资产接收和发送

接收流程：

1. 用户进入 Wallet。
2. 选择 BTC / ETH / TRON / SOL / BNB 中某个已支持资产。
3. 用户选择 Receive。
4. 系统显示对应网络、收款地址、QR、最小入账提示和确认数说明。
5. 资产到账后显示 pending / confirmed 状态。
6. 系统生成入账记录和 receipt / audit event。

发送流程：

1. 用户进入 Wallet 并选择某个外部资产。
2. 用户选择 Send。
3. 系统要求确认链类型，避免地址和网络不匹配。
4. 用户输入或扫描收款地址。
5. 系统完成地址格式校验、风险检查、余额检查和网络费用预估。
6. 用户确认金额、费用、预计到账时间和风险提示。
7. 小额发送使用 MPC Wallet + biometric / passkey；大额或高风险发送触发 Vault Card 或更高等级验证。
8. App 广播交易。
9. 系统显示 pending、confirmed 或 failed 状态。
10. 发送完成后生成 receipt 和 audit event。

7.9 凭证分享

1. 用户进入 Credential Center。
2. 选择证书，例如 Address Proof。
3. 选择分享范围。
4. 系统显示 recipient 和 expiry。
5. 用户确认。
6. 生成 proof QR 或 proof token。
7. 系统记录分享事件。

8. 权限与风险规则

9. MVP 范围建议

Phase 1：身份和账户底座

必须完成：

• MID 状态展示
• MID Card NFC 绑定和基础认证
• MPC Wallet 基础密钥架构
• MID 身份恢复钱包流程
• Personal Account
• 账户切换框架
• FCA / USDF 余额展示
• Receive address
• 基础收据
• 通知入口

暂不做：

• 多链复杂桥
• 开放聊天
• 高级 DeFi
• MXCD 真实交易

Phase 2：支付协作

必须完成：

• QR 添加验证联系人
• Payment request
• Payment note
• Receipt
• Confirmation
• Pay conversation list

Phase 3：IBC 与服务缴费

必须完成：

• IBC Account
• Role policy
• Signed invoice
• Service Payment
• Receipt attached to company record
• Credential attachment

Phase 4：高级安全和扩展轨道

必须完成：

• 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. 产品负责人交付清单

每个功能进入设计或开发前，产品负责人需要补齐：

• 用户故事
• 页面入口
• 所属账户类型
• 支持角色
• 展示数据
• 允许操作
• 禁止操作
• 空状态
• 加载状态
• 错误状态
• 安全规则
• 是否产生 receipt
• 是否产生 audit event
• 是否需要 MID Card
• 是否需要 MPC Wallet 策略签名
• 是否涉及钱包恢复
• 恢复是否需要冷静期或人工复核
• 是否需要官方签名
• 是否需要 Vault Card
• 是否涉及外部链上资产
• 外部资产是否支持接收和发送完整闭环
• 是否涉及未来政策门控

页面级验收模板：

页面名称：
用户角色：
用户目标：
入口：
主按钮：
次按钮：
必需数据：
状态：
风险规则：
MID Card：
MPC Wallet：
钱包恢复：
Swap 范围：
外部资产范围：
收据/审计：
MVP 是否必须：
设计备注：
后端依赖：

11. 设计语言建议

整体方向：

• MID-first
• Fresh official fintech
• 轻松但可信
• 像现代银行钱包，而不是交易所
• 像 Apple Wallet 存凭证，但不照搬
• 像 Wise/Monzo 的清晰和亲和，但保持 M Wallet 自己的绿色和官方身份感

颜色：

• 主绿色：#86AD4D
• 背景：ivory / pale sage
• FCA：soft navy / sage-slate / champagne silver
• USDF：terracotta / coral / rose-burgundy / soft champagne
• MXCD Future：green glass / sovereign glow

组件：

• 卡片圆角保持 8px 左右
• 状态 chip 简洁
• 不用大面积黑色
• 不用赌场式金币感
• 不用紫色 Web3 渐变
• 不让资产图标压过身份状态

12. 关键指标

激活指标：

• MID 认证完成率
• 钱包创建完成率
• 首次绑定 Passkey / biometric 完成率

支付指标：

• 首次收到 USDF / FCA
• 首次付款请求创建率
• 付款请求完成率
• Receipt 查看率

IBC 指标：

• IBC account 创建或绑定率
• 官方发票打开率
• IBC 服务付款完成率
• Receipt 导出率

凭证指标：

• Credential card 添加数量
• Proof QR 生成次数
• 凭证续期完成率

安全指标：

• MID Card 绑定率
• MID Card 基础签字成功率
• MPC Wallet 恢复完成率
• MPC Wallet 恢复复核率
• 恢复后安全事件发生率
• MPC 签名失败率
• Vault Card 绑定率
• 大额操作 Vault 签名成功率
• 恢复方式设置率
• 安全提醒确认率

13. 待决策问题

产品负责人需要在进入 PRD 前确认：

1. FCA 和 USDF 的首发地区、兑换关系和费用策略。
2. USDF 的法律披露文案和 reserve / settlement 表述边界。
3. MXCD Future 在界面中的显示级别：只在 Wallet 显示，还是也在 Service Payment 中显示。
4. IBC 的首发服务范围：注册、续费、证书、地址服务、税号服务哪些先做。
5. Vault Card 是否作为 MVP 绑定入口，还是 Phase 4 才开放。
6. MID Card 的卡内安全材料、发卡流程、补发流程和设备恢复规则如何定义。
7. MPC Wallet 采用什么阈值策略、恢复策略、冷静期和设备协作模型。
8. 钱包恢复在什么风险条件下自动通过、人工复核、临时只读或拒绝。
9. 外部资产首发支持哪些网络、发送限额、费用策略、确认数规则和风险控制；已支持资产必须具备展示、接收和发送完整闭环。
10. 官方广播由哪个后台系统发出，签名验证规则如何定义。
11. Credential Center 的首发卡片：MID Digital ID、Address Proof、Tax Number 是否优先于 Driver License。

14. 推荐产品优先级

如果只做一个可演示但有完整逻辑的版本，建议顺序：

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. 最终产品判断标准

产品负责人可以用这六个问题判断设计是否正确：

1. 用户是否一眼知道这是 MID-first 钱包，而不是普通 crypto wallet？
2. 用户是否清楚 Personal Account 和 IBC Account 的区别？
3. FCA、USDF、MXCD Future 的角色是否被清楚区分？
4. 所有付款、服务、凭证、MID Card、MPC Wallet、Vault 操作是否都有 receipt 或 audit event？
5. 用户是否能通过严谨的 MID 身份恢复流程找回钱包，而不是因为忘记助记词永久丢失资产？
6. 产品是否看起来像可信的数字身份金融基础设施，而不是投机交易工具？

如果六个答案都是“是”，这版产品方向就是成立的。