任何人都能写下这张交易单

一个陌生人可以把你的名字写进一张链上交易单。

他可以填写资产、付款、期限、结算授权方，以及两条交割腿各自的收款钱包。创建这份记录，不需要你的签名。

听起来像一场盗窃的开头。可在 Solana Foundation 的券款对付程序里，这只是一个提案的开头。

记录创建时，没有任何交易代币移动。陌生人不能逼你注资，也不能冒充你完成结算。真正的风险来自另一件事：你的软件把“记录已经存在”误当成“你已同意记录内容”。

最终交换可以保持原子性，但同意仍然需要一道检查关口。

最安全的按钮排在最后

券款对付解决的是一个很具体的问题。两条腿都完成注资后，指定的结算授权方可以在一笔交易里同时移动资产和付款。两边一起成功，否则整笔交易回滚。Solana DvP 指南

它消除了最后一步的“半笔交易”，却不会替第一步的交易单背书。

CreateDvp 是无许可的。创建时，只有支付账户租金的人签名；交易双方和结算授权方都不签。由此生成的 SwapDvp 账户是一张待核对的指令单，不是一份已经签署的协议。固定版本源代码

这个设计把边界划得很清楚。每一方用独立的代币转账为自己的交割腿注资；结算授权方再用另一条指令完成交换。创建可以开放而廉价，因为后续参与者本来就应该先读，再行动。

地址只是标签，不是合同

交易账户地址由结算授权方、双方身份、两种代币 mint 和一次性 nonce 推导出来。真正的经济条款放在账户内部。金额、时间和交割目的地都是存储数据，账户地址并不会把这些条款锁死。

这样做很灵活。同一组参与者和代币可以反复交易，不必重复一模一样的条件。代价是：只算出“正确地址”，远远不够。

注资之前，客户端要分别回答三个问题。

第一，这是不是一份真正的 DvP 记录？ 账户应由 DvP 程序持有，并符合固定的 458 字节布局。

第二，这是不是目标记录？ 账户地址应与记录内的授权方、双方、两种 mint 和 nonce 一致。

第三，这是不是双方真正同意的交易？ 金额、时间窗口、授权方和两个交割目的地，都必须与实际批准的订单逐项相符。

生成的客户端提供了检查账户归属、布局和地址推导的读取器。它不知道某个人的邮件、订单系统或签署文件里写了什么。商业条款的最后一次比对，必须由集成方完成。

注资让提案变成真实风险

最关键的时刻看起来很普通。一方使用 checked token transfer 把自己的代币送进托管账户。转账指令不会先去核对链下订单，也不会替你判断交易记录是否正确。它只会把代币送到指定的托管地址。

因此，安全控制必须放在构造交易之前，而不是等转账完成后再弹出警告。

一个实用的集成关口不必复杂：

1. 从可信的 RPC 响应读取记录；
2. 核验程序归属、账户布局和推导地址；
3. 将所有重要条款与已批准订单逐项比对；
4. 检查代币程序及可能影响转移的权限；
5. 只有全部一致，才构造注资交易。

如果字段缺失或不一致，客户端应该明确显示差异并停止。它不能把未知值改写成零，不能因为地址看起来熟悉就推断同意，也不该用一个笼统的“继续”按钮把用户送过风险边界。

先测试拒绝路径

最小而有用的构建，不是一次顺利完成的演示，而是两组测试样本。

样本 A 写入预期的参与方、金额、时间和目的地。样本 B 保留熟悉的身份和 mint，只改动一个重要字段，例如付款金额，或资产最终进入的钱包。

核验器应在构造注资指令之前接受 A、拒绝 B。然后逐项替换字段，重复测试。团队可以用序列化账户样本完成，也可以在不使用真实资产的 devnet 环境里验证。目标不是再次证明链能结算正确交易，而是证明客户端会拦下错误交易单。

我没有提交交易，也没有复现已部署程序的构建。来源研究以只读方式追踪了公开状态机、安全审计和线上程序账户。上述样本测试仍是一份设计，需要集成团队实际执行并留下记录。

原子结算让最后一个按钮更安全。好的客户端，会让前面的拒绝动作变得平淡、明确、可重复。

任何人都能写下这张交易单。第一枚代币是否值得送进去，应该由你的软件先作出判断。