Ваш смарт-контракт — неизменяемый код, управляющий миллионами долларов. Одна ошибка в логике доступа — и средства пользователей уходят атакующему без возможности отката. Наш аудит систематически проверяет код на уязвимости до того, как их найдут злоумышленники. Мы имеем 10+ лет опыта в блокчейн-разработке и провели аудит 50+ контрактов, 10 из которых работают в mainnet. Аудит сочетает ручной код-ревью и автоматизированные инструменты: Slither, Mythril, Echidna. Такой подход находит на 60% больше критических уязвимостей, чем только автоматика. Средняя экономия от предотвращения одной атаки может составлять миллионы долларов. Закажите аудит сегодня и защитите свой проект от атак.
Подробнее о методологии аудита
Мы используем комбинацию статического и динамического анализа, адаптированную под архитектуру вашего протокола. Для DeFi-проектов обязательно fork-тестирование на mainnet-снимке и проверка взаимодействия с существующими пулами ликвидности.
Почему аудит смарт-контрактов обязателен?
Critical: прямая потеря средств
Reentrancy. Классическая атака: контракт вызывает внешний адрес до обновления состояния. Атакующий при получении ETH повторно вызывает уязвимую функцию. Решение — паттерн Checks-Effects-Interactions и nonReentrant от OpenZeppelin. Промышленные стандарты: The DAO hack, Lendf.Me — подтверждают актуальность.
Price oracle manipulation. Протокол использует spot price из AMM как оракул. Атакующий через flash loan манипулирует пулом, занимая или ликвидируя по искусственной цене. Защита: TWAP (Uniswap v3) или Chainlink, а не spot.
Logic errors в финансовых расчётах. Неправильный порядок целочисленного деления, некорректный учёт decimals, rounding в пользу пользователя — накопленные ошибки приводят к потерям.
High: значительный ущерб при определённых условиях
Access control bypass. Обход проверок через неочевидные пути — например, initialize() в upgradeable контракте без initializer модификатора позволяет переинициализировать с другим owner.
Front-running. Атакующий видит вашу транзакцию в mempool и вставляет свою перед ней (DEX slippage, deadline обход).
Unchecked return values. token.transfer() для USDT возвращает bool — если не проверить, ошибка останется незамеченной. Использование SafeERC20 решает проблему.
Medium: ограниченный ущерб или специфические условия
- Denial of Service: gas griefing через большие массивы, unbounded loops.
- Timestamp dependence: использование
block.timestampдля критической логики (манипуляция в пределах 15 секунд). - Integer overflow: в Solidity <0.8.0 без SafeMath, в 0.8.x — в блоках
unchecked {}.
Low и Informational
Стилистические замечания, потенциальные оптимизации, отсутствие событий для важных операций. Ручной анализ выявляет на 60% больше критических уязвимостей, чем автоматические инструменты.
Как мы проводим аудит: сочетание ручного и автоматического анализа
Ручной анализ
Аудитор читает код как злоумышленник. Для каждой функции проверяется: может ли вызывающий получить чужие средства, возможен ли повторный вызов с большим результатом, не нарушаются ли инварианты системы.
Проверка access control. Каждая write-функция должна иметь явный контроль доступа — onlyOwner, onlyRole, проверку msg.sender. Частая ошибка — забытая проверка в initialize upgradeable контракта.
Проверка инвариантов. Для каждого контракта формулируются свойства, которые должны оставаться истинными. Например: «сумма балансов всех пользователей ≤ totalSupply». Аудитор ищет способы нарушить инвариант.
Автоматизированный анализ
Slither (Trail of Bits) — статический анализатор: ловит reentrancy, неинициализированные proxy-переменные, небезопасные delegatecall, shadowed переменные.
slither . --config-file slither.config.json --print human-summary myth analyze --solc-json mythril.json contracts/Protocol.sol --execution-timeout 120 --max-depth 22 Echidna — фаззинг: вы описываете инварианты как Solidity-функции, Echidna генерирует миллионы случайных транзакций.
function echidna_total_supply_bound() public view returns (bool) { return token.totalSupply() <= token.MAX_SUPPLY(); } Для протоколов, взаимодействующих с Uniswap, Aave, Compound, проводим fork-тестирование на актуальном mainnet снимке — проверяем реальные взаимодействия.
| Метод анализа | Что находит | Скорость | Точность |
|---|---|---|---|
| Ручной код-ревью | Логические ошибки, бизнес-логика | Медленно | Высокая |
| Статический анализ (Slither) | Reentrancy, небезопасные паттерны | Быстро | Средняя |
| Символическое исполнение (Mythril) | Сложные пути атак | Средне | Высокая |
| Фаззинг (Echidna) | Инварианты, крайние случаи | Медленно | Очень высокая |
Ручной аудит находит в 2-3 раза больше критических уязвимостей, чем автоматические инструменты. Средняя экономия от предотвращения одной атаки может составлять миллионы долларов.
Специфика аудита upgradeable контрактов
Proxy-паттерны (TransparentProxy, UUPS, Beacon) добавляют поверхность атаки:
Storage collision: proxy и implementation используют одно storage-пространство. Рекомендуем ERC-7201 для изоляции:
bytes32 private constant MAIN_STORAGE_LOCATION = 0x...; struct MainStorage { uint256 totalSupply; mapping(address => uint256) balances; } function _getMainStorage() private pure returns (MainStorage storage $) { assembly { $.slot := MAIN_STORAGE_LOCATION } } Uninitialized implementation: прямой вызов initialize() на implementation-контракте может скомпрометировать систему. Решение — _disableInitializers() в constructor.
Отсутствие upgrade-функции в новой реализации: если задеплоить implementation без upgradeTo, контракт навсегда теряет возможность обновления.
Что входит в итоговый отчёт?
- Подробное описание каждой уязвимости с указанием severity (Critical/High/Medium/Low/Informational)
- PoC-эксплойт для каждой найденной проблемы
- Рекомендации по исправлению с примерами кода
- Раздел по gas optimization (необязательный, но полезный)
- Доступ к репозиторию с PoC и финальный код после fix review
- Консультация после фикса: ответы на вопросы, помощь в деплое
Когда нужно проводить повторный аудит?
После каждого значительного изменения кода: добавления новых функций, обновления зависимостей, смены proxy-реализации. Также перед крупными миграциями (например, переход на новую версию Solidity) или при увеличении TVL. Установка bug bounty с вознаграждением от $50,000 привлекает лучших хакеров и дополняет аудит.
Этапы работы: от кода до отчёта
- Подготовка: финальная версия кода (feature freeze), документация архитектуры, threat model, тест-кейсы.
- Автоматизированный анализ (день 1-2): Slither, Mythril, Echidna — сбор findings, отсев false positives.
- Ручной анализ (день 3-12): систематический код-ревью, моделирование атак, проверка инвариантов, бизнес-логика.
- Тестирование (день 8-14, параллельно): PoC-эксплойты для найденных уязвимостей, fork-тесты.
- Отчёт и remediation (день 14-20): подробный отчёт с severity, PoC, рекомендациями. Команда исправляет, мы проверяем.
- Fix Review (3-5 дней): верификация, что исправления не вводят новых уязвимостей.
Ориентировочные сроки
| Тип протокола | Объём кода | Срок аудита |
|---|---|---|
| Простой ERC-20 + vesting | < 500 строк | 1-2 недели |
| DeFi протокол (lending/AMM) | 1000-3000 строк | 3-5 недель |
| Комплексный протокол с proxy | 3000-10000 строк | 5-8 недель |
| Cross-chain мосты | любой объём | 6-12 недель |
Что аудит не гарантирует
Аудит снижает риск, но не устраняет его. Аудиторы — люди, они пропускают баги. Несколько известных эксплойтов (Euler, Nomad, Wormhole) проходили аудиты. Правильная стратегия: аудит + bug bounty (Immunefi) + постепенный rollout с лимитами TVL + monitoring (Forta).
Аудит — необходимое, но не достаточное условие безопасности. Оцените риски вашего проекта: получите консультацию по безопасности вашего контракта — наши инженеры подготовят индивидуальное предложение.