Как читать транзакции Bitcoin и Ethereum: переводы, сдача и скрытые детали

Компания заплатила подрядчику в Bitcoin. Аналитик открыл транзакцию и увидел два адреса получателей. Второй платёж не согласовывали. Куда ушли деньги?

В другой ситуации компания отправила USDT в Ethereum, но в карточке транзакции указано 0 ETH. Получается, перевода не было?

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

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

Ethereum больше похож на банковский счёт: при переводе нужная сумма списывается с одного баланса и зачисляется на другой, без подбора «купюр» и сдачи. Это Account-модель, или модель счетов. При этом транзакция может не только переводить деньги, но и запускать программу — смарт-контракт, который выполняет сразу несколько действий.

Разберём, как эта разница влияет на проверку платежей, поиск связей между адресами и отслеживание средств.

UTXO - сокращение от Unspent Transaction Output, то есть «неизрасходованный выход транзакции». Проще говоря, это сумма BTC, полученная ранее и ещё не потраченная.

Представьте, что в кошельке лежат купюры на 5 000 и 1 000 рублей. Всего у вас 6 000 рублей, но для оплаты вы выбираете конкретные купюры.

Похожим образом Bitcoin-кошелёк может показывать баланс 0,8 BTC, который складывается из двух UTXO: 0,5 и 0,3 BTC. При оплате кошелёк использует один или несколько подходящих UTXO. Каждый выбранный UTXO расходуется целиком, а остаток можно вернуть сдачей.

В транзакции это выглядит так:

• Входы, inputs: ранее полученные UTXO, которые сейчас расходуются.
• Выходы, outputs: новые UTXO, которые создаются для получателей платежа и, если нужно, для сдачи.

Адрес и UTXO при этом не одно и то же: к одному адресу могут относиться несколько неизрасходованных выходов.

Рассмотрим условный пример. Компания использует UTXO на 1 BTC, чтобы заплатить подрядчику 0,3 BTC.


Change output - выход со сдачей. Кошелёк может направить её на новый адрес той же компании. Поэтому незнакомый адрес среди выходов ещё не означает нового контрагента. Такой механизм описан в документации Bitcoin.
В нашем примере платёж подрядчику составляет 0,3 BTC. Если принять сдачу за ещё один внешний платёж, отчёт существенно завысит сумму средств, ушедших из компании. Бухгалтерия такое творчество не оценит.

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

Если данных недостаточно, корректная формулировка: «предполагаемый выход сдачи», с объяснением основания.

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

Это эвристика общего контроля входов. Эвристика означает полезное правило для предположения, которое может оказаться неверным. Совместное расходование входов также называют co-spending.

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

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

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

В Account-модели средства учитываются через балансы и состояние аккаунтов. Аналогия с банковским счётом здесь ближе, чем с купюрами: при обычном переводе ETH баланс отправителя уменьшается, а получателя увеличивается. Понятия сдачи нет.

При этом балансы токенов, например USDT, учитываются в соответствующих смарт-контрактах.
Главная сложность в другом: одна транзакция может запустить несколько действий. Например, отправить токен в обменный пул, получить другой токен и распределить комиссию.
Поэтому при работе с Ethereum и другими сетями, совместимыми с EVM, полезно проверять три уровня.

1. Внешняя транзакция: что было отправлено на исполнение
Здесь видны отправитель, адрес назначения, передаваемое количество ETH и данные команды.
Поле to может содержать адрес контракта, которому поручено выполнить действие. Это не обязательно адрес конечного получателя денег. А поле value показывает количество передаваемого ETH, без комиссии, а не стоимость всех активов внутри операции. Эти поля описаны в документации Ethereum.

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

Обозреватели часто показывают часть этих действий в разделе Internal Transactions. Более подробную последовательность вызовов можно увидеть в трассировке исполнения. При этом вызов контракта не обязательно сопровождается переводом средств.
Практический смысл: если транзакция направлена в контракт, проверка не заканчивается на его адресе. Нужно понять, какие действия он выполнил и куда фактически отправил активы.

3. События контрактов: какие действия записаны в журнал
Events, или события - записи, которые контракт создаёт во время работы. Например, событие Transfer у ERC-20-токена содержит адрес отправителя, адрес получателя и сумму. На основе таких записей обозреватели формируют список переводов токенов.

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

Три уровня - это три способа изучить одну операцию. Они не означают, что в каждой транзакции обязательно есть внутренний перевод ETH и перевод токенов.

Компания отправляет подрядчику 1 000 USDT в сети Ethereum обычным переводом токена.
В карточке транзакции аналитик видит:


Компания обратилась к контракту USDT, чтобы он изменил токеновые балансы. Поэтому в To указан контракт, а фактического получателя USDT нужно искать в данных вызова и результате перевода.

Для подтверждения оплаты проверьте успешное исполнение, правильный контракт токена, адрес подрядчика и сумму. Одной строки Value: 0 ETH недостаточно. Комиссия за выполнение этой транзакции оплачивается отдельно в ETH.

Transaction - транзакция, отправленная в сеть. Transfer - перевод конкретного актива, который может происходить в рамках этой транзакции.

Отсюда три типичных ситуации:

• Обычный перевод токена: одна транзакция, один перевод.
• Обмен через протокол: одна транзакция, несколько переводов. Один актив уходит, другой приходит.
• Выдача разрешения, approve: транзакция разрешает расходовать токены, но сама по себе их не переводит. При этом комиссия за исполнение оплачивается.

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

Для финансовой сверки важно установить что ушло, что пришло и сколько составили комиссии. Для расследования дополнительно нужно понять, какие адреса получили активы и какую роль они выполняли.

Прежде чем написать «компания перевела средства контрагенту», пройдите короткую проверку:

1. Определите сеть и актив. BTC, ETH и USDT требуют разного прочтения операции.
2. Для Bitcoin разделите платёж, предполагаемую сдачу и комиссию. Не считайте каждый выход отдельным контрагентом.
3. Проверьте основания объединения адресов. Совместное расходование входов помогает анализу, но не доказывает одного владельца во всех случаях.
4. Для Ethereum изучите результат исполнения. Сопоставьте внешнюю транзакцию, необходимые внутренние вызовы и события нужных токенов.
5. Опишите экономический результат. Кто передал какой актив, кто его получил и что осталось неустановленным.

Хороший итог анализа можно объяснить без открытого обозревателя: «Компания заплатила подрядчику 0,3 BTC, остаток вернулся сдачей» или «Компания перевела подрядчику 1 000 USDT через контракт токена».

Если пока получается только «адрес взаимодействовал с адресом», стоит проверить детали до принятия решения.