适用范围：先确定所支持的链
钱包开发中的同名术语未必具有相同含义。以太坊账户文档侧重账户及其状态，比特币开发者指南侧重钱包程序、密钥文件和功能分工。理解这些概念时，应先明确目标链，再将术语对应到系统需求，不能把某条链的账户字段直接套用到所有钱包。
需求阶段：钱包、账户与地址
钱包是管理密钥、展示信息或协助与链交互的应用；账户是以太坊上的状态实体；地址用于标识交互对象。以太坊的外部账户由私钥控制，合约账户由代码逻辑控制。比特币语境中的“钱包”还可能指钱包文件，因此需求文档应明确讨论的是软件功能还是保存的数据。
这一区分影响功能命名。例如，“创建钱包”“生成地址”和“部署合约账户”代表不同工作，不能共用一个含糊的完成标准。界面显示多个地址，也不意味着必须部署多个钱包应用。
密钥管理阶段：私钥、公钥与加密存储
私钥用于签名，公钥用于验证相关签名；地址与公钥有关，但两者不能直接等同。Keystore通常指保存加密密钥的数据文件，WIF则是比特币私钥的一种编码格式。编码便于表示和校验，不等于加密保护。
开发文档需要分别描述密钥生成、存储与使用环节。文件加密解决的是存储保护问题，不能据此推断解密后的运行环境同样安全。钱包密码与链上签名权限也应分别解释，避免让用户误以为密码就是私钥。
架构阶段：签名端与联网端
比特币开发者指南将地址或公钥分发、签名、联网交互视为可分离的职责。只读钱包可以观察相关链上信息而不持有签名所需的私钥；硬件钱包主要承担专用签名职责，需要与联网程序协作。
采用分离架构时，接口设计应说明每个组件接收什么数据、返回什么结果，以及由谁展示待签名内容。评价架构不能只看是否使用硬件，还要检查签名内容能否被准确核对。
交易处理阶段：构建、签名与广播
构建是组织交易内容，签名是生成可验证的授权证明，广播是将已签名交易交给网络传播。三个动作具有不同的完成条件，因此“签名成功”不能直接作为“链上执行成功”的界面提示。
以太坊的nonce涉及账户交易顺序管理，balance字段表示ETH余额，wei是ETH的基础计量单位。这些术语分别对应顺序控制、余额读取和数值表示，不应混成一个笼统的“资产处理”模块。
常见问题：如何把术语变成验收条件
“只读钱包能否独立签名”“文件加密后是否仍需保护运行环境”“广播完成后界面该显示什么”，都可以转化为明确的验收问题。术语表应注明所属链、功能边界和成功条件，使产品说明、接口定义与测试预期保持一致。