Wallet Interface, Payment Integration, or Risk Project? A Web3 Demand Matrix
A framework for user flows, asset responsibility, payments, identity, fraud, and security boundaries in legitimate wallet-product work.
Signals to watch
- Organization, product, and user flow can be verified
- Asset, key, custody, and transaction responsibilities are explainable
- Payment, identity, fraud, or security problems are specific
- Release, audit, or partner acceptance creates timing
Direct answer
“We need wallet integration” may describe a front-end connection or a broader payment, asset-control, identity, fraud, and regulatory problem. First establish who controls assets and keys, who handles transactions and refunds, and which users are served. Exclude anonymous speculation, laundering, sanctions evasion, and credential requests.
Demand qualification matrix
| Dimension | Weak signal | Stronger signal | Next verification |
|---|---|---|---|
| User interface | “Add a wallet button” | Connection, signature, consent, and error handling are defined | Confirm supported actions and user-warning responsibility |
| Asset responsibility | “We need all wallet features” | Custodial or non-custodial boundary, keys, and recovery are clear | Never request user seed phrases or private keys |
| Payments | “Support collection” | Goods, amount, order, refund, and reconciliation are described | Verify provider and applicable rules |
| Identity and fraud | “Avoid extra verification” | User risk, abnormal behavior, and escalation controls exist | Reject identity and compliance evasion |
| Security review | “Check it before launch” | Architecture, permissions, contracts, or APIs and remediation timing are defined | Set test environment, access, and reporting responsibility |
What remains unknown
- Product and company ownership
- Whether any party has custody
- Target users and jurisdictions
- Payment, refund, and dispute flow
- Incident response and user notification
Common false positives and misrouting
- Anonymous token or return promotion
- Seed phrase, private key, or stolen-asset requests
- Sanctions, identity, or monitoring evasion
- Ideas without an organization or user flow
Questions to ask first
- Which organization owns the product?
- What user action is supported?
- Who controls assets, keys, and recovery?
- Who handles transactions, refunds, and reconciliation?
- Which risks require detection and escalation?
- Which tests and approvals precede release?
Reusable conclusions
- Define asset and responsibility boundaries first.
- Wallet connection is not custody.
- Payments include refunds and reconciliation.
- Security and compliance cannot be replaced by UX.
- Exclude high-risk and evasion requests.
Related reading：Mini App security audit and Mini App benchmark method The matrix supports routing; it does not replace factual verification or professional advice.
Frequently asked questions
What problem does this matrix solve?
“We need wallet integration” may describe a front-end connection or a broader payment, asset-control, identity, fraud, and regulatory problem. First establish who controls assets and keys, who handles transactions and refunds, and which users are served. Exclude anonymous speculation, laundering, sanctions evasion, and credential requests.
What is the most common misrouting risk?
Anonymous token or return promotion; Seed phrase, private key, or stolen-asset requests
What should the first verification ask?
Which organization owns the product?; What user action is supported?; Who controls assets, keys, and recovery?