CONFIRMING — самый долгий по времени жизни статус во всём жизненном цикле ордера, и так задумано: депозит в BTC может провисеть там 10–60 минут и при этом быть абсолютно здоровым, потому что статус измеряет не «что-то сломалось», а «сеть уже доделала свою работу или нет». Большинство тикетов в саппорт, открытых во время CONFIRMING, закрываются сами собой, как только человек понимает: этот статус, в отличие от TIME_EXPIRED, вообще не умеет падать сам по себе — он может только двигаться вперёд или быть перекрыт закрытием окна депозита.
Что «Confirming» на самом деле значит в жизненном цикле ордера
Каждый ордер на свап проходит фиксированную последовательность статусов: NEW → WAIT_DEPOSIT → CONFIRMING → EXCHANGING → SENDING → DONE. CONFIRMING стоит ровно посередине — и это первый статус, на котором твои деньги реально покинули кошелёк и попали в блокчейн.
До него WAIT_DEPOSIT значит, что ордер создан, но ничего ещё не пришло — либо ты не отправил, либо транзакция не разошлась по сети. После него EXCHANGING значит, что провайдер принял твой депозит как финальный и исполняет свап на своей стороне, а SENDING — что монета на выходе уже летит на твой адрес.
CONFIRMING принципиально отличается от терминальных статусов неудачи — TIME_EXPIRED, FAILED и REFUNDED. Это выходы из жизненного цикла: ордер останавливается, и что-то (обычно refund) должно произойти. CONFIRMING — не выход. Это ожидание.
«Confirming» — это не статус неудачи, это статус ожидания.
Сколько обычно занимает «Confirming» по сетям
Время подтверждения зависит от двух вещей: block time исходной сети и от того, сколько подтверждений требует провайдер, прежде чем считать депозит финальным. Второе число варьируется от провайдера к провайдеру и от размера депозита, так что таблица ниже — это реальные диапазоны, а не гарантия.
| Сеть | Типичный block time | Реальное окно «Confirming» |
|---|---|---|
| Bitcoin (BTC) | ~10 мин/блок | 10–60 минут |
| Ethereum (ETH) | ~12 сек/блок | Меньше 5 минут |
| Monero (XMR) | ~2 мин/блок | 10–20 минут |
| USDT (ERC-20) | ~12 сек/блок | Меньше 5 минут |
| USDT (TRC-20) | ~3 сек/блок | Меньше 2 минут |
| Solana (SOL) | Меньше секунды | Почти мгновенно |
| Tron (TRX) | ~3 сек/блок | Почти мгновенно |
Точный порог подтверждений — 1 блок, 2 или 10 — задаёт провайдер, через которого идёт твой ордер, и он может гулять в зависимости от размера депозита. Депозиту в $50 в BTC и депозиту в $50 000 в BTC не обязательно нужно одинаковое число подтверждений. Не воспринимай диапазоны выше как контракт — воспринимай их как «если ты внутри этого окна, пока всё в порядке».
Почему это занимает дольше, чем ты ожидал по block time
Если блоки ETH приходят каждые 12 секунд, почему Confirming иногда занимает несколько минут, а не ровно 12 секунд? Потому что одно подтверждение почти никогда не значит один блок.
Провайдеры требуют несколько подтверждений, чтобы защититься от реорганизации сети — редкого случая, когда блок задним числом заменяется другим, из-за чего твой депозит как бы «отменяется». Чем выше риск реорганизации у конкретной сети, тем больше подтверждений запросит осторожный провайдер. Плюс к этому твою транзакцию сначала должен подобрать майнер или валидатор, а в загруженной сети с низкой комиссией само это подбирание может занять дольше, чем подсказывает голый block time.
Блокчейну всё равно, что ты нетерпелив. Провайдеру — тоже.
Именно поэтому BTC доминирует в тикетах саппорта именно про Confirming — его 10-минутный block time значит, что даже 2 подтверждения это 20 минут в лучшем случае, а перегрузка mempool регулярно растягивает это до 40–60 минут для тех, кто поставил комиссию по нижней границе.
Когда «Confirming» ещё не проблема
Ты внутри нормального диапазона, если:
- депозит уже подтверждён по счётчику блок-эксплорера (даже если ордер всё ещё показывает
Confirming— провайдеры часто ждут больше подтверждений, чем показывает дефолтный вид эксплорера) - ты внутри реального окна для этой сети из таблицы выше
- на странице ордера ещё есть активное время в окне депозита
- нет признаков неправильной сети (см. ниже)
Ничего из этого не требует действий. Большинство ордеров на Confirming сами переходят в Exchanging, и открытие тикета на этом этапе ничего не ускоряет — саппорт не может протолкнуть блок через сеть быстрее, чем это делает сама сеть.
Когда действительно пора беспокоиться
Есть сигналы, на которые стоит реагировать:
- окно депозита ордера почти закрылось, а транзакция всё ещё показывает ноль или частичное число подтверждений на эксплорере
- эксплорер вообще ничего не показывает на твою отправленную сумму — обычно это значит не ту сеть, а не медленное подтверждение
- ты сильно вышел за реальное окно для этой сети (например ETH-депозит всё ещё не подтверждён спустя 30+ минут без видимой перегрузки mempool)
Если окно депозита закроется раньше, чем завершатся подтверждения, ордер переходит в TIME_EXPIRED, а не остаётся в Confirming бесконечно — это отдельный режим сбоя со своим путём восстановления, разобранный в гайде про TIME_EXPIRED. Указать refund-адрес перед депозитом — вот что делает это восстановление автоматическим, а не ручным тикетом в саппорт.
Что проверить самому перед тикетом в саппорт
Три проверки закрывают подавляющее большинство вопросов «мой свап завис на Confirming» ещё до того, как тикет вообще нужен:
- Найди txid. История транзакций в кошельке показывает исходящий перевод — скопируй хэш.
- Вставь его в блок-эксплорер конкретной сети. Проверь, что транзакция существует, сколько у неё подтверждений, и та ли это вообще сеть (адрес Tron не найдётся в эксплорере Ethereum, например).
- Сравни число подтверждений с реальным окном из таблицы выше. Если ты внутри окна — всё нормально. Если ты близко к границе окна депозита, а подтверждения отстают — вот тогда стоит открыть тикет, с готовыми order ID и txid, чтобы саппорту не пришлось их запрашивать.
Что дальше: Confirming → Exchanging → Sending, или Confirming → TIME_EXPIRED
Из Confirming ведут два пути. В подавляющем большинстве ордеров депозит набирает нужные подтверждения, ордер переключается на Exchanging, провайдер исполняет свап на своей стороне, а следом идёт Sending — выплата приходит в кошелёк, и ордер закрывается как DONE.
Второй путь открывается только если окно депозита закрывается раньше, чем завершаются подтверждения — медленная сеть, слишком низкая комиссия или реально перегруженная сеть. Это даёт TIME_EXPIRED, терминальный статус со своим процессом восстановления, а не продолжение Confirming. Прочитать гайд про типы rate перед свапом — самый простой способ вообще не попасть на этот путь: floating-rate даёт медленным сетям больше времени, чем тугой fixed-лок.
Если ничего из этого не совпадает с тем, что видишь ты, остальную часть жизненного цикла ордера разбирают страницы FAQ и как это работает.