Короткий ответ: пользователь подписывает одну внешнюю транзакцию, но вызванный ею контракт способен обратиться к другим контрактам, передать нативную монету и записать события токенов. Обозреватель собирает эти уровни из разных данных. «Внутренняя транзакция» обычно означает восстановленный trace выполнения, а событие Transfer – запись в журнале, созданная кодом токена.
Одна подпись и цепочка вызовов
Внешняя транзакция начинается у обычного аккаунта, имеет nonce, оплачивает gas и получает TxID. Например, пользователь вызывает маршрутизатор обмена. Дальше маршрутизатор обращается к пулу, пул переводит токены, а часть комиссии направляет другому контракту. Для всех действий сохраняется один исходный TxID.
Контракт не создаёт новую подписанную транзакцию в обычном смысле. Он исполняет вложенный вызов внутри уже начатой операции. Обозреватели часто помещают такие шаги на вкладку Internal Transactions, хотя точнее говорить о внутренних вызовах или traces.
Последовательность важна для диагностики. Если верхний вызов завершился откатом, изменения его вложенных шагов тоже откатываются. Отдельная строка в trace не доказывает самостоятельный платёж и не получает собственный nonce.
Что показывает trace
Trace восстанавливает дерево выполнения: кто вызвал контракт, какой адрес был следующим, передавалась ли нативная монета и на каком шаге возникла ошибка. Эти сведения предоставляются узлом через механизмы трассировки и могут индексироваться не всеми сервисами одинаково.
Поэтому два обозревателя иногда показывают различное число «внутренних транзакций». Один уже построил trace, другой ещё обрабатывает блок, а третий отображает только выбранные типы вызовов. Состояние блокчейна от дизайна вкладки не меняется.
При проверке выплаты из контракта найдите исходный TxID, откройте дерево вызовов и проследите путь нативной монеты до адреса. Затем сравните конечный баланс в соответствующем блоке. Не принимайте отсутствие отдельной строки на главной вкладке за отсутствие движения.
События ERC-20 и реальный перевод
Токены ERC-20 обычно записывают событие Transfer с адресом отправителя, получателя и суммой. Обозреватель читает журналы и показывает их как Token Transfers. Это удобный стандартный сигнал, но сам журнал создаёт контракт. Он не является независимым распоряжением сети.
Нормальный токен одновременно обновляет балансы согласно своей логике и публикует событие. Однако произвольный контракт способен записать похожий лог без ценного актива. Поэтому неизвестная строка Token Transfer не доказывает, что пользователь получил торгуемый токен. Проверяйте контракт по инструкции, как сверить адрес токена.
Сумма в журнале хранится в базовых единицах. Обозреватель применяет decimals, чтобы показать привычное число. При странном количестве пригодится материал о том, как decimals меняет отображение баланса.
Почему статус Success не отвечает на все вопросы
Success означает, что внешняя транзакция завершилась без необработанного отката и изменения состояния зафиксированы. Но это не всегда означает желаемый экономический результат. Контракт может корректно обработать отказ внутри себя, вернуть нулевой результат или направить актив по условиям, отличным от ожиданий пользователя.
Сначала изучите получателя внешней транзакции и вызванный метод, затем token transfers, события и trace. Для обмена сравните исходный и полученный актив, суммы и реальные адреса контрактов. Если интерфейс показывает перевод, которого нет в балансе, обновите данные через другой индексатор.
При статусе Failed комиссия всё равно может быть списана за выполненную работу. Почему откат не возвращает gas, объясняет статья о комиссии неудачной транзакции.
Отдельно проверяйте, в каком месте цепочки появился желаемый актив. Агрегатор может сначала получить промежуточный токен, затем обменять его и отправить результат пользователю. Если смотреть только первый Transfer, легко принять служебное движение за конечную выплату. Направление определяют по всей последовательности и итоговому владельцу.
Комиссия протокола тоже может быть отражена отдельным событием или уменьшением выходной суммы. Не складывайте автоматически все строки одного токена: часть движений проходит между контрактами и не относится к дополнительному зачислению пользователю.
Практический порядок чтения обозревателя
- Проверьте сеть, TxID, номер блока и итоговый статус.
- Сверьте внешний адрес отправителя, nonce и контракт-получатель.
- Откройте token transfers и сопоставьте контракты, направления и decimals.
- Просмотрите события, относящиеся к нужному протоколу, без доверия к одному названию.
- Откройте trace, чтобы увидеть вложенные вызовы и движение нативной монеты.
- Подтвердите результат по фактическим балансам после блока.
Если обозреватель не показывает token transfers, это может быть задержкой индексатора. Проверьте тот же TxID в другом сервисе и прочитайте журналы блока. Общий алгоритм расхождений описан в инструкции, что делать при разном отображении транзакции.
Для сложной операции запишите ожидаемый маршрут до подписи: какой актив уходит, через какой контракт и какой должен прийти. После блока этот план проще сопоставить с trace, чем пытаться восстановить намерение по десяткам незнакомых событий.
Что можно сообщить поддержке
Подготовьте сеть, TxID, публичный адрес, адреса контрактов, номер блока, ожидаемый результат и снимок нужной вкладки. Секретные данные для чтения trace и событий не требуются. Не передавайте seed-фразу, приватный ключ, пароль или код 2FA, даже если собеседник обещает вручную «добавить внутренний перевод».
Итог
Внешняя транзакция задаёт подпись, nonce и оплату gas. Внутренние вызовы показывают ход исполнения, а события токенов помогают приложениям индексировать результат. Чтобы подтвердить перевод, сопоставляйте все три уровня с конечными балансами и адресами контрактов, а не доверяйте одной строке обозревателя.
