先区分钱包、账户与代币
钱包通常是用户与区块链账户交互的界面或应用，不等同于账户本身。账户负责在链上持有资产、发起或响应交易；钱包则可能负责创建账户、保存或调用密钥、组织交易请求、展示余额，并将签名后的请求提交到网络。因此，确认功能边界的第一步，是把“钱包能做什么”和“账户或合约能做什么”分别列出。
在以太坊语境下，账户主要包括由私钥控制的外部拥有账户，以及由合约代码控制的合约账户。两类账户都可以接收、持有和发送 ETH 或代币，也都可以与已部署的智能合约交互，但交易发起方式和控制机制不同。钱包是否支持某类账户，应以它能否正确识别、签名或调用该账户为准，而不能仅以界面上是否显示一个地址判断。
以控制权和签名范围划定核心边界
对于外部拥有账户，私钥用于签署消息和交易，掌握私钥通常意味着能够控制该账户关联的资产。钱包的核心责任应包括保护密钥或安全调用密钥、展示待签名内容、让用户确认操作对象和金额，并避免在未经授权的情况下签名。私钥、公钥和地址的用途不同：地址用于识别账户，私钥用于签名，公开地址不能反推出私钥。
功能设计还应明确签名范围。普通转账、代币转账、授权合约使用代币，以及调用其他合约，可能是不同类型的请求。钱包若只支持资产转账，就不应把“支持连接合约”表述成“支持所有代币应用”；若支持合约调用，则应展示目标地址、方法或参数、资产数量和网络等关键信息，并将无法解析的请求与已识别请求区分开。
区分代币转账与合约交互
ERC-20 是一种可替代代币标准，代币合约通常记录总供应量以及各账户的余额，并提供转账等标准化操作。代币并不单独存放在钱包应用内，而是由区块链上的代币合约按照账户地址记录状态。钱包的代币功能因此至少包含三层：发现或添加代币合约、读取账户余额、构造并签署合约调用。
“发送代币”并不一定等于向接收方直接发送一条原生资产转账。对 ERC-20 代币而言，常见做法是调用代币合约的转账方法，由合约更新发送方和接收方的余额记录。钱包需要确认代币合约地址、网络、接收地址和数量，并避免仅凭代币名称或图标识别资产。对于授权、质押、兑换等操作，钱包实际面对的是更广泛的合约交互，不能将其自动归入普通转账功能。
把精度、余额和显示规则写进边界
代币合约内部使用整数记录余额，decimals 通常用于界面显示和单位换算，而不是改变合约底层的整数运算。比如界面显示的数量需要结合代币合约声明的精度进行换算，钱包发送时则必须把用户输入转换为合约所需的最小单位。因而，钱包的功能边界应明确：显示精度来自哪里、输入的小数位如何限制、舍入或非法格式如何处理，以及余额读取失败时是否禁止提交交易。
显示出来的代币名称、符号和数量不应被视为资产真实性的充分证明。准确的余额至少需要关联具体网络、账户地址和代币合约地址。若同一名称或符号对应多个合约，钱包应保留合约地址等识别信息，避免把展示层信息误当作链上身份。
确认适用条件与不应承诺的能力
一个清晰的钱包功能说明应写明适用网络、支持的账户类型、支持的代币标准、是否支持合约调用、是否支持硬件或外部签名设备，以及交易广播失败、网络不一致和余额读取异常时的处理方式。不同网络或不同代币合约可能存在额外规则，不能因为某一类 ERC-20 代币可用，就推断所有代币或所有合约都兼容。
还应把保管模式单独说明。非托管钱包、托管服务和采用多方控制或合约账户的产品，其密钥控制、签名流程和恢复机制并不相同。若产品只提供查看地址和余额的功能，就不应暗示用户可以在其中完成转账；若产品能发起签名，也应说明签名权限覆盖的是普通转账、代币操作，还是任意合约调用。
常见问题：用一份边界清单复核
可以用以下问题复核产品定义：第一，钱包管理的是私钥、外部签名器，还是仅保存公开地址；第二，支持外部拥有账户、合约账户，还是只支持其中一种；第三，代币余额是否按网络和合约地址区分；第四，转账与授权、合约调用是否分别展示和确认；第五，代币精度、最小单位和输入校验是否一致；第六，失败、待确认和已确认状态是否明确。
如果这些问题无法得到明确答案，通常说明钱包、账户和代币合约的责任边界仍然混在一起。较稳妥的做法是先建立能力矩阵：以账户类型、网络、资产类型和操作类型为坐标，逐项标记“读取、构造、签名、广播、确认”分别由哪个组件负责。这样既能避免把钱包能力夸大为链上能力，也能减少因单位、权限或合约目标识别不一致造成的产品错误。