STON.fi V2 Transaction Deadlines: Wallet Signing Is Not DEX Expiry
A STON.fi V2 swap can still expire after the wallet has already authorized the first message. TON moves the operation through separate contracts, and STON.fi stores tx_deadline in the DEX payload so stale execution can be rejected later.
🔥 Wallet time vs DEX time
- validUntil in TonConnect only governs whether the wallet accepts the request.
- valid_until on the wallet message only limits signed-message acceptance.
- tx_deadline belongs to the STON.fi V2 payload and protects later execution.
🚀 The message path that carries expiry
1. The user wallet starts the offer Jetton transfer.
2. The Router Jetton wallet sends transfer_notification to the STON.fi Router.
3. The Router receives swap data including tx_deadline, refund address and min_out.
4. The Router sends a swap message to the matching Pool.
5. The Pool still has tx_deadline when it applies swap conditions.
🧠 Why this split exists
Signing, token transfer, Router processing and Pool execution are not one event on TON. Under load, time can pass after the first transaction already landed. STON.fi added an optional V2 deadline after those delays. min_out and tx_deadline still solve different problems.
⚡ What to inspect after expiry
- Earlier wallet and token-transfer transactions can already exist.
- Follow Router notification, Pool timing, then pay_to output or refund.
- Do not treat the first wallet hash as settlement.
- If the quote is stale, resimulate instead of refreshing only the deadline.
STON.fi expiry is enforced when the Pool executes, not when the wallet signs.
Would you set a shorter STON.fi tx_deadline under load or keep more room for message delay? 👇
Drop the trace step that confused you most when a V2 swap looked expired.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
A STON.fi V2 swap can still expire after the wallet has already authorized the first message. TON moves the operation through separate contracts, and STON.fi stores tx_deadline in the DEX payload so stale execution can be rejected later.
🔥 Wallet time vs DEX time
- validUntil in TonConnect only governs whether the wallet accepts the request.
- valid_until on the wallet message only limits signed-message acceptance.
- tx_deadline belongs to the STON.fi V2 payload and protects later execution.
🚀 The message path that carries expiry
1. The user wallet starts the offer Jetton transfer.
2. The Router Jetton wallet sends transfer_notification to the STON.fi Router.
3. The Router receives swap data including tx_deadline, refund address and min_out.
4. The Router sends a swap message to the matching Pool.
5. The Pool still has tx_deadline when it applies swap conditions.
🧠 Why this split exists
Signing, token transfer, Router processing and Pool execution are not one event on TON. Under load, time can pass after the first transaction already landed. STON.fi added an optional V2 deadline after those delays. min_out and tx_deadline still solve different problems.
⚡ What to inspect after expiry
- Earlier wallet and token-transfer transactions can already exist.
- Follow Router notification, Pool timing, then pay_to output or refund.
- Do not treat the first wallet hash as settlement.
- If the quote is stale, resimulate instead of refreshing only the deadline.
STON.fi expiry is enforced when the Pool executes, not when the wallet signs.
Would you set a shorter STON.fi tx_deadline under load or keep more room for message delay? 👇
Drop the trace step that confused you most when a V2 swap looked expired.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
