任何人都能寫下這張交易單

一個陌生人可以把你的名字寫進一張鏈上交易單。

他可以填寫資產、付款、期限、結算授權方，以及兩條交割腿各自的收款錢包。建立這份紀錄，不需要你的簽名。

聽起來像一場盜竊的開頭。可在 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 環境裡驗證。目標不是再次證明鏈能結算正確交易，而是證明用戶端會攔下錯誤交易單。

我沒有提交交易，也沒有重現已部署程式的建構。來源研究以唯讀方式追蹤了公開狀態機、安全審計和線上程式帳戶。上述樣本測試仍是一份設計，需要整合團隊實際執行並留下紀錄。

原子結算讓最後一個按鈕更安全。好的用戶端，會讓前面的拒絕動作變得平淡、明確、可重複。

任何人都能寫下這張交易單。第一枚代幣是否值得送進去，應該由你的軟體先作出判斷。