Почему свап завис в TIME_EXPIRED — 6 причин и как вернуть деньги

TIME_EXPIRED выглядит пугающе, но структурно это триггер refund’а, а не потеря денег. На некастодиальном агрегаторе твоя крипта вообще не заходит в чужой кошелёк — либо она не уходила из твоего, либо вернётся на refund-адрес, который ты указал. Статус означает буквально одно: депозит не пришёл в подтверждённом виде до того, как часы ордера закончились. В гайде — шесть реальных причин (низкая комиссия, медленная сеть, перегруз, fix-лок, не та сеть, не та сумма) и пятишаговая последовательность восстановления, которую можно отработать за две минуты.

Что такое TIME_EXPIRED на самом деле

Каждый свап-ордер живёт по фиксированному state machine. Пока он живой — статус идёт NEW → WAIT_DEPOSIT → CONFIRMING → EXCHANGING → SENDING → DONE. Когда умирает — попадает в один из трёх терминальных статусов неудачи.

TIME_EXPIRED означает конкретно: окно депозита закрылось до того, как твоя транзакция собрала достаточно подтверждений у провайдера. Это терминальный статус — сам по себе ордер дальше не двинется. Это структурно отличается от FAILED (провайдер отверг ордер или сломался внутри) и от REFUNDED (refund уже явно сделан). TIME_EXPIRED — это корзина «депозит не пришёл вовремя».

Полный флоу статусов со скриншотами разобран на странице how-it-works. Главное здесь: TIME_EXPIRED — это статус оригинального ордера, а не блокировка твоих средств.

TIME_EXPIRED — триггер refund’а, а не failure. На некастодиальном агрегаторе твоя крипта не заходит ни в чей кошелёк: либо ты не отправлял, либо она вернётся на refund-адрес.

Первая проверка — депозит вообще ушёл из кошелька?

До того как лезть в восстановление, выясни, отправлял ли ты депозит вообще. Половина всех «у меня свап завис» тикетов закрывается именно здесь.

• Ордер открыл, депозит не отправил. Крипта в кошельке. Ордер просто истёк idle. Никакого восстановления и тикетов — открой новый свап.
• Отправил, транзакция всё ещё в mempool. Депозит может прийти и после того как ордер истёк. Что дальше — зависит от late-deposit политики провайдера: большинство делает авто-refund на refund-адрес, который ты указал, кто-то даёт продолжить по живому floating-курсу.
• Отправил, транзакция подтвердилась до истечения, но статус всё равно TIME_EXPIRED. Перепроверь order ID — может быть ты смотришь не на тот ордер или у тебя кэш страницы. Подтверждённый в окно депозит должен пройти CONFIRMING → EXCHANGING → SENDING.

Практический шаг: открой кошелёк, найди исходящую транзакцию по этому ордеру, скопируй txid, вставь в блок-эксплорер нужной сети. Confirmed / pending / dropped — этот один факт определяет всю дальнейшую логику.

6 реальных причин TIME_EXPIRED

Почти любой истёкший ордер сводится к одной из шести причин. Понимание, какая именно — это и план восстановления, и инструкция как не повторить.

Причина 1 — Заниженная комиссия сети

Самая частая. Отправил депозит с низким sat/vB на BTC или низким gas на ETH, транзакция висит в mempool часами, окно депозита ордера закрывается до первого подтверждения. Это чистый промах в оценке комиссии — «economy» или «slow» тариф твоего кошелька был ниже того, что сеть реально клировала в этот момент. Используй mempool.space для BTC или gas-tracker для ETH, и склоняйся к fast-тарифу когда часы ордера тикают.

Причина 2 — Исходная сеть медленная by design

У BTC — 10–60 минут на подтверждение. XMR требует 10 подтверждений по 2-минутному блоку — минимум 20 минут на полный settlement. ETH в перегруженный день переползает с 1–3 минут до 10+. Если окно провайдера короче реального settlement твоей сети — истечение статистически вероятно даже на щедрой комиссии. Это случай, где узкое место — сама блокчейн-сеть.

Причина 3 — Спайк перегруза сети

Внезапный спайк mempool — запуск memecoin’а, авария CEX и волна выводов, популярный NFT-mint — двигает твою транзакцию в конец очереди даже на «рекомендованной» комиссии. Случай «я заплатил рекомендованный sat/vB и всё равно истекло». Комиссия была правильной на момент broadcast и неправильной к моменту следующего блока.

Причина 4 — Истёк лок у fixed-rate

У fixed-rate ордеров лок-окно короче (обычно 10–30 минут), чем у floating. Лок — это гарантия курса: если депозит подтверждается после закрытия окна, провайдер не может удержать залоченный курс и сваливается в refund. Длительность лока разная у разных провайдеров, но всегда туже floating-окна — провайдер несёт ценовой риск. Полный разбор механики курса — в гайде fixed vs floating.

Fixed-rate ордера истекают чаще floating, потому что лок гарантирует курс, а не окно депозита. На медленной исходной сети типа BTC mainnet лок часто закрывается до первого подтверждения.

Причина 5 — Не та сеть

Выбрал в виджете USDT (ERC-20), отправил USDT по TRC-20 на похожий адрес. Ожидаемая сеть депозита не увидела, ордер истёк в ожидании. Это структурно худшая причина, потому что восстановление — самое грязное: депозит лёг на сеть, о которой у ордера нет записи, и насколько он восстановим — зависит от того, держит ли принимающий провайдер кошелёк на той сети, куда ты реально отправил. Всегда перечитывай network badge на экране send своего кошелька перед подтверждением.

Причина 6 — Несовпадение суммы

Отправил меньше минимума (amount_from floor), больше максимума или сумму, не совпадающую с ожидаемой. Многие провайдеры удержат и сделают refund после вмешательства саппорта, но сам ордер уйдёт в TIME_EXPIRED, потому что ожидаемая сумма в окно не пришла. Fixed-rate строже: floating терпит маленький over/under в рамках лимитов провайдера, fixed — обычно нет.

Что происходит с твоими деньгами в каждом сценарии

Механика восстановления зависит от того, что реально произошло on-chain. Сматчи свой случай со строкой ниже.

• Не отправлял. Ничего не произошло. Ордер на данном этапе — UI-артефакт. Открой новый — восстанавливать нечего.
• Отправил на правильной сети, депозит подтвердился поздно, refund-адрес указан. Провайдер делает авто-refund на refund-адрес или маршрутизирует через саппорт. С refund-адресом, указанным заранее, всё в основном автоматом — в этом и есть смысл привычки указывать refund-адрес. Жди возврата on-chain в течение 1–60 минут.
• Отправил на правильной сети, refund-адрес не указан. Средства не потеряны, но восстановление через тикет в саппорт: order ID, txid депозита, адрес назначения. Дольше — от нескольких часов до нескольких дней, в зависимости от загрузки провайдера.
• Отправил на неправильной сети. Зависит от того, декодируется ли вообще адрес неправильной сети у принимающего провайдера и держит ли он кошелёк на той сети. Иногда восстанавливается с помощью саппорта, иногда нет. Срочно в саппорт провайдера — не жди.
• Отправил неправильную сумму. Обычно делается refund за вычетом on-chain комиссии за возвратную транзакцию. Статус ордера не обновится, потому что депозит не удовлетворил ордеру — разрешается через саппорт с txid.

SwapZilla — некастодиальный агрегатор: средства идут между твоим кошельком и адресами депозита/выплаты провайдера. Мы не кастодим, поэтому не можем в одностороннем порядке «отпустить» — восстановление всегда идёт через провайдера, который выдал оригинальный адрес депозита. Эта механика разобрана простым языком в FAQ.

Как не словить TIME_EXPIRED в следующий раз

Чек-лист на 30 секунд, который превращает большинство «зависших» ордеров в нормальные свапы.

• Указывай refund-адрес каждый раз. Однопольная привычка, которая превращает паничный тикет в саппорт в автоматический on-chain bounce-back. Самый высокий ROI среди всех привычек на любом агрегаторе.
• На медленных исходных сетях бери floating. BTC mainnet, XMR, ETH в перегрузе — floating-окно мягче fix-лока. Не плати за лок, который статистически истекает до первого подтверждения.
• Плати честную комиссию сети. Актуальный estimator (mempool.space для BTC, gas-tracker для ETH) и склон к «fast» тарифу когда часы ордера тикают. Экономия на комиссии редко стоит цены истёкшего ордера.
• Перепроверь сеть до нажатия send. USDT TRC-20 vs ERC-20 vs Solana — самая частая ошибка категории «не та сеть». Network badge в виджете показывает, какую сеть ожидает ордер — сравни с тем, что показывает send-экран кошелька.
• На fixed-rate отправляй ровно ту сумму. Floating терпит маленький over/under в рамках лимитов провайдера, fixed обычно нет.
• Для пятизначных сумм по возможности используй быструю исходную сеть. Lightning, Solana, USDT-TRC20 settle’ятся за секунды и обходят почти все категории таймаута. Если BTC mainnet — единственный вариант, заложи timeout-риск в план.

В виджете свапа на каждой котировке до подтверждения видны сеть и тип курса — именно эти два поля ловят большинство ошибок, ведущих к таймауту.

Главная привычка с самым высоким ROI на любом свап-агрегаторе: указывай refund-адрес каждый раз. Это превращает истёкший ордер из тикета в саппорт в автоматический on-chain bounce-back.

Что делать прямо сейчас если ордер показывает TIME_EXPIRED

Пятишаговая последовательность, которую можно пройти за две минуты.

Шаг A — Определи, отправлял ли ты вообще. Открой кошелёк, из которого собирался слать. Если исходящей транзакции по этому ордеру нет — стоп: ничего не потеряно, открывай новый свап.

Шаг B — Если отправлял, скопируй txid и проверь его на блок-эксплорере. Confirmed / pending / dropped. Это первый кусок информации, который запросит любой саппорт-флоу.

Шаг C — Проверь refund-адрес на странице ордера. Если он был указан и транзакция подтвердилась поздно на правильной сети — жди авто-refund в течение 1–60 минут (зависит от провайдера). Refund будет on-chain, виден в блок-эксплорере.

Шаг D — Если refund-адрес не был указан — один тикет в саппорт с полным набором данных. Order ID, txid депозита, исходная сумма, исходная и целевая монеты, и адрес на исходной сети, который ты контролируешь. Не открывай несколько тикетов — один аккуратный восстанавливается быстрее пяти панических. Стандартный флоу обращения — в FAQ.

Шаг E — Не отправляй депозит повторно на тот же адрес. Ордер терминальный с момента TIME_EXPIRED. Второй депозит ляжет на адрес без активного ордера за ним — это усложнит восстановление, а не упростит.

Edge cases и частые заблуждения

Несколько мифов, которые всплывают в саппорт-тикетах каждую неделю.

• «Прошёл час, можно отменить?» TIME_EXPIRED и есть отмена. Отдельной кнопки cancel нет — ордер уже терминальный. Делать ничего не нужно, чтобы его остановить.
• «Меня спишут за истёкший ордер?» Нет. На некастодиальном агрегаторе нет баланса, который можно списать. Если ты отправил поздний депозит — заплатишь маленькую on-chain комиссию за возвратную транзакцию refund’а. Это блокчейн-экономика, а не комиссия платформы.
• «Депозит подтвердился, но ордер всё ещё TIME_EXPIRED.» Транзакция подтвердилась после окна депозита. Провайдер обычно делает авто-refund на refund-адрес, который ты указал. Если не указывал — см. Шаг D выше.
• «Можно ли продлить окно депозита?» В общем случае нет на флоу агрегатора. Окно задаёт провайдер и его нельзя расширить со стороны клиента. Если знаешь заранее, что депозит уйдёт поздно — не отправляй, дай ордеру истечь idle и сделай свежую котировку.
• «Отправил на неправильную сеть и ордер истёк.» Структурно самый сложный случай. У принимающего провайдера нет записи о депозите. Восстановление зависит от того, декодируется ли адрес неправильной сети у них и держат ли они кошелёк на той сети. Срочно в саппорт — не жди и больше ничего не отправляй.
• «Может ли TIME_EXPIRED авто-восстановиться в DONE?» Нет. Это терминальный статус неудачи. Любой пост-expiry депозит становится refund-флоу, а не свапом.