How STON.fi Transaction Deadlines Stop Stale Execution
A STON.fi transaction deadline is a DEX v2 time limit baked into swap and liquidity payloads. If the Router sees the operation after that timestamp, the stale instruction should expire instead of executing like a fresh swap.
🔥 What the Deadline Actually Does
- It travels with the DEX instruction, not just the wallet UI.
- STON.fi checks now() against the encoded uint64 deadline.
- Swaps and liquidity operations both use this time boundary.
🚀 Why Stale Execution Is a Real Problem
You can prepare a swap at noon from current pool reserves, then get delayed by an open confirmation screen, a retry, a weak connection, or other trades that move the pool. The signed request may still look valid, but the market context that created it is older.
That is why STON.fi v2 does not treat an old instruction as valid forever.
🧠 Deadline, Slippage and Wallet Validity
- Deadline: is this operation too late?
- min_out: is the output now too small?
- valid_until: is the signed wallet request itself still usable?
A longer deadline is not the same as looser slippage. The first gives more time. The second still blocks a bad output.
⚡ What Failure Can Still Cost
TON messages are asynchronous. The wallet step can succeed while later contract messages are still moving. Expiration stops ordinary DEX execution, but gas may already be spent and a multi-hop route may not roll back to the original token.
💬 My take
Use both time and output guards, and rebuild a quote if the transaction sat around too long before signing.
Do you treat a delayed STON.fi swap as expired intent or just extra waiting time? 👇
Drop the last stale-swap case you ran into in the comments.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
A STON.fi transaction deadline is a DEX v2 time limit baked into swap and liquidity payloads. If the Router sees the operation after that timestamp, the stale instruction should expire instead of executing like a fresh swap.
🔥 What the Deadline Actually Does
- It travels with the DEX instruction, not just the wallet UI.
- STON.fi checks now() against the encoded uint64 deadline.
- Swaps and liquidity operations both use this time boundary.
🚀 Why Stale Execution Is a Real Problem
You can prepare a swap at noon from current pool reserves, then get delayed by an open confirmation screen, a retry, a weak connection, or other trades that move the pool. The signed request may still look valid, but the market context that created it is older.
That is why STON.fi v2 does not treat an old instruction as valid forever.
🧠 Deadline, Slippage and Wallet Validity
- Deadline: is this operation too late?
- min_out: is the output now too small?
- valid_until: is the signed wallet request itself still usable?
A longer deadline is not the same as looser slippage. The first gives more time. The second still blocks a bad output.
⚡ What Failure Can Still Cost
TON messages are asynchronous. The wallet step can succeed while later contract messages are still moving. Expiration stops ordinary DEX execution, but gas may already be spent and a multi-hop route may not roll back to the original token.
💬 My take
Use both time and output guards, and rebuild a quote if the transaction sat around too long before signing.
Do you treat a delayed STON.fi swap as expired intent or just extra waiting time? 👇
Drop the last stale-swap case you ran into in the comments.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
