STON.fi トランザクションの締切が「古い実行」を止める方法

STON.fi のトランザクション締切は、スワップおよびリクイディティのペイロードに組み込まれた DEX v2 の時間制限です。Router がそのタイムスタンプ以降に処理を受け取った場合、古い指示(stale instruction)は「新しいスワップ」のように実行されず、期限切れとして無効になります。

🔥 結局、締切は何をするの?

- DEX の指示と一緒に送られ、ウォレットUIだけの表示ではありません。
- STON.fi は now() を、エンコードされた uint64 の締切と照合します。
- スワップとリクイディティ操作の両方で、この時間の境界が使われます。

🚀 「古い実行」が本当の問題になる理由

たとえば、現在のプール残高を元に正午にスワップ準備できたとしても、確認画面が開いたまま遅延したり、リトライ、弱い接続、または他の取引によってプールが動いたりすることで遅れます。署名済みリクエスト自体はまだ有効に見えても、それを作った「市場状況」が古くなっているのです。

だからこそ STON.fi v2 は、古い指示を永遠に有効とは扱いません。

🧠 締切・スリッページ・ウォレット有効性

- Deadline:この操作は遅すぎないか?
- min_out:出力が今小さすぎないか?
- valid_until:署名されたウォレットリクエスト自体はまだ使えるか?

締切が長いことは、スリッページが緩くなることと同じではありません。前者はより長い時間を与えます。後者は「悪い出力」を許可してしまう(=それをブロックできなくなる)点が問題です。

⚡ それでも起こり得る損失

TON のメッセージは非同期です。ウォレット側の手順が成功していても、後続のコントラクトメッセージはまだ移動中かもしれません。期限切れにより通常の DEX 実行は止まりますが、ガスがすでに消費されている可能性があり、マルチホップ経路が元のトークンにロールバックされるわけでもありません。

💬 私の見解

時間と出力のガード(締切と min_out のような条件)を両方使い、署名の前にトランザクションが長く滞留していた場合は、クオートを作り直してください。

遅延した STON.fi スワップは「期限切れの意図」ですか?それとも「待ち時間が増えただけ」だと考えますか? 👇

コメント欄で遭遇した最後の“古いスワップ”ケースを教えてください。

※投資助言ではありません。自分で調査してください! 🚀

$GRAM @STONfi DEX