Крипта застряла на мосту: pending, failed и ожидание ликвидности

Почему мост — не обычный перевод

Обычный перевод в одной сети: один TXID, Status, From / To. Мост делает два шага в двух реестрах. На исходной стороне токены блокируют или сжигают; на целевой выпускают wrapped-актив, разблокируют резерв или ждут, пока пул ликвидности выдаст вам токен. Пока вторая сторона не завершена, кошелёк на целевой сети может показывать «пусто», хотя в исходной списание уже Success.

Разные конструкции ведут себя по-разному. Нативные мосты L2 (например, вывод с Arbitrum на Ethereum) часто требуют ручного клейма на родительской сети после окна оспаривания — дни, не минуты; в интерфейсе это выглядит как «ещё не пришло». Liquidity-мосты зависят от наличия токена в пуле на той стороне. Сообщенческие протоколы добавляют релейер: сообщение ушло, исполнение ещё нет. Путать их — лечить не ту поломку.

Что такое TXID и где его взять — в что такое TXID и TxHash. Как читать Status и token transfers — в как читать блокчейн-эксплорер. Для USDT отдельно сверяйте сеть и канонический контракт: отследить USDT.

Pending, failed и ожидание ликвидности

Failed в исходной сети — не «застряло на мосту»: попытка не исполнена. Pending — ещё не факт лок. Самый частый пользовательский тупик: Success на L2/L1-источнике и ожидание клейма или семидневного окна на Ethereum. Второй: на целевой сети нет нативного газа (ETH, MATIC и т.п.), поэтому клейм из интерфейса не отправляется. Третий: liquidity-мост ждёт пул, а не «ошибку контракта».

Взлом моста — другой класс. Если резерв протокола уведён, ваш лок в исходной сети не означает, что на целевой кто-то вам выплатит. Тогда статус в официальном интерфейсе и сообщениях протокола важнее кнопки «повторить перевод». Повторная отправка тех же параметров может создать второй лок. Не обещайте себе, что «в большинстве случаев ничего не потеряно»: зависит от конструкции и инцидента.

Чеклист: что проверить в эксплорерах

1. Возьмите TXID исходной отправки из кошелька или истории моста; запишите сеть-источник и сеть-назначение.
2. Откройте эксплорер исходной сети (Etherscan, Arbiscan, Polygonscan и т.д.): Status, From / To (часто контракт моста), token transfers.
3. Если Status = Success, найдите в официальном UI моста статус сообщения / клейма — не в первом рекламном «бридже».
4. Откройте эксплорер целевой сети по тому же адресу получателя: входящие token transfers после времени исходного блока.
5. Проверьте, есть ли на целевой сети нативный газ для клейма; без него кнопка Claim не исполнит транзакцию.
6. Сохраните два URL, оба хеша (если целевая нога уже есть), время и скрины — одним пакетом.

Типичные ловушки. Вставили хеш исходной сети в чужой эксплорер — «транзакции нет». Смотрите только Value в ETH, тогда как ушёл USDT. Считаете Success на источнике зачислением на MetaMask в другой сети. Путаете канонический токен и копию с тем же тикером. Как не смешивать сети — ещё раз в чтении эксплорера.

Официальная документация мостов (например, вывод Arbitrum) прямо пишет: после окна оспаривания клейм на родительской сети часто ручной. «Застряло» в этом сценарии может значить «ещё нельзя забрать» или «можно, но вы не нажали Claim». Это проверяется в UI моста и эксплорере, а не в чате «ускорителей».

Где самостоятельный разбор заканчивается

• Остановите DIY, если обе ноги найдены, Status понятен, токен на целевом адресе — смените сеть в кошельке и покажите скрытый актив.
• Остановите, если UI моста показывает ожидание окна / клейма и это совпадает с документацией протокола: дождитесь шага, не дублируйте перевод.
• Остановите и не «ускоряйте» контракт, если статус нестандартный, релейер молчит часами без официального инцидента, или мост объявил эксплойт.
• Не отдавайте seed сервисам «достанем с бриджа» и не подписывайте чужие permit / approve «для клейма».

Имеет смысл передать разбор, когда нужны атрибуция контракта (официальный мост или фишинг-клон), связка нескольких TXID после частичного исполнения или пакет для протокола / юристов. Тогда контур — блокчейн-аналитика: карта, где лежит лок, а не обещание выпустить токен на целевой сети. Сопровождение кейса после оценки — на success-fee.

Самостоятельная проверка двух эксплореров закрывает большинство «кошелёк не обновился» и «я не нажал Claim». Она не лечит дыру в мосте и не заставляет пул выдать ликвидность. Чем точнее снимок статуса, тем меньше шансов сделать второй вредоносный перевод «на всякий случай».