Успешная транзакция на L1 сама по себе не доказывает завершение депозита Arbitrum на L2. Сначала установите, было ли это только разрешение на токен, настоящий вызов моста или другое действие. Затем проследите результат целевой стороны в правильной сети. Для маршрута с retryable создание билета и его успешное исполнение — самостоятельные этапы проверки.
Определите маршрут до поиска повторной кнопки
Здесь рассматривается канонический переход от родительской цепочки к дочерней, например Ethereum → Arbitrum One. У стороннего моста ликвидности, вывода биржи и другой цепочки Arbitrum процесс может отличаться. Сохраните приложение, исходную и целевую сети, получателя и актив. Слова Arbitrum недостаточно для различия One, Nova и тестовой среды. Каждая из них имеет собственную запись состояния.
Возьмите первоначальный хеш L1 из истории отправки. Если это лишь разрешение расходовать токен, найдите последующую транзакцию депозита. Разрешение не означает доставку. Обычный успешный перевод на контракт также нельзя автоматически считать нужным вызовом моста. Важно фактическое действие: что подписывалось, какой метод исполнялся и какой результат должен был появиться дальше.
В инструкции моста Arbitrum разделены исходная и целевая сети, а также разные формы активов, включая USDC. Сверьте ожидаемый целевой токен вместо поиска только по тикеру. Правильное поступление может не отображаться из-за другого сетевого режима или другой строки актива. Эти варианты требуют настройки просмотра, а не второй исходной отправки.
Запишите этапы с учётом вида перевода
| Наблюдаемый этап | Что сохранить | Следующий вопрос |
|---|---|---|
| Разрешение токена на L1 успешно | Хеш approval и токен | Был ли отдельный депозит |
| Депозит L1 исполнен | Вызов моста и созданное сообщение | Какое действие инициировано на цели |
| Создан retryable, если применим | Идентификатор и текущее состояние | Успешно ли выполнено исполнение |
| Целевая попытка неуспешна | Точную ошибку | Доступно ли поддерживаемое продолжение |
| Целевое действие завершено | Получателя и точный актив | Правильны ли сеть и отображение кошелька |
| Экран отличается от сети | Аккаунт и выбранную цепочку | Не является ли проблема представлением |
| Получатель контролируется сервисом | Инструкции его депозита | Выполнена ли внутренняя привязка |
В документации parent-to-child messaging простой депозит нативной монеты отделён от токеновых сообщений через retryable. Нельзя применять одну процедуру повторного исполнения билета ко всем депозитам ETH. Сначала определите механизм, затем ожидаемый тип записи и инструмент. Отсутствие ненужного данному маршруту объекта не означает неисправность.
Для retryable проверяйте исполнение отдельно
В подходящем процессе публикация и целевое действие выполняются асинхронно. Билет способен создаться, хотя автоматическая попытка исполнения отказала. Тогда проверяют его текущее состояние и допустимость дальнейшего исполнения. Успех создающей транзакции не заменяет результата назначения. Сохраните обе записи, чтобы поддержка не приняла проблему исполнения за неудачное создание.
Документация описывает ограниченное время жизни и продление подходящего действующего билета. Сверьте фактическое истечение и доступное действие своевременно вместо бессрочного ожидания. Там же есть порядок возврата нативного call value. Его нельзя расширять до обещания, что любой объём ERC-20 автоматически вернётся первоначальному отправителю L1. Разные составляющие стоимости и актива требуют собственного разбора.
В FAQ Arbitrum указаны история моста и официальный инструмент retryable. Открывайте их из независимо проверенной документации. Для поиска нужен идентификатор инициирующей операции. Продолжение существующего билета отличается от новой исходной отправки: вторая способна создать дополнительный перевод. Само слово «повторить» на экране ещё не объясняет, какое действие предлагается подписать.
Проверьте получающий аккаунт и сеть
Прочитайте реальное назначение и итоговое движение актива. Для обычных внешних аккаунтов привычное соответствие адреса может работать, но контрактные и делегированные варианты требуют внимания к aliasing. Такие случаи описаны в документации сообщений. Не заменяйте получателя вручную и не применяйте угаданное преобразование адреса ради похожего результата в обозревателе. Сначала уточните смысл действительного назначения.
При успешном целевом исполнении проверьте выбранную L2, аккаунт и идентичность токена. Отсутствие фиатной оценки или строки актива само по себе не опровергает запись сети. Если адрес принадлежит платформе, её приём конкретного токена и внутреннее зачисление рассматриваются отдельно. Передайте получателю конкретный результат, а не требуйте объяснить только пустой общий экран кошелька.
Направление депозита также отличается от вывода. Период проверки для child-to-parent операции не является универсальным ожиданием parent-to-child поступления. Совет всем подождать обратный срок способен оставить доступный для действия retryable без внимания. Определите реальное состояние вместо заимствования времени у другого маршрута. Дата наблюдения и текущее состояние полезнее общего обещания зачисления.
Сравните три учебных исхода
В случае «Ясень» на L1 подтверждено только allowance-разрешение. Настоящий депозит ещё не установлен, поэтому искать пропавшую доставку рано. В случае «Берёза» депозит создал retryable, но целевое исполнение отказало: нужен статус билета. В случае «Кедр» всё завершилось, однако кошелёк смотрит Nova вместо нужной One. Одно пользовательское описание здесь скрывает три разные причины.
Это вымышленные варианты, не сообщения об инцидентах. Следующие действия у них различаются, хотя каждый человек может сказать «на L1 успешно, на L2 ничего». Ещё одна исходная отправка плохо различает такие причины. Сохраните собранные свидетельства, чтобы ответ поддержки не начинал разбор с неправильного этапа. Особенно важно не потерять первоначальный хеш после создания новой попытки.
Продолжайте только проверенный процесс
- Сохраните исходный хеш L1, сети, приложение, токен и ожидаемый адрес.
- Классифицируйте действие L1, отделив разрешение от вызова моста.
- В официальной истории найдите связанное сообщение либо депозит.
- Если применяется retryable, проверьте состояние, срок и ошибку целевого исполнения.
- Используйте документированное продолжение данной записи; непонятные расходы уточните у настоящей поддержки.
- При завершённом исполнении отдельно исследуйте отображение либо учёт принимающей платформы.
Раздел устранения проблем моста содержит продуктовый путь проверки. Предметное обращение называет последний подтверждённый этап и сетевые ссылки. Оно не утверждает одинаковую причину всех отказов автоисполнения или доступность любого восстановления. Слова восстановления кошелька для такого разбора не нужны.
Читать целевые записи поможет руководство обозревателей L2, стоимость рассматривается отдельно в материале о комиссиях Arbitrum. Для обмена без регистрации используйте инструкции заказа: он не обязан повторять этот канонический маршрут. Разберите согласованный перевод до новой подписи.
Частые вопросы
Что проверить в обозревателе моста Arbitrum после успеха L1?
Найдите целевую запись, связанную с первоначальной операцией. Сначала убедитесь, что исходная транзакция была депозитом, а не только разрешением токена.
Что смотреть у Arbitrum retryable ticket?
Проверьте текущее состояние, срок действия и результат целевого исполнения. Одного факта создания билета недостаточно для подтверждения доставки.
Любой депозит ETH нужно повторно исполнять через retryable?
Нет, документация разделяет простой нативный депозит и другие процессы сообщений. Установите механизм конкретной отправки до применения процедуры билета.