Если CCTP ожидает attestation, успешное сжигание USDC в исходной сети ещё не подтверждает поступление в целевой. Проверяйте три отдельных этапа: сжигание, подписанное сообщение Circle и выпуск у получателя. Не начинайте новое сжигание только из-за пустого экрана кошелька. Сначала установите, какая часть уже существующего перевода не завершилась.
Убедитесь, что перед вами именно сжигание CCTP
Сохраните исходную и целевую сети, название приложения, хеш первоначальной операции, ожидаемый адрес и номер перевода сервиса. Успешное разрешение на расходование USDC не означает сжигание. Приложение моста может предлагать несколько маршрутов, поэтому одного знакомого тикера недостаточно для определения протокола. Изучите маршрут и фактическую запись, а не восстанавливайте их по названию кнопки.
В технической документации CCTP описаны сообщение исходной сети, подпись внешнего сервиса и обработка сообщения в целевой сети. На маршрутах EVM компоненты сжигания и передачи сообщений выполняют разные роли. В других поддерживаемых сетях реализация отличается. Нельзя без проверки переносить совет для EVM-контракта на операцию в иной системе.
Проверьте, что исходное действие завершилось и создало ожидаемое сообщение о сжигании. Если операция откатилась, начинать следует не с поиска подписи. Если найдено только разрешение allowance, выясните, подписывалась ли отдельная операция burn. А если настоящее сжигание уже состоялось, новый перевод создаст ещё один случай вместо завершения первого.
Разложите общий статус на этапы
| Что подтверждено | Какой вывод допустим | Что ещё требуется |
|---|---|---|
| Успешное разрешение allowance | Контракту выдано разрешение | Отдельная отправка и исполнение burn |
| Сжигание и его сообщение | Выполнен исходный этап | Готовность подписи нужного сообщения |
| Attestation доступна | Есть подписанное сообщение | Публикация и исполнение в целевой сети |
| Целевая операция ожидает | Существует попытка получения | Результат и правильный адрес |
| Целевая операция неуспешна | Попытка не завершила действие | Точная ошибка и порядок продолжения у приложения |
| Выпуск состоялся на нужный адрес | Есть получение в сети | Отображение кошелька или учёт сервиса |
| Интерфейс пишет complete | Продукт показывает свой статус | Какой именно этап назван завершённым |
Слово complete нужно читать в контексте. В API сообщений и подписей Circle возвращаются данные attestation; в примере отдельно показана информация дальнейшей передачи. Статус готовности подписи не следует превращать в утверждение о зачислении получателю. Для этого нужна самостоятельная запись целевого исполнения.
Проверьте область поиска, прежде чем объявлять потерю
Текущий API использует исходный domain и хеш транзакции либо nonce. Domain определяет сеть внутри CCTP и не обязан совпадать с произвольным номером сети в настройках кошелька. Поиск в неверной среде или по другому исходному domain может не дать полезного результата при существующем сжигании. Поддержке передавайте название исходной сети вместе с хешем.
Одна транзакция способна создавать несколько сообщений. Сверяйте целевую сеть, получателя и сумму конкретного сообщения вместо выбора первого элемента ответа. Номер перевода приложения храните рядом с сетевым хешем. Так удастся связать запись сервиса, конкретное сообщение сжигания и целевую операцию, не выдавая разные идентификаторы за одно и то же.
В старых примерах встречаются поиск attestation по хешу сообщения и статус pending_confirmations. Это не основание считать старый адрес API и каждый термин подходящими для текущего перевода. Уточните версию и реализацию, создавшую burn. Отсутствие целевой операции в обозревателе также не объясняет само по себе, готова ли подпись внешнего сервиса.
Готовность подписи и получение — разные события
Срок attestation зависит от уровня подтверждения исходной цепочки и режима перевода. Быстрый вариант не является общим предельным сроком. Задержка сама по себе не доказывает сбой: сверяйте состояние маршрута и официальные сообщения. Не опрашивайте вручную API непрерывным потоком запросов; обычные проверки должен выполнять интерфейс или разбирать его поддержка.
Если подпись доступна, но выпуска ещё нет, изучайте целевую сторону. В одном приложении отправкой занимается исполнитель сервиса, в другом пользователю предлагается шаг получения. Могут требоваться подпись, успешное исполнение или обеспечение комиссии. Используйте официальный процесс продолжения своего приложения. Не вставляйте данные сообщения на случайный сайт, обещающий вернуть зависшие USDC.
У части быстрых сообщений есть условие истечения срока. В справке повторной аттестации и техническом руководстве Circle описан вариант обновления подписи для подходящих случаев. Это не поручение повторно сжечь первоначальную сумму. До новой исходной операции уточните у приложения, какой порядок относится именно к вашему сообщению.
Подготовьте обращение с последним подтверждённым этапом
- Запишите номер перевода, хеш burn, исходную и целевую сети, ожидаемый адрес получения.
- Проверьте исходное исполнение, отделив разрешение расходования от состоявшегося сжигания.
- Найдите нужное сообщение и состояние подписи через официальное приложение или документированный интерфейс.
- При готовой подписи ищите попытку целевой отправки и её результат, не начиная исходный перевод заново.
- Передайте поддержке последний установленный этап, точную ошибку и время проверки. Секретные слова и ключи не включайте.
Представим вымышленный перевод «Кедр»: burn завершён, подпись доступна, но приложение ожидает подтверждение получения. Полезный вопрос поддержке — существует ли целевая операция и что мешает её завершению. Название «зависшее сжигание» скрывает уже собранные сведения. Если выпуск затем состоялся, следующий вопрос относится к отображению у владельца или внутреннему зачислению сервиса. Сохраните дату и время наблюдения статуса: следующий ответ поддержки должен отличать прежнее ожидание от новой неудачной попытки в целевой сети. Скриншот без названия сети и времени проверки не даёт такого различия. Не удаляйте первоначальную запись после обновления страницы.
Перед будущей отправкой различайте нативный и перенесённый USDC, сверяйте идентичность целевого актива. В чтении записей поможет инструкция проверки хеша. У обмена без регистрации собственные инструкции: упоминание CCTP не доказывает использование этого протокола конкретной заявкой. Проверяйте реально согласованный маршрут.
Частые вопросы
Что показывает explorer при зависшем переводе USDC CCTP?
Он помогает связать исходное сжигание, attestation и целевую операцию. Уточняйте смысл каждого статуса и сверяйте важные результаты с официальными записями.
Сжигание через CCTP bridge уже означает получение USDC?
Нет, готовность подписи и исполнение в целевой сети проверяются отдельно. Сохраните исходную запись и разбирайте её, не создавая новую отправку ради проверки.
Можно использовать старую инструкцию для USDC CCTP V2?
Проверьте соответствие версии и реализации вашего приложения. Старые адреса API и примеры статусов нельзя автоматически применять к текущему процессу получения.