Короткий ответ: подтверждение исходной транзакции ещё не доказывает, что кроссчейн-действие завершилось. Нужно связать исходный вызов с конкретным сообщением, а затем найти соответствующее исполнение в целевой сети. Сверяйте сети, идентификатор сообщения, отправителя, получателя, актив и итоговый статус, а не только сумму и похожий TxID.
У каждой цепочки собственный реестр и собственные идентификаторы транзакций. Мост или протокол обмена наблюдает за событием в одной сети и организует действие в другой. Поэтому у маршрута обычно есть как минимум две транзакции, а иногда и отдельные стадии проверки, доставки или повторного исполнения. Общее объяснение этой разницы есть в статье о межсетевых сообщениях и token bridge.
Начните с исходной операции
Скопируйте TxID из кошелька или истории моста и откройте обозреватель именно исходной сети. Проверьте, что запись находится в подтверждённом блоке, а не только ожидает включения. Сверьте адрес отправителя, контракт назначения, входной актив и сумму. Если вызов выполнялся через агрегатор, отправителем контракта может быть не пользовательский адрес: в таком случае смотрите полный receipt и события, а не делайте вывод по одной строке «From».
Вызов должен соответствовать ожидаемому маршруту. Название токена недостаточно: проверьте адрес контракта и сеть. У токенов с одинаковым тикером могут быть разные эмитенты, версии и мостовые представления. Из receipt можно установить, было ли принято разрешение токена, списание или блокировка, а также какое событие создал контракт. Отсутствие ожидаемого события – причина остановиться и проверить детали, а не отправлять ту же сумму повторно.
Сохраните сеть и идентификатор блока вместе с TxID. Один и тот же короткий хэш-поиск в обозревателе другой сети может не найти запись или привести к случайному совпадению формата. Если перевод важен для учёта, зафиксируйте также дату, адрес контракта и сумму в исходном активе. Не публикуйте секреты кошелька: для проверки достаточно публичной транзакции и адресов.
Найдите идентификатор кроссчейн-сообщения
Следующий шаг – связать операцию с транспортным сообщением. В разных протоколах идентификатор и структура события отличаются: это может быть GUID, nonce вместе с доменами, hash сообщения или запись в специализированном обозревателе. Не подставляйте универсальный шаблон. Откройте документацию конкретного протокола и найдите в журнале исходного контракта поля с исходной сетью, сетью назначения, отправителем, целевым приложением и полезной нагрузкой.
Сопоставьте идентификатор с той же исходной транзакцией. Иногда обозреватель маршрута показывает сразу несколько внутренних вызовов одной пользовательской операции. Выбирайте сообщение, чей отправитель, целевой контракт и направление соответствуют действию, которое вы подписывали. Проверка только суммы ненадёжна: в сообщении могут передаваться инструкции, пакетные действия или данные, а сама сумма может быть указана в другой единице.
Статус «обнаружено» или «отправлено» означает лишь, что исходное событие увидел сервис. Он не равен исполнению в целевой сети. Между стадиями могут оставаться требование финальности, проверка доказательства, ожидание relayer или подтверждение от отдельного набора участников. Чем больше таких стадий, тем важнее записать время и последний подтверждённый шаг, не выдавая промежуточное состояние за завершение.
Проверьте целевую транзакцию
В обозревателе маршрута откройте ссылку на destination transaction, затем отдельно подтвердите её в обозревателе целевой сети. Проверьте, что TxID существует, receipt успешный, а блок относится к ожидаемой цепочке. Сверьте контракт, который исполнил действие, адрес получателя и фактически поступивший актив. Успешный статус пользовательского интерфейса без записи целевой сети не доказывает, что токены уже доступны на нужном адресе.
Результат не всегда совпадает с отображаемым названием исходного токена. В целевой сети это может быть нативно выпущенный актив, обёрнутая версия, доля в пуле или другой токен с тем же символом. Сравните контрактный адрес с официальным реестром проекта и выясните, какой актив принимает следующий сервис. Если перевод нужен для пополнения биржи, отдельно проверьте список поддерживаемых сетей и токенов самой биржи.
Сумму сравнивайте после учёта явно показанных расходов и механики маршрута. Не считайте разницу доказательством пропажи: часть токенов могла быть обменена, удержана как комиссия или направлена в другой адрес по параметрам сделки. Одновременно не принимайте любое расхождение на веру. Найдите в целевой транзакции конкретный перевод и соотнесите его с отправителем и сообщением. Полезный фон по двум TxID разобран в материале почему у перевода через мост два TxID.
Как действовать, если маршрут остановился
- Если исходная транзакция не включена или завершилась ошибкой, ориентируйтесь на её receipt. Не создавайте второй перевод, пока не понятно, списал ли контракт средства.
- Если сообщение найдено, но исходная сеть ещё не достигла требуемой протоколом финальности, сохраните страницу статуса и дождитесь следующей стадии по документации. Число подтверждений и интервалы зависят от цепочки.
- Если доставка ожидается, но destination transaction отсутствует, проверьте, доступна ли официальная функция повторной отправки. Перед повтором убедитесь, что сообщение ещё не исполнено: некоторые контракты защищают от повтора, но повторная команда или платная услуга может иметь дополнительные условия.
- Если целевая транзакция неуспешна, прочитайте её причину и проверьте, вернулся ли актив в исходное состояние или остаётся в контракте. Не отправляйте средства на адрес из личного сообщения с предложением «ручного возврата».
- Если запись успешна, но баланс не изменился, проверьте сеть кошелька, адрес контракта токена, скрытые активы и точный адрес получателя. Поддержка проекта должна получить публичные TxID и идентификатор сообщения, но никогда не seed-фразу.
Чек-лист сопоставления
Перед выводом окончательного статуса убедитесь, что обе транзакции относятся к заявленному направлению; исходное событие содержит нужный message ID; данные отправителя и получателя совпадают; целевая операция успешна; адрес актива и сумма соответствуют результату маршрута. Для отдельного исследования модели доверия пригодится материал о light-client и multisig-мостах, а для безопасного выбора приложения – проверка перевода через мост.
Сопоставление двух записей подтверждает связь конкретного действия, но не даёт гарантии против будущей реорганизации сети, ошибки смарт-контракта или сбоя маршрутизатора. Для крупных сумм разумно сохранять доказательства и проверять, какая именно финальность нужна получающему сервису. Если маршрут поддерживает разные способы доставки, заранее выясните их комиссии и доверительные предположения. Не раскрывайте публично больше адресной истории, чем необходимо: публичность блокчейна делает взаимосвязанные транзакции наблюдаемыми.
Итог
Надёжная проверка начинается с исходного receipt, проходит через идентификатор сообщения и заканчивается подтверждением в целевой сети. Каждую стадию подтверждайте соответствующим обозревателем и документацией выбранного протокола. Не полагайтесь на похожие суммы, один общий статус или случайную ссылку поддержки. Если целевая транзакция не найдена, зафиксируйте последнее подтверждённое состояние и используйте только официальный путь восстановления.
