Explore visual directions before they become product rules.

DID onboarding01

Create your MID walletSubmit profile · bind MID NFC card

SubmitScan card

Identity entry

DID application and profile submission

Use when a new user has no approved DID yet. The page should make the wallet promise visible while keeping asset actions locked.

• First signal: DID not ready, but wallet path is clear.
• States: no profile, profile draft, submitted, missing data.
• Backend anchors: did_application, profile_submission, nfc_card_binding.

Discuss: should the user see a sample balance before DID approval, or only locked actions?

Review tracker02

KYCGovernmentMint DID

Government reviewExpected next update · 24-48 hours

TrackSupport

Trust state

KYC and government review progress

Use when the user is waiting. The design should reduce anxiety and show that the process is official, signed, and auditable.

• First signal: current review stage.
• States: KYC review, government review, approved, failed, resubmit.
• Backend anchors: review_stage, review_event, issuer_decision.

Discuss: how much timing detail can we show without overpromising?

Home03

MID verifiedMPC recovery enabled

$2,847.90

SendRequestReceive

Main account

Verified daily wallet home

The default consumer home should feel light and financially useful while preserving the MID-first product narrative.

• First signal: verified status, then balance.
• States: verified, risk alert, payment pending, official notice.
• Backend anchors: account_summary, asset_balance, security_status.

Discuss: should Pay or Wallet be the primary tab after Home?

Asset detail04

FCANetwork fuel

USDFPayment rail

SendReceiveReceipt

Asset wallet

FC assets plus external send and receive

Use for FCA, USDF, BTC, ETH, TRON, SOL, and BNB. External assets are supported for view, receive, and send, but not external-chain swaps.

• First signal: asset role and network.
• States: address ready, network degraded, pending confirmations, failed send.
• Backend anchors: network_adapter, chain_tx, fee_quote.

Discuss: how clearly should the UI separate FC-native assets from external assets?

Payment request05

250 USDFVerified payment request

Memo: company service filing

PayReceipt

Pay flow

Payment request, memo, confirmation, receipt

This is the core payment communication model. It should feel human, but remain structured and auditable.

• First signal: verified counterparty and amount.
• States: requested, paid, cancelled, receipt ready, failed.
• Backend anchors: payment_request, payment_note, receipt.

Discuss: do we allow free text notes, templates, or both?

Scan contact06

Add by QRVerify MID before payment

AddRequest

Social payment utility

QR scan add friend for payment

Use when users add each other for future payment requests. It is a payment contact layer, not a social network.

• First signal: contact identity and verification status.
• States: scanned, verified, duplicate contact, blocked, request sent.
• Backend anchors: contact, did_lookup, payment_channel.

Discuss: should nickname and avatar be user-controlled or DID-derived?

Swap07

FCA→USDF

Inside FC ecosystemExternal-chain swap disabled

QuoteSwap

Closed loop exchange

FC ecosystem swap only

Use for swaps between FC ecosystem currencies and introduced assets where policy allows. This keeps the wallet focused on ecosystem services, not exchange trading.

• First signal: allowed pair and policy note.
• States: quote loading, quote expired, policy blocked, completed.
• Backend anchors: swap_pair, quote, swap_receipt.

Discuss: should Swap live under Wallet, Pay, or a separate tab?

Credential08

Address ProofIssuer signed · valid

Driver LicenseShare proof QR

ProveShare

Credential center

Card-based official proof sharing

Use for official cards and verified certificates. The interaction should resemble Wallet cards but always show issuer, validity, consent, and proof purpose.

• First signal: card type and validity.
• States: valid, expired, revoked, shareable, shared.
• Backend anchors: credential, proof_request, consent_record.

Discuss: should proof sharing be one-time, time-limited, or reusable?

IBC invoice09

Blue Cedar Ltd.Director · payment allowed

Annual filingOfficial signed · 250 USDF

ReviewPay

Company account

IBC official service payment

Use when a company account pays an official invoice. The UI must show company context, operator role, invoice signature, and receipt archive.

• First signal: active company and role permission.
• States: role missing, invoice due, signed, paid, archived.
• Backend anchors: company, role, invoice, company_receipt.

Discuss: how visible should role permission be before every company payment?

Broadcast10

Official noticeIssuer verified · action required

Address proof update requested

ReviewArchive

Government channel

Official broadcast and system message

Use for government or system information that must reach users reliably. It should feel signed and official, not like marketing push.

• First signal: verified issuer and priority.
• States: unread, read, action required, archived, issuer warning.
• Backend anchors: broadcast, issuer_signature, read_receipt.

Discuss: should critical notices require user acknowledgment?

MPC recovery11

2/3

Recovery case openCooling period · risk review

VerifyContinue

Recovery advantage

MID-based recoverable wallet

Use when a verified MID holder loses a device or key access. The page should communicate safety and strict process, not convenience alone.

• First signal: recovery status and required proofs.
• States: opened, proof pending, cooling period, approved, rejected.
• Backend anchors: recovery_case, mpc_policy, risk_review.

Discuss: how should the UI explain recovery without making it sound too easy?

NFC signing12

MID CardTap to sign identity proof

Human-readable payloadAmount · network · purpose

TapSign

Card signing

MID Card and Vault Card signing moment

Use when signing identity proof, recovery approval, or protected high-value actions. MID Card proves identity; Vault Card protects higher-value wallet signing.

• First signal: what is being signed and why.
• States: tap required, card detected, signature created, failed, Vault required.
• Backend anchors: signing_session, nfc_challenge, vault_policy.

Discuss: where should the interface teach the MID Card / Vault Card distinction?

Account switcher13

PersonalMID verified · daily wallet

IBCBlue Cedar Ltd. · director

VaultProtected signing account

SwitchManage

Account context

Personal, IBC, and Vault account switcher

Use wherever payment, signing, or credential sharing depends on account context. It prevents users from paying from the wrong identity or company role.

• First signal: active account and permission boundary.
• States: personal active, IBC active, role missing, Vault locked.
• Backend anchors: account_context, role_grant, vault_policy.

Discuss: should the account switcher be persistent on every tab?

Navigation14

HomeWalletPayMID

Primary tab logicHome for status · Pay for action · MID for trust

ScanPayCards

Information architecture

Bottom navigation and quick action model

Use to decide the app skeleton. The wallet should not feel like a crypto exchange; navigation should serve identity, payment, credentials, and official services.

• First signal: which job each tab performs.
• States: new user, verified user, IBC user, high-risk alert.
• Backend anchors: feature_flag, account_capability, navigation_state.

Discuss: should Scan be a tab, a floating action, or inside Pay?

MXCD Future15

MXCD FuturePolicy-gated sovereign asset rail

LearnNotify me

Future asset narrative

MXCD Future policy-gated asset card

Use before MXCD is live. The UI should build understanding without implying current availability, guaranteed issuance, or investment value.

• First signal: future, policy-gated, not tradable now.
• States: hidden, education only, waitlist, eligible, launched.
• Backend anchors: asset_policy, eligibility_state, launch_phase.

Discuss: how do we express future value without overpromising?

USDF rail16

USDFUSD-denominated rail

ReferenceDesigned for USD payment expression

ReceiveUse

Stable rail language

USDF as a USD-denominated payment expression

Use to explain USDF professionally and safely: a payment rail intended for USD-denominated use, not a promise that conflicts with future Montserrat stablecoin policy.

• First signal: payment utility, denomination, and boundary.
• States: active, limited, conversion unavailable, policy note shown.
• Backend anchors: asset_disclosure, rail_policy, conversion_reference.

Discuss: where should the risk and disclosure language appear?

Receive external17

BTCETHTRONSOLBNB

Receive addressSelect network before showing QR

CopyQR

External asset support

External network receive flow

Use when users receive BTC, ETH, TRON, SOL, or BNB. The page must prevent wrong-network deposits with clear network selection and confirmation copy.

• First signal: selected network and deposit warning.
• States: network selected, address generated, copied, QR shown.
• Backend anchors: deposit_address, network_adapter, address_policy.

Discuss: should the wallet hide unsupported networks or show them disabled?

Send external18

0.25 ETHTo 0x7a...91f2

Network fee$3.42

ReviewSend

External send

External asset send confirmation

Use before broadcasting external transactions. It should show amount, address, fee, network, confirmation expectation, and irreversible warning.

• First signal: human-readable send summary.
• States: address invalid, fee loading, ready, pending, completed, failed.
• Backend anchors: send_intent, fee_quote, chain_tx.

Discuss: when should Vault Card signing be required for external sends?

Merchant QR19

Montserrat ServicesVerified merchant · 86 USDF

ScanPay

Merchant payment

Merchant QR checkout

Use for point-of-sale or service counter payments. The wallet should verify merchant identity before payment and create a clean receipt after settlement.

• First signal: verified merchant and amount.
• States: scanned, merchant verified, amount fixed, paid, receipt ready.
• Backend anchors: merchant_profile, checkout_intent, payment_receipt.

Discuss: should merchant QR codes support tips or only fixed amounts?

Split request20

AJM+

Split 120 USDF3 payment requests · MID verified

RequestTrack

Group payment

Split bill and multiple payment requests

Use for small groups without creating social chat. The wallet sends structured payment requests and tracks who has paid.

• First signal: amount split and verified recipients.
• States: drafted, requested, partially paid, completed, expired.
• Backend anchors: payment_batch, payment_request, participant_status.

Discuss: should group requests show all participant names or privacy-safe initials?

Scheduled21

IBC renewalDue May 28 · 250 USDF

ReminderApprovePay

SchedulePay now

Future payment

Scheduled official payment and reminder

Use when official invoices or service fees have due dates. It should help users avoid missed obligations without silently moving funds.

• First signal: due date, amount, and approval requirement.
• States: scheduled, reminder sent, approval needed, paid, missed.
• Backend anchors: scheduled_payment, invoice_due_date, reminder_event.

Discuss: should scheduled payments auto-pay or only remind?

Receipt vault22

Payment · USDFCredential shareIBC invoice

SearchExport

Records

Receipt vault and searchable activity archive

Use for user trust and support. Receipts should not be a hidden transaction list; they should be official records across payments, credentials, recovery, and IBC services.

• First signal: record type and searchable history.
• States: empty, filtered, exported, disputed, archived.
• Backend anchors: receipt, activity_event, export_job.

Discuss: should receipts export as PDF, JSON, or both?

Fees23

Amount250 USDF

Network fee0.12 USDF

Total250.12

ConfirmReceipt

Transparency

Fee and total cost breakdown

Use wherever a user pays, swaps, sends externally, or signs a protected operation. The UI should make costs predictable before commitment.

• First signal: total amount and fee source.
• States: loading quote, fee changed, accepted, expired.
• Backend anchors: fee_quote, quote_expiry, cost_summary.

Discuss: should fee changes force a new confirmation every time?

Network status24

FC Chain · normalETH · delayedTRON · normal

DetailsRetry

Reliability

Network status and degraded service state

Use when a network is delayed or unavailable. It should explain impact clearly and prevent users from blaming the wallet for chain conditions.

• First signal: which network is affected.
• States: normal, delayed, paused, retrying, restored.
• Backend anchors: network_status, service_incident, retry_policy.

Discuss: should degraded networks be hidden from Send until restored?

Risk block25

Payment blockedNew device · unusual amount

Explain reasonVerify MIDTry again

VerifySupport

Risk UX

Suspicious payment blocked state

Use when the wallet prevents a risky action. The block should feel protective, not arbitrary, and should show a safe next step.

• First signal: blocked action and reason category.
• States: blocked, step-up required, support review, released, denied.
• Backend anchors: risk_signal, policy_decision, step_up_request.

Discuss: how much risk detail can we show without helping attackers?

Devices26

iPhone 15 · trustedMacBook · newOld phone · remove

TrustRemove

Security settings

Trusted devices and active sessions

Use so users can understand wallet access and security. Device management should connect to MPC recovery and risk controls.

• First signal: trusted device status.
• States: trusted, new, suspicious, removed, recovery locked.
• Backend anchors: device_session, trusted_device, session_revoke.

Discuss: should removing a device trigger a cooling period?

Support case27

Case #1042Recovery review · waiting for proof

OpenReviewResolve

UploadMessage

Customer experience

Support case for recovery or official service issue

Use when support must guide the user through strict actions. It should keep support communication structured and auditable.

• First signal: case status and required action.
• States: opened, waiting user, internal review, resolved, escalated.
• Backend anchors: support_case, case_message, evidence_upload.

Discuss: should support messages live inside Pay-style threads or a separate inbox?

Renewal28

Address ProofExpires in 14 days

Renew credentialUpload document · issuer review

RenewRemind

Credential lifecycle

Credential expiry and renewal

Use for address proof, license, tax number, and IBC certificates. The wallet should prevent silent expiry from breaking payments or services.

• First signal: expiry timeline and affected features.
• States: valid, expiring, expired, renewal submitted, renewed.
• Backend anchors: credential_expiry, renewal_case, issuer_review.

Discuss: should expired credentials hide cards or keep them visible as inactive?

Services29

Company filingAddress proofTax recordLicense

StartPay

Official services

Government service marketplace

Use when official services become wallet actions. The design should feel like a trusted service desk, not a commercial app store.

• First signal: official service category and eligibility.
• States: eligible, locked, fee due, form started, completed.
• Backend anchors: service_catalog, eligibility_check, service_case.

Discuss: should services be grouped by personal, IBC, and government roles?

IBC role30

Invite operatorFinance manager · limited payment role

View invoicesPrepare paymentNo Vault signing

InviteApprove

Company permission

IBC role invitation and approval

Use when a company grants wallet permissions to a director, accountant, or operator. The page must show scope and signing limits clearly.

• First signal: role scope and approval path.
• States: invited, accepted, pending approval, active, revoked.
• Backend anchors: role_invite, permission_scope, approval_event.

Discuss: should role approvals require MID Card, Vault Card, or both?

Vault signing31

Vault CardTap for protected transaction

High-value send1,500 USDF · IBC account

ReviewTap

Cold wallet layer

Vault Card high-value operation

Use when the wallet needs Tangem-like card signing for large or sensitive actions. It is separate from the MID Card identity proof.

• First signal: Vault required and payload summary.
• States: Vault unbound, tap required, signed, failed, policy blocked.
• Backend anchors: vault_card, signing_payload, transaction_policy.

Discuss: what limits should trigger Vault Card signing?

Learning32

Why MID-first?Identity unlocks payments, credentials, and recovery.

What is USDF?USD-denominated payment rail.

NextDone

Onboarding education

First-week product education cards

Use for early users so the wallet's difference becomes clear without long tutorials. Education should appear as timely cards, not marketing pages.

• First signal: one concept at a time.
• States: new user, dismissed, completed, resurfaced by action.
• Backend anchors: education_card, onboarding_progress, dismissal_event.

Discuss: which concepts must be taught before the first payment?

Setup mode33

MID + MPCMID CardVault Card

RecommendedRecoverable wallet with identity proof.

Start setupCompare

Wallet creation

Wallet setup path selector

Use before wallet creation so users understand the difference between a recoverable MPC wallet, MID Card identity signing, and Vault Card protected signing.

• First signal: recovery and signing model.
• States: recommended, card required, advanced, disabled by policy.
• Backend anchors: wallet_setup_mode, key_policy, card_binding_state.

Discuss: should MPC be the default for all normal users?

MID Card34

Tap MID CardIdentity key activation

ScanBind

Identity hardware

MID Card first tap activation

Use when the physical MID Card becomes the identity proof and signing companion. It should feel foundational, not like an optional cold wallet feature.

• First signal: this card proves identity, not asset custody.
• States: card detected, PIN required, card bound, card mismatch, blocked.
• Backend anchors: mid_card_binding, nfc_challenge, identity_signature.

Discuss: should MID Card setup happen before or after DID approval?

MPC recovery35

MID proofDevice riskCooling period

2/3

ContinuePause

Recoverable wallet

MPC recovery quorum progress

Use when a user recovers a wallet through verified MID identity. The interface should show progress, but never make recovery feel casual or instant.

• First signal: strict recovery checkpoints.
• States: submitted, risk review, cooling period, approved, rejected.
• Backend anchors: mpc_recovery_case, identity_reverification, cooling_period.

Discuss: how much recovery detail should be visible to the user?

Freeze36

Wallet frozenOutgoing transfers are paused.

ReasonUser request · suspicious device.

ReviewUnfreeze

Emergency control

Emergency freeze and unfreeze

Use when the user or risk engine pauses outgoing transfers. This is important because recoverability must be paired with fast damage control.

• First signal: what is frozen and what remains usable.
• States: user frozen, system frozen, review required, unfreeze pending.
• Backend anchors: wallet_freeze, risk_trigger, unfreeze_approval.

Discuss: can receive and credential use stay active while send is frozen?

Offline receive37

Pending syncCollect request created offline.

Show codeSync

Connectivity edge

Offline receive request

Use for places where connectivity is unreliable. The wallet can prepare a signed payment request and reconcile it once the device is online.

• First signal: offline mode and sync status.
• States: offline draft, shown, scanned, expired, synced.
• Backend anchors: offline_payment_request, sync_event, request_expiry.

Discuss: what offline limits prevent abuse while keeping utility?

Weak network38

USDF send · queuedBTC receive · waitingReceipt · synced

RetryDetails

Reliability

Low-connectivity transaction queue

Use when the app cannot confirm a network action immediately. The design should prevent duplicate sends and make pending states calm.

• First signal: queued, not failed.
• States: queued, broadcasting, confirmed, failed, user cancelled.
• Backend anchors: transaction_queue, broadcast_attempt, idempotency_key.

Discuss: should users be allowed to cancel before broadcast?

Trust tiers39

Verified MIDFull payment confidence

Known contactNickname verified by user

Unknown addressExtra confirmation required

Address book

Trusted contact tiers

Use to reduce payment mistakes. Contacts should not be just names; they should carry trust signals, identity proof, and history.

• First signal: verified person, known contact, or raw address.
• States: verified, user trusted, unverified, blocked, stale.
• Backend anchors: contact_trust_level, did_resolution, address_alias.

Discuss: can users pay unknown addresses without extra friction?

Pay chat40

Dinner share?Request 24 USDFPaid

RequestReceipt

Payment messaging

Payment chat thread

Use for the limited chat layer we discussed: payment request, payment note, receipt, and simple confirmation messages only.

• First signal: payment context, not social chat.
• States: request sent, paid, declined, expired, receipt issued.
• Backend anchors: payment_message, request_status, receipt_event.

Discuss: should free-text messages be disabled or capped?

Invoice chat41

Invoice #2048Attached to payment request

Due420 USDF

ReviewPay

IBC payments

Invoice attachment in payment chat

Use when an IBC sends a payable invoice inside the payment conversation. The payment object should carry invoice data, not just a chat bubble.

• First signal: invoice identity and due amount.
• States: attached, reviewed, approved, paid, disputed.
• Backend anchors: invoice_attachment, payable_request, ibc_payment_case.

Discuss: should invoice approval require a separate company role?

Export42

March receiptsIBC tax packCSV + PDF

FilterExport

Records

Receipt export and tax pack

Use when users or IBCs need clean records for tax, accounting, or service proof. It turns wallet history into usable documentation.

• First signal: period, account, and export format.
• States: filtered, generated, encrypted, downloaded, shared.
• Backend anchors: receipt_export, statement_period, audit_file.

Discuss: should official receipts have a verification QR?

Merchant43

Today
1,240 USDFPaid
38

SettlementUSDF to FCA account.

CollectSettle

Merchant mode

Merchant payment console

Use for verified merchants who receive frequent USDF payments. It should be simple enough for a counter, but auditable enough for business records.

• First signal: today's collection and settlement status.
• States: open, collected, refund requested, settled, reconciled.
• Backend anchors: merchant_account, collection_event, settlement_batch.

Discuss: should merchant mode be inside personal wallet or separate?

POS44

Quick collect12.80 USDF · expires in 90s

Point of sale

Counter POS quick collect

Use for cashier-style payment. The screen should be readable from a distance, with amount, merchant proof, and expiry visible.

• First signal: amount and verified merchant.
• States: created, displayed, scanned, paid, expired.
• Backend anchors: pos_payment_request, merchant_did, payment_expiry.

Discuss: should POS mode allow manual amount edits after QR creation?

Mandate45

Monthly paymentMontserrat Services · max 60 USDF

Next chargeMay 1

ApproveLimit

Recurring payments

Recurring payment mandate

Use when a user authorizes a predictable official or merchant payment. The mandate must show cap, frequency, cancellation, and audit trail.

• First signal: who can charge, how much, and how often.
• States: pending, active, paused, exceeded, cancelled.
• Backend anchors: payment_mandate, spending_cap, mandate_event.

Discuss: should all recurring payments require MID Card confirmation?

Limits46

Operator limit500 USDF/day

SaveAudit

Delegated control

Delegated spending limit

Use when an IBC grants operational payment ability without full signing authority. This keeps business payments fast but bounded.

• First signal: role, limit, and approval override.
• States: draft, active, exceeded, override requested, revoked.
• Backend anchors: delegated_limit, role_policy, override_request.

Discuss: should limits be per day, per payment, or per counterparty?

Whitelist47

Family reserveIBC treasuryNew address locked

AddReview

Protection rule

Beneficiary whitelist

Use for users who want high-value payments limited to trusted beneficiaries. It is a softer daily alternative to a full wallet freeze.

• First signal: trusted destination list.
• States: active, pending addition, cooling period, locked, removed.
• Backend anchors: beneficiary_whitelist, destination_policy, cooling_period.

Discuss: should new beneficiaries require a 24-hour delay?

Travel48

HomeUSDF

Local viewGBP

EnableRates

Travel use

Travel mode display

Use when a user is abroad and needs clearer local value display without changing the actual asset or settlement logic.

• First signal: display currency, not asset conversion.
• States: suggested, enabled, manual currency, disabled.
• Backend anchors: display_currency, geo_hint, fx_reference_rate.

Discuss: should travel mode be automatic or opt-in?

Currency view49

100 USDF$100.00

100 FCANetwork asset

ChangeExplain

Comprehension

Local currency display controls

Use to separate asset identity from display currency. This helps users understand USDF, FCA, and external assets without misleading conversion language.

• First signal: asset amount and reference value are different layers.
• States: USD reference, local reference, hidden value, stale rate.
• Backend anchors: valuation_display, reference_rate, rate_timestamp.

Discuss: how often should reference values refresh?

Asset detail50

ETH0x7a...91f2

NetworkEthereum

CopyExplorer

External assets

Asset detail and explorer handoff

Use for BTC, ETH, TRON, SOL, and BNB detail pages. External assets need transparent network information and explorer handoff.

• First signal: asset, network, and address.
• States: loaded, syncing, explorer unavailable, unsupported action.
• Backend anchors: external_asset_account, chain_indexer, explorer_url.

Discuss: how much external-chain detail should non-crypto users see?

Risk copy51

Wrong network = loss riskAddress cannot be reversedCheck first transfer

I understandBack

External asset safety

External chain risk education

Use before first external send or receive. The tone should be calm and practical, not frightening, but the risk must be unmistakable.

• First signal: external-chain finality and network mismatch risk.
• States: first-time, acknowledged, repeated warning, blocked.
• Backend anchors: risk_acknowledgement, chain_warning, policy_block.

Discuss: when should warnings become blocking confirmations?

Treasury52

Runway8.4 months

PayReport

IBC finance

IBC treasury overview

Use for business accounts that need more than a token list. The dashboard should show liquidity, obligations, and pending approvals.

• First signal: cash position and payable pressure.
• States: healthy, low runway, approvals pending, reporting due.
• Backend anchors: ibc_treasury, payable_summary, cashflow_snapshot.

Discuss: should treasury be visible to all company roles?

Batch pay53

12 recipients2,400 USDFDirector approval

ValidateSubmit

Business payments

Batch payroll payout

Use when IBCs need to pay many verified recipients. It needs validation, clear totals, and a strong approval record.

• First signal: recipient count, total, and approval requirement.
• States: draft, validation errors, ready, approved, paid.
• Backend anchors: batch_payment, recipient_validation, approval_signature.

Discuss: should batch payout require Vault Card for every batch?

Approval54

OperatorDirectorVault

Pending Director1 signature remaining.

RemindCancel

Governance

Director approval chain

Use for sensitive IBC operations. The chain should make it obvious who has acted, who is next, and what policy requires it.

• First signal: current approver and remaining signatures.
• States: initiated, waiting, approved, rejected, expired.
• Backend anchors: approval_chain, signature_requirement, approval_deadline.

Discuss: should directors approve inside chat or a separate approval inbox?

Official action55

Tax filing openSubmit by June 30

StartArchive

Government broadcast

Actionable government broadcast

Use when official messages carry a task, form, or payment action. Broadcast should connect directly to a safe service flow.

• First signal: issuer, deadline, and required action.
• States: unread, read, action started, completed, overdue.
• Backend anchors: official_broadcast, service_deep_link, deadline_event.

Discuss: should official broadcasts be able to pin themselves on Home?

Emergency56

Service disruptionFC Chain delayed · funds safe

Send pausedReceive delayedStatus updating

Public alert

Emergency public alert state

Use when the system or government needs to communicate urgent information. It must be visible without causing panic.

• First signal: what happened, what is affected, what is safe.
• States: active, updated, resolved, false alarm, archived.
• Backend anchors: incident_alert, service_status, alert_update.

Discuss: what alerts should override normal wallet navigation?

Verify57

Digital LicensePresent proof only

Credential use

Credential verification at counter

Use when a user presents a credential to a person or office. The screen should show exactly what is being shared and what is hidden.

• First signal: credential type and disclosure level.
• States: ready, scanned, verified, expired, cancelled.
• Backend anchors: credential_presentation, selective_disclosure, verification_event.

Discuss: should the user see verifier identity before sharing?

Credential pack58

Residency packDID + address + tax number

ViewShareExpire link

Proof bundle

Credential bundle share

Use when several proofs are needed together, such as address proof, tax number, and digital residency status.

• First signal: bundle contents and expiry.
• States: draft, link created, viewed, revoked, expired.
• Backend anchors: credential_bundle, share_link, revocation_event.

Discuss: should bundles be reusable templates or one-time shares?

Consent59

Shared licenseRevoked address proofViewed by agency

FilterRevoke

Privacy control

Privacy consent log

Use to make identity sharing trustworthy. Users should be able to see what was shared, with whom, when, and whether it can be revoked.

• First signal: disclosure history and control.
• States: active consent, revoked, expired, verifier viewed.
• Backend anchors: consent_record, data_disclosure, revocation_status.

Discuss: should consent logs be shown in Home alerts?

Access60

Readable modeLarger text · stronger contrast

SmallReadableHighVoice

Inclusive design

Accessible mode switch

Use for older users, low-vision users, and high-stress payment moments. Accessibility should be a first-class wallet setting.

• First signal: readability and confidence.
• States: default, readable, high contrast, voice assistance.
• Backend anchors: accessibility_preference, device_setting_sync, ui_mode.

Discuss: should readable mode be suggested after repeated payment errors?

Locale61

EnglishSource

ChineseMirror

SwitchTerms

Language system

Language and regional terms

Use to keep English as the source while supporting complete Chinese pages. Critical financial terms must stay consistent across languages.

• First signal: language, region, and legal term source.
• States: source current, translation stale, term pending review.
• Backend anchors: locale_content, term_dictionary, content_version.

Discuss: which terms need controlled vocabulary approval?

Diagnostics62

Payment issueGuided checks · no duplicate send

Device OKNetwork delayedCase ready

FixContact

Support experience

Guided diagnostics and incident status

Use before opening support cases. The wallet should help users understand whether a problem is device, network, policy, or service related.

• First signal: likely cause and safe next step.
• States: self-check, issue found, case created, incident linked.
• Backend anchors: diagnostic_session, support_case, incident_link.

Discuss: which diagnostics can run locally without sending private data?

Readiness63

DID readyMPC activeMID Card boundVault optional

ReviewImprove

Product readiness

Wallet readiness health centre

Use to show whether the wallet is fully ready for payments, credentials, recovery, IBC actions, and protected signing.

• First signal: what is ready, what is missing, and what matters next.
• States: complete, partial, action required, blocked, recommended.
• Backend anchors: wallet_readiness, capability_state, next_best_action.

Discuss: should this appear on Home or inside Security?

Reverify64

Document expiredSelfie checkAddress proof

StartLater

Identity lifecycle

DID re-verification request

Use when an identity proof expires or a higher-risk action requires fresh verification. The message must be firm but not accusatory.

• First signal: why re-verification is needed.
• States: requested, started, submitted, approved, failed, overdue.
• Backend anchors: reverification_case, proof_expiry, risk_step_up.

Discuss: which wallet actions should be limited during re-verification?

Mismatch65

Name mismatchPassport and account profile differ.

FixContact

Review exception

Name or address mismatch resolution

Use when submitted identity data conflicts with an existing profile. The user should know exactly what to correct without seeing internal risk language.

• First signal: mismatch type and safe correction path.
• States: mismatch found, user correcting, manual review, resolved, rejected.
• Backend anchors: profile_mismatch, correction_request, manual_review.

Discuss: how much mismatch detail can be shown safely?

Policy lock66

Action unavailablePolicy review required before sending.

Learn whyAppeal

Policy state

Policy lock explanation

Use when an action is blocked by policy, eligibility, or compliance controls. The design should explain the user path without exposing sensitive rules.

• First signal: blocked action and next available step.
• States: locked, appeal available, under review, unlocked, permanently restricted.
• Backend anchors: policy_lock, eligibility_rule, appeal_case.

Discuss: what policy language is safest for public UI?

Dispute67

Payment disputeMerchant did not deliver service.

OpenEvidenceDecision

Customer protection

Payment dispute case

Use when a payment itself is final, but the service or merchant relationship needs a complaint workflow. It should not promise chargebacks where none exist.

• First signal: dispute is service resolution, not chain reversal.
• States: opened, evidence requested, merchant response, resolved, closed.
• Backend anchors: payment_dispute, evidence_upload, case_decision.

Discuss: which payments are eligible for dispute support?

Refund68

OriginalRefundReceipt

Returned86 USDF

Merchant service

Merchant refund and receipt reversal

Use when a merchant sends a refund or voids a receipt. Users need a clear link between the original payment and the returned funds.

• First signal: refund amount and original receipt.
• States: requested, approved, sent, failed, receipt updated.
• Backend anchors: refund_event, receipt_link, merchant_case.

Discuss: should refunds require the same asset as the original payment?

USDF info69

USD referenceFC payment railAttestation link

ViewExplain

Stable asset trust

USDF reserve and attestation card

Use to explain USDF safely as a USD-denominated FC ecosystem payment asset, with reserve or attestation information where policy permits.

• First signal: denomination, issuer, and transparency link.
• States: current, stale, pending attestation, unavailable, warning.
• Backend anchors: usdf_disclosure, attestation_status, issuer_notice.

Discuss: what wording avoids implying sovereign stablecoin status?

FCA fuel70

Network fuel0.42 FCA

Top upWhy?

Native asset education

FCA network fuel explanation

Use to explain why the native FC Chain asset matters even when users mostly pay with USDF. It should be simple, practical, and not speculative.

• First signal: FCA powers network actions.
• States: enough fuel, low fuel, sponsored, blocked, auto top-up suggested.
• Backend anchors: network_fee_balance, fee_asset, fuel_threshold.

Discuss: should normal users see FCA fuel or should it be abstracted?

Fee sponsor71

Fee coveredGovernment service pays network fee.

ContinueDetails

Service payment

Sponsored fee official service

Use when the government, a service provider, or a promotional policy covers the network fee. This can make official services feel less technical.

• First signal: user pays service amount, not network fee.
• States: sponsored, partially sponsored, expired, not eligible.
• Backend anchors: fee_sponsorship, sponsor_policy, fee_receipt.

Discuss: should fee sponsorship be visible or quietly applied?

Swap quote72

100 FCA to 18.40 USDFQuote valid for 20 seconds

RouteFC pool

FC ecosystem swap

Swap quote with validity window

Use for swaps inside the FC ecosystem only. The design should show quote duration, fee, route, and final receive amount without crypto trading clutter.

• First signal: exact receive estimate and quote expiry.
• States: quoted, refreshing, expired, accepted, failed.
• Backend anchors: swap_quote, quote_expiry, fc_liquidity_route.

Discuss: should swap feel like exchange, conversion, or payment preparation?

Liquidity73

Limited liquidityTry a smaller amount or later.

ReduceNotify me

Swap edge case

Swap unavailable due to liquidity

Use when FC ecosystem liquidity cannot support a requested swap. The tone should be service-like, not trading-platform-like.

• First signal: unavailable reason and safe alternatives.
• States: insufficient liquidity, route unavailable, amount reduced, notify enabled.
• Backend anchors: liquidity_check, route_status, availability_alert.

Discuss: should the app suggest smaller amounts automatically?

Asset policy74

Asset support changingReceive disabled after review date.

MoveLearn

Asset lifecycle

Unsupported asset or network sunset

Use when an external asset, network, or token support policy changes. Users need enough time and clear actions to move safely.

• First signal: affected asset, deadline, and allowed actions.
• States: notice, receive disabled, send only, hidden, archived.
• Backend anchors: asset_support_policy, sunset_notice, action_limit.

Discuss: how much notice is required before disabling receives?

Security update75

Update requiredSecurity patch before high-value send.

UpdateDetails

App integrity

Security update required state

Use when an app version is too old for sensitive actions. The app should preserve trust by explaining the reason and keeping low-risk access available.

• First signal: update protects account security.
• States: recommended, required, blocked action, updated, failed update.
• Backend anchors: minimum_app_version, security_patch, action_gate.

Discuss: which actions can remain available on old versions?

New phone76

Verify MIDTap cardRestore wallet

StartOld device?

Device lifecycle

New phone migration

Use when a user moves to a new phone. The flow should feel secure and reassuring, especially because the wallet is recoverable through MID.

• First signal: safe migration path and old device status.
• States: old device available, old device lost, MID verified, restored, old sessions revoked.
• Backend anchors: device_migration, session_revocation, mpc_share_refresh.

Discuss: should old devices be revoked automatically after migration?

Card replace77

MID Card replacementOld card disabled after new card binds.

OrderReport lost

MID Card lifecycle

Lost MID Card replacement

Use when a user loses the MID Card. This must be clearly separate from losing the Vault Card or losing the wallet itself.

• First signal: identity card replacement, wallet still protected.
• States: reported lost, replacement ordered, new card verified, old card disabled.
• Backend anchors: mid_card_replacement, card_revocation, replacement_order.

Discuss: can users continue payments while waiting for a new MID Card?

Backup card78

Primary VaultBackup Vault

AddTest

Vault resilience

Vault Card backup management

Use for users or IBCs that need a backup protected signing card. The design should prevent confusion with the MID identity card.

• First signal: primary and backup signing devices.
• States: primary active, backup untested, backup active, revoked, rotation due.
• Backend anchors: vault_card_set, backup_card_test, signing_device_rotation.

Discuss: should backup Vault Cards have lower signing limits?

Handoff79

Continue on desktopQR expires in 2 minutes

Show QRCancel

Cross-device

Secure cross-device handoff

Use when users begin a service or IBC task on mobile and continue on desktop. The handoff should never transfer signing authority silently.

• First signal: session handoff, not key handoff.
• States: QR created, scanned, verified, expired, revoked.
• Backend anchors: session_handoff, handoff_challenge, session_scope.

Discuss: which tasks are safe for desktop continuation?

Closure80

Export recordsMove assetsRevoke shares

PrepareCancel

Account lifecycle

Account closure and data export

Use when users want to close or pause the wallet. It should protect records, revoke credential shares, and avoid stranded assets.

• First signal: what must be completed before closure.
• States: requested, checklist incomplete, ready, closed, reactivation window.
• Backend anchors: account_closure, data_export, credential_revocation.

Discuss: should wallet closure be reversible for a limited time?

Legacy81

Trusted access planInactive account review after policy period.

NominateRules

Long-term safety

Trusted access and estate planning

Use for long-term account safety planning. This is sensitive and should be policy-led, with strict identity, waiting periods, and legal controls.

• First signal: controlled access plan, not shared passwords.
• States: nominee added, inactive review, proof requested, approved, denied.
• Backend anchors: trusted_access_plan, inactive_account_policy, legal_review.

Discuss: should this be part of MVP or a later trust feature?

Ops queue82

12 DID reviews4 recovery cases2 policy appeals

AssignAudit

Operations console

Government or trust operations review queue

Use as a reference for the internal side of the product. The wallet experience depends on clear review queues, assignment, and audit trails.

• First signal: case type, risk level, and SLA.
• States: unassigned, assigned, escalated, approved, rejected, audited.
• Backend anchors: review_queue, case_assignment, operator_audit.

Discuss: what internal states must map directly to user-facing states?

Composer83

Broadcast previewAudience: all verified residents

PreviewSchedule

Official communication

Government broadcast composer

Use for the team to discuss how official messages are authored, targeted, approved, scheduled, and audited before reaching wallets.

• First signal: audience, issuer, approval, and delivery time.
• States: draft, review, approved, scheduled, sent, corrected.
• Backend anchors: broadcast_composer, audience_segment, approval_workflow.

Discuss: should every broadcast require two-person approval?

KYB84

CompanyDirectorWallet

IBC onboarding

IBC KYB status journey

Use for companies moving from registration to operational wallet use. It should show director verification, wallet capability, and pending blockers.

• First signal: company status and next blocked step.
• States: company submitted, director verified, wallet pending, active, rejected.
• Backend anchors: ibc_kyb_case, director_link, company_wallet_state.

Discuss: should IBC wallet activation wait for all directors?

Fee calc85

Service totalApplication 50 + network 0 + document 8

Total58 USDF

Official service pricing

Government service fee calculator

Use when an official service has multiple fee lines. Users should see what each fee means before signing or paying.

• First signal: total and fee breakdown.
• States: estimated, confirmed, fee changed, sponsored, paid.
• Backend anchors: service_fee_quote, fee_line_item, payment_instruction.

Discuss: should fee quotes be locked for a time window?

Issuer86

License issuedRenewal pendingRevocation ready

IssueAudit

Credential issuer

Credential issuer console

Use as a reference for agencies or approved issuers that create, renew, revoke, and audit digital credentials inside the ecosystem.

• First signal: issuer authority and credential lifecycle state.
• States: draft, issued, renewed, suspended, revoked.
• Backend anchors: credential_issuer, issuance_event, revocation_registry.

Discuss: which issuers can revoke credentials directly?

Privacy support87

Safe support viewAddresses masked, documents hidden.

Share logsStop

Support privacy

Safe support data redaction

Use when a user shares diagnostic data with support. The product should show what support can see and let users stop sharing.

• First signal: shared data is limited and temporary.
• States: not shared, user approved, shared, expired, revoked.
• Backend anchors: support_data_grant, data_redaction, grant_expiry.

Discuss: what should support never be able to view?

Risk score88

Medium riskNew device + new beneficiary

VerifyWait

Risk transparency

User-safe risk explanation

Use when the system adds friction. The user needs a plain reason without exposing fraud-detection internals or enabling circumvention.

• First signal: practical reason and next step.
• States: low, medium, high, step-up required, blocked.
• Backend anchors: risk_level, step_up_reason, friction_policy.

Discuss: how specific can risk explanations safely be?

Product map89

VerifyPayRecoverSupport

TraceExport

Product analytics

Event map for product owners

Use to align product, engineering, and analytics around meaningful events instead of scattered button clicks.

• First signal: capability journey and measurable state changes.
• States: event defined, instrumented, validated, deprecated.
• Backend anchors: product_event, funnel_state, analytics_contract.

Discuss: which events prove MID-first wallet value?

Design tokens90

Token setTrust, action, warning, official.

Design system

Design token usage sample

Use to keep samples from becoming disconnected art. Color, elevation, spacing, and state tokens should map to product meaning.

• First signal: visual decisions are reusable system rules.
• States: draft token, approved token, deprecated token, theme variant.
• Backend anchors: design_token, component_state, theme_mapping.

Discuss: which colors are reserved for official or risk states?

Empty state91

No receipts yetYour first payment receipt will appear here.

Make paymentLearn

State library

Empty state library

Use to make first-use screens helpful instead of blank. Empty states should point to one useful next action and explain the value of the page.

• First signal: nothing is wrong, the user has not used this feature yet.
• States: no data, filtered empty, permission empty, service unavailable.
• Backend anchors: empty_state_reason, first_action_hint, permission_state.

Discuss: should empty states teach or stay very quiet?

Error state92

Something needs attentionPayment not sent. No funds moved.

Try againSupport

Failure design

Failure and reassurance state

Use for failed payment, signing, recovery, and service actions. The most important message is whether funds moved and what the user can safely do next.

• First signal: outcome, safety, and next action.
• States: failed safely, partial completion, retry available, support required.
• Backend anchors: failure_outcome, safe_retry, support_escalation.

Discuss: what failure states require human support immediately?

Notifications93

Notification controlsOfficial, security, payment, marketing.

RequiredOptionalMuted

Communication control

Notification preference centre

Use to separate mandatory official or security notices from optional product and merchant messages. Users should feel in control without missing critical information.

• First signal: which messages are required and why.
• States: required, enabled, muted, digest, disabled by policy.
• Backend anchors: notification_preference, required_notice, delivery_channel.

Discuss: which notification categories can never be disabled?

Inbox94

3 require actionTax filing · Security update · DID renewal

ActionFilter

Official inbox

Priority inbox filter

Use when the wallet has many messages. Critical notices should be grouped by action and deadline, not mixed into a generic message list.

• First signal: action required and urgency.
• States: all, action required, official, security, payment, archived.
• Backend anchors: inbox_priority, message_category, action_deadline.

Discuss: should overdue official actions affect the Home page?

Funds source95

Source of fundsSalary, business income, savings.

DeclareUpload

Compliance prompt

Source of funds declaration

Use when policy requires the user or IBC to explain funds before a high-value action. The flow should feel professional and bounded.

• First signal: declaration reason and privacy handling.
• States: requested, draft, submitted, under review, accepted, rejected.
• Backend anchors: source_of_funds, compliance_request, document_evidence.

Discuss: when does a declaration require document upload?

Large transfer96

Amount checkPurposeVault sign

Transfer9,800 USDF

High-value control

Large transaction review

Use when a transaction crosses a policy or risk threshold. The user should see why the review exists and which actions remain possible.

• First signal: transaction is paused for review, not lost.
• States: threshold triggered, user evidence, manual review, approved, blocked.
• Backend anchors: large_transaction_review, threshold_policy, review_outcome.

Discuss: should large-transaction review happen before or after signing?

Restricted97

Region not supportedSome services are unavailable in this jurisdiction.

ExplainContact

Eligibility boundary

Restricted jurisdiction safe copy

Use when legal or policy restrictions limit access. The copy must be calm, precise, and avoid implying wrongdoing by the user.

• First signal: service eligibility, not user blame.
• States: supported, restricted, under review, appeal available, permanently unavailable.
• Backend anchors: jurisdiction_policy, service_eligibility, restriction_notice.

Discuss: should restricted users see future availability notices?

Monitoring98

Case submittedTransaction will continue after review.

FlaggedReviewOutcome

Transaction monitoring

Monitoring case user state

Use when a transaction enters compliance monitoring. The UI should avoid exposing detection rules while keeping the user informed.

• First signal: action is under review and funds are accounted for.
• States: flagged, waiting, information requested, cleared, blocked.
• Backend anchors: monitoring_case, case_status, compliance_hold.

Discuss: how should we explain review time without promising exact deadlines?

Confirmations99

BTC deposit2/6

External deposit

External deposit confirmation progress

Use when BTC, ETH, TRON, SOL, or BNB deposits need network confirmations before becoming spendable.

• First signal: received but not yet available.
• States: seen, confirming, available, delayed, failed, reorg warning.
• Backend anchors: deposit_confirmation, required_confirmations, chain_event.

Discuss: should pending external deposits count in total balance?

Labels100

Exchange BTCbc1q...8n4 · user label

Supplier ETH0x82...19d · verified by payment

External address book

Address label and memo management

Use to make external addresses safer for repeated use. Labels must remain user-controlled and not imply verified identity unless confirmed.

• First signal: user label versus verified identity.
• States: unlabeled, labeled, verified by user, stale, removed.
• Backend anchors: address_label, external_address_book, label_origin.

Discuss: should external addresses expire or require periodic re-confirmation?

Pay link101

Payment link86 USDF · expires Friday

CopyShare

Payment request

Payment link creation

Use when a merchant or user wants to send a payment request outside the wallet chat. The link must preserve verified recipient and expiry.

• First signal: amount, recipient, and expiry.
• States: created, shared, viewed, paid, expired, cancelled.
• Backend anchors: payment_link, request_token, expiry_policy.

Discuss: should payment links be public, private, or contact-bound?

Merchant KYB102

BusinessOwnerWallet

Merchant onboarding

Merchant verification onboarding

Use when a merchant applies to receive verified wallet payments. The flow should make the difference between personal, IBC, and merchant accounts clear.

• First signal: merchant acceptance depends on verification.
• States: application, owner verified, bank or wallet linked, approved, rejected.
• Backend anchors: merchant_onboarding, merchant_kyb, merchant_capability.

Discuss: can a personal user become a merchant without an IBC?

Staff mode103

Counter staffCan collect payments, cannot withdraw.

CollectRefundNo payout

Merchant operations

Store staff terminal role

Use for shops where staff need to accept payments without seeing full business treasury or signing authority.

• First signal: limited staff permission.
• States: invited, active, shift open, shift closed, revoked.
• Backend anchors: merchant_staff_role, terminal_session, permission_scope.

Discuss: should staff sessions automatically expire at shift end?

Accounting104

Accounting exportXero-ready CSV · monthly receipts

ConnectExport

Business tooling

Accounting integration export

Use when IBC or merchant wallets need external accounting. Start with export formats before promising deep two-way integrations.

• First signal: export period and accounting format.
• States: not connected, export ready, generated, imported, failed.
• Backend anchors: accounting_export, ledger_mapping, statement_file.

Discuss: which accounting integrations matter for launch?

Reconcile105

1 mismatchInvoice total differs from payment.

MatchExplain

Accounting edge

Reconciliation mismatch

Use when invoices, receipts, and payments do not match exactly. This is a practical business-wallet feature, not a crypto feature.

• First signal: mismatch type and suggested resolution.
• States: matched, amount mismatch, missing invoice, duplicate, resolved.
• Backend anchors: reconciliation_case, invoice_match, ledger_exception.

Discuss: should small rounding differences auto-resolve?

Future rail106

USDF today, MXCD tomorrowPayment experience stays familiar.

LearnNotify

Asset narrative

USDF to future Montserrat stablecoin transition

Use to explain USDF as a transitional USD-denominated FC ecosystem payment asset that prepares users for a future Montserrat stablecoin without overclaiming.

• First signal: continuity of user experience, difference in issuer status.
• States: USDF active, future rail announced, migration available, migrated, legacy hidden.
• Backend anchors: asset_transition_notice, stablecoin_migration, issuer_status.

Discuss: what wording keeps this accurate before formal issuance?

MXCD107

MXCD not available yetJoin updates when policy opens.

FollowExplain

Future asset

MXCD availability waitlist

Use to prepare for future MXCD or sovereign stablecoin features without presenting them as currently usable financial products.

• First signal: future availability, not current access.
• States: unavailable, updates joined, eligibility pending, available, not eligible.
• Backend anchors: future_asset_interest, eligibility_waitlist, availability_notice.

Discuss: should unavailable assets appear in the wallet asset list?

Disclosure108

Stable asset disclosureUnderstand issuer, risks, and redemption terms.

AcceptRead

Risk disclosure

Stable asset risk disclosure

Use before a user first holds or uses a stable asset. It should be readable, auditable, and versioned.

• First signal: asset type, issuer, and risk acknowledgement.
• States: not accepted, accepted, updated terms, expired, revoked.
• Backend anchors: asset_disclosure, terms_acceptance, disclosure_version.

Discuss: should disclosures be per asset or per product family?

Proof request109

Bank requests proofAddress + DID status · expires in 7 days

ReviewDecline

Third-party verification

Proof request from bank or partner

Use when a verified third party asks the user to share credentials. The wallet must make verifier identity and requested fields unmistakable.

• First signal: who asks, what they ask for, and expiry.
• States: received, reviewed, shared, declined, expired, revoked.
• Backend anchors: proof_request, verifier_identity, requested_claims.

Discuss: should unknown verifiers be blocked by default?

Verifier110

Verified verifierMontserrat Revenue Office

Issuer checkedPurpose shownExpiry setRevocable

Trust before sharing

Verifier trust screen

Use before credential sharing. Users need to trust not just the credential, but the party requesting it.

• First signal: verifier identity and purpose.
• States: verified, partially verified, unknown, blocked, reported.
• Backend anchors: verifier_registry, verification_purpose, trust_status.

Discuss: should every verifier be in an official registry?

Revocation111

Credential revokedDigital license no longer valid.

DetailsRenew

Credential lifecycle

Credential revocation notice

Use when an issued credential is revoked, suspended, or no longer valid. The user must see consequence and appeal or renewal route.

• First signal: credential status changed and why it matters.
• States: active, suspended, revoked, appeal pending, renewed.
• Backend anchors: credential_revocation, revocation_reason, appeal_route.

Discuss: what revocation reasons can be shown to users?

Renewal pay112

License renewalFee due · credential expires in 14 days

PaySchedule

Credential payment

Scheduled credential renewal payment

Use when a credential renewal includes a fee and deadline. This links official credential lifecycle to wallet payment logic.

• First signal: credential expiry and renewal cost.
• States: upcoming, scheduled, paid, renewed, expired.
• Backend anchors: credential_renewal, renewal_fee, scheduled_payment.

Discuss: should renewal payment automatically trigger credential renewal?

Assistant113

Family assistantCan request payment, cannot send.

InviteLimits

Delegated support

Family or assistant limited access

Use for elderly users or busy business owners who need help managing requests without giving away signing authority.

• First signal: helper can assist, not control funds.
• States: invited, accepted, active, limited, revoked.
• Backend anchors: helper_access, delegated_permission, approval_required.

Discuss: should helper access require periodic reconfirmation?

Guardian114

Recovery nomineeCan support recovery, cannot access funds.

AddExplain

Recovery support

Guardian recovery nominee

Use when a user nominates a trusted person or institution to support recovery evidence without receiving custody.

• First signal: nominee helps recovery, never holds keys.
• States: nominated, verified, active, removed, challenged.
• Backend anchors: recovery_nominee, nominee_verification, recovery_evidence.

Discuss: should nominees be individuals, institutions, or both?

Vault lost115

Signing frozenVault Card reported lost.

ReplaceReview

Cold signing safety

Lost Vault Card freeze signing

Use when the protected signing card is lost. Freeze signing authority while keeping identity and wallet visibility separate.

• First signal: signing is frozen, assets are still visible.
• States: reported, signing frozen, replacement started, re-bound, resolved.
• Backend anchors: vault_card_lost, signing_freeze, vault_rebind.

Discuss: can small payments continue without Vault Card?

PIN116

PIN resetMID proof and card tap required.

Card credential

Card PIN reset

Use when a user forgets a MID Card or Vault Card PIN. The flow must distinguish card access recovery from wallet recovery.

• First signal: reset protects the card, not the whole wallet.
• States: requested, identity verified, card tapped, reset complete, locked out.
• Backend anchors: card_pin_reset, pin_attempt_policy, card_unlock_event.

Discuss: how many failed PIN attempts should trigger support?

Offline ID117

Offline identity checkMID Card proof cached for verifier.

PresentExpire

Offline identity

Offline MID Card identity check

Use when a verifier needs proof but network access is unreliable. The UI should make freshness and expiry clear.

• First signal: offline proof is time-limited.
• States: proof prepared, presented, verified offline, expired, sync logged.
• Backend anchors: offline_identity_proof, proof_expiry, verification_sync.

Discuss: which credentials are safe for offline proof?

Watch-only118

View-only accountMonitor balance, cannot move funds.

AddAlert

Account visibility

Watch-only account view

Use when users monitor external addresses or company reserves without importing signing authority into M Wallet.

• First signal: view-only means no send capability.
• States: added, syncing, alert enabled, hidden, removed.
• Backend anchors: watch_only_account, read_only_address, balance_alert.

Discuss: should watch-only assets appear in total balance?

Release119

What changedNew recovery status, merchant refunds, proof requests.

ReadDismiss

Product change

Release notes and user education

Use when new wallet capabilities ship. Release notes should explain user value, risk changes, and any action needed.

• First signal: what changed and whether user action is required.
• States: unread, read, action required, dismissed, resurfaced.
• Backend anchors: release_note, feature_education, version_notice.

Discuss: should security-related release notes be dismissible?

Design QA120

ReadableState mappedRisk copyBackend anchor

PassRevise

Team process

Design QA checklist card

Use during design review so every sample is checked for readability, state logic, risk language, localization, and engineering mapping.

• First signal: design quality is evaluated against product logic.
• States: draft, reviewed, needs revision, approved, archived.
• Backend anchors: design_review_item, qa_status, decision_record.

Discuss: should this checklist become a mandatory design gate?