Внутри операции из 12 000 honeypot-контрактов на Avalanche

Это расследование началось с чистки базы данных.

Разбирая несколько тысяч подозрительных токенов в мониторинговой базе Prelisted, я заметила группу контрактов на Avalanche, у которых totalSupply() возвращал одно и то же до абсурда специфичное число:

100,018,746,193,931,376,489,308,801,730

Не круглое число. Не 1,000,000,000 × 10¹⁸. Что-то странно точное, повторяющееся у множества с виду не связанных друг с другом токенов. Первой моей догадкой было, что я наткнулась на шаблон массового деплоя — какой-то бот, штампующий дешёвые ERC-20.

Так и оказалось. Но интересен был не сам шаблон.

Это одно число привело меня к 5746 контрактам одного и того же семейства, к тысячам вызовов занесения в чёрный список, нацеленных на отдельные он-чейн-адреса, к зашитому в код кошельку с админ-правами, которые переживают отказ от владения контрактом, и ко второму кошельку, который раз за разом создавал новые токены из воздуха и сливал их через DEX.

Затем кластер стал больше. Более ранняя кампания на Avalanche из 2025 года — задеплоенная другим кошельком и с другим числом supply — как выяснилось, несёт в своём байткоде тот же самый зашитый адрес-менеджер. Вместе известная часть операции на Avalanche охватывает теперь около 12 000 контрактов за период не менее 13 месяцев.

И это не история из прошлого. Кошелёк-менеджер всё ещё рассылал вызовы занесения в чёрный список 12 августа 2026 года. Дренажный кошелёк совершил свой последний своп 14 августа 2026 года — в день, когда я финализировала эти заметки.

Затем, создавая карту финансирования, я обнаружила ту же операцию, запущенную в сети Polygon.

Это история о том, как странный артефакт в базе данных превратился в живое, многосетевое расследование он-чейн-мошенничества — и о том, как именно устроена его часть на Avalanche. Вот вся машина на одной схеме; остальная часть статьи — о том, как каждый её элемент был найден и проверен.

---

Число привело к тысячам контрактов

Константа supply была той самой ниточкой. Я выполнила обратный поиск по ней во всей сети Avalanche и вытащила каждый контракт, чей totalSupply() совпадал байт в байт.

5746 контрактов. Все задеплоены в течение двухнедельного окна в апреле–мае 2026 года плотным кластером из трёх кошельков. Все — исключительно на Avalanche: у этих деплоеров ноль транзакций в сетях BNB Chain, Ethereum, Polygon, Arbitrum, Base и Optimism. И все они разделяют один и тот же скомпилированный рантайм-байткод: solc 0.8.19, ~8428 байт (16 856 hex-символов), различаясь лишь аргументами конструктора, задающими имя и символ каждого токена.

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

Тикеры выдавали замысел. Извлечение symbol() из всех 5746 контрактов дало 5137 уникальных тикеров, и они группируются по узнаваемым категориям-приманкам: имитации стейблкоинов (DAI, DUSD, VUSD, USDM, TUSD, FDUSD), мемкоин-культура (PEPE, WOJAK, ANDY, MOG, GOAT), имитация брендов (GME, TON, BTCST, BRLA) и названия L1/L2 (DOT, ADA, MATIC, ARB, OP, SUI, SEI). Набор сконструирован так, чтобы поймать того, кто ищет реальный проект по тикеру в DEX-агрегаторе: вводишь «PEPE», попадаешь на один из PEPE-контрактов конвейера — и покупаешь.

(Для протокола: 16,3% тикеров совпадают с проектами, которые в тот или иной момент имели листинг на бирже первого эшелона, против базового уровня 12,1% для случайных токенов на ту же дату. Умеренный перекос — оператор гнался за горячими нарративами, а не систематически опережал будущие листинги.)

Итак, у меня был склад токенов-двойников. Очевидный вопрос: что на самом деле внутри них?

---

Затем я открыла байткод

Ни у одного из этих контрактов не было верифицированного исходника на Snowscan, поэтому я вытащила рантайм-байткод напрямую и прогнала его через декомпилятор. Под стандартным на вид ERC-20 каждый контракт содержит три функции, которых нет в стандарте ERC-20:

Все три защищены одинаково — они срабатывают, только если вызывающий это номинальный owner или конкретный адрес, зашитый прямо в байткод контракта:

// доступ: только зашитый менеджер (Address A) или текущий владелец
require(msg.sender == 0xce54c175880ff4edaa5d80b2dc66dda0e34a36ac
     || msg.sender == _owner);

Этот зашитый адрес — 0xce54c175…, я буду называть его Address A, — и есть вся суть. Он впечатан в скомпилированный код каждого контракта, поэтому его нельзя удалить, передать или отозвать. Тот, у кого есть ключ от Address A, обладает постоянными админ-правами над всеми этими токенами — независимо от того, что показывает видимый owner().

Вот самая важная функция, proof(uint256), прямо из декомпиляции:

require(msg.sender == 0xce54c175880ff4edaa5d80b2dc66dda0e34a36ac
     || msg.sender == _owner);
_totalSupply += amount;
_balanceOf[msg.sender] += amount;
emit Transfer(address(0), msg.sender, amount);

Ничто в названии proof не намекает на то, чем она является: это минт без ограничений. Вызывающий может создать любое количество токена себе на баланс в любой момент. И при этом запускается событие Transfer с нулевого адреса — так что в блок-эксплорере минт неотличим от обычного первичного выпуска токена.

Это скрытый контролёр. Теперь — ловушка.

---

Как на самом деле работает honeypot

Execute(address) добавляет адрес во внутренний маппинг чёрного списка. Approved(address) — удаляет. Обе защищены доступом только для Address A или владельца. Само по себе наличие чёрного списка не является чем-то необычным — он есть у множества легитимных токенов.

Ханипотом это делает то, что чёрный список творит внутри логики перевода. Во внутренней функции _transfer есть одна проверка:

require(!mapping_1[sender], 'Recipient is Gwei');

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

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

1. Создание honeypot-токена — Address A зашит в него с самого рождения.
2. Добавление ликвидности на DEX, чтобы токен можно было купить.
3. Реальные пользователи покупают. Покупку ничто не блокирует.
4. Занесение покупателей в чёрный список вызовом Execute(target) — теперь они не могут продать.
5. Минт свежей партии токенов оператору через proof(huge_amount).
6. Сброс этой свежей партии в пул, вывод AVAX, переход к следующему.

Отказ от владения здесь ничего не значит

Эти контракты реализуют стандартную функцию renounceOwnership(). Кто угодно — включая автоматический инструмент оценки доверия — может проверить «отказались ли от владения?» и получить обнадёживающее «да». Этот ответ — обманка, потому что каждая привилегированная функция также принимает Address A:

require(msg.sender == 0xce54c175880ff4edaa5d80b2dc66dda0e34a36ac
     || msg.sender == _owner);

Найти вредоносный код — это одно. Найти того, кто активно им пользуется, — совсем другое.

---

Затем я нашла дренажный кошелёк

Устройство контрактов показало, что в ловушку может попасть кто угодно. Следующий кошелёк показал это в деле.

Отслеживание того, кто на самом деле вызывал proof() и функции свопа, привело ко второму кошельку — 0x6b89422…, Address B. В период с 5 мая по 14 августа 2026 года он совершил 30 758 транзакций. Сгруппированные по методу, они складываются в крайне повторяющийся паттерн:

Основной цикл, прогоняемый по контракту за контрактом, всегда состоит из одних и тех же трёх шагов:

1. approve — разрешить роутеру LFJ тратить баланс токена X, принадлежащий Address B.
2. proof(…) — сминтить свежую порцию токена X на Address B.
3. swapExactTokensForNATIVE(X → AVAX) — продать свежий минт, отправить AVAX на кошелёк-сборщик.

Затем повторить. Тысячи раз.

И Address B — не только дренажер. Верификационный проход выявил то, что я поначалу упустила: Address B — это ещё и один из зашитых ключей-менеджеров. При выборке из 100 контрактов апреля–мая Address A впечатан в 65 из них, а Address B — в остальные 35, причём каждый встречается по десять раз в виде PUSH20-константы, с идентичными админ-правами. Оператор использует два ключа-менеджера и делит между ними инвентарь. То, что сперва выглядело как пробел в покрытии Address A, оказалось просто вторым ключом, делающим свою половину работы.

---

10 054 свопа — и отпечаток объясняет сам себя

Сложите оба варианта свопа — и получится, что Address B совершил 10 054 успешных свопа по выводу средств. Каждый продавал свежесминченные токены за AVAX, и в каждом было выставлено amountOutMin = 0 — принять всё, что даст пул, никогда не отменять сделку из-за цены. Это массовое извлечение, а не аккуратная торговля.

Затем я посмотрела, сколько минтил каждый вызов proof(). Каждый раз это было одно и то же число:

18,746,193,931,376,489,308,801,730

Это число выглядело знакомым. И неудивительно — оно всё это время сидело внутри отпечатка, с которого началось всё расследование.

   100,018,746,193,931,376,489,308,801,730  ← константа supply, которую я заметила первой
−  100,000,000,000,000,000,000,000,000,000  ← ровно 100 000 000 000 × 10¹⁸
=       18,746,193,931,376,489,308,801,730  ← ровно столько минтится при каждом сливе

«До абсурда специфичное» число сминченной партии вовсе не было случайным. Это круглая база в 100 миллиардов плюс фиксированное количество, которое оператор выводит, — сконструированное так, чтобы одно и то же количество минта можно было переиспользовать на каждом контракте. Аномалия, по которой я нашла конвейер, была той самой аномалией, которая заставляла конвейер работать, — и она объясняет сама себя лишь в момент слива. Улика и механизм всё это время были одним и тем же числом.

Куда уходит AVAX? ABI-декодирование параметра to в calldata свопа даёт ответ: при каждом успешном сливе выручка уходит на один адрес — 0xeec6d5994b7ed166e5cf7f5444d4bf0aaebce92d, кошелёк-сборщик, который я обозначила как C2 Root Funder.

По состоянию на 14 августа 2026 года на кошельке-сборщике находится 462.79 AVAX, относимых к сливам через DEX-роутеры (≈ $20 000 по ценам апреля 2026 года), — 406.65 через роутер LFJ V2.2 плюс 56.14 через Trader Joe V1. Ещё 294 AVAX поступили с двух других кошельков, чья связь с операцией пока расследуется, поэтому я не включаю их в итог по сливам.

Траектория показательна. Май 2026 года был индустриальным всплеском — примерно 8500 минтов, 8400 одобрений и 8400 свопов за один месяц. Июнь продолжился примерно на пятой части этого объёма. Июль и август упали до однозначного числа транзакций в день. Операция сворачивается, но не выключена: последний слив Address B был 14 августа 2026 года.

---

Я думала, остальные «спят». Я ошибалась.

Это тот момент, когда моя первая теория рассыпалась, — и его стоит оставить, потому что именно исправление ошибки открыло истинный масштаб.

Поначалу я проверила 5746 контрактов по обычным источникам данных о пулах — DexScreener, Trader Joe V1, Pangolin V1 — и почти ничего не нашла. У трёх контрактов был проиндексированный пул; у остальных — ничего. Я списала конвейер как гигантский склад спящих поддельных токенов, большинство из которых даже не подключены к DEX.

Этот вывод был ошибочным, и 10 054 свопа Address B это доказали. Токены не спали — я просто смотрела не на тот DEX. Оператор построил всё на LFJ Liquidity Book V2.2, чьи пулы концентрированной ликвидности («bin»-пулы) ненадёжно индексируются розничными инструментами безопасности, которые я проверила первыми. Как только я пошла по транзакциям Address B в LFJ V2.2, якобы пустой склад оказался хранилищем более чем десяти тысяч реальных, успешных сливов.

Это же объясняет, почему сливы почти невидимы для обычных пользователей. Односторонний bin-пул LFJ — весь в токене, без AVAX, в каком и остаётся каждый пул после слива — по-прежнему существует он-чейн, но торговать через него фактически нельзя. Для DexScreener это выглядит так, будто там ничего нет. Для оператора — это выполненная работа.

---

Анатомия одной ловушки

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

Из 5746 контрактов ровно три несут сейчас проиндексированный пул на DEX: BRLA (имитация бразильского стейблкоина на реал), USTC (Terra Classic USD) и BTCST (Bitcoin Standard Hashrate Token). У каждого — небольшой пул на Trader Joe, около $625 ликвидности, без сколько-нибудь значимого объёма, созданный в тот же день, когда был задеплоен токен. Реальные названия брендов, крошечные живые пулы, ожидающие своего часа.

Именно эти три оператор всё ещё навещает. Ещё 10–12 августа 2026 года Address A рассылал вызовы Execute(address) против всех трёх — BRLA 12 августа в 09:22 UTC, USTC 12 августа в 02:02 UTC, BTCST 11 августа в 04:52 UTC. Каждый такой вызов добавляет конкретный адрес в список «не может продать» живого, доступного для покупки токена.

Он-чейн проверяем каждый шаг, кроме намерения жертвы: контракт был задеплоен, пул создан, Address A занёс конкретные адреса в чёрный список, Address B сминтил через proof() и продал минт сборщику — всё с временными метками и хешами транзакций. Единственное, что я не утверждаю, — что каждый занесённый в чёрный список адрес был непременно невинным покупателем, собиравшимся продать; подтверждение этого требует истории покупок по каждому адресу, а это отдельная задача. Но устройство вокруг них задокументировано полностью — и на этих трёх контрактах оно работает до сих пор, прямо в этом месяце.

---

Это была не первая кампания

Развёртывание апреля–мая 2026 года — назовём его Кампания 2 — было тем, куда меня привёл отпечаток. Но Address A появился раньше.

История вызовов Execute(address) у Address A уходит корнями в июль 2025 года, против совершенно другого набора контрактов: 4887 токенов, задеплоенных одним кошельком (0x3eb8d668…) с июля по октябрь 2025 года. Назовём это Кампанией 1. В ней используются другие числа supply — в основном константа 490,255… и чистая 100,000,000,000 × 10¹⁸ — и слегка иная раскладка байткода. На первый взгляд — не связанная с остальным партия скамов.

Вот только байткод говорит об обратном. Я сделала выборку из 30 контрактов Кампании 1 и обнаружила Address A зашитым во всех 30. Тот же мастер-ключ, впечатанный в кампанию на девять месяцев старше, задеплоенную другим кошельком, с другими константами supply и другим путём финансирования. Две кампании, у которых нет ничего общего на графе адресов, — кроме единственного адреса, вкомпилированного в код каждого контракта. Это один оператор.

Между двумя кампаниями на Avalanche Address A разослал 4999 вызовов Execute(address) против одних только контрактов Кампании 1 за июль–октябрь 2025 года — систематическое занесение в чёрный список промышленного масштаба. (Были ли все 4999 целей подтверждёнными покупателями — это, опять же, отдельный вопрос по каждому адресу, который я не закрывала для всего набора.)

Июньская партия-продолжение 2026 года — Кампания 2B, ещё 1585 контрактов — завершает картину по Avalanche. Стоит уточнить, чем 2B является, а чем нет. Начиная с июня, Address B переключил свои свопы с обычного пути роутера на вариант, совместимый с fee-on-transfer, и я поначалу заподозрила, что июньские токены добавили механизм burn-налога. Диф байткода пяти контрактов Кампании 2A против пяти контрактов Кампании 2B это опроверг: они байт в байт идентичны, за исключением аргументов конструктора — тот же размер рантайма, те же 28 селекторов функций, никаких новых переменных состояния, никакого fee-on-transfer или burn-налога на уровне токена. Смена пути роутера была операционной, а не изменением шаблона. Я это отмечаю, потому что моим первым подозрением было обратное.

---

Шаблон тоже был не их

Ещё одно, что раскрыл байткод: оператор не писал этот ханипот. Он его форкнул.

Контракт — это форк общедоступного honeypot-набора, который исследователь безопасности Дев Свонсон (Dev Swanson) опубликовал 5 июня 2023 года как учебный артефакт по мошенничеству — код, призванный помочь аудиторам распознавать ровно этот паттерн «враждебный минт / ловушка-чёрный-список». Набор содержит всю форму, которую использует оператор: гейт минта proof(uint256), пару чёрного списка Execute/Approved, ловушку в _transfer, даже конкретные небрежные артефакты — параметр с опечаткой _uzer, неродные для носителя строки ошибок «Gwei-ed» и «tronglisted», обманчивое сообщение «Recipient is Gwei» и bool _decimals, который должен быть uint8.

Это важно по двум причинам.

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

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

---

Точка атрибуции через Binance

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

Оба кошелька, с которых стартует Кампания 1, были профинансированы в пределах двухминутного окна выплатами по выводу средств клиентов Binance:

2025-07-22 13:47 UTC   Binance 85  → Address A    (0xce54c175…)    1.996 AVAX   tx 0x88741657…
2025-07-22 13:49 UTC   Binance 110 → деплоер К1   (0x3eb8d668…)   97.996 AVAX   tx 0x5100523d…

Binance 85 и Binance 110 — это собственные кошельки Binance для пакетных выплат (помечены как таковые на Snowscan и в нашей базе). Такие выводы средств исполняются из этой общей внутренней инфраструктуры. Так что блокчейн доказывает реальное происхождение: два операционных кошелька — деплоер, построивший 4887 контрактов, и мастер-ключ, зашитый во все из них, — были профинансированы выводами средств клиентов Binance с разницей в две минуты. Один — операционный запас ≈ $2700, достаточный, чтобы покрыть газ на деплой всей кампании; другой — пополнение ≈ $53 для кошелька-менеджера.

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

Деплоеры Кампании 2 финансировались аккуратнее — через кластер промежуточных кошельков, подпитываемых мелкими DEX-свопами, которые скрывают CEX-происхождение. Более чистый след Binance у Кампании 1 — это якорь, а присутствие Address A в обеих кампаниях — то, что переносит идентичность между ними.

---

12 000 контрактов, 13 месяцев, всё ещё активна

Подведём итог по стороне Avalanche:

Это не спящая инфраструктура, каталогизируемая задним числом. Последняя транзакция Address A была 12 августа 2026 года; последний слив Address B — 14 августа 2026 года. Вызовы занесения в чёрный список всё ещё уходят против живых пулов BRLA/USTC/BTCST. Кем бы ни был оператор, он всё ещё разрабатывает свой инвентарь в момент этой публикации — и почти наверняка есть более ранние или промежуточные кампании, которые я пока не выявила.

---

Затем Avalanche привёл к Polygon

Создавая карту финансирования, я обнаружила ту же архитектуру контрактов, работающую параллельно в сети Polygon, — под управлением 0xbfd4a51c…, активную с 8 июля 2025 года, то есть за 14 дней до начала Кампании 1 на Avalanche. Polygon не был копией операции на Avalanche. Он был пилотом.

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

Поэтому я декодировала calldata fee-on-transfer-свопов по выводу средств у менеджера Polygon, чтобы увидеть, куда на самом деле уходил выведенный POL. 37 из его 42 декодированных свопов (88%) направляют выручку на 0xeec6d5994b7ed166e5cf7f5444d4bf0aaebce92d — тот самый C2 Root Funder, который получает выведенный AVAX с Avalanche. (Сначала я видела «0 POL» на сборщике: средства идут через подконтрольный оператору роутер-посредник, поэтому не появляются в реестре внутренних транзакций самого кошелька-менеджера — пока не декодируешь параметр to внутри вызова роутера.)

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

Краткий анонс того, что охватывает Часть 2:

• 624 контракта конвейера на Polygon за 13 месяцев, под управлением одного ключа, с использованием чистого шаблона supply 100B × 10¹⁸ из Кампании 1.
• 1154 вызова занесения в чёрный список, с более экономной моделью «деплой широко, слив выборочно» — менеджер напрямую слил пока лишь ~40 контрактов, оставив остальные как инвентарь под управлением чёрного списка.
• Путь слива через fee-on-transfer, который Avalanche перенял лишь в июне 2026 года, был стандартом на Polygon с первого дня — Polygon натренировал оператора на этом механизме за год до того, как его применили на Avalanche.

---

Почему это важно

Форма этой операции — 12 000 контрактов, 13 месяцев, две сети — делает несколько тезисов по инструментам безопасности предметными:

1. renounceOwnership() — не сигнал доверия. Любой инструмент, оценивающий контракт по «отказались ли от владения?», побеждается зашитым бэкдором. Эти контракты получают лучшую оценку, когда владение отозвано.
2. Обман через имена функций работает. proof(uint256) выглядит как проверка, а это минт без ограничений. Execute(address) звучит как триггер, а это чёрный список. Сканеры, сопоставляющие по именам или сигнатурам функций, — а не инспектирующие, что реализация делает на самом деле, — пропустят эти контракты.
3. Снятие отпечатка с байткода ловит то, что упускают графы адресов. Две кампании с разными деплоерами, разными константами supply и разными графами финансирования незримо связаны одним адресом, вкомпилированным в каждый контракт. Кластеризуйте по константе-менеджеру и схожести байткода, а не по статусу владения отдельного контракта.
4. Следы CEX-KYC всё ещё работают даже когда более поздние кампании отмывают своё происхождение через DEX-переходы. Чистый вывод средств Binance у Кампании 1 — тот якорь, на котором держится остальное.

Более широкий вывод: пользователь, проверяющий любой из этих 12 000 токенов через ходовой инструмент безопасности, увидит отозванное владение, стандартные методы ERC-20 и никаких необычных прав владельца. Полагаясь только на эти сигналы, он может не иметь никакого указания на то, что весь класс токенов разделяет один зашитый бэкдор к мастер-кошельку. Только проверка происхождения уровня кластера — графы финансирования плюс сигнатуры байткода плюс поведение — делает эту структуру видимой.

---

Что защитники могут сделать прямо сейчас

Операция активна: вызовы чёрного списка на Avalanche по состоянию на 12 августа, сливы — на 14 августа 2026 года. Список действий по ролям:

Для продавцов кошельков и сканеров безопасности

(Rabby, MetaMask, Blockaid, De.Fi, GoPlus, Wallet Guard.) Снимайте отпечаток с рантайм-байткода шаблона-бэкдора — триада селекторов proof(uint256) + Execute(address) + Approved(address) на рантайме ~8428 байт должна помечаться красным независимо от того, что возвращает owner(). Помечайте известные константы-менеджеры 0xce54c175880ff4edaa5d80b2dc66dda0e34a36ac (Avalanche) и 0xbfd4a51c9f4c5b8109bdd462c8a57a5d268be3d0 (Polygon) как PUSH20-константы в байткоде. Детектируйте по семантике — запись в маппинг, защищённая require(msg.sender == <зашитый адрес> || msg.sender == _owner), является чёрным списком, как бы она ни называлась.

Безопасность LFJ и экосистемы Avalanche

Выявите оставшиеся живые пары Liquidity Book V2.2 для любого контракта конвейера из IOC-списка; рассмотрите трение на стороне LP или предупреждения в интерфейсе при совпадении с шаблоном. Любой новый деплой, несущий байткод бэкдора, следует считать вероятным продолжением этой операции — или копией того же публичного шаблона — и в любом случае помечать.

Комплаенс Binance

Два вывода средств от 2025-07-22 (13:47 UTC, 1.996 AVAX → 0xce54c175… через Binance 85; 13:49 UTC, 97.996 AVAX → 0x3eb8d668… через Binance 110) заслуживают проверки, а соответствующие записи об аккаунтах и выводах стоит сохранить. Эти два адреса напрямую связаны с 12 000+ действующих honeypot-контрактов в двух сетях.

Threat-intel и компании-сканеры

(Chainalysis, TRM, Elliptic, отделы trust & safety бирж.) Загрузите IOC-список в свои системы, пересчитайте исторические риск-оценки для любого контракта конвейера, получившего оценку «безопасно», и поищите сигнатуру шаблона в других сетях с подставленными адресами-менеджерами. Две сети подтверждены; Ethereum, BNB Chain, Arbitrum, Base и Optimism все стоит проверить.

Конечные пользователи

Считайте малозаметный токен на Avalanche или Polygon, который торгуется только на LFJ V2.2 (Avalanche) или на клоне Uniswap V2 (Polygon), непроверяемым, пока не сможете независимо подтвердить его происхождение — это площадки, используемые этой операцией. И для этих токенов отозванное владение — не гарантия; зашитый бэкдор полностью обходит владение.

---

Проверки, методология и ограничения

Короткая заметка о том, что доказано, а что выведено логически, — намеренно вынесенная за пределы истории выше.

Терминология. «Кампания 1 / 2A / 2B» — мои обозначения трёх наблюдаемых волн деплоя на Avalanche; «C2 Root Funder» — моё обозначение общего кошелька-сборщика. Все они определяются он-чейн-поведением, а не каким-либо самоописанием оператора.

---

Данные и воспроизведение

Публикацию сопровождает IOC-пакет:

• Все 5746 адресов контрактов Кампании 2 плюс 4887 целей вызовов Execute Address A из Кампании 1
• Полные графы деплоеров и спонсоров; истории активности Address A и Address B
• Декомпилированный ABI шаблона Кампании 2
• Эвристика детекта на ~30 строк, помечающая контракты конвейера по сигнатуре зашитого менеджера в рантайм-байткоде

Формат: CSV + JSON с версионируемой контрольной суммой SHA256, размещённые публично. Каждое утверждение выше можно независимо проверить или опровергнуть по этому пакету.

---

Одно число — вся система

То, что началось с единственного странного на вид числа supply, оказалось операционным отпечатком. Это одно число связало тысячи контрактов, два поколения инфраструктуры на Avalanche, живой дренажный кошелёк, общий кросс-чейн кошелёк-сборщик и более раннюю кампанию на Polygon, где тот же сценарий обкатали первым. Каждый контракт по отдельности был сделан так, чтобы выглядеть обычным — отозванное владение, стандартные методы ERC-20, ничего подозрительного. Операция стала очевидной лишь тогда, когда контракты рассмотрели как систему: сгруппировав их по адресу, вкомпилированному в каждый из них, а не оценивая токен за токеном.

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

---

Контекст серии

• Часть 1 (этот материал) — конвейер honeypot-контрактов «100B» на Avalanche
• Часть 2 — Polygon: параллельная, более ранняя операция того же оператора, связанная общим кошельком-сборщиком
• Часть 3 — волна мем-лаунчпадов апреля 2026 года и то, как всплеск деплоя этого оператора ненадолго приняли за легитимную активность лаунчпадов
• Часть 4 — открытие исходников защитного слоя: проверка происхождения кластеров, детект бэкдоров по байткоду и поведенческое подтверждение

---

Источники и заметки по методологии

• Метаданные контрактов: Etherscan V2 API (getcontractcreation, getsourcecode, txlist с глубокой пагинацией)
• Граф финансирования: txlist Etherscan V2 по каждому кошельку, с прослеживанием первых входящих транзакций, несущих ценность
• Он-чейн-состояние: eth_call для totalSupply()/symbol()/name()/owner() через Alchemy Avalanche RPC
• Байткод: eth_getCode через Alchemy, группировка по keccak256 + извлечение CBOR-метаданных
• Декомпиляция: library.dedaub.com на solc 0.8.19
• DEX-пулы: DexScreener, getPair Trader Joe V1 + Pangolin V1, фабрика LFJ Liquidity Book V2.2/V2.1
• Метки CEX-кошельков: публичные теги Snowscan для Binance 85 и Binance 110
• Анализ сливов Address B: txlist Etherscan V2 с фильтром по method ID, успех по isError, ABI-декодирование получателя to в calldata
• Кросс-чейн-связь: ABI-декодирование параметра to в fee-on-transfer-свопах менеджера Polygon