先区分代币与钱包的职责
代币是由区块链上的智能合约或相应协议记录的一类资产表示，钱包则是管理地址、密钥和交易流程的软件或设备。以 ERC-20 为例，代币合约通常围绕余额查询、总供应量、转账、授权和代扣转账等能力工作，并通过 Transfer、Approval 等事件记录状态变化。钱包不应把这些合约能力全部视为自身职责，而应通过标准接口读取余额、发起调用并展示结果。
钱包的核心边界首先是“控制资产所需的密钥和交易”。对于支持账户模型的网络，钱包通常需要生成或导入密钥、计算或展示地址、创建交易、请求签名，并在适当情况下将已签名交易广播到网络。余额计算、代币名称和精度等信息可以由链上合约读取，但这不等于钱包拥有发行、修改或保证代币价值的能力。
用三层模型确认功能范围
第一层是资产识别与展示。钱包可以读取代币合约的符号、精度、总供应量和指定地址余额，也可以根据链上交易或事件更新记录。此层重点是数据来源、网络选择和显示规则，尤其要区分链上最小单位与用户界面中的显示数量，避免把展示格式误认为实际资产变更。
第二层是交易与授权。钱包可以帮助用户构造转账交易，也可能支持授权某个地址在限额内代为转移代币。授权属于明确的链上权限变化，界面应展示被授权对象、额度和交易网络，不能只用“连接”或“确认”这类模糊措辞代替。钱包应负责让用户签名，但不应在未明确展示交易内容时替用户扩大权限。
第三层是密钥与网络分工。钱包可以是全功能模式，也可以拆分为观察或联网组件与专门签名组件。联网部分负责读取区块链信息、准备未签名交易和广播结果，离线或硬件设备负责保存私钥、审核交易细节并签名。确认产品边界时，应分别写清哪些组件接触私钥、哪些组件仅持有公钥或地址、签名后由谁广播。
按使用场景判断是否属于钱包功能
如果目标是个人自主管理，最低范围通常包括地址生成或导入、密钥备份与恢复、资产查询、交易签名和广播；代币列表、历史记录和二维码属于便利功能。若产品只负责展示余额和交易状态，却不持有私钥、也不签名，则更接近观察型或查询型工具。若由平台代为保存私钥和签名，产品边界则涉及托管流程、权限分级和内部操作控制，不能仅按普通本地钱包描述。
如果目标是收款服务，地址分配、入账监测和交易广播可能是主要功能，但还要明确是否支持代币合约交互。不能因为一个地址能够接收代币，就推断系统一定能够识别、记账或提取所有代币。支持哪些网络、代币标准、合约调用方式和确认规则，都应在产品范围中列明。
必须写入边界说明的风险
纯 ERC-20 转账没有强制要求接收合约提供接收回调。因此，用户使用 transfer 或 transferFrom 将代币发送到不具备处理能力的合约地址时，代币可能停留在该地址，未必能够取回。钱包或收款系统应避免把“地址可用”简单等同于“资产一定可处理”，并在面向合约地址的转账流程中增加识别、提醒或人工确认机制。
对于钱包开发者，还应考虑误转入自身代币合约或其他不支持代币管理的合约地址的情况。能否拒绝、识别或提取误转资产，取决于具体合约和产品设计，不是 ERC-20 钱包接口天然保证的能力。必要时，应在支持清单和异常处理流程中明确限制，而不是笼统宣称兼容所有代币。
确认边界的实用清单
可以用以下问题完成范围确认：钱包是否生成或保存私钥；是否只读地址和链上数据；是否支持代币余额与精度读取；是否支持 transfer、approve 或 transferFrom 等操作；签名在联网设备、离线设备还是硬件设备完成；谁负责广播交易；支持哪些网络和代币标准；向合约地址转账时如何提示和处理；交易失败、授权撤销和误转资产如何反馈。
当这些问题都有明确答案后，再将功能分为“必须支持”“可选支持”和“不在范围内”。这样既能避免把代币合约能力误认为钱包能力，也能让用户清楚知道钱包负责的是密钥、签名和交互流程，而不是代币本身的发行规则、价值或最终可回收性。