Адрес и сущность - не одно и то же: главная концепция onchain-аналитики

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

Адрес (address) - технический идентификатор в блокчейн-сети. По нему можно изучать операции, но сам по себе он не устанавливает личность пользователя, назначение инфраструктуры или принадлежность средств. Сродни номеру банковской карты, без контекста и других данных это просто цифры.

Сущность (entity) - человек, компания или сервис, с которым связаны адреса. В банковской аналогии это владелец карты: у него может быть несколько карт с разными номерами. Так и одна биржа или компания может использовать множество адресов для разных задач.

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

У одной сущности может быть много адресов. При этом один сервисный адрес может обслуживать операции множества клиентов. Поэтому правило «один адрес = один человек» не подходит для анализа.

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

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

Поэтому вопрос «риск адреса или риск сущности?» не требует выбора одного варианта. Проверка должна связать три уровня:

• Операция: что произошло, когда, с каким активом и на какую сумму.
• Адрес: какую функцию он выполняет и что показывает его история.
• Сущность: с кем связан адрес, чем это подтверждено и как влияет на решение.

Принадлежность к кластеру тоже требует проверки. Ошибка объединения может привести к тому, что чужая активность будет приписана проверяемому участнику.

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

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

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

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

Много входящих переводов, регулярные выплаты, быстрое перемещение средств дальше - сами по себе эти наблюдения ещё не объясняют, что делает адрес. Чтобы их интерпретировать, нужно понять, какую сущность он представляет и какую функцию выполняет.

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

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

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

Предположим, несколько адресов взаимодействуют с одним DEX-роутером (смарт-контракт, который автоматически находит оптимальный путь для обмена), через который выполняются обмены. Роутер относится к инфраструктуре протокола. Адреса пользователей обращаются к этой инфраструктуре, но от этого не становятся её частью.

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

• Адрес относится к инфраструктуре сущности: например, депозитный адрес входит в инфраструктуру биржи.
• Адрес взаимодействует с сущностью: например, пользователь отправляет средства на биржу или выполняет обмен через DEX.

Первое помогает определить роль адреса и того, кто им распоряжается. Второе описывает контакт. Для вывода об общем управлении адресами одного контакта недостаточно.

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

Так же нужно читать и разметку риска. Утверждения «адрес относится к инфраструктуре мошеннической схемы» и «адрес получил перевод из этой инфраструктуры» имеют разный смысл. В первом случае речь о принадлежности, во втором - о поступлении средств. Основания и последствия этих выводов нельзя смешивать.

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

Метка рядом с адресом помогает быстрее понять, с кем мы имеем дело. Но короткая подпись может скрывать разные основания: сервис сам опубликовал адрес, аналитики подтвердили его принадлежность или инструмент предположил её по характеру переводов.

Поэтому перед выводом важно выяснить: что именно известно об адресе и на чём это основано? Разберём несколько примеров.

1. «Биржа X» и «перевод на биржу X» - не одно и то же.
Допустим, инструмент показывает связь адреса с биржей. Посмотрите, что это за связь: адрес входит в её инфраструктуру или просто отправлял туда средства? Во втором случае оснований называть его биржевым адресом нет. Пользование сервисом не означает принадлежности к нему.

2. Метка «Exchange» ещё не говорит, какая именно это биржа.
Допустим, у адреса стоит общая метка «Exchange», без названия площадки. Она указывает на предполагаемый тип сервиса, но не устанавливает конкретную компанию. Аналогично, метка «Scam» сама по себе не объясняет, с какой схемой связан адрес и на каком основании.
Откройте подробности разметки: есть ли название сущности, описание, источник или пояснение аналитиков? Если дополнительных данных нет, не достраивайте вывод самостоятельно. В отчёте точнее написать «источник помечает адрес как биржевой; конкретная площадка не установлена», чем приписать его известной бирже по похожему поведению.

Тип сервиса, название сущности и основание связи с ней - разные сведения. Короткая метка не всегда содержит все три.

3. Две одинаковые метки могут оказаться одним подтверждением.
Вы проверили адрес в двух инструментах, и оба показывают «Сервис X». Это полезное совпадение, но они могли использовать один и тот же исходный источник.
Более убедительная проверка - найти дополнительное основание: например, прямое подтверждение сервиса или собственные документированные данные о взаимодействии с ним. Если происхождение меток неизвестно, не стоит описывать их как два независимых подтверждения.

4. Дата инцидента важна не меньше названия метки.
Допустим, адрес получил метку «скомпрометирован» после кражи в июне, а вы изучаете перевод за март. Нельзя автоматически приписать мартовскую операцию злоумышленнику: нужно выяснить, когда произошла компрометация и к каким операциям относится информация.

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

Если оснований недостаточно, сохраните это ограничение в выводе: «Источник относит адрес к сервису X; независимое подтверждение пока не найдено». Такая формулировка позволяет использовать метку в дальнейшей проверке, не выдавая её за установленную принадлежность.

Адрес - технический идентификатор, по которому мы видим операции. Сущность - человек, организация или сервис, с которым связан адрес. Кластер - группа адресов, объединённых по определённым основаниям. Обнаружить такую группу и установить, кто за ней стоит, - разные задачи.

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

Практический совет: перед выводом о риске закончите три предложения:

• Этот адрес выполняет роль…
• Мы относим его к этой сущности на основании…
• С проверяемой операцией или клиентом его связывает…

Если какое-то предложение пока нечем закончить, зафиксируйте пробел. Например: «Адрес относится к инфраструктуре биржи, но связь конкретного поступления с нашим клиентом не установлена».

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