扫码收款在稳定币支付里已经日常化，但大多数用户只把二维码当成一张图片，没意识到中间那一串字符是一种被规范化过的协议。Solana 生态为此有一套名为 Solana Pay 的链接标准：用一条以 solana: 开头的 URL 描述一笔转账请求，钱包读到它就能替用户把交易组装好。它的设计蓝本来自比特币的 BIP-21 与以太坊的 ERC-681，三条生态各自独立收敛到几乎相同的思路上，这件事本身就值得对照阅读。
先看链接结构。一条转账请求链接以收款方的基础 58 编码公钥作为地址主体，后面跟一串可选参数：amount 是金额，以用户单位书写而不是最小单位，比如写 1.5 而不是十五亿拉门特；spl-token 指定代币的铸造账户地址，一旦出现，钱包必须按关联代币账户的约定推导收款地址；reference 可以出现多次，每个值是 32 字节数组，钱包要把它们以只读非签名身份塞进转账指令；label 和 message 是给人看的字符串，必须 URL 编码；memo 则会被写进链上的备忘录指令，随交易永久公开。
这些参数里最巧妙的是 reference。它不参与转账逻辑，唯一用途是留下可检索的标记：Solana 验证者按账户键索引交易，商户把订单号哈希成 32 字节放进 reference，之后用按地址查签名历史的方法就能把链上交易和自己的订单系统对上——在交易发生之前，这个标记就已经可用了。相比让用户复制粘贴订单备注，或者依赖链上备忘录，参考键方案不改变交易结构、多笔转账还能分别追踪，是典型的用现有索引能力解决对账问题的工程。
金额字段的严谨度容易被人低估。标准规定：不写金额时钱包必须弹窗让用户自己填；小数位超过支持精度（原生 SOL 支持九位，代币按各自精度）的链接必须判为格式非法直接拒绝；零点几的写法必须带前导零，科学计数法被明令禁止。这些看起来琐碎，针对的都是真实事故——把金额单位搞错一个数量级、或者用十六进制小数混进 JSON，都会造成静默的多付少付。
memo 字段则是一个隐私教学点：标准明确它会进链上备忘录、被验证者记录，因此不得包含隐私或敏感信息。把它和 label、message 对照最能说明问题：后两者只在钱包界面显示，不必然上链；memo 则是公开账本的一部分。同一句话写进不同字段，公开程度完全不同。收款方展示品牌名用 label，写订单说明用 message，只有确实需要链上留痕时才用 memo。
安全边界方面，这条标准从诞生时就把责任写给了收款方：应用必须确认交易已获确认且有效之后，才能放货或开门。二维码不保证资金最终性，它只是请求，后面还可能遇到重组、替换与双花场景。钱包侧的约定同样具体：移动端钱包应注册接管这个链接协议头，让用户在环境里点开链接时直接进入核对界面而不是浏览器。与以太坊的支付链接相比，Solana Pay 把代币收款强制走关联账户推导，堵住了收款地址填成辅助代币账户的常见坑；与比特币的 BIP-21 相比，它多了链上备忘录与只读键两类挂钩，对账能力更强。
对普通用户，记住三点就够：扫码后看钱包界面显示的金额与收款方名称，那是解码后的内容；对不上就拒绝，不要相信页面旁边的文字说明；确认付款后把订单号与链上交易号各自保存一份。对开发者，reference 设计与字段公开级别的选择，才是这套标准真正的精华。
值得一提的是这套标准的生态协调背景：规范文档自述其共识已经达成，钱包与实现方在发布时已有落地版本，同时明确它从比特币 BIP-21 与以太坊 ERC-681 汲取灵感——三条生态在完全不同的技术栈上，各自独立演化出请求即链接的同构方案，说明支付场景对非对称沟通（商户不必在线、用户不必复制地址）的需求足够刚性，也说明这类标准的生命力取决于钱包是否默认接管协议头，而不是委员会的规模。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。