STON.fi Transaction Deadlines Explained: Time Risk Versus Slippage
STON.fi DEX v2 puts an execution deadline inside the swap payload so a prepared operation can be rejected if it arrives after its allowed timestamp. That stops one class of delayed-execution risk. It does not replace minimum received or wallet validity.
🔥 Why Delayed STON.fi Execution Matters
- After you approve a quote, inclusion, Router handling and Pool execution can take longer than expected.
- Pool reserves can change while the signed instruction is still technically valid.
- Without a time boundary, an old swap can still run simply because other conditions remain valid.
🚀 How the Deadline Works
Suppose a swap prepared at 12:00 carries a 12:15 deadline. At 12:14 it can still proceed if other checks pass. At 12:16 it should follow the failure or refund path instead of executing normally. The contract only compares execution time with the encoded timestamp.
🧠 Deadline and Min Out Are Different Jobs
- Deadline asks: is this operation too old?
- Min out asks: is current output below the encoded minimum?
- A late swap that still returns enough tokens can pass price and fail time, or the reverse.
💬 Extra Layers Users Should Notice
TON wallets and TonConnect can also use validUntil on the signed request. That wallet-level window is not the same as the STON.fi DEX deadline traveling through Router and Pool messages. Multi-contract TON routes are also not fully atomic, so expiration can stop a late stage without unwinding every earlier message.
STON.fi deadlines are time-based execution protection built for high-load delays. Pair them with a fresh simulation and a sensible minimum output.
Would a shorter STON.fi deadline make you more comfortable signing a swap? 👇
Share how you currently set swap lifetime in the comments.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
STON.fi DEX v2 puts an execution deadline inside the swap payload so a prepared operation can be rejected if it arrives after its allowed timestamp. That stops one class of delayed-execution risk. It does not replace minimum received or wallet validity.
🔥 Why Delayed STON.fi Execution Matters
- After you approve a quote, inclusion, Router handling and Pool execution can take longer than expected.
- Pool reserves can change while the signed instruction is still technically valid.
- Without a time boundary, an old swap can still run simply because other conditions remain valid.
🚀 How the Deadline Works
Suppose a swap prepared at 12:00 carries a 12:15 deadline. At 12:14 it can still proceed if other checks pass. At 12:16 it should follow the failure or refund path instead of executing normally. The contract only compares execution time with the encoded timestamp.
🧠 Deadline and Min Out Are Different Jobs
- Deadline asks: is this operation too old?
- Min out asks: is current output below the encoded minimum?
- A late swap that still returns enough tokens can pass price and fail time, or the reverse.
💬 Extra Layers Users Should Notice
TON wallets and TonConnect can also use validUntil on the signed request. That wallet-level window is not the same as the STON.fi DEX deadline traveling through Router and Pool messages. Multi-contract TON routes are also not fully atomic, so expiration can stop a late stage without unwinding every earlier message.
STON.fi deadlines are time-based execution protection built for high-load delays. Pair them with a fresh simulation and a sensible minimum output.
Would a shorter STON.fi deadline make you more comfortable signing a swap? 👇
Share how you currently set swap lifetime in the comments.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
