Мосты в сеть Arbitrum делятся на два разных по устройству класса. Официальный шлюз — это пара контрактов самой сети: он запирает токен на родительской цепочке и выпускает его в дочерней, а обратный путь проходит через окно оспаривания длиной не менее семи дней. Сторонний сервис денег через протокол не проводит: он выдаёт вам актив из своего запаса на стороне получателя. Отличаются они не скоростью, а тем, чем подкреплён результат и кто отвечает за сбой.

Официальный шлюз Arbitrum — это связка контрактов родительской и дочерней цепочки, которая переносит активы по правилам самого протокола, тогда как сторонний мост — это приложение поверх сети, выдающее актив из собственного запаса под обещание рассчитаться позже.

Почему мосты в сеть Arbitrum существуют в двух видах: механика без упрощений

Протокол умеет одно: передавать сообщения между цепочками по своим правилам и в свои сроки. Эти сроки заданы конструкцией. Загрузка сети тут вторична. Пользователю хочется быстрее, и на этом спросе выросли сторонние сервисы.

Документация Arbitrum, прочитанная 16 октября 2026 года, описывает официальный путь через пары контрактов-шлюзов: по одному на каждой стороне. Маршрутизацией занимаются два контракта, L1GatewayRouter и L2GatewayRouter, которые документация называет оракулом соответствия адресов между родительской и дочерней цепочками. Для токенов, у которых нет собственного шлюза, работает StandardERC20Gateway — он открыт для любого токена без предварительной регистрации.

Сторонний мост устроен иначе. Перенос ему не нужен. На обеих сторонах у него лежит запас ликвидности, и ваш токен он не переносит, а обменивает: забирает на входе и отдаёт равный объём из запаса на выходе. Расчёт между своими запасами сервис проводит потом и по своему усмотрению.

Отсюда главный вывод, который теряется в спорах о скорости. Официальный шлюз опирается на гарантии протокола, сторонний — на платёжеспособность и исправность конкретного приложения.

Сама документация формулирует это сдержанно и точно: пользователям следует относиться к неканоническим мостам так же, как к любому приложению, работающему в Arbitrum, и проявлять осторожность и должную осмотрительность, прежде чем доверять им свои средства.

Официальный шлюз: что происходит с токеном шаг за шагом

Ввод и вывод через канонический путь устроены несимметрично. Это важнее любых цифр.

При вводе пользователь обращается к маршрутизатору, тот передаёт вызов шлюзу родительской цепочки, и шлюз, по формулировке документации, депонирует присланные токены и создаёт retryable-тикет. На дочерней стороне шлюз в методе finalizeInboundTransfer выпускает соответствующий объём токенов. Срок прибытия средств документация оценивает примерно в 15–30 минут в зависимости от загрузки сети.

Вывод идёт обратным порядком: вызов маршрутизатора дочерней цепочки, сжигание выпущенного токена, сообщение через системный контракт ArbSys, а после истечения окна оспаривания — исполнение через Outbox, которое освобождает депонированный токен. По документации Arbitrum One и Nova срок составляет не менее семи дней, в интерфейсе отсчёт показывают как 7–8 дней, и на финальном шаге средства нужно забрать кнопкой вручную.

Параметры официального шлюза по документации Arbitrum на 16 октября 2026 года. Ввод: средства на дочерней цепочке — ориентировочно через 15–30 минут. Вывод из Arbitrum One и Nova: не менее семи дней, в интерфейсе отсчёт 7–8 дней, затем ручное подтверждение получения. Срок жизни retryable-тикета по умолчанию — семь дней, и в этот период выкупить его может кто угодно. Числа взяты из документации; фактическая длительность зависит от загрузки цепочек.

Сторонний сервис: та же задача, другая гарантия

Скорость у ликвидного моста объяснима. Актив на выходе выдаётся до того, как расчёт между сторонами завершён, — риск этого разрыва несёт сервис, а не протокол.

Из этого вытекают три практических различия. Первое: объём ограничен запасом в пуле, и крупная сумма проходит хуже мелкой. Второе: вы получаете то представление токена, которое сервис держит на складе, а оно не обязано совпадать с каноническим. Третье: при остановке сервиса средства зависают в его контуре, и обращаться придётся к нему, а не к сети.

Иллюстрация к второму пункту есть в самой документации: Arbitrum One поддерживает две различные формы USDC — нативную и перенесённую мостом. Документация предупреждает, что перед вводом стоит разобраться, какую из форм вы получите.

Совпадение символа токена не означает совпадения контракта. В обращениях читателей повторяется один сюжет: актив пришёл, но приложение в сети его не принимает, потому что держит в белом списке другой адрес. Разбираться проще до перевода, а не после.

Как понять, что именно случилось при сбое

Диагностика у двух маршрутов разная. Объясняют это редко.

У официального пути есть промежуточное состояние. Если исполнение на дочерней стороне не удалось, сообщение превращается в retryable-тикет, который, по документации, можно выкупить в течение срока жизни — по умолчанию семь дней. То есть операция не исчезает: она ждёт повторного исполнения, и инициировать его вправе любой.

У стороннего сервиса такого состояния нет. Есть транзакция у вас, есть внутренняя очередь у него, и видимость заканчивается на границе приложения. Проверять приходится по адресам контрактов и событиям в публичном обозревателе Arbiscan, сопоставляя, кто и с какими аргументами вызывал контракт. Навык разобран отдельно: как понять, кто вызывал контракт и с какими параметрами.

Застрявшая исходная транзакция — отдельная история, не связанная с выбором моста. Пока она в мемпуле, применима обычная замена по nonce; порядок описан в разборе про то, как ускорить зависшую транзакцию в Ethereum через повышение комиссии.

Пошаговый выбор маршрута

  1. Определите направление. Ввод и вывод через официальный шлюз различаются по сроку на порядок, и планировать их нужно по-разному.
  2. Уточните, какая форма токена вам нужна на стороне Arbitrum: каноническая или та, что держит конкретный сервис.
  3. Сверьте адрес контракта с документацией эмитента и со списком приложения, в котором собираетесь этот токен использовать.
  4. Оцените сумму относительно запаса ликвидности выбранного сервиса, если идёте не через официальный путь.
  5. Проведите пробную операцию и дождитесь появления актива на стороне получателя.
  6. Сохраните хэши обеих сторон и, для вывода, отметьте дату, когда истекает окно и потребуется ручное подтверждение.
Схема из пяти шагов: обращение к маршрутизатору, депонирование токена шлюзом родительской цепочки, создание retryable-тикета, выпуск токена в Arbitrum, повторное исполнение тикета при сбое
Схема из пяти шагов: обращение к маршрутизатору, депонирование токена шлюзом родительской цепочки, создание retryable-тикета, выпуск токена в Arbitrum, повторное исполнение тикета при сбое

Сколько это стоит

Денежная часть у обоих маршрутов складывается из комиссий двух сетей и платы сервиса. Неденежная часть расходится сильнее. Официальный путь берёт плату временем на выводе и ручным шагом в конце, сторонний — доверием к приложению и привязкой к его запасу.

Признак Официальный шлюз Сторонний сервис
Чем подкреплён результат Контрактами протокола: токен депонирован шлюзом родительской цепочки Запасом ликвидности приложения на стороне получателя
Срок ввода Около 15–30 минут по документации, зависит от загрузки Минуты, пока в запасе есть свободный объём
Срок вывода Не менее семи дней, отсчёт в интерфейсе 7–8 дней, затем ручное подтверждение Минуты, но расчёт между сторонами остаётся на сервисе
Что происходит при сбое исполнения Сообщение становится retryable-тикетом, срок жизни по умолчанию семь дней, выкупить может любой Операция остаётся во внутренней очереди приложения, видимость обрывается на его границе
Какой токен приезжает Форма, выпущенная шлюзом сети Представление из запаса сервиса, не обязательно каноническое
К кому идти с проблемой К контрактам: состояние операции читается в обозревателе К оператору сервиса по его регламенту

Как не повторить

Ошибка редко в самом мосте. Она в несовпадении ожиданий со сроком и формой токена.

  • Планировать вывод заранее: окно оспаривания не ускоряется доплатой
  • Проверять, какую форму токена принимает приложение-получатель
  • Соотносить сумму с запасом ликвидности, если маршрут не канонический
  • Помнить про финальный ручной шаг при выводе через официальный путь
  • Не считать, что средства потеряны, пока не прочитано состояние операции в обозревателе

Сопоставление вариантов на соседней сети помогает откалибровать ожидания: в разборе про мосты в сеть Base и сравнение вариантов перевода эфира та же развилка показана на другом наборе контрактов. Контекст по родительской цепочке даёт материал о том, что меняет обновление Glamsterdam для сети Ethereum.

Итог

Официальный шлюз и сторонний сервис решают одну задачу с разным обеспечением. Первый опирается на контракты протокола и платит за это временем на выводе, второй отдаёт актив из запаса сразу и переносит риск на приложение. Промежуточное состояние в виде retryable-тикета есть только у канонического пути, и оно даёт шанс довести операцию до конца без участия оператора. Выбор между маршрутами — это выбор, чьё обещание вам понятнее, а не выбор скорости.

Частые вопросы

Почему вывод через официальный шлюз занимает неделю, а ввод — минуты?

Направления устроены несимметрично. Ввод передаётся сообщением в дочернюю цепочку и исполняется там обычным порядком. Вывод требует, чтобы родительская цепочка признала результат, а на это отведено окно оспаривания: по документации Arbitrum One и Nova — не менее семи дней. Доплатой окно не сокращается.

Что такое retryable-тикет и зачем он мне?

Это механизм отложенного исполнения сообщения на стороне дочерней цепочки. Если исполнение сорвалось, сообщение не пропадает, а становится тикетом, который по документации можно выкупить в течение срока жизни — по умолчанию семь дней. Сделать это вправе любой, не обязательно отправитель.

Сторонний мост быстрее. В чём подвох?

Подвоха нет, есть другая модель. Сервис выдаёт актив из собственного запаса, не дожидаясь расчёта между сторонами, и риск разрыва несёт сам. Отсюда зависимость от размера запаса, вероятность получить неканоническую форму токена и закрытая для внешнего наблюдения очередь операций при сбое.

Почему на Arbitrum бывает два разных USDC?

Документация прямо описывает две формы: нативную и перенесённую мостом. Адреса контрактов у них разные, и приложения принимают не обе. Перед вводом стоит посмотреть, какая форма нужна получателю, иначе придётся делать дополнительный обмен внутри сети.

Как проверить состояние операции самому?

По хэшу исходной транзакции в обозревателе родительской цепочки и по адресу получателя в обозревателе Arbitrum. Смотрят события шлюза: депонирование на входе, выпуск на выходе. Если выпуска нет, проверяют, не ждёт ли сообщение повторного исполнения в виде тикета.

Вердикт

Спор об официальном шлюзе и сторонних сервисах чаще всего ведут не о том. Скорость здесь вторична, первично — чем подкреплён актив на стороне получателя и у кого спрашивать при сбое. Канонический путь честно показывает своё промежуточное состояние и даёт его исправить, ликвидный мост прячет расчёт внутри приложения. В редакционной практике разбор зависших переводов почти всегда упирается в то, что этот выбор делали не глядя.

Разборы сетевой механики выходят в нашем Telegram-канале Cryptium.

Архитектура шлюзов описана в технической документации Arbitrum о переносе токенов. Сроки и параметры там обновляются вместе с протоколом.