先限定二维码里面是什么
冷钱包扫码签名这个说法容易把载体与操作混在一起。二维码只是传递数据的一种方式；本文只讨论它承载支付请求URI的情形，不覆盖设备配对、分片数据或其他离线签名编码，也不声称所有硬件钱包都采用同一种格式。
支付请求的作用是把建议执行的内容交给应用解释。应用能够识别请求、打开一个付款界面，不代表用户已经授权，更不是链上付款凭证。读资料时，先问当前看到的是请求内容、用户确认步骤，还是后续执行记录，不能只按界面上出现“扫码”二字归类。
比特币请求须按对应规范读取
当前查阅的BIP-321状态为Complete，并标明替代BIP-21。它描述比特币支付指令的URI方案，可以包含地址及查询参数，也允许某些扩展支付指令。这里的文档状态不是对每款钱包兼容性的测试结果，旧教程仍需核对适用版本。
在这套方案中，amount字段若出现，采用十进制BTC数量；label和message主要提供说明，不能当作收款人的身份证明。客户端处理请求必须取得用户授权。对于带req-前缀但客户端不能理解的必要参数，规范要求将整个请求视为无效，而不是忽略后继续。
以太坊请求的目标可能是合约
ERC-681中的目标字段有两种重要语义：请求原生资产付款时，它可以是收款对象；请求调用代币转移函数时，它是相应的代币合约，实际受益地址另在参数中。把这两个位置都叫收款地址，会遗漏应用究竟要调用谁。
该规范的chain_id可以省略，此时客户端当前网络设置继续有效，不能把缺少网络字段理解为自动识别无误。原生资产的value等数量有原子单位语义，不能把一串整数直接按页面常见的小数单位阅读。请求给出的金额和其他参数仍是供用户确认的建议。
识别成功后仍要保留核对步骤
一份不含秘密的检查记录可以写明：采用哪种请求方案，预期网络是什么，目标是普通接收地址还是合约，以及金额按什么单位解释。ERC-681还明确关注请求来源与内容完整性；格式正确并不证明参数来自原本打算联系的对象。
这些字段不能直接套用到其他二维码标准。设备显示的是另一种离线数据格式时，应回到该型号的正式说明，而不是手动拼凑支付请求。本文没有生成可扫描付款码、真实地址或签名材料，也未执行支付；目的只是让请求、确认和结果各自有清楚的位置。