Блог им. MarketologMarketologov
Этот разбор не о том, как «вернуть криптовалюту», и не о том, как оценивать доходность проекта. Здесь интереснее техническая сторона: какие артефакты могут указывать на рискованную схему, если криптопроект обещает высокую доходность, использует токен и работает через смарт-контракты.
В качестве кейса рассмотрим SPUSD и проект SoulPeg Labs. По материалам расследования, участникам предлагали вложения в USDC с обещанием 18% доходности в месяц. Вокруг проекта, согласно описанию кейса, было 931 холдер и предположительно 18,5 млн долларов вложений.
Такие цифры сами по себе не доказывают злоупотребление. Но они задают контекст: если проект обещает высокую регулярную доходность, архитектура токена и движение средств должны быть особенно прозрачными.
• сайт проекта и закрытые коммуникационные каналы;
• токен SPUSD в экосистеме BSC;
• пополнение через смарт-контракты;
• использование USDC как актива вложения;
• реферальная механика с вознаграждением за привлечение новых участников;
• цепочки транзитных кошельков;
• поддельные письма от имени Binance с требованием доплаты для «разморозки» средств.
Для технического анализа в подобных случаях важна не одна деталь, а совокупность признаков. Один рискованный параметр контракта может быть ошибкой дизайна. Несколько признаков вместе уже требуют более внимательной проверки.
По материалам кейса, анализ смарт-контрактов показал следующие признаки: отсутствие аудита в сети BSC, возможность менять код, наличие одного администратора и владельца, большое максимальное предложение с возможностью дополнительного выпуска, функции выпуска и сжигания токенов, изменение логики после деплоя.
В терминах threat modeling это означает, что пользовательский риск связан не только с рыночной ценой токена. Значимую роль играет governance-риск: кто контролирует параметры контракта, может ли владелец менять поведение системы и есть ли технические ограничения на выпуск или изменение логики.
По описанию кейса, после поступления средств на связанные контракты они конвертировались в USDC и выводились на транзитные адреса. Упрощенная схема выглядит так:
Пользователь -> смарт-контракт -> конвертация в USDC -> транзитные адреса -> консолидация средств
На этапе анализа важно не ограничиваться первым адресом. Если средства уходят через несколько промежуточных кошельков, полезно смотреть паттерны: частоту переводов, одинаковые суммы, связь адресов по времени, консолидацию, взаимодействие с биржами или мостами.
Отдельный интерес представляет вторая фаза: сообщения о «разморозке» средств. По материалам кейса, жертвам приходили письма от имени Binance с требованием пополнить счет в течение 48 часов. Внутри были ссылки на Telegram-чат с человеком, который представлялся Binance Angel.
С технической точки зрения это уже не on-chain артефакт, а слой социальной инженерии. Но для incident report его нельзя игнорировать. Именно такие сообщения часто приводят к повторным платежам после первичной потери.
• адреса контрактов и их верификацию;
• owner/admin-роли и возможность изменения параметров;
• наличие audit report и его применимость к текущему коду;
• mint/burn и supply-механику;
• маршрут входящих средств после пополнения;
• связь с транзитными адресами и точками консолидации;
• домены, письма, Telegram-аккаунты и инфраструктуру социальной инженерии.
Вывод: сам по себе токен и смарт-контракт не являются признаком надежности. Если проект обещает фиксированную высокую доходность, использует закрытые чаты, реферальные выплаты и при этом имеет централизованный контроль над контрактом, техническая проверка должна идти до перевода средств, а не после потери доступа. не использовать блоки с услугами, кнопками и обещаниями возврата. Если нужно упомянуть команду или источник анализа, сделать это в нейтральном дисклеймере в конце: «Материал основан на разборе публичных и предоставленных артефактов».