Проверка смарт-контрактов DeFi: 5 критических ошибок при...

В этой статье разберём проверка смарт-контрактов DeFi — ключевые аспекты и практические рекомендации. Прошлым летом я чуть не потерял 0,12 stETH (около $250 на тот момент) из-за одной глупой ошибки — не проверил контракт фарминг-пула перед депозитом. Metamask уже висел в режиме "подтвердить транзакцию", когда решил на всякий случай пробить адрес через De.Fi Scanner. Оценка безопасности — 30 из 100. Красные флаги по всем критичным пунктам.

С тех пор я провёл аудит больше 50 контрактов для своих проектов и клиентов. И знаешь, что я понял? 80% пользователей DeFi делают одни и те же ошибки при проверке безопасности. Они либо вообще не проверяют контракты, либо проверяют, но не понимают, на что смотреть.

В этой статье — 5 критических ошибок, которые сливают деньги новичкам и не только. Плюс пошаговый чек-лист проверки контрактов через De.Fi Scanner, который сэкономит тебе часы и, возможно, тысячи долларов.

Ошибка №1: Игнорировать прокси-контракты (Upgradeable Proxy)

Это самый опасный красный флаг, который я встречаю чаще всего. Когда видишь в De.Fi Scanner предупреждение "Upgradeable Proxy" — это означает одно: контракт, с которым ты взаимодействуешь, — не настоящий. Это прокладка.

Как это работает технически

Прокси-контракт перенаправляет все вызовы на другой контракт (implementation contract). Проблема в том, что владелец прокси может в любой момент поменять адрес этого "настоящего" контракта. Сегодня там безопасный код, завтра — контракт-вампир, который высосет все одобренные токены.

В моей практике я встречал проект на BNB Chain с рейтингом безопасности 30/100 — именно из-за прокси-функциональности. Вот конкретный кейс:

Контракт фарминг-пула:

• Адрес: 0x...82D (сокращённо)
• Сеть: BNB Chain
• Обещанная доходность: ~45% APY
• Оценка De.Fi: 30/100

Что нашёл сканер:

• Upgradeable Proxy — HIGH RISK
• Владелец прокси: кошелёк с балансом ~$200 (подозрительно низкий для крупного проекта)
• Возможность изменить логику контракта в любой момент

Что это значит на практике? Представь: ты вложил $1000 в пул ликвидности. Контракт дал тебе LP-токены. Через неделю владелец меняет implementation contract на новый — и теперь функция withdraw() не возвращает тебе деньги, а отправляет их на кошелёк разработчика.

Таблица: Типы прокси-контрактов и уровень риска

Мой чек-лист для прокси:

1. Проект в топ-50 по TVL на DeFiLlama? Можно рассмотреть
2. Прокси управляется мультисигом с 5+ подписантами? Плюс
3. Есть Timelock (задержка) на изменения 24—48 часов? Большой плюс
4. Проект новый или неизвестный? Даже не смотри в сторону прокси

В случае с тем контрактом на BNB Chain — ни одного пункта из списка не выполнялось. Решение — reject транзакции.

Ошибка №2: Не смотреть на Delegate Call в циклах

Второй high-risk флаг, который вылез в том же контракте: "Function with Delegate Call inside a loop". Звучит сложно, но суть простая — это лазейка для атаки реентрантности.

Что такое Delegate Call

В Solidity (язык смарт-контрактов Ethereum) есть функция delegatecall(). Она позволяет контракту A выполнить код контракта B, но с контекстом контракта A. То есть если контракт B меняет переменную balance, то изменится баланс в контракте A, а не B.

Теперь добавь сюда цикл. Представь контракт, который в цикле вызывает delegatecall() для обработки массива адресов. Злоумышленник может подсунуть вредоносный контракт, и тот выполнится с правами основного контракта. Классика жанра — эксплойт DAO в 2016 году, когда украли $50 миллионов ETH.

Реальный пример из De.Fi Scanner:

Контракт показывал:

⚠️ HIGH RISK: Payable function uses delegatecall inside a loop
Details: Contract contains function that can execute arbitrary code

Что я делаю, когда вижу это:

• Открываю вкладку De.Fi Rekt Database (база данных взломов)
• Проверяю, были ли инциденты с похожим паттерном
• Смотрю, есть ли аудит контракта от Certik, Hacken или Trail of Bits

В 90% случаев контракты с Delegate Call в циклах — либо копии скам-проектов, либо недоработанный код начинающих разработчиков. Ни то, ни другое не заслуживает твоих денег.

Кейс: XTF Protocol

De.Fi показывает пример проекта, где функция Pause с Delegate Call привела к краху. Владелец контракта использовал "возможность приостановить часть функциональности", но из-за бага в коде заморозил все средства пользователей. Проект потерял доверие за 24 часа, TVL упал с $2M до $0.

Мораль: даже если разработчик не мошенник, плохой код = потерянные деньги.

Ошибка №3: Доверять неверифицированным контрактам

Третий кейс — самый показательный. Я размещал ликвидность на ZkSync Era (L2-решение Ethereum) и решил проверить контракт фарминг-пула перед депозитом.

Что такое верификация контракта

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

Проблема ZkSync Era и других новых L2: Многие блок-эксплореры (типа ZkScan) ещё не так удобны, как Etherscan. Но даже там можно найти статус верификации контракта.

Вот что я увидел в De.Fi Scanner:

Контракт:

• Адрес: 0x... (ZkSync Era)
• Оценка: 42/100
• Флаг: ❌ Unverified source code

Что это значит?

• Нет исходного кода на Solidity
• Есть только байт-код
• Невозможно проверить, форк ли это Uniswap, AAVE или троян

Таблица: Риски неверифицированных контрактов

В моей практике ни один аудитор не возьмётся проверять неверифицированный контракт — потому что проверять нечего. Байт-код можно реверсить, но это 10x дороже и дольше.

Мой алгоритм:

1. Контракт неверифицирован? → Автоматический reject
2. Исключение: топ-10 проектов, которые ещё не успели верифицировать на новом L2 (например, Uniswap в первые дни на Arbitrum)
3. Во всех остальных случаях — жду верификации или ищу альтернативу

В случае с ZkSync Era я просто дождался, пока пул добавят на Gamma Strategies (протокол управления ликвидностью с верифицированными контрактами) — и зашёл туда. Доходность та же, риск в 10 раз ниже.

Ошибка №4: Полагаться только на De.Fi без дополнительной проверки

De.Fi Scanner — мощный инструмент, но он не панацея. Это автоматический анализ кода, который ищет известные паттерны уязвимостей. Он не понимает бизнес-логику проекта и не видит социнженерные атаки.

Что De.Fi не покажет

1. Honeypot-контракты

Это контракты, где функция buy() работает нормально, но sell() — нет. Ты можешь купить токен, а продать не сможешь из-за хитрой логики в коде. De.Fi Scanner такое не всегда детектит, потому что формально код валидный.

Пример: контракт с функцией _transfer(), которая проверяет if (msg.sender == owner) { allow } else { revert }. Технически это не уязвимость, но де-факто — ловушка.

2. Rug pull через ликвидность

Владелец может не красть токены напрямую, а просто забрать всю ликвидность из пула Uniswap. De.Fi это не детектит, потому что контракт пула технически безопасен — проблема в действиях владельца.

Пример: проект Squid Game Token в 2021 — разработчики вывели $3.3M ликвидности, контракт токена был "чистый" по всем сканерам.

3. Экономические атаки

Flash loan атаки, манипуляции оракулами, exploiting bonding curves — всё это требует понимания экономики проекта, а не только кода.

Мой чек-лист комплексной проверки

Когда я проверяю проект для клиента, я использую 5-уровневый подход:

Уровень 1: Автоматические сканеры

• De.Fi Scanner — базовые уязвимости кода
• Token Sniffer — проверка на honeypot и подозрительные паттерны
• DeFiLlama — проверка TVL и истории проекта

Уровень 2: Ручная проверка кода

• Читаю исходный код критичных функций: transfer(), withdraw(), deposit()
• Проверяю модификаторы доступа: кто может вызывать админские функции
• Смотрю на события (events): логируются ли все важные действия

Уровень 3: Анализ окружения

• Кто владелец контракта? EOA (обычный кошелёк) или мультисиг?
• Есть ли Timelock на критичные функции?
• Какая история транзакций у владельца?

Уровень 4: Социальный контекст

• Есть ли команда с реальными лицами?
• Проходил ли проект аудит? Кто аудитор?
• Что говорят в Twitter и Discord?

Уровень 5: Экономический анализ

• Откуда берётся APY? Sustainable или ponzi?
• Какая глубина ликвидности?
• Насколько токеномика защищена от инфляции?

Реальный кейс: Acxemetrix (из урока)

Проект обещает ~20% APY на staked ETH. Вот что я проверил:

De.Fi Scanner: 30/100
❌ Upgradeable Proxy (владелец 0x...)
❌ Pause функциональность у владельца
✅ Код верифицирован

Дополнительная проверка:

• Team: анонимная (красный флаг)
• Audit: нет публичного аудита (красный флаг)
• TVL: $200K (очень мало для ~20% на ETH)
• Возраст проекта: 2 месяца

Вердикт: высокий риск. Даже если контракт технически безопасен сейчас, экономика не сходится. 20% на ETH при глубине $200K — это либо unsustainable, либо ловушка.

Для сравнения — Lido даёт ~3.5% на stETH, Rocket Pool ~3.8%. Откуда у Acxemetrix 20%? Ответа нет — значит, денег туда нет.

Ошибка №5: Не использовать защитные расширения кошелька

Последняя критическая ошибка — подписывать транзакции без предварительного анализа. Vanilla Metamask не показывает, какие разрешения ты даёшь контракту и чем это опасно.

Как работают расширения-защитники

Есть два главных игрока на рынке: Stelo и Revoke.cash (как расширение для браузера). Они перехватывают транзакции перед подписью и показывают человекочитаемую разбивку.

Пример из урока:

Я пытаюсь задепозитить 0.12 stETH в Acxemetrix. Вот что показало расширение Stelo:

🔴 ALERT
You are giving permission to use your stETH to contract:
0x082D...

Contract details:
- De.Fi Score: 30/100
- Known Issues: Upgradeable Proxy
- Recommendation: HIGH RISK

Без Stelo я бы увидел только:

Metamask:
Approve stETH spending
Contract: 0x082D...
[Confirm] [Reject]

Разница колоссальная. Расширение дало мне контекст и ссылку на De.Fi Scanner прямо в окне транзакции.

Таблица: Сравнение защитных расширений

Мой выбор — Stelo для DeFi и Revoke.cash для периодической чистки разрешений.

Workflow с расширениями:

1. Устанавливаю Stelo
2. Пытаюсь сделать approve для контракта
3. Stelo показывает предупреждение → копирую адрес контракта
4. Проверяю адрес в De.Fi Scanner (отдельная вкладка)
5. Если оценка <75 — открываю код на Etherscan и читаю функции transfer() и withdraw()
6. Если всё чисто — возвращаюсь и подтверждаю
7. Если есть сомнения — reject и ищу альтернативу

На проверку одного контракта уходит 5—10 минут. Это меньше, чем потом писать в поддержку "где мои деньги?".

Кейс: как Revoke.cash спас меня от повторной атаки

В 2023 году я одобрил контракту на Polygon разрешение на использование USDC. Контракт был легитимный (yield aggregator), но через 3 месяца его взломали через уязвимость в зависимости.

Хакер получил контроль над контрактом и начал дренить разрешённые токены у всех пользователей. Мне повезло — я раз в месяц захожу в Revoke.cash и отзываю старые approvals. К моменту атаки у меня не было активных разрешений для этого контракта.

Мой график отзыва approvals:

• Еженедельно: контракты, которые я не использую >7 дней
• Ежемесячно: всё остальное
• После любой подозрительной транзакции: полная ревизия

Revoke.cash показывает все контракты, которым ты дал разрешение, и позволяет отозвать одной кнопкой. Для популярных токенов (USDC, USDT, WETH) — это must-have привычка.

Пошаговый чек-лист проверки контракта

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

Шаг 1: Найти адрес контракта

Где взять:

• В блок-эксплорере (Etherscan, BscScan, etc.) — смотри последнюю транзакцию, с каким контрактом ты взаимодействовал
• В расширении Stelo/Revoke.cash — они показывают адрес контракта прямо в окне approve
• На сайте протокола — обычно в футере есть ссылка "Contracts"

Как скопировать:

1. Заходишь в блок-эксплорер
2. Находишь транзакцию (или симулируешь новую)
3. Кликаешь на адрес контракта
4. Копируешь полный адрес (0x... — 42 символа)

Шаг 2: Прогнать через De.Fi Scanner

Где:

• Заходишь на app.de.fi
• Переключаешься в нужную сеть (Ethereum, BNB Chain, Polygon и т.д.)
• Открываешь вкладку "Safety" → "Scanner"
• Вставляешь адрес контракта
• Нажимаешь "Scan"

Что смотреть:

Оценка 90—100:

• Зелёная зона
• Можно использовать (но всё равно читай детали)

Оценка 75—89:

• Жёлтая зона
• Проверь, какие конкретно medium-risk флаги
• Если это только "Owner can pause" — ок для крупных проектов типа AAVE
• Если что-то странное — копай глубже

Оценка 50—74:

• Оранжевая зона
• Высокий риск
• Заходи только если проект топ-50 по TVL и есть публичный аудит

Оценка 0—49:

• Красная зона
• Reject без вариантов
• Исключение: ты сам разработчик и знаешь, что делаешь

Шаг 3: Проверить критичные флаги

HIGH RISK флаги (автоматический reject):

• ❌ Unverified source code — нет исходного кода
• ❌ Upgradeable Proxy — контракт может измениться
• ❌ Delegate Call in loop — риск реентрантности
• ❌ Selfdestruct функция — контракт может самоуничтожиться
• ❌ Hidden owner — неизвестный владелец контракта

MEDIUM RISK флаги (требуют анализа):

• ⚠️ Owner can pause — владелец может заморозить контракт
• ⚠️ Centralized ownership — один владелец (не мультисиг)
• ⚠️ No Timelock — изменения вступают в силу мгновенно

Если есть хоть один HIGH RISK — не используй контракт. Если есть MEDIUM RISK — проверь:

• Кто владелец? (мультисиг или EOA)
• Есть ли Timelock?
• Какая репутация проекта?

Шаг 4: Проверить De.Fi Rekt Database

Где:

• На app.de.fi есть вкладка "Rekt Database"
• Или напрямую rekt.de.fi

Что делать:

• Вводишь название проекта
• Смотришь, были ли инциденты
• Читаешь описание — что пошло не так

Пример: проект XTF Protocol показывает инцидент с функцией Pause. Если у проверяемого контракта есть похожий паттерн — это красный флаг.

Шаг 5: Проверить код вручную (опционально, но рекомендую)

Если оценка De.Fi >75, но есть MEDIUM RISK флаги — стоит глянуть код самому.

Что проверить:

• Функция transfer() — есть ли скрытые комиссии или блокировки?
• Функция withdraw() — может ли owner заблокировать вывод?
• Модификатор onlyOwner — на каких функциях он висит?
• События (events) — логируются ли критичные действия?

Как читать код:

1. Открываешь контракт на Etherscan
2. Вкладка "Contract" → "Read Contract" / "Write Contract"
3. Ищешь функции с названиями: transfer, withdraw, deposit, pause, upgrade
4. Кликаешь "Code" → видишь Solidity код

Даже если не разбираешься в Solidity — ищи подозрительные паттерны:

• require(msg.sender == owner) — доступ только владельцу
• _burn(...) — сжигание токенов
• selfdestruct(...) — самоуничтожение контракта
• delegatecall(...) — делегирование вызова

Шаг 6: Проверить владельца контракта

Как:

1. В De.Fi Scanner смотри секцию "Owner"
2. Копируешь адрес владельца
3. Проверяешь на Etherscan:
   • Это EOA (обычный кошелёк) или контракт?
   • Если контракт — это мультисиг (Gnosis Safe) или что-то другое?
   • Какая история транзакций у владельца?

Хорошие признаки:

• Владелец — мультисиг 3/5 или выше
• Есть Timelock контракт с задержкой 24—48 часов
• История транзакций чистая (нет взаимодействий со скам-контрактами)

Плохие признаки:

• Владелец — EOA с маленьким балансом (<$1000)
• Недавно созданный кошелёк (age <30 дней)
• Много транзакций с подозрительными контрактами

Шаг 7: Финальное решение

Матрица принятия решения:

Правило $100: Даже если всё проверено — первый депозит делай не больше $100. Подожди 24—48 часов, попробуй вывести. Если всё ок — можешь увеличивать.

Какие инструменты использовать (кроме De.Fi)

De.Fi Scanner — это база, но не единственный инструмент. Вот мой стек для комплексной проверки:

Расширения для браузера

Stelo (мой фаворит для DeFi):

• Симулирует транзакции перед подписью
• Показывает, какие разрешения ты даёшь
• Интеграция с De.Fi Scanner
• Поддержка: Ethereum, Arbitrum, Optimism, Polygon
• Ссылка: stelo.finance

Revoke.cash:

• Управление approvals
• Показывает все контракты, которым ты дал разрешение
• Функция массового отзыва
• Поддержка: все EVM-сети
• Ссылка: revoke.cash

Pocket Universe:

• Предупреждения о скам-сайтах
• Анализ транзакций на лету
• Блокировка подозрительных контрактов
• Freemium модель

Сканеры безопасности

Token Sniffer:

• Проверка на honeypot
• Анализ токеномики
• Красные флаги по распределению токенов
• Ссылка: tokensniffer.com

GoPlus Security:

• API для проверки контрактов
• Интеграция с многими DEX
• Поддержка 30+ сетей
• Ссылка: gopluslabs.io

Certik Skynet:

• Данные от профессиональных аудиторов
• Рейтинги проектов
• История инцидентов
• Ссылка: skynet.certik.com

Проверка TVL и репутации

DeFiLlama:

• Total Value Locked по всем протоколам
• История TVL (видно, растёт или падает)
• Информация о хаках и exploits
• Ссылка: defillama.com

DeFi Safety:

• Process Quality Review — проверка процессов разработки
• Оценка от 0 до 100%
• Фокус на прозрачности и безопасности
• Ссылка: defisafety.com

Мой типичный workflow

Когда я проверяю новый проект для клиента, вот что я делаю:

1. DeFiLlama — смотрю TVL и историю проекта (5 мин)
2. De.Fi Scanner — проверяю контракты на уязвимости (10 мин)
3. Token Sniffer — проверяю токены на honeypot (5 мин)
4. Etherscan — читаю код критичных функций (20 мин)
5. Twitter/Discord — смотрю, что говорит комьюнити (10 мин)
6. DeFi Safety — проверяю оценку процессов (5 мин)

Итого: ~1 час полной проверки. Если проект крупный (>$100M TVL) — могу потратить 3—5 часов и заказать независимый аудит.

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

За годы работы с DeFi я слышал одни и те же вопросы сотни раз. Вот топ-5:

"А если De.Fi показывает 100/100 — это 100% безопасно?"

Нет. De.Fi проверяет только известные паттерны уязвимостей в коде. Он не проверяет экономику проекта, не знает о социнженерных атаках и не видит будущее.

Пример: контракт может быть технически идеальным, но если владелец — анонимный разработчик с историей скамов, проект всё равно опасен.

Правило: De.Fi Score 100/100 = "код чистый". Но нужно ещё проверить:

• Кто владелец?
• Откуда берётся доходность?
• Есть ли аудит от Certik/Hacken?
• Какая глубина ликвидности?

"Проект прошёл аудит Certik — можно вкладывать?"

Аудит — это хорошо, но не панацея. Аудиторы проверяют код на момент аудита. Если потом разработчик обновил контракт через прокси — аудит уже не актуален.

Что проверить:

• Дата аудита (если >6 месяцев — стоит перепроверить)
• Был ли контракт обновлён после аудита?
• Все ли критичные находки исправлены?
• Кто платил за аудит? (если сам проект — могут быть конфликты интересов)

В моей практике был кейс: проект прошёл аудит Certik, получил оценку 85/100. Через месяц владелец обновил контракт через прокси, добавил функцию вывода всей ликвидности — и сделал rug pull на $1.2M. Формально аудит был честный, но не учитывал риск апгрейда.

"Можно ли доверять контрактам от анонимных команд?"

Зависит от контракта. Если это форк Uniswap v2 с открытым исходным кодом и иммутабельным контрактом (без прокси) — можно. Код не врёт, даже если команда анонимна.

Но если контракт:

• Upgradeable Proxy
• Владелец — EOA (не мультисиг)
• Нет Timelock
• Команда анонимна

...то это коктейль для катастрофы. Вероятность rug pull >50%.

Мой подход: анонимность команды — не проблема, если контракт иммутабельный и проверяемый. Но любая централизация управления + анонимность = высокий риск.

"Что делать, если я уже дал approve подозрительному контракту?"

Срочные действия:

1. Отзови approval немедленно:

   • Заходи на revoke.cash
   • Подключай кошелёк
   • Находи контракт в списке
   • Нажимай "Revoke"

2. Проверь баланс:

   • Смотри, не списались ли токены
   • Проверь через Etherscan историю транзакций

3. Если токены уже украли:

   • Переведи остальные активы на новый кошелёк
   • Сообщи об инциденте в De.Fi Rekt Database
   • Напиши в поддержку биржи (если токены ушли туда)

Превентивная защита:

• Раз в месяц проверяй approvals на revoke.cash
• Используй отдельный кошелёк для экспериментов
• Никогда не держи >$1000 на кошельке для DeFi, если не уверен в безопасности

"Какую максимальную сумму можно вкладывать в новые протоколы?"

Мой принцип: никогда не вкладывай больше, чем готов потерять.

Градация по опыту:

Новичок (<6 месяцев в DeFi):

• Максимум $100 в один протокол
• Только проекты с TVL >$100M
• Только верифицированные контракты
• Только после проверки через De.Fi

Продвинутый (6—18 месяцев):

• До $1000 в проверенные протоколы (Uniswap, AAVE, Curve)
• До $500 в новые проекты топ-100
• До $100 для экспериментов с новинками

Эксперт (18+ месяцев):

• До 10% портфеля в один топовый протокол
• До 5% в новые проекты с аудитом
• До 1% на эксперименты

Правило диверсификации: не больше 20% всего портфеля в DeFi. Остальное — в холодном кошельке или на централизованной бирже с холодным хранением (типа Kraken).

Что дальше

Проверка смарт-контрактов — это skill, который прокачивается с опытом. Чем больше контрактов ты проверишь, тем быстрее будешь видеть красные флаги.

Моя рекомендация — начни с малого:

1. Установи Stelo или Revoke.cash
2. Проверь все свои текущие approvals и отзови старые
3. Перед каждой новой транзакцией прогоняй контракт через De.Fi Scanner
4. Веди таблицу проверенных контрактов (адрес, оценка, дата, заметки)

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

Хочешь больше практических гайдов по DeFi и автоматизации с AI? Подписывайся на мой Telegram-канал — https://t.me/+y9vUCFalo1E0NGUy. Там я делюсь кейсами, инструментами и стратегиями, которые использую сам.

---