先明确流程的适用范围
“钱包提币到交易所”在自托管钱包场景下，通常指钱包发起链上转账，接收平台随后识别到账并记入用户账户。确认功能边界的核心，是把发送端、区块链网络和接收端分开判断。若钱包属于托管服务，还涉及服务方内部处理，不能仅凭链上原理判断其全部流程。
钱包端：签名和广播分别证明什么
以太坊交易文档说明，交易通过签名表达账户授权，并需要广播、纳入区块和执行。钱包端的边界因此可以分为交易信息展示、签名授权和提交网络；这些环节完成，并不自动证明接收平台已经记账。
签名只能说明相应密钥授权了交易，不能证明接收地址属于预期平台。交易哈希用于标识交易，也不能单独证明交易已确认。界面中的“已发送”，需要结合其实际指代的状态理解。
网络端：链上成功需要看具体动作
网络状态与业务状态应分别核对。对于以太坊，交易被纳入区块后还需要区分执行成功或失败，并关注后续确认与最终性。不能把出现区块记录直接解释为预期资产已经转移。
普通ETH转账与代币合约调用的核对对象也有区别：前者可关注接收地址和转账金额；后者还涉及合约及实际执行内容。合约调用的交易目标可能是代币合约，因此不能只看交易外层的目标地址判断最终收款对象。
接收端：识别到账与账户记账是独立环节
比特币支付处理指南说明，收款系统可以建立地址与付款请求的对应关系，再扫描匹配交易。这体现了接收端的一项独立职责：把链上付款关联到具体业务记录。该机制可以帮助理解充值识别，但不能据此断言某家交易所采用了相同实现。
确认具体平台的边界，需要其自身规则说明支持的网络、资产、账户归属方式及入账条件。两份技术文档没有规定交易所统一的确认次数或处理时限，不能据此推导具体到账承诺。
常见问题：如何判断流程停在哪一层
有交易哈希但未入账，能否认定平台故障？不能。需要分别确认网络是否收录、执行结果是否符合预期，以及接收端是否完成识别。链上成功只能回答链上动作的问题，平台账户余额还需要平台记录佐证。
二维码或备注能否证明充值归属？二维码主要承载付款信息；比特币BIP21中的label和message不会写入实际交易，不能把它们视为通用的链上归属凭证。
功能验收可围绕三类证据展开：钱包的授权与提交记录、网络的交易与执行记录、接收平台的账户入账记录。每类证据只支持对应环节的结论，才能避免把局部完成误报为全流程完成。