Как дедлайны транзакций STON.fi останавливают устаревшее выполнение
Дедлайн транзакции STON.fi — это временное ограничение DEX v2, «зашитое» в payload'ы свапа и ликвидности. Если Router видит операцию после указанного timestamp, устаревшая инструкция должна истечь, вместо того чтобы исполняться как свежий свап.
🔥 Что именно делает дедлайн
- Он передаётся вместе с DEX-инструкцией, а не только отображается в UI кошелька.
- STON.fi сверяет теперь() с закодированным uint64-дедлайном.
- И свапы, и операции с ликвидностью используют эту временную границу.
🚀 Почему устаревшее выполнение — реальная проблема
Вы можете подготовить свап в полдень, опираясь на текущие резервы пула, а затем получить задержку из‑за открытого экрана подтверждения, ретрая, слабого соединения или других сделок, которые двигают пул. Подписанный запрос может по‑прежнему выглядеть валидным, но рыночный контекст, который его породил, уже старый.
Именно поэтому STON.fi v2 не считает старую инструкцию валидной навсегда.
🧠 Дедлайн, проскальзывание и валидность кошелька
- Deadline: слишком поздно для этой операции?
- min_out: сейчас выход слишком маленький?
- valid_until: сам подписанный запрос кошелька всё ещё пригоден?
Более длинный дедлайн — это не то же самое, что более мягкое проскальзывание. Первый даёт больше времени. Второе всё равно блокирует плохой выход.
⚡ Что всё ещё может стоить
Сообщения TON асинхронны. Шаг кошелька может успешно завершиться, пока позже контрактные сообщения ещё перемещаются в сети. Истечение останавливает обычное DEX-исполнение, но газ мог быть уже потрачен, а многохоп‑маршрут может не откатиться обратно к исходному токену.
💬 Мой взгляд
Используйте и временные, и выходные ограничения, и пересобирайте котировку, если транзакция пролежала слишком долго перед подписанием.
Вы рассматриваете задержанный свап STON.fi как истёкшее намерение или просто как дополнительное ожидание? 👇
Оставьте в комментариях последний случай со «стейл‑свапом», с которым вы столкнулись.
Не инвестиционная рекомендация — проведите собственное исследование! 🚀
$GRAM @STONfi DEX
Дедлайн транзакции STON.fi — это временное ограничение DEX v2, «зашитое» в payload'ы свапа и ликвидности. Если Router видит операцию после указанного timestamp, устаревшая инструкция должна истечь, вместо того чтобы исполняться как свежий свап.
🔥 Что именно делает дедлайн
- Он передаётся вместе с DEX-инструкцией, а не только отображается в UI кошелька.
- STON.fi сверяет теперь() с закодированным uint64-дедлайном.
- И свапы, и операции с ликвидностью используют эту временную границу.
🚀 Почему устаревшее выполнение — реальная проблема
Вы можете подготовить свап в полдень, опираясь на текущие резервы пула, а затем получить задержку из‑за открытого экрана подтверждения, ретрая, слабого соединения или других сделок, которые двигают пул. Подписанный запрос может по‑прежнему выглядеть валидным, но рыночный контекст, который его породил, уже старый.
Именно поэтому STON.fi v2 не считает старую инструкцию валидной навсегда.
🧠 Дедлайн, проскальзывание и валидность кошелька
- Deadline: слишком поздно для этой операции?
- min_out: сейчас выход слишком маленький?
- valid_until: сам подписанный запрос кошелька всё ещё пригоден?
Более длинный дедлайн — это не то же самое, что более мягкое проскальзывание. Первый даёт больше времени. Второе всё равно блокирует плохой выход.
⚡ Что всё ещё может стоить
Сообщения TON асинхронны. Шаг кошелька может успешно завершиться, пока позже контрактные сообщения ещё перемещаются в сети. Истечение останавливает обычное DEX-исполнение, но газ мог быть уже потрачен, а многохоп‑маршрут может не откатиться обратно к исходному токену.
💬 Мой взгляд
Используйте и временные, и выходные ограничения, и пересобирайте котировку, если транзакция пролежала слишком долго перед подписанием.
Вы рассматриваете задержанный свап STON.fi как истёкшее намерение или просто как дополнительное ожидание? 👇
Оставьте в комментариях последний случай со «стейл‑свапом», с которым вы столкнулись.
Не инвестиционная рекомендация — проведите собственное исследование! 🚀
$GRAM @STONfi DEX
