Как проверить транзакцию по TxID в 2026 году: Bitcoin, USDT, TRC20, ERC20, TON и Solana

TxID — это идентификатор транзакции в блокчейне, по которому можно проверить, была ли операция передана в сеть, попала ли она в блок, успешно ли выполнилась и какие адреса или токены участвовали. На практике одного хэша недостаточно: сначала нужно определить сеть, затем открыть подходящий обозреватель и правильно прочитать его поля. Один и тот же перевод может отображаться как успешный в блокчейне, но ещё не быть зачисленным биржей, обменником или кошельком.

Проверка по TxID особенно важна при переводах USDT, Bitcoin, ETH, TON, SOL и других активов между биржами и личными кошельками. Она отделяет сетевой факт от внутреннего статуса сервиса. Если транзакции нет в блокчейне, проблема обычно находится на стороне отправляющего приложения или площадки. Если операция подтверждена, но баланс получателя не изменился, нужно проверять сеть депозита, токен, минимальную сумму, memo или comment, внутреннюю обработку и требования площадки.

Эта инструкция построена как универсальный диагностический алгоритм. Сначала разбираются виды идентификаторов и базовые поля обозревателя, затем — особенности Bitcoin, Ethereum и других EVM-сетей, TRON/TRC20, TON и Solana. В заключительных разделах собраны причины статуса «не найдено», действия при успешной, но незачисленной транзакции, доказательства для поддержки и правила безопасности. Для узкой проверки USDT используйте также инструкцию OneMagic по TxID перевода USDT.

Что такое TxID и какие данные он действительно подтверждает

TxID, transaction hash и signature: похожие названия, разные форматы

В Bitcoin и большинстве EVM-сетей идентификатор часто называют TxID или transaction hash. В TRON используется transaction ID, в Solana основным идентификатором выступает первая подпись транзакции, а в TON для точного поиска могут понадобиться hash, адрес аккаунта и logical time. Пользовательский интерфейс нередко объединяет все эти значения словом «хэш», хотя техническая модель сети различается.

Главное правило — копировать идентификатор из самой операции и открывать обозреватель именно той сети, в которой была отправлена транзакция. Хэш Ethereum не найдётся в обозревателе TRON, а подпись Solana нельзя проверить как Bitcoin TxID. Формат строки помогает предположить сеть, но не заменяет проверку выбранной сети в истории вывода или в карточке операции.

Что TxID доказывает, а чего не доказывает

Найденная транзакция доказывает, что конкретная операция существует в публичном реестре указанной сети. Из обозревателя можно получить отправителя, получателя, сумму, токен, время, комиссию, номер блока или слот и результат исполнения. Эти данные сильнее скриншота кошелька, потому что их можно независимо проверить через разные узлы и обозреватели.

Однако TxID не доказывает личность владельца адреса, законность сделки, получение банковских денег или выполнение внеблокчейн-договора. Он также не гарантирует автоматическое зачисление биржей. Площадка может требовать больше подтверждений, правильный memo, минимальный депозит или ручную проверку. Поэтому TxID — центральная часть доказательств, но не единственный документ.

TxID не равен номеру заявки, ордера или вывода

Биржи, обменники и P2P-площадки создают внутренние номера операций. Такой номер существует в базе сервиса и помогает поддержке найти заявку, но он не является блокчейн-хэшем. До фактической отправки вывода площадка может показывать только внутренний ID, статус проверки безопасности и ожидаемое время обработки.

Если сервис сообщает, что вывод завершён, в карточке операции должен появиться внешний хэш или ссылка на обозреватель. Для обращения в поддержку сохраняют оба значения: внутренний номер нужен самой площадке, а TxID подтверждает сетевую часть. Если внешнего хэша нет, нельзя считать, что криптовалюта уже покинула сервис.

TxID не равен адресу кошелька

Адрес обозначает аккаунт или назначение перевода, а TxID — одну конкретную операцию. У одного адреса может быть тысячи транзакций, и каждая получает собственный идентификатор. По адресу можно открыть историю, но при активном кошельке поиск нужной суммы и времени становится сложнее, чем проверка по точному хэшу.

Мошенники иногда присылают адрес вместо TxID и утверждают, что перевод выполнен. Наличие средств на адресе или история других платежей не подтверждают вашу транзакцию. Требуйте хэш именно того перевода, который должен содержать вашу сумму, ваш адрес получателя и согласованную сеть.

TxID не равен хэшу блока

Хэш блока идентифицирует набор транзакций, включённых валидатором или майнером. TxID идентифицирует одну операцию внутри блока. В обозревателе эти значения располагаются рядом, поэтому новичок может случайно скопировать block hash и не найти его в поиске по транзакциям.

Обычно ссылка на транзакцию содержит раздел transaction, tx или аналогичное обозначение. После открытия проверяйте, что страница показывает поля From и To либо входы и выходы, сумму и статус. Если отображается список множества операций и заголовок блока, вы открыли не тот объект.

Почему одна операция может иметь несколько связанных идентификаторов

Сложные операции вызывают смарт-контракты, создают внутренние сообщения или включают несколько инструкций. В Ethereum одна внешняя транзакция может породить internal calls и события Transfer. В TON пользовательское действие разворачивается в trace из нескольких сообщений и транзакций разных аккаунтов. В Solana одна подпись покрывает пакет инструкций.

Для обычной поддержки начинают с внешнего идентификатора, который выдал кошелёк. Затем внутри обозревателя раскрывают токен-переводы, события, internal transactions или trace. Нельзя брать любой внутренний хэш и считать его исходным переводом: сначала нужно установить причинную цепочку от подписанной пользователем операции до итогового движения токена.

Публичный блокчейн и внутренняя бухгалтерия сервиса

Блокчейн показывает сетевое состояние, а биржа ведёт отдельные балансы клиентов. Когда депозит достигает адреса площадки, её система должна распознать актив, дождаться требуемого уровня подтверждения и начислить внутренний баланс. Эта стадия не создаёт новую публичную транзакцию для каждого клиента.

Поэтому ситуация «TxID успешен, но баланс нулевой» возможна без противоречия. Сеть завершила перевод, а сервис ещё обрабатывает депозит или не смог его сопоставить. Подробный разбор такого сценария есть в материале почему TxID есть, а депозит ещё не зачислен.

Внутренний перевод может не иметь публичного TxID

Если два пользователя находятся внутри одной биржи или кастодиального кошелька, сервис может изменить свои внутренние записи без отправки операции в блокчейн. Перевод по UID, email или номеру телефона нередко выполняется мгновенно и не имеет публичного хэша. Это не означает, что операция поддельная, но проверяется она только в истории сервиса.

При споре сохраняют номер внутреннего перевода, отправителя, получателя, сумму, время и скрин карточки операции. Если приложение обещало on-chain вывод, а затем показывает только внутренний номер, уточните тип маршрута. Внутренний перевод нельзя найти в обозревателе, даже если актив называется так же, как токен публичной сети.

Основные форматы идентификаторов по сетям

Bitcoin и EVM обычно используют шестнадцатеричные строки, но длина и отображение могут совпадать у разных сетей. TRON также показывает хэш транзакции в hex-формате. Solana использует длинную base58-подпись. TON может показывать hash в base64 или hex и связывать его с адресом и logical time. Внешний вид помогает, но не даёт стопроцентного ответа.

Надёжный способ определить сеть — открыть историю вывода отправителя, проверить выбранную сеть и сопоставить адрес получателя. Если данные прислал контрагент, попросите ссылку из официального интерфейса и отдельно скопируйте чистый идентификатор. Сокращённый хэш с многоточием непригоден для поиска и доказательства.

Какие сведения нужно получить до начала проверки

Минимальный набор: актив, сеть, полный TxID или signature, адрес отправителя, адрес получателя, сумма и примерное время. Для биржевого депозита дополнительно нужны memo, tag или comment, минимальная сумма и требования по подтверждениям. Для токена важно знать контракт, потому что одинаковый тикер могут использовать разные смарт-контракты.

Если часть данных отсутствует, проверка превращается в догадку. Не пытайтесь искать перевод только по сумме в глобальной истории сети. Сначала соберите карточку операции и страницу депозита получателя. Для подготовки перед переводом используйте чек-лист проверки сети USDT.

Универсальная проверка транзакции по TxID: пошаговый алгоритм

Шаг 1. Определите сеть по данным отправителя

Начинайте не с поисковика, а с истории операции. В карточке вывода обычно указаны asset и network. Например, USDT может быть отправлен через TRON, Ethereum, BNB Smart Chain, TON или Solana. Один и тот же тикер не определяет сеть. Если выбрать неправильный обозреватель, результат «не найдено» ничего не говорит о существовании перевода.

Сверьте сеть с депозитной страницей получателя. Если там указана другая сеть, зафиксируйте ошибку и не предпринимайте повторную отправку до анализа. Подробный сценарий восстановления описан в статье что делать, если USDT ушёл не в той сети.

Шаг 2. Получите полный идентификатор без пробелов и сокращений

Копируйте TxID кнопкой Copy из карточки операции. Не перепечатывайте длинную строку вручную и не используйте хэш, показанный как первые и последние символы. При копировании из сообщения удалите кавычки, пробелы, переносы строк и знаки пунктуации, которые могли приклеиться к идентификатору.

Сравните скопированное значение с оригиналом. Буфер обмена может быть подменён вредоносным приложением, хотя чаще подмена касается адресов. Для важного спора сохраните скриншот карточки операции, но передавайте поддержке сам хэш в текстовом виде, чтобы его можно было вставить в обозреватель.

Шаг 3. Откройте обозреватель именно этой сети

Обозреватель — интерфейс над публичными данными блокчейна. Предпочтительно использовать официальный или давно известный сервис, открытый из документации сети, сайта биржи или ссылки в кошельке. Рекламный результат в поиске может вести на фишинговую копию, которая просит подключить кошелёк или ввести seed-фразу.

Для простого чтения транзакции подключение кошелька не требуется. Если сайт требует подпись, установку расширения, приватный ключ или recovery phrase, закройте страницу. Проверка публичного TxID выполняется без авторизации и без доступа к активам.

Шаг 4. Найдите статус и убедитесь, что это страница транзакции

Первая контрольная точка — статус: pending, confirmed, success, failed, reverted, finalized или аналогичный. Значение зависит от сети. Одновременно убедитесь, что открылась транзакция, а не адрес, блок или токен-контракт. На странице должны присутствовать отправитель, получатель или набор входов и выходов, время и комиссия.

Статус «success» означает успешное исполнение на уровне сети, но не обязательно получение ожидаемого токена. Например, пользователь мог успешно вызвать approve вместо transfer или отправить нативную монету вместо USDT. Поэтому после статуса переходят к проверке содержания операции.

Шаг 5. Сверьте отправителя и получателя полностью

Проверьте адреса не только по началу и окончанию. В UTXO-сетях найдите нужный output, потому что транзакция может содержать несколько получателей и change-адрес. В смарт-контрактных сетях поле To может показывать контракт токена, а фактический получатель — событие Transfer. Обозреватель обычно выделяет token transfers отдельным блоком.

Если адрес получателя отличается, не отправляйте новую транзакцию «для исправления» по просьбе неизвестного лица. Сначала определите, кому принадлежит ошибочный адрес и кастодиальный ли это сервис. Практические действия собраны в инструкции что делать при отправке не на тот адрес.

Шаг 6. Сверьте актив, контракт и фактическую сумму

Название токена в интерфейсе не всегда надёжно. Для ERC20, TRC20, SPL и jetton-токенов проверьте контракт или mint. Сумма может отображаться в минимальных единицах и преобразовываться по decimals. Биржа также может удержать комиссию, поэтому адрес получателя получает меньше исходной суммы вывода.

Убедитесь, что обозреватель показывает именно transfer нужного токена. Успешный вызов контракта без события перевода может не изменить баланс. Спам-токен с тикером USDT не равен официальному активу. Для существенной суммы сравнивайте контракт с депозитной страницей получателя или официальной документацией эмитента.

Шаг 7. Проверьте время, блок, слот и число подтверждений

Время помогает исключить чужую операцию с похожей суммой. Номер блока или слот показывает, что транзакция включена в историю. В сетях с моделью подтверждений глубина увеличивается по мере появления новых блоков. Биржи устанавливают собственный порог, который может меняться при технических работах и повышенном риске реорганизации.

Не используйте универсальное правило вроде «одного подтверждения всегда достаточно». Порог зависит от сети, актива и площадки. Смотрите страницу депозита или статус в аккаунте. Если блокчейн подтверждён, а биржа пишет insufficient confirmations, это ещё не сбой — её внутренний порог пока не достигнут.

Шаг 8. Прочитайте комиссию и ресурсные поля

В Bitcoin важна ставка комиссии относительно размера транзакции, в EVM — gas used и effective gas price, в TRON — Energy, Bandwidth и сожжённый TRX, в Solana — base fee и возможная priority fee, в TON — совокупные комиссии сообщений и исполнения. Абсолютное число без контекста сети малоинформативно.

Комиссия помогает диагностировать задержку или отказ. Слишком низкая ставка Bitcoin может оставить операцию в mempool. Недостаточный gas limit в EVM приводит к failed при списанной комиссии. В TRON неудачное исполнение контракта также может израсходовать ресурсы. Факт оплаты комиссии не доказывает успешный перевод токена.

Шаг 9. Проверьте memo, tag, comment и другие метки

Некоторые сервисы используют общий адрес для множества клиентов и различают депозиты по метке. В TON комментарий может быть важен для платежного сервиса, а в XRP и других сетях используется destination tag или memo. Метка обычно не влияет на поступление в сам блокчейн-адрес, но определяет, кому сервис начислит внутренний баланс.

Если перевод подтверждён на общем адресе, но метка отсутствует или неверна, соберите TxID, адрес, сумму и доказательство владения аккаунтом. Не создавайте второй перевод до ответа поддержки. Новый платёж не исправляет старую метку и может увеличить сумму, требующую ручного зачисления.

Шаг 10. Сопоставьте блокчейн со статусом сервиса

После проверки сети откройте историю депозита или вывода на площадке. Возможны четыре состояния: транзакция ещё не создана; создана и ожидает включения; подтверждена сетью, но ждёт порога сервиса; полностью зачислена. На каждом этапе нужен разный адресат обращения и другой набор доказательств.

Если хэш не существует, пишет отправляющий сервис. Если транзакция failed, причину ищут в сети или кошельке. Если success и адрес правильный, но депозит не зачислен, обращаются к получателю. Если деньги зачислены в блокчейне и внутреннем аккаунте, но не видны в нужном разделе, проверяют Funding, Spot, Earn или иной внутренний баланс.

Как проверить Bitcoin-транзакцию по TxID

Как формируется Bitcoin TxID

Bitcoin TxID получается из сериализованной транзакции и служит ссылкой на набор входов и выходов. В SegWit-транзакциях обозреватель также может показывать wtxid, учитывающий witness-данные. Для обычного пользователя основной идентификатор, который присылает кошелёк или биржа, — txid. Его используют для поиска, поддержки и доказательства перевода.

Не путайте TxID исходной транзакции с идентификатором предыдущей операции, выход которой расходуется как input. На странице будет много хэшей: каждый input ссылается на старый UTXO. Искомый перевод определяется заголовком страницы и списком outputs, где должен присутствовать адрес получателя.

Inputs, outputs и сдача: почему сумма не читается как в банковском платеже

Bitcoin-транзакция расходует целые неизрасходованные выходы. Если кошельку нужно отправить 0,01 BTC, он может использовать input на 0,05 BTC, создать output получателю, второй output со сдачей владельцу и вычесть комиссию. Поэтому сумма всех входов значительно выше платежа и не означает, что получатель получил весь объём.

Ищите конкретный output на нужный адрес. Change-адрес может быть новым и незнакомым, хотя принадлежит тому же кошельку отправителя. Обозреватель не знает автоматически, какой output является сдачей, если адреса не размечены. Для доказательства достаточно совпадения адреса и суммы нужного выхода.

Mempool и первое появление транзакции

После broadcast узлы принимают корректную транзакцию в mempool и распространяют её по сети. Разные обозреватели подключены к разным узлам, поэтому один может увидеть TxID раньше другого. Краткая задержка не доказывает отмену. Проверьте несколько надёжных источников и историю кошелька отправителя.

Если операция долго не появляется нигде, возможно, кошелёк только создал, но не передал её, сервис ещё проверяет вывод или транзакцию отклонил локальный узел. Статус «sending» в приложении без TxID не равен нахождению в mempool. Сначала дождитесь внешнего идентификатора.

Подтверждения Bitcoin и глубина блока

Первое подтверждение появляется, когда майнер включает транзакцию в блок. Каждый последующий блок увеличивает глубину. Получатель сам выбирает, сколько подтверждений считать достаточным с учётом суммы и риска. Биржи публикуют порог депозитов и могут временно повышать его при нестабильности сети.

Нулевое подтверждение означает, что транзакция остаётся неподтверждённой. Это не всегда проблема: при нормальной комиссии она может войти в ближайшие блоки. Но крупный получатель обычно не считает такой платёж окончательным, особенно если транзакция допускает замену через RBF.

Комиссия Bitcoin: sat/vB важнее общей суммы fee

Майнеры сравнивают ставку комиссии на виртуальный байт, а не только абсолютный fee. Большая транзакция с множеством inputs может заплатить больше сатоши, но иметь низкую ставку и ждать дольше маленькой операции. Обозреватель показывает размер, weight, fee rate и положение относительно текущего mempool.

Не устанавливайте произвольную дополнительную комиссию через сторонний «ускоритель». Возможности зависят от кошелька и структуры транзакции. Для детального сценария используйте инструкцию по RBF и CPFP для зависшего Bitcoin.

RBF: когда старый TxID заменяется новым

Replace-by-Fee позволяет отправителю заменить неподтверждённую транзакцию версией с более высокой комиссией при соблюдении правил. Старый TxID может отображаться как replaced, conflicted или dropped, а новый — как активная операция. Получателю нужно следить за новым хэшем и убедиться, что его output сохранён.

Если контрагент показывает неподтверждённый платёж с возможностью RBF, не считайте его окончательным. После подтверждения замена обычным RBF невозможна. Биржи и кошельки по-разному обозначают эту функцию, поэтому смотрите признаки replaceability в обозревателе и документации приложения.

CPFP и зависимость дочерней транзакции

Child Pays for Parent использует неподтверждённый выход и добавляет дочернюю транзакцию с повышенной комиссией, чтобы совокупный пакет стал привлекательнее майнеру. В обозревателе появляются два TxID и зависимость между ними. Получатель может использовать метод, если контролирует подходящий выход и кошелёк поддерживает функцию.

Нельзя отправлять BTC из ещё не подтверждённого депозита вслепую. Сначала проверьте, допускает ли кошелёк spending unconfirmed outputs и как он рассчитывает комиссию пакета. Некорректная дочерняя транзакция не исправляет адрес или сумму исходного платежа.

Dropped, evicted и конфликтующая транзакция

Транзакция с очень низкой комиссией может исчезнуть из mempool конкретного узла при перегрузке или истечении локальных правил хранения. Это не глобальный официальный статус: другой узел всё ещё может её помнить, а отправитель может повторно передать исходные данные. Баланс кошелька иногда становится снова доступным после очистки.

Конфликт возникает, когда другой валидный платеж расходует тот же input. Если конфликтующая транзакция подтверждена, исходная уже не может войти в цепь. Проверяйте spent outputs и replacement-ссылки. Не принимайте скрин старого TxID как доказательство после появления confirmed-конфликта.

Как доказать Bitcoin-перевод поддержке

Сохраните TxID, адрес получателя, конкретный output, сумму BTC, время, число подтверждений, fee rate и ссылку на обозреватель. Если применялся RBF, перечислите старый и новый TxID. Для биржевого депозита приложите страницу депозитного адреса и доказательство, что перевод превысил минимум.

Не отправляйте xprv, seed-фразу или приватные ключи. Поддержке достаточно публичных данных и скриншотов аккаунта. Если требуется доказательство владения адресом, используйте безопасную подпись сообщения только по официальной инструкции сервиса и внимательно проверяйте, что подписывается именно текст, а не транзакция.

Проверка Ethereum и других EVM-транзакций

Transaction hash в Ethereum, BNB Smart Chain, Polygon и L2

EVM-сети используют похожий формат хэша и совместимые поля, но каждая имеет отдельную цепь. Один и тот же адрес может существовать в Ethereum, BNB Smart Chain, Arbitrum, Optimism, Base и Polygon, однако балансы и транзакции независимы. Хэш ищут в обозревателе той сети, которую выбрал отправитель.

Если операция не находится в Ethereum, это не доказывает её отсутствие: она могла быть отправлена в другой EVM-сети. Проверьте network name, chain ID, нативную монету комиссии и историю кошелька. Ошибка сети особенно опасна при депозите на биржу, даже если формат адреса 0x совпадает.

Pending, success и failed в receipt

До включения в блок транзакция pending и может не иметь receipt. После исполнения receipt содержит статус: success или failed. Успешный статус означает, что верхнеуровневый вызов завершился без revert. Failed означает, что изменения состояния откатились, но комиссия за вычисления обычно списана.

Не путайте failed с отсутствующей транзакцией. Она существует в блоке и имеет хэш, однако ожидаемое действие не выполнено. Перед повтором выясните причину: недостаточный gas limit, условие контракта, пауза токена, неверные параметры, недостаточный баланс или нарушение allowance.

Nonce и очередь операций одного адреса

Каждая исходящая EVM-транзакция аккаунта имеет nonce. Сеть обрабатывает их последовательно. Если операция с меньшим nonce зависла, более поздние транзакции того же адреса могут оставаться pending, хотя их gas price выше. Обозреватель показывает nonce и иногда предупреждает о pending-предшественнике.

Для замены используют тот же nonce и более конкурентную комиссию. Создание новой операции с другим nonce не разблокирует очередь. Пользователь должен применять функцию Speed Up или Cancel в своём кошельке, а не подписывать инструкции неизвестного сайта.

Gas limit, gas used и effective gas price

Gas limit ограничивает объём вычислений, gas used показывает фактическое потребление, а effective gas price — цену единицы после механики базовой и приоритетной комиссии. Общий fee вычисляется из использованного gas и цены. Высокая комиссия не гарантирует успех, если контракт завершился revert.

При out of gas операция failed и всё выделенное вычисление может быть израсходовано. Увеличивать gas limit нужно по оценке кошелька, а не произвольно уменьшать ради экономии. Для обычного токен-перевода неожиданно высокая оценка может указывать на нестандартный или вредоносный контракт.

Native transfer и token transfer: почему поле Value может быть нулевым

При отправке ETH поле Value содержит нативную сумму. При переводе ERC20 пользователь вызывает контракт токена, поэтому верхнеуровневое Value часто равно нулю, а реальное движение отображается в Token Transfers или logs. Новичок может увидеть 0 ETH и ошибочно решить, что USDT не отправлен.

Сверьте событие Transfer: контракт, from, to и token amount. Если token transfer отсутствует, успешная транзакция могла быть approve, swap, bridge-действием или другой функцией. Название метода и decoded input помогают понять, что именно подписал пользователь.

Approve не является переводом токена

Approve выдаёт spender разрешение тратить токены владельца в пределах лимита. Баланс сразу не переходит получателю, хотя транзакция может иметь success и комиссию. Мошеннические сайты часто убеждают пользователя, что approve нужен для получения выплаты, а затем используют allowance для списания активов.

В обозревателе отличайте метод approve от transfer или transferFrom. Если выдали неизвестное разрешение, отключите dApp, отзовите allowance через проверенный инструмент и оцените перенос активов. Не вводите seed-фразу в сервис «отмены транзакции».

Internal transactions и traces

Смарт-контракт может отправлять нативную монету другим контрактам и адресам во время исполнения. Такие движения не являются отдельными подписанными пользователем транзакциями, но обозреватели показывают их как internal transactions или traces. Они помогают понять обмен, вывод из bridge и сложную DeFi-операцию.

Внутреннее движение следует читать в контексте исходного хэша. Статус верхней транзакции и trace вместе показывают результат. Если весь вызов reverted, промежуточные изменения откатываются, даже если trace отображает попытки исполнения.

L2, bridge и два этапа подтверждения

Перевод между Ethereum и L2 часто включает транзакцию в исходной сети и отдельное сообщение или доказательство в целевой. Один TxID подтверждает только свой этап. Депозит в rollup может появиться после обработки сообщения, а вывод в Ethereum — требовать дополнительного периода или claim-транзакции.

Сохраняйте оба хэша и bridge order ID. Проверяйте официальный интерфейс моста и обозреватели обеих сетей. Не отправляйте повторный bridge-перевод, если исходная транзакция success, а целевая часть ещё обрабатывается: сначала найдите message status и требования claim.

Replaced, cancelled и dropped в EVM

Pending-транзакцию можно заменить другой с тем же nonce и более высокой комиссией. Если новая отправляет нулевую сумму самому себе, кошелёк может назвать её Cancel, хотя в блокчейне это обычная замена. Старый хэш перестаёт быть активным, а обозреватель связывает операции по nonce.

Dropped может означать, что узлы удалили транзакцию из очереди или приняли замену. Баланс для исходной операции не списывается окончательно, кроме уже подтверждённых комиссий других транзакций. Ищите confirmed-операцию с тем же nonce, прежде чем повторять перевод.

Как проверять USDT и другие ERC20-токены

Сначала убедитесь, что контракт официальный для выбранной сети. Затем проверьте decimals и Token Transfer. Получатель в событии должен совпадать с депозитным адресом, а amount — с ожидаемой суммой после комиссии вывода. Сам transaction To обычно является контрактом токена и не должен совпадать с адресом получателя.

Если биржа принимает USDT только в другой сети, успешный ERC20-перевод на тот же 0x-адрес может потребовать ручного восстановления. Сохраните хэш и не взаимодействуйте с токеном на адресе биржи самостоятельно. Только площадка контролирует приватные ключи депозитного адреса.

Как проверить транзакцию TRON и перевод USDT-TRC20

Transaction ID и execution receipt в TRON

В TRON основная транзакция ищется по transaction ID. Для смарт-контрактного вызова нужно смотреть не только raw data, но и receipt или transaction info, где указаны execution result, fee, Energy usage и сообщение об ошибке. Факт принятия broadcast не гарантирует включение и успешное исполнение.

Если обозреватель показывает SUCCESS, переходите к разделу token transfers и проверяйте контракт. Если FAILED, комиссия или ресурсы могли быть израсходованы, но USDT не переместился. Повтор без анализа Energy, fee limit и состояния контракта создаёт вторую неудачную операцию.

TRX transfer и TRC20 contract call

Обычный перевод TRX меняет баланс нативной монеты. USDT-TRC20 передаётся вызовом смарт-контракта, поэтому на странице транзакции видны contract execution и событие Transfer. Эти операции имеют разную стоимость ресурсов и разные поля. Успешный перевод небольшого TRX не подтверждает отправку USDT.

В карточке USDT сверяйте официальный контракт, адрес from, адрес to и amount. Если актив не отображается, откройте token transfers. Некоторые обозреватели показывают вызов TriggerSmartContract отдельно от понятного пользовательского события.

Energy, Bandwidth и сжигание TRX

TRON использует Bandwidth для размера транзакции и Energy для выполнения смарт-контракта. Ресурсы можно получить через стейкинг или делегирование; при недостатке часть затрат оплачивается сжиганием TRX. Receipt показывает фактическое потребление и fee. На бирже эти детали скрыты за фиксированной комиссией вывода.

Failed-транзакция может потратить TRX или ресурсы. Не делайте вывод, что средства украдены, только по уменьшению TRX. Сначала проверьте result и token transfer. Для глубокой оценки сети используйте материал OneMagic о комиссии USDT-TRC20, Energy и TRX.

Адрес получателя и контракт USDT

Адрес TRON обычно начинается с T, но это не доказывает поддержку конкретного токена. В transaction call поле contract address указывает на контракт USDT, а фактический получатель зашифрован в параметрах и выводится в token transfer. Не отправляйте токены на адрес контракта вместо адреса человека или биржи.

Поддельный TRC20-токен может называться USDT. Сверьте контракт с официальным источником и депозитной страницей получателя. Если сумма пришла неизвестным токеном, не подписывайте swap или approve по ссылке из описания актива.

Подтверждение TRON и статус биржевого депозита

После включения транзакции сеть продолжает формировать блоки и фиксировать состояние. Биржа сама определяет число подтверждений, после которого начисляет депозит. Порог зависит от актива и текущего риска. Обозреватель может показывать success раньше, чем внутренний баланс площадки обновится.

Проверьте минимальный депозит и временную доступность сети. Если адрес и контракт верны, а порог достигнут, создайте обращение получателю с TxID, скрином страницы депозита и аккаунтом назначения. Не отправляйте ещё одну сумму «для активации».

Internal transfer биржи и отсутствие TRON TxID

Перевод между пользователями одной площадки может выполняться внутри системы без транзакции TRON. В этом случае сервис показывает internal transfer ID. Он не появится в публичном обозревателе. При выводе на внешний T-адрес должен появиться настоящий transaction ID после обработки.

Если контрагент обещал on-chain USDT, но прислал только внутренний номер, попросите карточку операции и уточните площадку получателя. Внутренний перевод действителен лишь внутри конкретной системы и не доказывает движение средств на ваш личный адрес.

Ошибка insufficient Energy и failed contract execution

Кошелёк может оценить недостаток ресурсов до отправки либо создать транзакцию с ограничением, которого не хватит для контракта. В receipt появится failed и сообщение, связанное с Energy, fee limit или revert. USDT останется на адресе, но часть TRX может быть списана.

Пополните ресурс только через понятный способ и перепроверьте оценку. Не арендуйте Energy у первого Telegram-бота и не передавайте подпись с неизвестными разрешениями. Потребность в ресурсах не требует seed-фразы или доступа к кошельку третьего лица.

Как доказать TRC20-перевод

Сохраните TxID, result SUCCESS, token transfer, контракт USDT, адреса, amount, timestamp и fee. Для биржи добавьте депозитный адрес, минимум и сеть TRON. Если сервис просит видеодоказательство, показывайте вход в собственный кошелёк и переход к публичному хэшу без раскрытия seed-фразы.

При споре полезно приложить две ссылки на независимые обозреватели. Различия интерфейса не меняют данные сети. Если один индексатор временно не видит свежую транзакцию, второй помогает отделить задержку сайта от отсутствия операции.

Как проверять транзакции и сообщения в TON

Почему TON сложнее простой модели «один TxID — один перевод»

TON построен вокруг аккаунтов и асинхронных сообщений. Пользователь отправляет внешнее сообщение кошельку, кошелёк создаёт транзакцию и исходящее внутреннее сообщение, которое вызывает транзакцию получателя или токен-кошелька. Одно пользовательское действие может образовать trace из нескольких связанных узлов.

Поэтому проверка только первой транзакции иногда показывает, что сообщение отправлено, но не раскрывает итоговый результат у получателя. Хороший обозреватель визуализирует trace, входящие и исходящие сообщения, комиссии и действия. Для платежа важно дойти до конечного адреса и token transfer.

Hash, logical time и адрес аккаунта

В TON точная ссылка на транзакцию может включать адрес аккаунта, logical time и hash. Некоторые интерфейсы позволяют искать по хэшу, другие — по адресу и истории. Сохраняйте полную ссылку из кошелька, потому что один текстовый фрагмент без контекста иногда сложнее найти через другой индексатор.

Logical time отражает порядок событий в асинхронной системе и помогает пагинации истории. Пользователю не нужно рассчитывать lt вручную, но при обращении к API или поддержке полезно передать hash и lt вместе с адресом.

Toncoin transfer и jetton transfer

Toncoin — нативный актив аккаунта, а USDT и другие jetton-токены используют отдельные jetton wallet-контракты. Перевод jetton может включать сообщение от пользовательского кошелька к его token wallet, затем сообщение token wallet получателю и уведомления. Баланс токена меняется не в том же поле, что Toncoin.

В обозревателе найдите действие Jetton Transfer или token transfer, проверьте master-контракт, отправителя, получателя и amount. Успешное списание Toncoin на комиссию не доказывает перевод USDT, если trace завершился ошибкой на одном из последующих этапов.

Comment и payload в TON-платежах

Комментарий может быть обычным текстом, идентификатором заказа или payload для сервиса. Перевод на правильный адрес без нужного комментария достигнет аккаунта, но автоматическая система не определит клиента или счёт. Это похоже на memo в кастодиальных депозитах.

Проверяйте comment в trace или decoded message. Если он отсутствует, не отправляйте повтор автоматически. Получатель может зачислить платёж вручную по hash, сумме и времени. Поддержке передают адрес, hash, lt и ожидаемый комментарий.

Bounce и возврат сообщений

В TON сообщения могут быть bounceable. Если контракт назначения не принимает вызов, часть средств после вычета комиссий может вернуться обратным сообщением. Пользователь видит исходящее действие, но итоговый баланс получателя не увеличивается. Trace показывает направление возврата и причину на уровне фаз исполнения.

Нельзя оценивать результат только по слову completed в кошельке отправителя. Проследите всю цепочку сообщений. Если средства вернулись, не пытайтесь «дотолкнуть» тот же message: исправьте адрес, состояние аккаунта, payload или сумму комиссии.

Masterchain, shardchain и задержка индексатора

TON использует шардинг, а обозреватели получают данные через indexer. Свежая транзакция может появиться в одном интерфейсе раньше другого. Это не меняет состояние сети. Официальный низкоуровневый explorer и крупные индексаторы показывают разные уровни детализации, особенно traces и распознанные действия.

Если кошелёк выдал hash, но сторонний explorer временно ничего не показывает, проверьте официальный интерфейс и историю адреса. Не вводите seed-фразу в сайт, который обещает «синхронизировать TON-транзакцию». Публичные данные доступны без доступа к кошельку.

Почему получатель видит Toncoin, но не видит USDT

Возможны разные адреса token wallet, неподдерживаемый jetton master, скрытый токен в интерфейсе или незавершённый trace. Сначала проверьте jetton action и официальный master. Затем убедитесь, что приложение получателя отображает этот токен и работает в mainnet, а не testnet.

Если токен пришёл на личный адрес, но не виден, добавление правильного актива в интерфейс может решить отображение. Если депозит отправлен бирже, самостоятельно управлять её token wallet нельзя — требуется заявка на ручное зачисление.

Как собирать доказательства TON-перевода

Сохраните адрес исходного кошелька, адрес назначения, hash, lt, trace ID или ссылку, сумму Toncoin или jetton, master-контракт, comment и комиссии. Для сложного платежа сделайте скрин trace целиком и отдельный скрин конечного действия. Это помогает поддержке понять, на каком сообщении возникла проблема.

Не ограничивайтесь уведомлением Telegram или кошелька. Оно может показывать только инициированное действие. Публичный trace — более сильное доказательство фактического исполнения и доставки сообщения.

Как проверить транзакцию Solana по signature

Signature как идентификатор транзакции Solana

В Solana транзакция содержит одну или несколько подписей. Первая подпись используется как уникальный идентификатор для поиска. Кошелёк обычно называет её transaction signature или TxID. Это длинная строка base58, которая отличается от hex-хэшей EVM и Bitcoin.

Копируйте signature полностью. Если приложение показывает сокращённое значение, откройте детали. Официальный Solana Explorer и другие надёжные интерфейсы позволяют найти операцию по подписи без подключения кошелька.

Processed, confirmed и finalized

Solana использует уровни commitment. Processed означает, что узел обработал транзакцию в своём текущем форке; confirmed даёт более сильное подтверждение голосами кластера; finalized указывает на максимально закреплённое состояние по правилам сети. Сервисы сами выбирают уровень, достаточный для зачисления.

Не считайте processed равным окончательному депозиту. Для крупной операции дождитесь уровня, который требует получатель. Если RPC одного сервиса отстаёт, разные обозреватели могут кратковременно показывать разные статусы.

Success и Program Error

Транзакция Solana атомарна: если одна инструкция завершается ошибкой, изменения остальных инструкций откатываются. Fee за подписи всё равно списывается. В meta поле err показывает отсутствие или наличие ошибки, а log messages помогают определить программу и причину.

Не повторяйте операцию только потому, что баланс уменьшился на небольшую сумму SOL: это могла быть комиссия failed-транзакции. Сначала прочитайте error, program log и token balance changes. Исправьте аккаунты, лимиты, blockhash или данные инструкции.

Recent blockhash и истечение транзакции

Обычная транзакция содержит recent blockhash и должна быть обработана в ограниченном окне. Если подпись создана, но отправка произошла слишком поздно или RPC не доставил пакет, транзакция может истечь и никогда не появиться как подтверждённая. Кошелёк должен сформировать новую транзакцию с новым blockhash.

Старая signature не подтверждает перевод, если getTransaction возвращает null и статус не найден. Не пытайтесь повторно broadcast устаревшие байты через неизвестный сайт. Используйте функцию повторной отправки в исходном кошельке, которая создаёт корректное новое сообщение.

Instructions и программы

Операция Solana включает набор инструкций для системной программы, Token Program, Associated Token Program, swap-программы и других контрактов. Обозреватель декодирует их и показывает transfer, create account, close account или swap. Для проверки токена нужно найти инструкцию перевода и изменения token balances.

Успешное создание associated token account не равно отправке нужной суммы. В одной транзакции оба действия могут быть объединены, но иногда пользователь подписывает только подготовительную операцию. Сверяйте post token balance и destination token account.

Mint и подлинность SPL-токена

В Solana токен определяется mint address. Тикер и логотип являются метаданными и могут быть скопированы мошенником. При проверке USDT, USDC или другого актива сверяйте mint с официальным источником и страницей депозита. Token account принадлежит владельцу и хранит конкретный mint.

Если destination wallet верен, но mint другой, получатель не получил ожидаемый актив. Биржа может не поддерживать такой токен и не зачислить его автоматически. Сохраните signature и обратитесь к получателю, не подписывая предложенные третьими лицами «возвратные» транзакции.

Associated Token Account и адрес получателя

В интерфейсе пользователь обычно вводит основной wallet address, а программа направляет токен в associated token account, вычисленный для владельца и mint. Обозреватель может показать destination token account, который не совпадает с введённым адресом. Это нормально, если owner этого token account — нужный кошелёк.

Проверяйте связь owner и token account, а не делайте вывод только по отличию строк. Для биржевого депозита следуйте адресу, который выдала площадка; не создавайте token account вручную на её behalf.

Priority fee, compute units и congestion

Базовая комиссия зависит от подписей, а приоритетная — от параметров compute budget. Высокая загрузка может увеличить конкуренцию и привести к задержке доставки, но истёкшая транзакция не становится pending навсегда как классическая Bitcoin-операция. Она требует новой подписи и blockhash.

Обозреватель показывает fee, compute units consumed и инструкции приоритета. Не платите стороннему боту за «разморозку signature». Если операция finalized, ускорять нечего; если она истекла, нужен новый перевод из исходного кошелька.

Как доказать SPL-перевод или перевод SOL

Сохраните signature, commitment/status, slot, block time, from, destination owner, token account, mint, amount, fee и error. Для токена приложите pre/post token balances. Для биржи также нужен депозитный адрес и подтверждение поддерживаемой сети Solana.

Если один RPC возвращает null, включите поиск истории или откройте другой надёжный explorer. Краткая разница между индексаторами возможна, но finalized-транзакция должна воспроизводиться через архивные данные.

Почему TxID не находится или транзакция успешна, но деньги не зачислены

Выбран неправильный обозреватель или сеть

Это самая частая причина «не найдено». USDT мог быть отправлен через TRON, BNB Smart Chain или Solana, а пользователь ищет хэш в Ethereum. Адреса EVM выглядят одинаково, а тикер токена не указывает сеть. Вернитесь к карточке вывода и проверьте network.

Если контрагент прислал ссылку, не полагайтесь только на домен. Сверьте название сети и поля страницы. Поддельный explorer может показывать выдуманный статус. Публичный хэш должен находиться в независимом известном обозревателе той же сети.

Скопирован номер заявки вместо TxID

Внутренний ID часто короче, содержит дефисы или префиксы и не соответствует формату сети. Откройте подробности вывода и найдите Transaction Hash, TxID, On-chain ID или Explorer. Если такого поля нет, вывод ещё не был отправлен либо выполнен внутренне.

Не просите поддержку «найти транзакцию в блокчейне» только по order ID. Передайте внутренний номер сервису, а после broadcast запросите внешний хэш. Это разграничивает ответственность отправляющей площадки и сети.

Транзакция создана, но не broadcast

Некоторые кошельки показывают локальную запись сразу после подписи, даже если RPC не принял пакет. Причиной может быть потеря соединения, истёкший blockhash, отклонение узлом или временный сбой. Без появления на независимых узлах операция не является публичной.

Проверьте статус в исходном приложении и возможность retry. Не отправляйте новый платёж, пока не ясно, может ли старый всё ещё быть принят. В Bitcoin локально созданную транзакцию можно повторно broadcast, а в Solana истёкшая требует нового blockhash и подписи.

Хэш сокращён или повреждён

Один пропущенный символ полностью меняет идентификатор. Мессенджер может обрезать длинную строку, вставить пробел или преобразовать регистр там, где это важно для представления. Копируйте значение кнопкой из приложения и передавайте в кодовом блоке или отдельной строке.

Если доступен только скриншот, попросите текст. OCR и ручной набор ненадёжны. Поддержка также быстрее обрабатывает копируемый хэш, чем изображение.

Индексатор обозревателя отстаёт

Explorer не является самим блокчейном. Он индексирует данные узлов и может временно задерживать свежие блоки, traces или token events. Сравните официальный низкоуровневый обозреватель, второй независимый сервис и историю адреса. Если все источники пусты, вероятность задержки ниже.

Не подключайте кошелёк для «принудительной индексации». Индексатор обновляется без действий пользователя. Сайт, требующий подпись для показа публичной транзакции, опасен.

Success в блокчейне, но неправильный актив

Транзакция может успешно доставить TRX вместо USDT, ETH вместо ERC20 или токен с поддельным контрактом. Биржа видит поступление на адрес, но её система не начисляет ожидаемый актив. Проверяйте не только статус и сумму, но token contract, mint или jetton master.

Не пытайтесь обменять неизвестный токен на адресе биржи. Приватный ключ принадлежит площадке. Создайте заявку на recovery и приложите публичные данные. Возможность восстановления зависит от технической поддержки сети и политики сервиса.

Сумма ниже минимального депозита

Публичный перевод может быть полностью успешен, но биржа не начислит баланс, если полученная сумма меньше опубликованного минимума. Некоторые площадки суммируют последующие депозиты, другие требуют ручную заявку или не восстанавливают малые суммы. Правило проверяется до отправки.

Не доплачивайте автоматически, пока не прочитаете условия. Второй депозит может не объединиться с первым. Сохраните оба TxID и уточните точный механизм поддержки.

Неверный или отсутствующий memo, tag, comment

Актив поступает на общий адрес сервиса, но внутренний получатель не определяется. В блокчейне всё выглядит успешно. Для ручного зачисления площадка проверяет TxID, сумму, адрес и принадлежность аккаунта. Иногда требуется видео из отправляющего кошелька или тестовый перевод по официальной инструкции.

Не публикуйте документы и полную банковскую информацию в открытом чате. Используйте официальный тикет. Seed-фраза никогда не нужна для проверки memo.

Порог подтверждений ещё не достигнут

Обозреватель уже показывает блок, но площадка ждёт больше подтверждений или более высокий commitment. Внутренний статус может называться confirming, pending confirmations или processing. Это нормальный промежуточный этап, если число подтверждений растёт и сеть работает.

Сравните текущую глубину с порогом на странице депозита. Если глубина давно выше, а статус не меняется, переходите к поддержке получателя. Приложите время, хэш и скрин порога.

Сеть или депозит временно приостановлены

Биржа может оставить старый адрес активным, но приостановить автоматическое зачисление во время обновления кошелька. Транзакция достигает on-chain адреса, однако обработка откладывается до восстановления сервиса. Страница статуса и уведомление аккаунта помогают отличить это от ошибки пользователя.

Не отправляйте дополнительные депозиты в период приостановки. Сохраните доказательства и следите за официальным статусом. Сотрудник поддержки не должен просить перевод на «новый безопасный адрес» в личном сообщении.

Баланс зачислен не в тот внутренний раздел

На бирже актив может появиться в Funding, Spot, Unified, Trading, Earn или другом счёте. TxID и депозит успешны, но пользователь смотрит только один раздел. Проверьте историю депозитов и общий баланс, затем выполните бесплатный внутренний transfer, если это предусмотрено.

Не создавайте on-chain вывод между разделами одной биржи. Внутреннее перемещение обычно не требует сетевой комиссии и TxID. Если актив заблокирован в Earn, марже или ордере, сначала завершите соответствующую операцию.

Доказательства, безопасность и обращение в поддержку

Минимальный пакет доказательств транзакции

Сохраните полный TxID, сеть, актив, контракт или mint, адреса, сумму, время, статус, комиссию и подтверждения. Для биржевой операции добавьте внутренний ID, страницу депозитного адреса, memo и историю аккаунта. Для обменника — номер заявки, курс, срок и переписку.

Скриншоты полезны, но не заменяют текстовые данные. Формируйте папку с понятными именами и отдельный краткий реестр. Подробный чек-лист есть в статье какие доказательства перевода сохранить.

Как написать обращение без лишней информации

Начните с короткой хронологии: дата и время, актив, сеть, сумма, откуда и куда отправлено, TxID, текущий статус в обозревателе и проблема в аккаунте. Затем перечислите приложения. Это позволяет специалисту сразу сопоставить on-chain и внутреннюю запись.

Не отправляйте seed-фразу, приватный ключ, полный пароль, коды 2FA или резервные коды. Маскируйте ненужные банковские данные. Поддержка может запросить KYC через защищённую форму, но не должна просить секреты кошелька.

Почему скриншот «Success» может быть подделан

Изображение легко отредактировать, а фейковый сайт может имитировать explorer. Проверяйте хэш самостоятельно. Настоящая публичная транзакция воспроизводится по идентификатору и показывает согласованные адреса, сумму и время. Нельзя отпускать товар, криптовалюту или доступ только по картинке.

Если контрагент отказывается дать полный TxID, это сильный стоп-сигнал. Для внутренних переводов требуйте запись из официального приложения и проверяйте поступление в собственном аккаунте, а не уведомление отправителя.

Фишинговые обозреватели и запрос подключения кошелька

Чтение публичных данных не требует approve, connect wallet или sign message. Мошенническая страница может показать выдуманную ошибку и предложить «синхронизацию», «возврат» или «разблокировку» через подпись. Результатом становится выдача allowance или вредоносная транзакция.

Открывайте explorer из официальной документации сети, кошелька или биржи. Проверяйте домен и сертификат. Не устанавливайте расширение по всплывающей подсказке и не загружайте APK из сообщения поддержки.

Проверка TxID не является AML-проверкой

Обычный обозреватель показывает движение средств, но не присваивает надёжную юридическую оценку происхождению адресов. AML-сервис использует дополнительные метки, кластеры и риск-категории. Наличие success не означает, что депозит не попадёт на compliance review.

Для значимой сделки заранее проверяйте контрагента и сохраняйте происхождение средств. Общий алгоритм рисков описан в статье что проверить перед криптопереводом.

TxID в банковском или налоговом пакете документов

Хэш связывает криптовалютную часть с биржевым ордером, банковской оплатой и последующей продажей. В реестре фиксируют дату, актив, сеть, сумму, курс, комиссии, адреса и назначение операции. Для P2P добавляют чек и данные ордера, для биржевой торговли — отчёт сделки.

Один TxID без объяснения экономического смысла недостаточен. Он подтверждает движение актива, но не стоимость приобретения и не сторону банковского расчёта. Документы нужно соединить хронологически.

Когда обращаться к отправителю, а когда к получателю

До появления публичного TxID отвечает отправляющий сервис: он контролирует очередь вывода и проверки безопасности. После success на правильный адрес основная зона проверки переходит к получателю, который управляет зачислением. При failed причина находится в транзакции, кошельке или контракте.

Такое разделение экономит время и исключает пересылку между поддержками. В обращении прямо указывайте, какой этап уже доказан. Если вывод завис одновременно с обменником или банковским платежом, используйте общий алгоритм диагностики зависшего криптоперевода.

Когда нужен тестовый перевод

Тест снижает риск ошибки адреса, сети, memo и минимального депозита. Он особенно полезен при новом кошельке, крупной сумме или неизвестном маршруте. Но тест должен превышать минимум получателя и учитывать две комиссии. Слишком маленькая проба может не зачислиться и создать ложный вывод, что адрес неверен.

После успешного теста заново сверяйте адрес перед основной суммой. Буфер обмена и депозитные реквизиты могут измениться. Не копируйте адрес из истории без проверки актуальной страницы получателя.

Почему нельзя публиковать полный финансовый профиль вместе с TxID

Сам TxID публичен, но сочетание хэша, имени, телефона, банковской выписки и скриншотов аккаунта связывает личность с адресами и балансами. Перед публикацией в форуме маскируйте персональные данные. Полный пакет передавайте только официальной поддержке или уполномоченному специалисту.

Seed-фраза и приватный ключ не нужны даже в закрытом тикете. Если они раскрыты, кошелёк считается скомпрометированным, и активы переводят на новый безопасно созданный адрес.

Финальная матрица решения по статусу

Проверка завершается не словом success, а ответом на пять вопросов: правильная ли сеть; существует ли транзакция; успешно ли исполнена; правильны ли актив, адрес и метка; выполнил ли получатель внутреннее зачисление. Только сочетание этих ответов определяет дальнейшее действие.

Не выполняйте повторный перевод под давлением. Сначала зафиксируйте текущую операцию и найдите точку разрыва. Повтор оправдан только когда старая транзакция точно failed, expired или заменена и средства снова доступны, либо когда поддержка официально объяснила порядок исправления.

Кейс: биржа пишет «вывод завершён», но TxID отсутствует

Статус Completed внутри биржи иногда означает завершение внутренней процедуры, но при настоящем on-chain выводе должна существовать внешняя транзакция. Откройте расширенные детали и найдите network, fee и transaction hash. Если площадка использовала внутренний transfer другому пользователю той же системы, публичного хэша действительно не будет, однако получатель должен увидеть запись в своей истории.

Если адрес назначения был внешним, а TxID не выдан, создайте тикет отправляющей площадке. Приложите withdrawal ID, адрес, сеть, сумму и время. Не обращайтесь к сети или получателю: без broadcast они не могут найти операцию. Не оплачивайте «повторную сетевую комиссию» по реквизитам из личного сообщения.

Кейс: USDT-TRC20 имеет SUCCESS, но биржа не начислила депозит

Сначала откройте token transfer и убедитесь, что контракт соответствует USD₮ в TRON, адрес получателя совпадает с депозитным адресом, сумма выше минимума, а сеть не была приостановлена. Затем сравните глубину подтверждений с требованием площадки. Само поле SUCCESS подтверждает исполнение контракта, но не внутреннее начисление конкретному аккаунту.

В обращении укажите TxID, адрес, сумму, время, сеть и UID аккаунта. Если депозитный адрес общий или сервис использует дополнительные реквизиты, приложите их. Не отправляйте небольшой второй перевод без письменного правила о суммировании депозитов: некоторые системы обрабатывают каждую операцию отдельно.

Кейс: EVM-транзакция success, но пользователь подписал approve

На странице может быть зелёный статус и нулевая сумма нативной монеты. Откройте Method и decoded input. Если указано approve, increaseAllowance или permit, токен не был отправлен получателю — был выдан доступ spender. Проверьте размер allowance, домен dApp и последующие transferFrom из адреса.

При неизвестном spender отзовите разрешение проверенным инструментом и оцените перенос активов на новый адрес. Не подписывайте «cancel approval» по ссылке из сообщения. Сетевую транзакцию approve нельзя отменить после подтверждения, но разрешение можно изменить новой безопасной операцией.

Кейс: ETH-перевод завис из-за предыдущего nonce

В истории адреса найдите самую раннюю pending-транзакцию. Даже если последующий перевод имеет более высокую максимальную комиссию, валидаторы не могут исполнить nonce с пропуском. Кошелёк может показывать несколько ожидающих операций, но блокирующей является первая по порядку.

Используйте Speed Up или Cancel именно для её nonce. После подтверждения замены очередь продолжит обработку. Не создавайте ещё десять переводов с новыми nonce: это расширяет очередь и усложняет расчёт доступного баланса. Сохраняйте хэш замены вместе со старым для поддержки.

Кейс: Solana signature не находится после отправки

Проверьте, вернул ли кошелёк подтверждённую signature или только локально сформировал транзакцию. Если recent blockhash истёк до обработки, RPC может не вернуть confirmed transaction. В отличие от долгого Bitcoin mempool, такая операция не ожидает бесконечно: её нужно сформировать заново с актуальным blockhash.

Сначала убедитесь, что исходный баланс не изменился кроме возможной комиссии другой операции. Повтор выполняйте через исходный кошелёк. Сайт, предлагающий «реанимировать signature» подключением кошелька, не нужен и может быть фишинговым.

Кейс: TON-платёж дошёл на адрес, но заказ не опознан

Откройте trace и найдите comment или payload. Если адрес и сумма верны, но комментарий отсутствует, blockchain-перевод завершён, а проблема находится в системе получателя. Зафиксируйте hash, lt, адрес, сумму и время. Поддержка может вручную сопоставить платёж с заказом.

Не отправляйте идентичную сумму повторно до ответа. Для нового перевода создаётся новая транзакция и новое обязательство. Если получатель просит тест, это должно быть официальное действие в тикете, а не личное сообщение неизвестного администратора.

Кейс: Bitcoin TxID заменён через RBF

Обозреватель старой транзакции показывает replacement или конфликт. Перейдите к новому TxID и найдите output на адрес получателя. Сумма могла остаться прежней, а комиссия увеличиться; но отправитель технически мог изменить получателя или сумму до подтверждения. Поэтому доказательством является только актуальная confirmed-версия.

Для торговой сделки не передавайте товар по нулевому подтверждению, если транзакция replaceable. После включения в блок наблюдайте требуемую глубину. Сохраняйте обе ссылки: они объяснят поддержку, почему первоначальный хэш не подтверждён.

Кейс: перевод выполнен в неправильной EVM-сети на тот же 0x-адрес

Формат адреса совпадает, но актив находится в другой цепи. Если получатель — ваш некастодиальный кошелёк и вы контролируете тот же приватный ключ, токен часто можно увидеть после добавления сети и официального контракта. Если адрес принадлежит бирже, восстановление возможно только её техническими средствами.

Не импортируйте seed-фразу в случайное приложение ради доступа к другой сети. Используйте проверенный кошелёк и чистое устройство. Для биржи сразу передайте hash, chain ID, contract и destination address; не пытайтесь вывести токен с её адреса самостоятельно.

Кейс: транзакция содержит пакет выплат

Биржа или сервис может объединить множество получателей в одну Bitcoin-транзакцию либо выполнять batch-вызов смарт-контракта. Общая сумма и число адресов выглядят непривычно. Найдите конкретный output или event на свой адрес. Один общий TxID может подтверждать выплаты десяткам пользователей.

При обращении указывайте индекс output или конкретный token transfer, если обозреватель его показывает. Скрин только верхней части страницы с общей суммой не доказывает вашу выплату. Поддержке нужна точная строка, связывающая TxID с вашим адресом.

Кейс: мультиподписной кошелёк показывает операцию, но она ещё не отправлена

В multisig-системе сначала создаётся proposal или safe transaction hash, затем собираются подписи участников, и только после исполнения появляется on-chain transaction hash. Внутренний proposal ID нельзя искать как TxID. Статус «awaiting confirmations» относится к подписям владельцев, а не к подтверждениям блокчейна.

Для проверки запросите execution transaction hash. До него средства не покинули multisig. В корпоративном регламенте храните proposal ID, список подтверждений, инициатора, исполнителя и итоговый on-chain хэш как связанные записи.

Кейс: аппаратный кошелёк подписал перевод, но приложение не показало TxID

Подписание на устройстве создаёт криптографическое разрешение, но программный интерфейс ещё должен передать транзакцию узлу. При сбое сети подпись могла остаться локально. Проверьте историю приложения и публичный адрес. Не вводите recovery phrase в браузер для «завершения синхронизации».

Если транзакция не broadcast, повторите через официальное приложение после проверки адреса и суммы на экране устройства. Если появилась другая операция, сравните nonce или UTXO, чтобы не создать двойную выплату.

Кейс: обменник прислал TxID, но сумма отличается от заявки

Сравните ожидаемую сумму после курса и комиссии с фактическим output или token transfer. Возможны удержание сетевой комиссии, пересчёт плавающего курса или частичная выплата. Условия должны быть зафиксированы в заявке до перевода. TxID доказывает фактическую сумму, а не справедливость расчёта.

Сохраните страницу заявки, заявленный курс, резерв, срок и переписку. Если выплата меньше без предусмотренного правила, направьте претензию сервису. Не переводите доплату по новым реквизитам, пока не установлена причина расхождения.

Кейс: подтверждённая транзакция попала на AML-проверку

Площадка видит success и правильный адрес, но приостанавливает депозит для compliance review. TxID здесь нужен для анализа происхождения, однако решение зависит от истории адресов, контрагента и документов. Подготовьте ордер приобретения, банковский чек, выписку биржи и объяснение маршрута.

Не пытайтесь «очистить» историю переводом между своими адресами. Публичная цепочка сохраняется, а дополнительные hops могут усложнить объяснение. Отвечайте последовательно и не подделывайте документы.

Кейс: транзакция нужна для налогового регистра

В таблице учёта TxID связывают с датой, активом, сетью, количеством, курсом, рублёвой стоимостью, комиссией и основанием. Для swap требуется входящий и исходящий актив, а для bridge — хэши обеих сетей. Внутренний transfer между своими счетами не должен ошибочно считаться продажей.

Экспорт обозревателя полезен как техническое доказательство, но стоимость приобретения подтверждают ордера и фиатные документы. Храните неизменяемую копию отчёта и ссылку, поскольку интерфейс обозревателя может измениться, хотя данные сети останутся.

Кейс: автоматический мониторинг депозитов через API

Бизнес не должен полагаться только на экран explorer. Система запрашивает транзакцию через RPC или indexer, проверяет сеть, статус, актив, адрес, сумму и требуемую финальность, затем связывает событие с заказом. Для TON анализируется trace и comment, для EVM — logs, для Solana — instructions и token balances.

Нужно учитывать реорганизации, задержки индексатора, повторные webhook и идемпотентность. Один и тот же TxID нельзя начислить дважды. Ручной кабинет должен показывать исходные данные и историю решений, чтобы специалист мог восстановить логику зачисления.

Кейс: корпоративная выплата и разделение ролей

В организации инициатор создаёт заявку, проверяющий сверяет адрес и сеть, подписант подтверждает на защищённом устройстве, а бухгалтер фиксирует TxID и основание. Такой процесс снижает риск подмены реквизитов и упрощает аудит. Для крупной суммы полезны address whitelist и тестовая транзакция.

Журнал должен включать внутренний payment ID и внешний TxID. При замене операции через RBF или nonce сохраняется связь версий. Секретные ключи не прикладывают к бухгалтерским документам; достаточно публичных данных и утверждённого регламента.

Проверка транзакции по TxID — это последовательное сопоставление данных, а не одно нажатие на ссылку. Сначала определяется сеть, затем подтверждается существование и результат операции, после чего сверяются адреса, актив, контракт, сумма, метка и требования получателя. Разные блокчейны используют разные модели: Bitcoin — inputs, outputs и mempool; EVM — nonce, receipt, gas и logs; TRON — contract result и ресурсы; TON — messages и traces; Solana — signature, commitment и instructions.

Безопасный пользователь не передаёт секреты кошелька ради просмотра публичной транзакции, не доверяет скриншотам без независимой проверки и не повторяет платёж до установления причины. При споре сохраняйте полный хэш и хронологию. При переводе между биржами заранее проверяйте сеть, minimum deposit и memo по инструкции как перевести USDT с одной биржи на другую.

Если операция ещё не начата, сначала проверьте кошелёк, сеть и адрес получателя. Полезные пошаговые материалы: проверка USDT-кошелька перед переводом и безопасная отправка криптовалюты на кошелёк. Такая подготовка значительно дешевле последующего восстановления неправильной сети, адреса или метки.