STON.fi 交易截止時間詳解：時間風險 vs. 滑點
STON.fi DEX v2 會在交換載荷中放入執行截止時間，因此如果已準備好的操作在允許的時間戳之後到達，就可以被拒絕。這樣可以阻止一類延遲執行風險。但它不會替代“最少收到（minimum received）”或“錢包有效期（wallet validity）”。
🔥 爲什麼延遲的 STON.fi 執行很重要
- 你批准報價後，納入打包（inclusion）、路由（Router）處理和池（Pool）執行可能比預期更久。
- 當簽名指令在技術上仍然有效時，池裏的儲備（reserves）可能已經發生變化。
- 如果沒有時間邊界，舊的交換仍可能繼續執行，僅僅因爲其他條件仍然有效。
🚀 截止時間如何工作
假設一筆在 12:00 準備好的交換帶有 12:15 的截止時間。到 12:14 時，只要其他校驗通過，它仍可以繼續執行。到了 12:16，它就應當走失敗或退款路徑，而不是按正常流程執行。合約只會把“執行時間”與編碼的時間戳進行比較。
🧠 截止時間和 Min Out（最小收到）是不同的工作
- 截止時間問：這個操作是否已經太舊？
- Min out 問：當前輸出是否低於編碼的最小值？
- 一筆“遲到但仍然返回足夠代幣”的交換可能會通過價格檢查卻在時間上失敗，反之亦然。
💬 用戶還應注意的額外層
TON 錢包和 TonConnect 也可以在簽名請求中使用 validUntil。這個“錢包級”時間窗口與 STON.fi DEX 的截止時間不相同：後者需要在通過 Router 和 Pool 的消息傳遞過程中生效。多合約的 TON 路由也並非完全原子（atomic），因此過期可能會阻止後續階段，但不會自動撤銷（unwind）之前的每一條消息。
STON.fi 的截止時間是爲高負載延遲場景設計的基於時間的執行保護。將它與最新的模擬（simulation）以及合理的最小輸出（minimum output）一起使用。
更短的 STON.fi 截止時間會讓你更願意爲交換進行簽名嗎？👇
在評論裏分享你目前如何設置交換的存活時間（swap lifetime）。
非投資建議——請自行研究！ 🚀
$GRAM @STONfi DEX
STON.fi DEX v2 會在交換載荷中放入執行截止時間，因此如果已準備好的操作在允許的時間戳之後到達，就可以被拒絕。這樣可以阻止一類延遲執行風險。但它不會替代“最少收到（minimum received）”或“錢包有效期（wallet validity）”。
🔥 爲什麼延遲的 STON.fi 執行很重要
- 你批准報價後，納入打包（inclusion）、路由（Router）處理和池（Pool）執行可能比預期更久。
- 當簽名指令在技術上仍然有效時，池裏的儲備（reserves）可能已經發生變化。
- 如果沒有時間邊界，舊的交換仍可能繼續執行，僅僅因爲其他條件仍然有效。
🚀 截止時間如何工作
假設一筆在 12:00 準備好的交換帶有 12:15 的截止時間。到 12:14 時，只要其他校驗通過，它仍可以繼續執行。到了 12:16，它就應當走失敗或退款路徑，而不是按正常流程執行。合約只會把“執行時間”與編碼的時間戳進行比較。
🧠 截止時間和 Min Out（最小收到）是不同的工作
- 截止時間問：這個操作是否已經太舊？
- Min out 問：當前輸出是否低於編碼的最小值？
- 一筆“遲到但仍然返回足夠代幣”的交換可能會通過價格檢查卻在時間上失敗，反之亦然。
💬 用戶還應注意的額外層
TON 錢包和 TonConnect 也可以在簽名請求中使用 validUntil。這個“錢包級”時間窗口與 STON.fi DEX 的截止時間不相同：後者需要在通過 Router 和 Pool 的消息傳遞過程中生效。多合約的 TON 路由也並非完全原子（atomic），因此過期可能會阻止後續階段，但不會自動撤銷（unwind）之前的每一條消息。
STON.fi 的截止時間是爲高負載延遲場景設計的基於時間的執行保護。將它與最新的模擬（simulation）以及合理的最小輸出（minimum output）一起使用。
更短的 STON.fi 截止時間會讓你更願意爲交換進行簽名嗎？👇
在評論裏分享你目前如何設置交換的存活時間（swap lifetime）。
非投資建議——請自行研究！ 🚀
$GRAM @STONfi DEX
