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
