Фишинговый сайт может скопировать дизайн официального моста и предложить транзакцию, которая выглядит привычно. Надёжная проверка начинается не с кнопки в интерфейсе, а с адреса контракта, выбранной сети и ожидаемого метода. Эти данные можно сверить до approve, депозита или вывода.
Каноническим обычно называют мост, который поддерживается самой L2 и связан с её системными контрактами. Он переводит ETH и токены между базовой сетью и rollup по правилам этой системы. Агрегатор или быстрый мост может быть полезен, но использует другую ликвидность и модель доверия. Название «официальный» в рекламе не делает маршрут каноническим.
Начните с документации самой сети
Введите адрес официального сайта сети вручную или откройте сохранённую закладку. Найдите в документации раздел Contracts, Deployments или Bridge. Для L2 должны быть указаны сеть, chain ID и адреса контрактов в Ethereum и в rollup. Не копируйте адрес из рекламы, комментария, сообщения поддержки или результатов поиска без дополнительной проверки.
Сверьте сведения как минимум по двум официальным путям: документация сети и ссылка из её основного приложения либо репозитория. Если значения расходятся, остановитесь. Причиной может быть обновление документации, миграция контракта или открытая тестовая сеть. Угадавать «более новый» адрес по дате страницы нельзя.
Проверьте окружение целиком. Один проект может использовать разные адреса в mainnet, testnet и нескольких L2. Совпадение первых и последних символов не компенсирует неверный chain ID. Кошелёк перед подписью должен показывать именно ту сеть, где расположен найденный контракт.
Разберите роль каждого контракта
Канонический мост редко состоит из одного адреса. В OP Stack пользователь может взаимодействовать с portal и стандартными bridge-контрактами, а сообщение проходит через связанные messenger и message passer. В другой архитектуре названия и разделение ролей будут иными. Адрес системного контракта нельзя подменять адресом интерфейса или токена.
Для депозита ERC-20 обычно участвуют контракт токена, разрешение на расходование и bridge, который блокирует либо учитывает актив. Для ETH approve не нужен. При выводе из L2 сначала создаётся сообщение, затем оно доказывается и окончательно исполняется в Ethereum. Этот путь подробнее разобран в инструкции по выводу из L2 через канонический мост.
Откройте найденный адрес в обозревателе нужной сети. Проверьте, что это контракт, а не обычный аккаунт, что исходный код верифицирован и что имя контракта соответствует роли в документации. Метка обозревателя удобна, но не является самостоятельным доказательством: её тоже следует сопоставить с официальным списком.
Проверьте proxy и реализацию
Многие bridge-контракты являются proxy. Пользователь отправляет транзакцию на постоянный proxy-адрес, а логика выполняется в отдельной implementation. Поэтому простой просмотр кода по адресу назначения может показать только механизм делегирования.
В обозревателе найдите признаки proxy и текущий implementation. Затем проверьте код реализации, admin или управляющий механизм и историю обновлений. Адрес proxy должен совпасть с документацией, а реализация – быть контрактом ожидаемого проекта. Пошаговая проверка этих связей описана в материале про proxy, admin и implementation.
Обновляемость не означает автоматическую проблему, но создаёт полномочие изменить логику. Выясните, кто контролирует upgrade, какой нужен порог подписей, действует ли timelock и существует ли emergency pause. Недавнее необъяснённое обновление перед переводом требует дополнительной проверки.
Сверьте транзакцию перед подписью
Когда официальный адрес установлен, сравните его с полем To в кошельке. Затем проверьте декодированный метод. Для депозита ожидается действие bridge или portal с параметрами токена, получателя, суммы и целевой сети. Неожиданные функции вроде передачи ownership, установки оператора или неограниченного approve постороннему адресу являются причиной отклонить запрос.
Approve и собственно депозит могут быть двумя транзакциями. В разрешении spender должен быть ожидаемым bridge-контрактом или документированным посредником маршрута. Сумму разрешения разумно ограничить планируемым переводом, особенно при первом использовании. После операции ненужный остаток allowance можно отозвать.
При переводе токена отдельно сверяйте его адрес в исходной и целевой сети. Одинаковый тикер может принадлежать поддельному активу. Канонический мост либо использует заранее зарегистрированную пару, либо создаёт представление по установленным правилам. Не добавляйте адрес токена только потому, что его показал неизвестный интерфейс.
Если кошелёк поддерживает симуляцию, изучите предполагаемые изменения баланса и события. Симуляция помогает заметить неожиданный перевод или разрешение, но выполняется относительно выбранного состояния и не доказывает честность сайта. Ограничения этого метода объясняет статья о том, почему симуляция не даёт гарантии.
Проведите малый тест и проверьте результат
Для первого маршрута отправьте небольшую сумму, которая всё же превышает возможные минимумы протокола. До подписи оцените gas в обеих сетях и поймите, понадобится ли отдельное действие prove или finalize. Не ориентируйтесь на фиксированный срок или комиссию из старой инструкции: загрузка сети и параметры rollup меняются.
После транзакции сохраните исходный хеш и найдите событие депозита либо withdrawal. Проверьте адрес получателя и статус межсетевого сообщения. Баланс интерфейса может обновиться позже, поэтому подтверждением служат записи обеих сетей. Если вывод остановился на промежуточном этапе, не создавайте второй вывод до выяснения статуса первого.
- Официальный домен открыт из документации или сохранённой закладки.
- Chain ID соответствует нужному mainnet, а не тестовой сети.
- Proxy-адрес совпадает с официальным списком контрактов.
- Implementation, admin и история upgrades не вызывают противоречий.
- Метод, spender, токен, сумма и получатель совпадают с планом.
- Малый тест завершён и подтверждён onchain в обеих сетях.
Общий чек-лист подготовки также есть в руководстве по безопасному переводу через мост. Его стоит проходить заново после смены сети, токена или интерфейса, даже если прежняя операция была успешной.
Адрес канонического моста надёжно подтверждается цепочкой совпадений: официальная документация, правильная сеть, роль контракта, proxy и реализация, ожидаемая транзакция и onchain-результат малого теста. Такая проверка занимает больше времени, чем сравнение логотипа, зато защищает от наиболее простой подмены маршрута.
