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

版本：2026-04-26  
用途：给产品负责人、设计负责人、后端负责人统一产品范围、页面逻辑、功能优先级和验收标准。  
相关文件：

- `M_Wallet_Product_Function_Manual.html`：功能手册网页版
- `M_Wallet_Team_Development_Guide.html`：团队开发指导网站英文源站
- `M_Wallet_Team_Development_Guide_ZH.html`：团队开发指导网站中文镜像
- `M_Wallet_Screen_Flow_Storyboard.html`：完整分页视觉故事板
- `MID_Wallet_Product_Concept.html`：可交互产品概念原型
- `M_Wallet_Detailed_Page_Spec_For_Engineering.html`：工程分页规格
- `M_Wallet_Product_Architecture_Government_Use_Case.html`：政府/投资人表述版本

---

## 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 Account | 个人资产、支付、凭证 | 默认首页账户 |
| IBC Account | 公司钱包、发票、收据、服务记录 | 与公司注册和角色权限绑定 |
| Vault Account | 高价值资产和公司储备保护 | 由独立 Vault Card 触发冷签名 |
| Merchant / Agent Account | 后续服务商、代理人、商户 | 后续扩展 |

产品设计上必须让用户清楚当前正在操作哪个账户，尤其是 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 本身是 NFC 卡，可存储私钥或安全凭证材料，用于认证通过和基础钱包签字 |
| MPC Wallet | 日常钱包密钥架构 | 日常付款、收款、账户恢复、设备协作签名 | 用于降低单点私钥风险，适合作为 App 内基础钱包能力 |
| Vault Card | 高价值冷签名卡 | 大额资产、公司储备、未来高安全场景 | 与 MID Card 不是一回事，不应混淆为零钱包或基础身份卡 |

产品表达原则：

- 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 持有者身份，而不是客服人工“重置密码”。
- 恢复过程必须严谨、安全、可审计，不能降低资产控制安全性。
- 恢复成功后，应重新建立新的设备份额或签名策略，而不是暴露旧私钥。

恢复原则：

| 原则 | 产品要求 |
|---|---|
| 身份先行 | 恢复前必须确认用户是合法 MID 持有者 |
| 多因子验证 | MID Card、Passkey / biometric、设备风险、官方记录可以组合验证 |
| 不暴露私钥 | 恢复流程不能向用户、客服、前端或服务器暴露完整私钥 |
| 策略门控 | 高风险恢复需要冷静期、人工审核或更高级别认证 |
| 全程审计 | 每一步恢复动作都要生成 audit event 和安全通知 |

---

## 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 管理公司储备

角色建议：

| 角色 | 权限 |
|---|---|
| Owner | 完整控制、付款、审批、Vault 操作 |
| Director | 付款审批、服务申请、收据查看 |
| Agent | 服务申请、资料提交、查看指定记录 |
| Accountant | 只读账务、导出收据 |

### 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. 信息架构

建议底部导航：

| Tab | 中文含义 | 主要功能 |
|---|---|---|
| Home | 首页 | MID 状态、账户切换、资产概览、快捷操作 |
| Wallet | 钱包 | FCA、USDF、MXCD Future、外部资产、Swap、Vault |
| Pay | 支付 | 扫码加好友、付款请求、备注、收据 |
| IBC | 公司账户 | 公司钱包、角色、发票、收据、服务记录 |
| MID | 身份中心 | Digital ID、MID Card、驾照、地址证明、税号、证书 |

辅助入口：

- 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. 权限与风险规则

| 操作 | 最低要求 | 产品表现 |
|---|---|---|
| 查看余额 | 登录设备会话 | 正常显示 |
| 小额付款 | MID active + MPC Wallet + biometric/passkey | 付款确认 |
| 基础身份签字 | MID active + MID Card NFC tap | 显示认证通过和签字记录 |
| 钱包恢复 | MID active + MID Card + MPC recovery policy + risk check | 恢复流程、冷静期或复核状态 |
| 外部资产接收 | 登录设备会话 + asset enabled + network available | 展示链、地址、QR、风险提示 |
| 外部资产发送 | MID active + MPC Wallet + biometric/passkey + network fee policy + risk check | 发送确认、pending 状态、链上确认数、收据 |
| Swap USDF/FCA | MID active + quote policy | 显示 quote 和 policy check |
| 生态货币 Swap | MID active + whitelist policy + quote policy | 显示白名单、quote 和 policy check |
| 外部链上资产 Swap | 不支持 | 不提供入口 |
| IBC 发票付款 | 公司角色 + signed invoice | 显示角色验证 |
| 大额转账 | Biometric + Vault Card | Tap-to-sign |
| 凭证分享 | Credential verified + user consent | 显示分享范围和过期时间 |
| 修改恢复方式 | Step-up authentication | 安全提醒 |
| 官方广播 | Issuer signature verified | 显示 verified issuer |

---

## 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
- 是否涉及外部链上资产
- 外部资产是否支持接收和发送完整闭环
- 是否涉及未来政策门控

页面级验收模板：

```text
页面名称：
用户角色：
用户目标：
入口：
主按钮：
次按钮：
必需数据：
状态：
风险规则：
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. 产品是否看起来像可信的数字身份金融基础设施，而不是投机交易工具？

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