Fresh Finance
接近 Wise 的轻量、清晰、直接金融界面,用 M 绿色作为主要行动色。适合建立付款信心和快速上手。
风险:如果 MID 和官方信任太弱,容易变得普通。这个页面是 M Wallet 的受控设计讨论区。它帮助产品、UI、品牌、工程、市场和客户体验团队比较不同设计路线,而不是过早改动正式产品指南。
目标不是复制某个银行钱包,而是从成熟金融 UX 中学习,再形成围绕 MID 认证和 FC Chain 轨道的 M Wallet 自己的语言。
接近 Wise 的轻量、清晰、直接金融界面,用 M 绿色作为主要行动色。适合建立付款信心和快速上手。
风险:如果 MID 和官方信任太弱,容易变得普通。更接近 Monzo 的日常钱包体验,强调付款请求、收据、联系人转账和轻松互动。
风险:如果太轻松,会削弱政府级身份系统的权威度。更克制的官方可信账户系统,突出认证、政策门控、签名记录和政府信息传播。
风险:如果日常支付不够简单,会显得沉重。钱包从认证身份出发,把资产表达为 MID、NFC 卡签名和 MPC 恢复所释放的金融能力。
风险:资产用户需要更明显的支付快捷入口。围绕 FCA、USDF、MXCD Future、IBC 账户和被选择支持的外部资产,形成闭环服务和支付生态。
风险:如果身份上下文不清楚,容易像传统 crypto 钱包。这些不是最终页面,而是小型布局观点。每个样品都在问:用户第一眼应该注意什么?
个人账户 · FC Chain
需要处理 · 仅 MID 持有人
FCA、USDF、MXCD Future、BTC、ETH、TRON、SOL、BNB
这些方案把设计方向转成页面行为。它们适合设计评审,因为每个方案都说明首页优先展示什么、哪些组件承载信任、产品风险在哪里。
一个清爽金融型首页,把 MID 状态、可恢复钱包控制和日常支付动作放在一个冷静层级里。这应该作为个人钱包的默认方向。
以凭证为中心的布局,用于电子驾照、地址证明、税收号码、IBC 证书和官方证明。可以像 Apple Wallet,但更官方、更可审计。
一个有沟通感但保持严格边界的支付页面,只支持付款请求、付款备注、收据和确认,不变成开放聊天。
更偏运营的公司账户布局,用于公司角色、官方发票和服务支付记录。它应该有商业感,但不要变成复杂后台。
一个把安全和恢复优势表达出来的方案:用户不会因为丢手机或忘助记词就失去资产,但恢复流程必须严谨、可审计。
用方案 01 作为产品基础方向,方案 02 用于 Credential Center,方案 03 用于 Pay,方案 04 用于 IBC,方案 05 用于 Security 和 Recovery。这样 M Wallet 仍是一套统一系统,但每个功能区域都有自己的表达重点。
关键决策是:首页到底先展示余额,还是先展示 DID 状态。我的判断是先展示 DID 状态,再展示余额,因为这个钱包最独特的价值是“认证后的、可恢复的金融能力”。
这个样本库把产品逻辑变成具体设计参考。每张卡都包含小型 UI 样本、用户第一眼信息、主动作、系统状态、后端锚点和讨论问题,覆盖身份、资产、支付、IBC、政府服务、恢复、硬件、隐私、运营、政策和客服支持。
用于用户还没有 approved DID 的阶段。页面要让钱包价值可见,同时把资产动作明确锁定。
did_application、profile_submission、nfc_card_binding。用于用户等待审核时。设计要降低焦虑,同时让流程看起来官方、已签名、可审计。
review_stage、review_event、issuer_decision。默认个人首页应该轻松、可用、有金融感,同时保留 MID-first 的产品叙事。
account_summary、asset_balance、security_status。用于 FCA、USDF、BTC、ETH、TRON、SOL 和 BNB。外部资产支持查看、接收和发送,但不做外部链 swap。
network_adapter、chain_tx、fee_quote。这是核心支付沟通模型。它可以有人味,但必须结构化、可审计。
payment_request、payment_note、receipt。用于用户互相添加付款联系人。它是支付联系人层,不是社交网络。
contact、did_lookup、payment_channel。用于 FC 生态货币和政策允许引入资产之间的兑换。这样钱包聚焦生态服务,而不是交易所。
swap_pair、quote、swap_receipt。用于官方卡片和认证证书。交互可以像 Wallet 卡,但必须显示签发方、有效性、授权和证明用途。
credential、proof_request、consent_record。用于公司账户支付官方发票。UI 必须显示公司上下文、操作者角色、发票签名和收据归档。
company、role、invoice、company_receipt。用于政府或系统性信息可靠触达用户。它应该像已签名的官方信息,不像营销推送。
broadcast、issuer_signature、read_receipt。用于已认证 MID 持有人丢失设备或密钥访问能力时。页面要表达安全和严谨流程,而不是单纯方便。
recovery_case、mpc_policy、risk_review。用于身份声明、恢复审批或受保护的大额操作。MID Card 证明身份;Vault Card 保护更高价值的钱包签名。
signing_session、nfc_challenge、vault_policy。用于付款、签名或凭证分享依赖账户上下文的场景。它可以防止用户从错误身份或公司角色下付款。
account_context、role_grant、vault_policy。用于决定 App 骨架。钱包不应该像交易所,导航要服务身份、支付、凭证和官方服务。
feature_flag、account_capability、navigation_state。用于 MXCD 尚未上线前。UI 要建立理解,但不能暗示当前可用、保证发行或投资收益。
asset_policy、eligibility_state、launch_phase。用于安全、专业地解释 USDF:它是面向美元计价使用的支付轨道,而不是和未来 Montserrat stablecoin 政策冲突的承诺。
asset_disclosure、rail_policy、conversion_reference。用于接收 BTC、ETH、TRON、SOL 或 BNB。页面必须通过清晰网络选择和确认文案,避免错误网络充值。
deposit_address、network_adapter、address_policy。用于广播外部链交易前。页面应展示金额、地址、费用、网络、确认预期和不可逆提醒。
send_intent、fee_quote、chain_tx。用于线下收银台或服务窗口付款。钱包应先验证商户身份,再付款,并在结算后生成清晰收据。
merchant_profile、checkout_intent、payment_receipt。用于小群体付款,但不产生社交聊天。钱包发送结构化付款请求,并追踪谁已经付款。
payment_batch、payment_request、participant_status。用于官方发票或服务费有到期日的场景。它应该帮助用户避免错过义务,但不能在未经确认的情况下自动划款。
scheduled_payment、invoice_due_date、reminder_event。用于用户信任和客服支持。收据不应该只是隐藏的交易列表,而应该覆盖付款、凭证、恢复和 IBC 服务。
receipt、activity_event、export_job。用于付款、swap、外部发送或受保护签名。UI 应在提交前让成本可预测。
fee_quote、quote_expiry、cost_summary。用于网络延迟或不可用时。它要清楚解释影响,避免用户把链上状态误解成钱包故障。
network_status、service_incident、retry_policy。用于钱包阻止高风险操作。阻止状态应像保护,而不是随意拦截,并且要给出安全下一步。
risk_signal、policy_decision、step_up_request。用于让用户理解钱包访问和安全。设备管理应和 MPC 恢复、风险控制连在一起。
device_session、trusted_device、session_revoke。用于客服必须引导用户完成严谨动作的场景。客服沟通也应该结构化、可审计。
support_case、case_message、evidence_upload。用于地址证明、驾照、税号和 IBC 证书。钱包应防止凭证静默过期后影响支付或服务。
credential_expiry、renewal_case、issuer_review。用于官方服务成为钱包动作时。设计要像可信服务柜台,而不是商业应用商店。
service_catalog、eligibility_check、service_case。用于公司向 director、accountant 或 operator 授权钱包权限。页面必须清楚展示范围和签名限制。
role_invite、permission_scope、approval_event。用于钱包需要 Tangem-like 卡片签名的大额或敏感操作。它和 MID Card 身份证明不是同一件事。
vault_card、signing_payload、transaction_policy。用于早期用户,让钱包差异被清楚理解,而不是做很长的新手教程。教育内容应该像及时卡片,不像营销页面。
education_card、onboarding_progress、dismissal_event。用于创建钱包前,让用户理解可恢复 MPC 钱包、MID Card 身份签名和 Vault Card 受保护签名之间的区别。
wallet_setup_mode、key_policy、card_binding_state。用于实体 MID Card 成为身份凭证和签名伙伴时。它应该显得很基础,而不是像一个可选冷钱包功能。
mid_card_binding、nfc_challenge、identity_signature。用于用户通过已验证 MID 身份恢复钱包。界面应该展示进度,但不能让恢复显得随意或瞬间完成。
mpc_recovery_case、identity_reverification、cooling_period。用于用户或风控系统暂停对外转账。可恢复能力必须和快速止损能力配套出现。
wallet_freeze、risk_trigger、unfreeze_approval。用于网络不稳定的场景。钱包可以提前生成签名付款请求,并在设备恢复联网后完成对账。
offline_payment_request、sync_event、request_expiry。用于 App 无法立即确认网络动作时。设计要避免重复发送,同时让等待状态保持冷静。
transaction_queue、broadcast_attempt、idempotency_key。用于减少付款错误。联系人不应该只是名字,还应该包含信任信号、身份证明和历史记录。
contact_trust_level、did_resolution、address_alias。用于我们讨论过的有限聊天层:只支持付款请求、付款备注、收据和简单确认消息。
payment_message、request_status、receipt_event。用于 IBC 在付款对话中发送可支付发票。付款对象应该携带发票数据,而不只是聊天气泡。
invoice_attachment、payable_request、ibc_payment_case。用于用户或 IBC 需要税务、会计或服务证明记录时。它把钱包历史转成真正可用的文件。
receipt_export、statement_period、audit_file。用于经认证商户频繁接收 USDF 付款。它要足够简单,适合柜台使用,也要足够可审计,适合业务记录。
merchant_account、collection_event、settlement_batch。用于收银台式付款。屏幕要能从一定距离读清楚,金额、商户证明和过期时间都要可见。
pos_payment_request、merchant_did、payment_expiry。用于用户授权可预测的官方或商户付款。授权必须展示上限、频率、取消方式和审计记录。
payment_mandate、spending_cap、mandate_event。用于 IBC 授予运营付款能力,但不授予完整签名权限。这样业务付款可以更快,但边界清楚。
delegated_limit、role_policy、override_request。用于用户希望大额付款只能转向可信受益人时。它是比完全冻结钱包更柔和的日常保护机制。
beneficiary_whitelist、destination_policy、cooling_period。用于用户在境外时,需要更清楚的本地价值显示,但不改变真实资产或结算逻辑。
display_currency、geo_hint、fx_reference_rate。用于把资产身份和显示货币分开。这样用户理解 USDF、FCA 和外部资产时,不会被误导性的兑换语言干扰。
valuation_display、reference_rate、rate_timestamp。用于 BTC、ETH、TRON、SOL 和 BNB 的详情页。外部资产需要清楚展示网络信息和区块浏览器入口。
external_asset_account、chain_indexer、explorer_url。用于首次外部发送或接收前。语气要冷静实用,不要吓人,但风险必须非常明确。
risk_acknowledgement、chain_warning、policy_block。用于需要的不只是 token 列表的企业账户。Dashboard 应该展示流动性、待付款和等待审批事项。
ibc_treasury、payable_summary、cashflow_snapshot。用于 IBC 向多个已验证收款人付款。它需要校验、清楚的总金额和强审批记录。
batch_payment、recipient_validation、approval_signature。用于敏感 IBC 操作。审批链应该清楚展示谁已经操作、下一步是谁、政策为什么要求这样做。
approval_chain、signature_requirement、approval_deadline。用于官方消息带有任务、表单或付款动作时。广播应该直接连接到安全的服务流程。
official_broadcast、service_deep_link、deadline_event。用于系统或政府需要传播紧急信息时。它必须足够可见,但不能制造恐慌。
incident_alert、service_status、alert_update。用于用户向个人或机构展示凭证时。屏幕应该清楚说明正在分享什么、隐藏什么。
credential_presentation、selective_disclosure、verification_event。用于需要多个证明一起提交的场景,例如地址证明、税号和数字居民身份状态。
credential_bundle、share_link、revocation_event。用于让身份分享变得可信。用户应该能看到分享过什么、给谁、什么时候,以及能否撤销。
consent_record、data_disclosure、revocation_status。用于年长用户、低视力用户和高压力付款场景。可访问性应该是钱包的一等设置。
accessibility_preference、device_setting_sync、ui_mode。用于保持英文为源网站,同时支持完整中文页面。关键金融术语必须在不同语言之间保持一致。
locale_content、term_dictionary、content_version。用于创建客服工单前。钱包应该帮助用户理解问题来自设备、网络、政策还是服务。
diagnostic_session、support_case、incident_link。用于展示钱包是否已经具备付款、凭证、恢复、IBC 操作和受保护签名的完整能力。
wallet_readiness、capability_state、next_best_action。用于身份材料过期,或高风险动作需要新鲜验证时。文案要坚定,但不能像指责用户。
reverification_case、proof_expiry、risk_step_up。用于提交身份数据与现有资料冲突时。用户应该知道具体要修什么,但不能看到内部风险语言。
profile_mismatch、correction_request、manual_review。用于动作被政策、资格或合规控制阻止时。设计要说明用户路径,但不能暴露敏感规则。
policy_lock、eligibility_rule、appeal_case。用于付款本身已经最终确认,但服务或商户关系需要投诉处理时。不要承诺不存在的链上撤回能力。
payment_dispute、evidence_upload、case_decision。用于商户退款或作废收据时。用户需要清楚看到退款和原始付款之间的关系。
refund_event、receipt_link、merchant_case。用于安全解释 USDF:它是 FC 生态里以美元计价表达的支付资产,并在政策允许时展示储备或证明信息。
usdf_disclosure、attestation_status、issuer_notice。用于解释即使用户主要用 USDF 支付,FC Chain 原生资产 FCA 为什么仍然重要。表达要简单、实用、不投机。
network_fee_balance、fee_asset、fuel_threshold。用于政府、服务方或推广政策覆盖网络费时。这能让官方服务少一些技术感。
fee_sponsorship、sponsor_policy、fee_receipt。用于 FC 生态内部 swap。设计要展示报价有效期、费用、路径和最终获得金额,但不要像传统交易所。
swap_quote、quote_expiry、fc_liquidity_route。用于 FC 生态流动性暂时无法支持用户请求的 swap 时。语气应该像服务提示,而不是交易平台提示。
liquidity_check、route_status、availability_alert。用于外部资产、网络或 token 支持政策变化时。用户需要足够时间和清楚动作来安全迁移。
asset_support_policy、sunset_notice、action_limit。用于 App 版本过旧,无法执行敏感动作时。产品应解释原因,同时保留低风险访问。
minimum_app_version、security_patch、action_gate。用于用户更换手机时。流程应该安全且让人安心,尤其因为钱包可以通过 MID 恢复。
device_migration、session_revocation、mpc_share_refresh。用于用户丢失 MID Card 时。它必须和丢失 Vault Card 或丢失钱包本身清楚区分。
mid_card_replacement、card_revocation、replacement_order。用于用户或 IBC 需要备用受保护签名卡时。设计要避免它和 MID 身份卡混淆。
vault_card_set、backup_card_test、signing_device_rotation。用于用户在手机开始服务或 IBC 任务,并在桌面继续时。接力绝不能静默转移签名权。
session_handoff、handoff_challenge、session_scope。用于用户想关闭或暂停钱包时。它应该保护记录、撤销凭证分享,并避免资产被遗留。
account_closure、data_export、credential_revocation。用于长期账户安全规划。这个功能非常敏感,应该由政策主导,并包含严格身份、等待期和法律控制。
trusted_access_plan、inactive_account_policy、legal_review。用于产品内部侧参考。钱包体验依赖清晰的审核队列、人员分配和审计轨迹。
review_queue、case_assignment、operator_audit。用于团队讨论官方消息如何撰写、定向、审批、定时和审计,然后再发送到钱包。
broadcast_composer、audience_segment、approval_workflow。用于公司从注册到可运营钱包的过程。它应该展示 director 验证、钱包能力和当前阻塞点。
ibc_kyb_case、director_link、company_wallet_state。用于官方服务有多个费用项目时。用户在签名或付款前应看到每项费用的含义。
service_fee_quote、fee_line_item、payment_instruction。用于机构或被批准的签发方在生态中创建、更新、撤销和审计数字凭证。
credential_issuer、issuance_event、revocation_registry。用于用户向客服分享诊断数据时。产品应该展示客服可以看到什么,并让用户能停止分享。
support_data_grant、data_redaction、grant_expiry。用于系统增加摩擦时。用户需要一个普通人能理解的原因,但不能暴露风控内部规则。
risk_level、step_up_reason、friction_policy。用于让产品、工程和数据围绕真正有意义的事件对齐,而不是只统计零散按钮点击。
product_event、funnel_state、analytics_contract。用于避免样本变成彼此无关的视觉图。颜色、阴影、间距和状态 token 应该映射到产品含义。
design_token、component_state、theme_mapping。用于让首次使用页面有帮助,而不是空白。空状态应该指向一个有用的下一步,并解释页面价值。
empty_state_reason、first_action_hint、permission_state。用于付款、签名、恢复和服务动作失败时。最重要的信息是资金是否移动,以及用户下一步如何安全处理。
failure_outcome、safe_retry、support_escalation。用于区分必须接收的官方/安全通知,以及可选的产品和商户消息。用户应该有控制感,但不能错过关键信息。
notification_preference、required_notice、delivery_channel。用于钱包消息变多时。关键通知应该按动作和截止日期组织,而不是混在普通消息列表里。
inbox_priority、message_category、action_deadline。用于政策要求用户或 IBC 在大额动作前说明资金来源时。流程应该专业且边界清楚。
source_of_funds、compliance_request、document_evidence。用于交易触发政策或风险阈值时。用户应该看到为什么要审核,以及哪些动作仍然可用。
large_transaction_review、threshold_policy、review_outcome。用于法律或政策限制影响访问时。文案必须冷静、准确,并避免暗示用户有过错。
jurisdiction_policy、service_eligibility、restriction_notice。用于交易进入合规监控时。界面不能暴露检测规则,但要让用户知道发生了什么。
monitoring_case、case_status、compliance_hold。用于 BTC、ETH、TRON、SOL 或 BNB 入账需要网络确认后才能使用的场景。
deposit_confirmation、required_confirmations、chain_event。用于让外部地址的重复使用更安全。标签必须由用户控制,除非确认,否则不能暗示已验证身份。
address_label、external_address_book、label_origin。用于商户或用户希望在钱包聊天之外发送付款请求时。链接必须保留已验证收款人和过期时间。
payment_link、request_token、expiry_policy。用于商户申请接收已验证钱包付款时。流程要清楚区分个人、IBC 和商户账户。
merchant_onboarding、merchant_kyb、merchant_capability。用于店员需要收款,但不应看到完整企业资金或拥有签名权限的商户场景。
merchant_staff_role、terminal_session、permission_scope。用于 IBC 或商户钱包需要外部会计处理时。先从导出格式开始,不要过早承诺深度双向集成。
accounting_export、ledger_mapping、statement_file。用于发票、收据和付款金额不完全一致时。这是实际企业钱包功能,不是传统 crypto 功能。
reconciliation_case、invoice_match、ledger_exception。用于解释 USDF 是 FC 生态中以美元计价表达的过渡性支付资产,为未来 Montserrat stablecoin 做用户体验准备,但不能过度宣称。
asset_transition_notice、stablecoin_migration、issuer_status。用于为未来 MXCD 或主权稳定币功能做准备,同时不把它呈现成当前可用金融产品。
future_asset_interest、eligibility_waitlist、availability_notice。用于用户首次持有或使用稳定资产前。它应该易读、可审计、有版本记录。
asset_disclosure、terms_acceptance、disclosure_version。用于已验证第三方请求用户分享凭证时。钱包必须清楚展示验证方身份和请求字段。
proof_request、verifier_identity、requested_claims。用于凭证分享前。用户不仅要信任凭证,也要信任请求凭证的一方。
verifier_registry、verification_purpose、trust_status。用于已签发凭证被撤销、暂停或不再有效时。用户必须看到影响,以及申诉或更新路径。
credential_revocation、revocation_reason、appeal_route。用于凭证更新包含费用和截止日期时。它把官方凭证生命周期和钱包付款逻辑连接起来。
credential_renewal、renewal_fee、scheduled_payment。用于年长用户或忙碌企业主需要他人协助管理请求,但不能给出签名权限的场景。
helper_access、delegated_permission、approval_required。用于用户指定可信个人或机构协助恢复证明,但不获得资产托管能力。
recovery_nominee、nominee_verification、recovery_evidence。用于受保护签名卡丢失时。冻结签名权,同时把身份和钱包可见性分开。
vault_card_lost、signing_freeze、vault_rebind。用于用户忘记 MID Card 或 Vault Card PIN 时。流程必须区分卡片访问恢复和钱包恢复。
card_pin_reset、pin_attempt_policy、card_unlock_event。用于验证方需要证明但网络不稳定时。界面必须清楚展示证明新鲜度和过期时间。
offline_identity_proof、proof_expiry、verification_sync。用于用户监控外部地址或公司储备,但不把签名权导入 M Wallet 的场景。
watch_only_account、read_only_address、balance_alert。用于新钱包能力发布时。更新说明应该解释用户价值、风险变化和是否需要用户行动。
release_note、feature_education、version_notice。用于设计评审时,检查每个样本的可读性、状态逻辑、风险语言、本地化和工程映射。
design_review_item、qa_status、decision_record。这个样品把顶部身份提示升级成 DID 状态中心。它保留钱包首页的熟悉结构,但把资料提交、KYC 审核、政府审核、失败修正和可 Mint DID 的状态讲清楚,方便产品、设计和工程团队一起讨论。
钱包应该和协议层使用同一套语言:did:mid、DID credential 和 DID approval。EID 容易像另一个产品,会削弱技术一致性。
凭证状态要先说明钱包当前是否可用,再让资产和支付动作出现。这样合规状态和用户动作不会互相打架。
Submit、Track、View、Fix 和 Mint DID 都应该映射到明确的后端状态。界面不要只放泛泛的提示条,让用户猜下一步。
Send、Receive、Swap 和 History 可以保留在页面中,但在审核完成前应置灰锁定。这样既展示未来价值,也让政策门控清楚可见。
这样设计评审就不会只停留在主观好看。一条漂亮路线如果削弱信任、恢复信心或工程清晰度,就不适合进入正式系统。
团队评审时可以直接使用这个部分,把主观反馈转成产品方向。
身份状态、余额、付款任务、官方通知或资产轨道。第一信号应该匹配页面目的。
MID 认证、NFC 卡签名、MPC 恢复、收据和官方广播必须可见,但不能压迫用户。
付款要快,凭证要易扫读,风险状态要冷静且可行动。
每个 UI 状态都应该能映射到后端状态、审计事件、权限规则或收据结果。
先做三套更高保真页面:Fresh Finance、Civic Trust 和 MID-First Identity。每套保持相同页面:Home、Pay、Credential Center、IBC Account 和 Recovery。
M Wallet 最终风格很可能是组合型:日常支付采用 Fresh Finance,官方动作采用 Civic Trust,产品叙事采用 MID-First Identity。
当某个探索方向稳定后,再同步更新团队指南、分页故事板、UI 系统和工程规格。