Короткий ответ: мост соединяет две независимые цепочки. Первая транзакция принимает или блокирует актив в исходной сети и создаёт сообщение. Вторая выпускает или переводит актив в целевой сети. У каждой операции собственный TxID, блок, комиссия и статус, а между ними существует идентификатор межсетевого сообщения.
Что фиксирует исходный TxID
Пользователь подписывает вызов контракта моста в исходной сети. Контракт получает токен, блокирует его, сжигает представление или записывает запрос на перевод. Receipt содержит события с адресом получателя, суммой и данными сообщения.
Success этого TxID доказывает успешную инициацию, но не поступление в другой блокчейн. После блока инфраструктура моста должна обнаружить событие, дождаться нужной уверенности и подготовить действие назначения.
Если исходная операция Failed, целевого перевода обычно не будет. Сначала разберите причину отката, а не ищите второй хеш.
Откуда появляется целевой TxID
В сети назначения контракт или поставщик ликвидности отправляет актив получателю. Транзакцию может создать relayer, валидаторная сеть, пользователь при claim или другой участник. Она получает новый хеш, потому что записана в другой цепочке.
Целевой TxID показывает фактический контракт токена, сумму и адрес. Его комиссия может оплачиваться мостом, вычитаться из результата или требовать нативную монету пользователя. Это должно быть понятно до начала маршрута.
Одинаковая строка адреса в EVM-сетях не объединяет историю. Каждый хеш открывайте в обозревателе своей сети.
Идентификатор сообщения связывает этапы
Мост извлекает из исходного события nonce, message hash или собственный transfer ID. Этот идентификатор не всегда является транзакцией и может не открываться в обычном обозревателе. Он нужен трекеру для сопоставления двух TxID.
Скопируйте его из проверенного интерфейса или событий контракта. Не подключайте кошелёк к случайному «декодеру»: публичные данные читаются без подписи. Если два сервиса показывают разные статусы, сопоставьте исходный блок и идентификатор сообщения.
Почему второй хеш задерживается
Мост может ждать финальности исходной сети, подтверждений валидаторов, доступной ликвидности или завершения периода оспаривания. Relayer способен временно отстать, хотя сообщение уже готово. Отсутствие целевого TxID не означает потерю актива.
Для канонического optimistic-вывода этапы могут включать proof и отдельный claim. Подробности есть в статье о многоэтапном выводе. У стороннего моста причины и сроки другие.
Если целевая транзакция подтверждена, но токен не виден, проверьте его контракт и добавьте актив в кошелёк. Не отправляйте исходный перевод повторно.
Бывает и обратная ситуация: целевой TxID создан, но завершился Failed. Тогда исходное сообщение может оставаться неисполненным и допускать повторный relay, а может быть уже погашено по правилам контракта. Проверяйте статус message ID, а не запускайте новый deposit.
Комиссии на разных этапах
Первая транзакция оплачивается нативной монетой исходной сети. Расход назначения может покрывать relayer или пользователь при claim. Сервисная комиссия иногда вычитается из выдаваемой суммы, поэтому полученный баланс меньше исходного без ошибки перевода.
До подписи сравните минимальный результат, gas обоих этапов и плату за ликвидность. После операции сохраните receipt: он помогает отличить сетевой расход от удержания мостом.
Когда TxID может быть больше двух
Approve перед мостом имеет отдельный хеш, но не является переносом. Канонический маршрут может добавить публикацию, proof и финализацию. Агрегатор способен использовать промежуточную сеть или обмен, создавая ещё несколько операций.
Составьте последовательность по назначению: approve, deposit, message, fill, claim. Не считайте любую строку с вашим адресом вторым платежом. События и traces помогает читать руководство о внутренних транзакциях.
Как проверить перевод без повторной отправки
- Откройте исходный TxID и убедитесь в Success.
- Сверьте контракт моста, актив, сумму и получателя.
- Найдите идентификатор сообщения в событиях или трекере.
- Проверьте требуемую финальность исходного блока.
- Найдите целевой TxID и откройте его в правильной сети.
- Сверьте конечный token transfer или нативный баланс.
Если используется сторонняя ликвидность, оцените маршрут по сравнению канонического и стороннего моста. Успех первого этапа не гарантирует, что посредник уже выдал средства.
Безопасна ли повторная отправка
Новый вызов моста создаёт новое сообщение и может перенести вторую сумму. Он не ускоряет существующее сообщение. Повтор оправдан только если первая транзакция однозначно Failed и токены остались у отправителя. При Success разбирайте последующий этап.
Если задержка связана с relayer, некоторые протоколы позволяют другому участнику исполнить готовое сообщение. Используйте только официальный контракт и точный message ID. Не подписывайте approve, если для claim он не предусмотрен.
Что сообщить поддержке
Передайте обе сети, исходный и целевой адрес, актив и контракт, сумму, исходный TxID, message ID и целевой TxID, если он появился. Seed-фраза, приватный ключ, пароль и 2FA не нужны. С этими секретами мошенник сможет создать настоящий новый перевод.
При депозите на биржу укажите целевой хеш. Инструкция про незачисленный депозит из L2 помогает собрать дополнительные сведения.
Если поддержка просит только один хеш, уточните сеть этого TxID. Исходная операция может быть бесполезна для сервиса, который отслеживает исключительно адрес назначения.
Итог
Два TxID – нормальное следствие записи в двух блокчейнах. Исходный хеш подтверждает приём, message ID связывает процесс, а целевой хеш доказывает выдачу. Отслеживайте этапы отдельно и не запускайте мост снова только потому, что второй хеш ещё не появился.
