Вывод из L2 может начинаться с адреса, который визуально ничем не отличается от адреса в другой EVM-сети. Но активы и сообщения учитываются отдельно в каждой цепочке. Ошибка на шаге выбора целевой сети или адреса получателя может привести к тому, что пользователь отправит активы не туда, куда рассчитывал, или создаст сообщение, которое сложно завершить ожидаемым способом.
Эта инструкция посвящена проверке получателя непосредственно перед подписью. Она не повторяет весь процесс вывода и не заменяет документацию конкретного моста. Общую последовательность канонического вывода описывает материал о переводе активов из L2 в Ethereum, а завершение этапов optimistic rollup разобрано отдельно в статье о доказательстве и завершении вывода.
Подтвердите исходную и целевую сеть
Сначала запишите названия и Chain ID обеих сетей. Проверьте, что кошелёк подключён к той L2, где находится актив, а маршрут указывает правильную целевую сеть. Не ориентируйтесь только на символ сети, цвет значка или название токена. Похожие названия и одинаковые форматы адресов встречаются у разных цепочек, а баланс одного адреса в одной сети не переносится автоматически в другую.
Откройте официальную страницу моста из документации rollup или приложения, которым доверяете. Проверьте домен и перечень поддерживаемых направлений. Если вы используете сторонний агрегатор, посмотрите, какой именно мост и какие контракты он выбрал. Проверьте целевой адрес и на экране кошелька, а не только в верхней части сайта. О том, почему адрес и сеть важнее тикера, рассказывает разбор одного адреса в нескольких EVM-сетях.
Проверьте адрес получателя и способ его передачи
Скопируйте адрес назначения из надёжного источника и сравните начало и конец строки после вставки. В некоторых интерфейсах адрес может подставляться автоматически из подключённого кошелька; это не доказывает, что он совпадает с адресом, который вы хотели использовать. Проверьте, не остался ли в поле старый адрес, контрактный кошелёк или адрес другого профиля.
Способ задания получателя зависит от конкретного bridge и версии его контракта. Один интерфейс передаёт отдельный параметр назначения, другой направляет средства на адрес отправителя, а третьи используют сообщение с дополнительной логикой. Не предполагайте, что любой канонический мост поддерживает произвольный адрес назначения. Откройте детали операции и документацию именно выбранного маршрута. Если интерфейс обещает альтернативного получателя, но данные транзакции не позволяют понять, куда пойдёт вывод, остановитесь.
Сверьте транзакцию в кошельке
До подписи проверьте контракт получателя вызова, сумму, токен, chain ID и данные вызова. Для одних транзакций кошелёк может расшифровать параметры, для других показать calldata или название функции. Сверьте его с описанием маршрута и сообщением моста. Если используется смарт-кошелёк, проверьте не только транзакцию-обёртку, но и внутренние действия, которые она собирается выполнить.
Не путайте адрес контракта моста в поле `to` с адресом получателя активов. Вызов часто отправляется именно контракту, который фиксирует вывод, а адрес назначения передаётся внутри данных. Проверка одного поля `to` поэтому недостаточна. Если decoded-параметры скрыты, ищите их в симуляции, обозревателе или официальных инструментах, но не считайте симуляцию безошибочной. Для другого подхода к чтению транзакции можно использовать инструкцию по проверке симуляции.
Учитывайте тип адреса в целевой сети
Обычный внешний EVM-адрес технически может быть получателем во многих совместимых сетях, но пользователь должен иметь доступ к соответствующему аккаунту и понимать, как подключиться именно к целевой цепочке. Если получатель – контракт, убедитесь, что он развёрнут и умеет принимать такой актив или сообщение. Контракт, работающий в исходной L2, не обязательно существует по тому же адресу в Ethereum.
Для биржевого или кастодиального аккаунта проверяйте дополнительные требования площадки: может требоваться memo, tag, конкретная сеть или предварительное включение депозита. Нельзя подставлять адрес из другой сети лишь потому, что его формат похож. До отправки полезно убедиться, что мост поддерживает нужный токен и выбранное направление, а адрес предназначен для личного кошелька или депозита именно в этой сети.
Если адрес задаётся в сообщении вывода
Некоторые rollup используют исходное сообщение, которое затем доказывают или финализируют в L1. Перед подписью сохраните исходный TxID и параметры вывода, особенно если адрес назначения не равен адресу отправителя. Позже при завершении операции проверьте, что доказывается именно ожидаемое сообщение и что финальное действие обращается к тому адресу, который был указан в исходной транзакции.
Если интерфейс предлагает несколько действий – инициировать, доказать, завершить – убедитесь, что вы находитесь на правильном этапе. Целевой адрес не обязательно можно изменить после отправки первой транзакции. Поэтому исправление ошибки может потребовать отдельной процедуры поддержки или вовсе оказаться невозможным. Конкретные сроки и способы восстановления зависят от сети; не отправляйте повторный перевод, пока не проверили статус исходного.
Короткий чек-лист перед подписью
Сверьте исходную сеть и Chain ID; подтвердите целевую сеть по документации моста; проверьте адрес получателя после вставки; выясните, как именно bridge передаёт адрес; сопоставьте сумму и токен; проверьте контракт вызова и внутренние параметры транзакции. Если вывод направляется на контракт или биржу, отдельно проверьте поддержку такого получателя и требования к депозиту.
Одинаковый адрес в двух EVM-сетях – удобство формата, а не гарантия одинакового аккаунта или баланса. Безопасность preflight-проверки заключается в том, чтобы подтвердить весь маршрут от исходной L2 до адреса в целевой сети. Если интерфейс не показывает получателя, маршрут выглядит неожиданно или детали кошелька расходятся с экраном bridge, не подписывайте операцию, пока причина не станет понятна.
