В обозревателе транзакция отмечена как успешная, но ожидаемого результата на адресе нет. Статус исполнения — только часть проверки. Вызов мог обратиться к контракту, а внутри него пройти несколько переводов разных токенов и адресов. Смотреть только на зелёную отметку или верхнее поле to недостаточно.
Разделите статус транзакции и события токена
Метод eth_getTransactionReceipt возвращает чек исполнения с полем status и массивом logs. В стандартном современном чеке 0x1 обозначает успешное исполнение, 0x0 — неуспешное. Отсутствие чека в ответе не устанавливает одну-единственную причину: по одному скопированному null нельзя надёжно определить состояние всей сети.
У ERC-20 перевод описывается событием Transfer с адресами отправителя и получателя и целым значением. Адрес контракта, который выдал лог, находится отдельно от этих участников. А поле to верхнего уровня относится к вызову транзакции: при работе с контрактами оно не обязано быть адресом конечного получателя токенов.
Учебный пример: входящие совпали, изменение по логам — нет
Возьмём условный контракт T и проверяемый адрес B. Ожидаемая величина — 1 500 000 минимальных единиц, отображение задано с шестью дробными знаками. Адреса в форме синтетические и не обозначают настоящий USDT или другой реальный актив.
| Индекс | Контракт | Отправитель → получатель | Единиц | Вклад для B по T |
|---|---|---|---|---|
| 0 | T | A → B | 1 000 000 | Входящие +1 000 000 |
| 1 | T | A → B | 500 000 | Входящие +500 000 |
| 2 | T | A → C | 700 000 | Не участвует: другой адрес |
| 3 | Другой | A → B | 1 500 000 | Не участвует: другой контракт |
| 4 | T | B → C | 250 000 | Исходящие −250 000 |
Входящие по выбранному контракту равны ожидаемым 1 500 000. Но исходящие в этой же транзакции составляют 250 000. Разность по поддержанным логам — 1 250 000, или 1.250000 при введённой точности. Если проверить только входящую сумму, второе действие останется незамеченным.
Почему название токена не заменяет адрес контракта
Символ и название не являются параметрами этого фильтра. Сравнивается точный адрес контракта, выбранный пользователем. Но одинаковая запись адреса в разных сетях не подтверждает один актив. Сеть и правильный контракт нужно установить независимо до разбора чека; инструмент их не угадывает.
Он также не считает любое событие с названием Transfer переводом ERC-20. В ERC-721 есть событие с той же сигнатурой типов, но другой индексацией значения. Поэтому проверяется поддерживаемая структура: три topics, два правильно дополненных адреса и 32 байта data. Иная структура отмечается для проверки, а не превращается в сумму токенов.
Что считается в отчёте
- Входящие
- Сумма подходящих Transfer выбранного контракта, где адрес указан получателем.
- Исходящие
- Сумма таких событий, где тот же адрес указан отправителем.
- Разность по логам
- Входящие минус исходящие. Перевод адресу самому себе входит в обе суммы и даёт нулевую разность.
- Совпадение с ожидаемым
- Арифметическая проверка введённых данных, а не подтверждение зачисления или фактического баланса.
Для стандартного разбора используются целые числа без округления через тип Number. Точность от нуля до восемнадцати знаков влияет только на отображение. Она не считывается из контракта. Сумма в data и введённое ожидание остаются целыми минимальными единицами.
Какие данные требуют отдельного разбора
Повторяющиеся logIndex не суммируются: все записи с конфликтующим индексом исключаются, а отчёт требует проверки. Логи с removed=true также не учитываются. Это не самостоятельная диагностика реорганизации: по скопированному набору нельзя установить, какие данные сейчас считает действительными выбранный узел.
Неуспешный чек не интерпретируется как выполненные переводы, даже если в него вручную добавлены логи. Некорректная структура события выбранного контракта блокирует итоговую отметку о прохождении локальных условий. Исторические чеки без status, нестандартные токены и изменение баланса без ожидаемых Transfer находятся вне модели.
Почему разность по логам не названа проверенным балансом
Для проверки реального баланса нужны достоверные данные состояния и особенности токена. Перебазирование, нестандартная логика и неполная копия чека могут сделать вывод только по этим событиям недостаточным. Форма не запрашивает balanceOf и не доказывает полноту или подлинность списка.
При выяснении обмена сохраните сеть, хеш транзакции, контракт, ожидаемый адрес и актуальный статус ордера. В KOT.CASH маршрут описан на странице «Как это работает»; условия обработки конкретного ордера нужно проверять отдельно. Генератор квитанции на сайте решает другую задачу — оформляет документ из полей, а этот разбор помогает понять события. Ни один локально заполненный документ или отчёт не заменяет проверку в выбранной сети.
Разобрать поддержанные ERC-20 Transfer из чека
Синтетический пример. До 200 логов и 100000 знаков JSON. Только стандартная структура ERC-20 Transfer с logIndex. Адреса сравниваются как hex без EIP-55-проверки. Не читает сеть, не подтверждает подлинность, баланс, окончательность или зачисление KOT.CASH. Расчёт выполняется на вашем устройстве, введённые данные никуда не отправляются.