Анализ криптовалют и on-chain-рисков

Что вообще даёт on-chain-анализ

Публичные блокчейны — Bitcoin, Ethereum, TRON и совместимые сети^1, 12 — устроены так, что каждая подтверждённая транзакция навсегда записана в открытый реестр. Это ключевое отличие от классической банковской аналитики: не нужно запрашивать выписку у контрагента, история переводов уже доступна и проверяема кем угодно. On-chain-анализ превращает этот поток записей в структуру: кто кому платил, какими суммами, через какие промежуточные адреса и насколько близко находится кошелёк к уже известным рисковым сущностям.

Важно сразу зафиксировать границу. Прозрачность здесь — про псевдонимность^2, 3, а не про анонимность и не про раскрытие личности. В реестре видны адреса и потоки, но не имена. Связь «адрес → реальный субъект» появляется только из дополнительных источников: меток бирж, публичных раскрытий, данных KYC, открытых расследований. Поэтому on-chain-картина — это сильная, но неполная половина анализа.

Отслеживание потоков

Базовая операция — проследить движение средств от адреса к адресу. В сетях с моделью UTXO (Bitcoin) транзакция тратит конкретные «непотраченные выходы» и создаёт новые; в account-based-сетях (Ethereum, TRON) меняется баланс счёта и фиксируются вызовы контрактов. И там, и там можно строить граф: вершины — адреса, рёбра — переводы⁶ с суммой и временем. На этом графе видно концентрацию потока, транзитные узлы и точки входа/выхода в фиатный контур через биржи.

Кластеризация адресов и её пределы

Один субъект почти никогда не пользуется одним адресом. Чтобы собрать кошельки в кластер, в UTXO-сетях применяют эвристику common-input-ownership^4, 5: если несколько входов потрачены в одной транзакции, предполагается, что приватными ключами от них распоряжается один владелец — иначе он не смог бы подписать их вместе. Эвристика рабочая и лежит в основе большинства промышленных систем, но это именно предположение, а не доказательство. Её ломают:

• CoinJoin и другие коллаборативные транзакции, где несколько независимых участников намеренно объединяют входы — общий вход больше не означает общего владельца.
• Кошельки бирж и кастодианов^7, 8, где входы тысяч клиентов сводятся в одну транзакцию; наивная кластеризация склеит их в один гигантский ложный кластер.
• Изменение change-адресов и сложные схемы консолидации, которые искажают границы кластера в обе стороны.

В account-based-сетях common-input-ownership неприменима в исходном виде: там нет множественных входов. Кластеризация опирается на другие признаки — паттерны депозитных адресов, поведение контрактов, повторяющиеся газовые источники, — и ещё сильнее зависит от качества внешних меток. Практический вывод один: кластер — это гипотеза с вероятностью ошибки, а не факт, и обращаться с ним нужно соответственно.

Связь с известными сущностями

Сам по себе граф потоков мало что говорит, пока к нему не привязаны метки. Ценность появляется, когда адрес связывается с распознанной сущностью: горячим кошельком биржи, сервисом-миксером, известным мошенническим адресом из открытых расследований или адресом под санкциями (например, из публичных списков OFAC SDN¹¹). Близость кошелька к таким узлам по графу — один из самых информативных признаков. Качество всей системы напрямую упирается в качество и актуальность этих справочников: устаревшая или ошибочная метка отравляет скоринг для всех адресов вокруг неё.

Риск-скоринг кошелька

Риск-скоринг отвечает на прикладной вопрос: насколько подозрителен конкретный адрес или транзакция. Это не ярлык «чистый / грязный», а оценка вероятности, собранная из нескольких групп признаков:

• История транзакций. Возраст адреса, число и объём операций, регулярность, доля входящих и исходящих потоков.
• Контрагенты. С кем адрес взаимодействовал напрямую и какая доля оборота приходится на помеченные рисковые сущности.
• Близость к рисковым адресам по графу. На каком расстоянии (в числе переводов — «хопов») находятся миксеры, санкционные или мошеннические узлы, и какая доля средств прослеживается до них.
• Поведенческие паттерны. Структура сумм, временные всплески, типичные для автоматизированного «дробления» переводы, признаки транзитных схем.

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

AML-эвристики и где они ломаются

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

• Миксеры и CoinJoin.⁹ Объединяют средства многих участников и перемешивают выходы так, что однозначное соответствие «вход → выход» теряется. После качественного микширования трассировка переходит из точной в вероятностную, а часто становится практически бесполезной на уровне отдельной монеты.
• Cross-chain bridges. Перевод актива из одной сети в другую рвёт единый граф: средства «исчезают» в одном блокчейне и «появляются» в другом. Без сопоставления событий по обе стороны моста цепочка обрывается.
• Privacy-coins. Сети вроде Monero по дизайну скрывают суммы, отправителей и получателей. Классический on-chain-анализ к ним почти неприменим — там нет открытого графа потоков, который можно обойти.

Отсюда главный методологический вывод: on-chain-сигналов недостаточно. Там, где трассировка обрывается, её нужно достраивать off-chain-контуром — данными KYC, IP- и устройствами, бизнес-контекстом операции, информацией от бирж по запросу. On-chain отвечает на вопрос «куда пошли средства», off-chain — «кто за этим стоит и зачем». Сильная система соединяет оба, а не подменяет один другим.

Сигналы и их ограничения

Чтобы скоринг был честным, рядом с каждым сигналом полезно держать его ограничение. Ниже — компактная сводка типичных признаков (значения порогов условны и зависят от сети, профиля сервиса и риск-аппетита).

Как это встраивается в комплаенс-процесс

On-chain-аналитика приносит пользу, когда становится частью процесса, а не разовой выгрузкой. Рабочая конфигурация обычно включает несколько слоёв.

1. Нормализация источников

Сводим on-chain- и off-chain-контур: транзакции сетей, справочники меток (биржи, миксеры, санкционные списки), внутренние данные клиента и события протоколов — к единой модели адресов и потоков.

2. Графовая аналитика и скоринг

Строим граф, считаем признаки близости к рисковым узлам и поведенческие метрики. Система обычно совмещает прозрачный слой правил (rule-based) и ML-слой: правила дают объяснимость и аудиторский след, модель помогает ловить нетривиальные комбинации¹⁰.

3. Пороги, алерты и эскалация

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

4. Мониторинг и пересмотр

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

Минимальный пример: история адреса и простой скоринг

Ниже — наглядный псевдокод на Python. Он показывает логику, а не готовый продукт: обращение к API эксплорера (синтаксис эндпоинтов приведён в стиле Etherscan-подобных сервисов и требует уточнения по актуальной документации провайдера), построение списка контрагентов и наивная метрика близости к множеству рисковых адресов. Значения весов и порога условны и приведены для примера.

import requests

# Множество помеченных рисковых адресов (из справочника: миксеры,
# санкционные списки, известные мошеннические кошельки).
RISKY = {"0xRISK1", "0xRISK2"}  # условные адреса для примера

def fetch_transfers(address, api_key):
    # Etherscan-подобный эндпоинт списка обычных транзакций адреса.
    # Точные имена параметров сверяйте с документацией провайдера.
    url = "https://api.etherscan.io/api"
    params = {
        "module": "account",
        "action": "txlist",
        "address": address,
        "sort": "asc",
        "apikey": api_key,
    }
    data = requests.get(url, params=params, timeout=30).json()
    return data.get("result", [])

def counterparties(address, transfers):
    # Все адреса, с которыми взаимодействовал кошелёк.
    peers = set()
    for tx in transfers:
        peers.add(tx["to"])
        peers.add(tx["from"])
    peers.discard(address.lower())
    return peers

def risk_score(address, api_key):
    # Наивный скоринг: доля прямых контрагентов из списка рисковых.
    # Это лишь признак первого уровня (1 хоп), а не полный анализ.
    transfers = fetch_transfers(address, api_key)
    peers = counterparties(address, transfers)
    if not peers:
        return {"score": 0.0, "reason": "нет транзакций"}

    risky_hits = peers & RISKY
    proximity = len(risky_hits) / len(peers)

    # Порог условный; калибруется по доле ложных срабатываний.
    flag = proximity > 0.0
    return {
        "score": round(proximity, 3),
        "risky_peers": sorted(risky_hits),
        "flag": flag,  # повод для проверки, не доказательство
    }

Даже на этом уровне видны ограничения метода. Метрика смотрит только на прямых контрагентов (1 хоп) и не учитывает близость через цепочки переводов; не различает биржевой узел и адрес конечного злоумышленника; полностью зависит от полноты множества RISKY. Продакшен-система добавляет обход графа на несколько хопов с затуханием веса по расстоянию, дедупликацию кластеров, учёт сумм и времени, а также объяснение каждого балла. Но усложнение модели не отменяет исходного принципа: это вероятностная оценка, которую проверяет человек.

Частые ошибки

1. Считают объёмы и число транзакций, игнорируя структуру связей между адресами.
2. Принимают кластер или метку за факт, не закладывая вероятность ошибки.
3. Не документируют логику скоринга — и теряют доверие комплаенса и аудиторский след.
4. Опираются только на on-chain там, где трассировка уже оборвана миксером или мостом.
5. Не связывают сигналы с бизнес-контекстом клиента и тонут в ложных срабатываниях.

Что важно для заказчика

Клиенту нужен не поток сырых событий, а система, отвечающая на вопросы: где риск, насколько он значим, как его обосновать и что делать дальше. Поэтому корректный on-chain-проект заканчивается понятной структурой решений и зафиксированными ограничениями метода, а не выгрузкой адресов. Мы не обещаем «стопроцентного выявления» — честная цель состоит в том, чтобы поднять качество сигналов и сделать решения воспроизводимыми и объяснимыми.

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