Почему мы отказались от проекта на TRON: как выглядит address poisoning scam изнутри

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

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

Что насторожило в ТЗ

В техническом задании были пункты, которые в нормальных продуктах встречаются крайне редко — зато часто встречаются в описаниях скам-схем:

• Массовая генерация кошельков и хранение сид-фраз в базе данных.
• Подбор адресов, визуально похожих на настоящие — по шаблону вида 6…6 (например, совпадение первых и последних символов).
• Автоматическое пополнение кошельков и мгновенный вывод средств на «буферные» адреса.
• Уведомления по входящим переводам от суммы $1 — как триггер на событие.

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

Что такое address poisoning scam (и почему это важно)

Это классика под названием address poisoning: мошенники создают адреса, которые похожи на реальные адреса жертвы (обычно совпадают первые и последние символы). Далее они отправляют «пыльные» транзакции или взаимодействуют так, чтобы эти адреса попали в историю переводов.

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

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

Почему мы отказались

Я веду бизнес в блокчейне и IT и отлично понимаю, что одна и та же технология может использоваться по-разному. Но есть граница между нейтральной инфраструктурой и системой, которая по своей архитектуре и целям заточена под обман.

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

Если вы строите Web3-продукт: короткий чеклист

Чтобы не оказаться на тёмной стороне случайно (или под видом «аутсорса на блокчейн»), я бы обращал внимание на следующие сигналы:

• Требование хранить сид-фразы пользователей/кошельков в БД без внятной модели custody и комплаенса.
• Пожелания «генерировать похожие адреса», «подбирать по маске», «совпадение первых/последних символов».
• Логика «пополнить → сразу вывести», особенно на множество промежуточных адресов.
• Ориентация на триггеры по мелким входящим транзакциям, чтобы адрес попадал в историю.

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

Если вы работаете в разработке под блокчейн, поделитесь: сталкивались ли вы с похожими запросами? Как вы проверяете клиентов на этапе пресейла?