钱包界面、支付接入还是风控项目？Web3 产品需求判断矩阵

重点监测信号

• 组织、产品与用户流程可以验证
• 资产、密钥、托管和交易责任可说明
• 支付、身份、欺诈或安全问题具体
• 发布、审计或合作验收日期明确

直接结论

“需要接钱包”可能只是前端连接，也可能涉及支付、资产控制、身份、欺诈和监管责任。任何项目都必须先确定谁控制资产和密钥、谁处理交易与退款、服务面向哪些用户，并排除匿名投机、洗钱、制裁规避和凭证请求。

需求判断矩阵

判断维度	弱信号	强信号	下一步核实
用户界面	“接一个钱包按钮”	连接、签名、授权和错误处理流程明确	确认支持的用户动作与提示责任
资产责任	“钱包功能都要”	托管或非托管边界、密钥和恢复责任清楚	禁止接触用户助记词和私钥
支付交易	“支持收款”	商品、金额、订单、退款和对账流程可描述	核实支付提供方和适用规则
身份与欺诈	“不想增加验证步骤”	用户风险、异常行为和升级流程有控制	拒绝规避身份和合规义务
安全审计	“上线前看看”	架构、权限、合约或接口范围与修复日期明确	定义测试环境、权限和报告责任

哪些信息仍然未知

• 产品与公司实际所有权
• 资产是否由任何一方托管
• 目标用户与司法辖区
• 支付、退款和争议流程
• 事件响应与用户通知责任

常见误报与误路由

• 匿名代币或收益推广
• 要求获取助记词、私钥或被盗资产
• 规避制裁、身份或交易监控
• 没有组织和用户流程的概念讨论

第一次应该问的问题

1. 产品和负责组织是谁？
2. 用户具体要完成什么动作？
3. 谁控制资产、密钥和恢复？
4. 交易、退款和对账由谁处理？
5. 哪些风险必须识别和升级？
6. 上线前需要什么测试和批准？

可复用结论

• 先划清资产与责任边界。
• 钱包连接不等于托管服务。
• 支付必须包含退款和对账。
• 安全与合规不能用前端体验替代。
• 高风险和规避请求应直接排除。

相关内容：Mini App安全审计、Mini App基准方法。矩阵用于路由，不能替代事实核实或专业意见。

常见问题

这个矩阵解决什么问题？

“需要接钱包”可能只是前端连接，也可能涉及支付、资产控制、身份、欺诈和监管责任。任何项目都必须先确定谁控制资产和密钥、谁处理交易与退款、服务面向哪些用户，并排除匿名投机、洗钱、制裁规避和凭证请求。

最常见的误路由是什么？

匿名代币或收益推广；要求获取助记词、私钥或被盗资产

第一次核实应该问什么？

产品和负责组织是谁？；用户具体要完成什么动作？；谁控制资产、密钥和恢复？

资料来源与延伸阅读

1. FATF：虚拟资产风险方法与国际标准
2. Telegram：Mini Apps 官方文档