Разработка vault-контрактов
Мы разрабатываем vault-контракты — смарт-контракты, которые принимают токены от пользователей, размещают их в стратегиях (Aave, Compound, Curve, Convex, Yearn) и выдают share-токены в обмен. На практике 80% проблем vault-архитектуры — это не ошибки в стратегии, а ошибки в логике расчёта shares при депозитах/выводах или неправильный учёт fee при harvesting. Несколько протоколов потеряли пользовательские средства именно здесь, не в самой стратегии. Наш опыт — более 10 DeFi-проектов с vault-архитектурой, и мы гарантируем защиту от типовых уязвимостей.
Как инфляционная атака уничтожает первый депозит?
Классическая атака на vault без ERC-4626 защиты: атакующий делает первый депозит на 1 wei, получает 1 share. Затем донатит напрямую (не через deposit) 1000 USDC в vault, повышая totalAssets без изменения totalSupply. Следующий пользователь депонирует 1999 USDC — при делении 1999e6 * 1 / 1000e6 получается 1 share (integer division). Атакующий с 1 share получает половину пула при withdrawall — 1499 USDC. Жертва потеряла 500 USDC.
OpenZeppelin в ERC4626.sol закрыл это через виртуальные shares и assets: _decimalsOffset() добавляет 10^N к знаменателю, делая атаку экономически невыгодной. Но это работает только если _decimalsOffset подобран под токен с учётом его decimals. Мы используем ERC-4626 как базу и добавляем _decimalsOffset = 3 для большинства ERC-20 токенов, что делает стоимость атаки ~1000x дороже profit.
Почему harvest и fee расчёт — частая ошибка?
При harvesting vault собирает награды (например, CRV + CVX из Convex), конвертирует их в underlying asset и добавляет в пул. В момент между harvesting и re-deposit share цена растёт. Если fee берётся после этого роста как процент от profit — всё корректно. Если fee берётся в момент harvest до re-deposit — management fee съедает часть principal, а не только profit.
Типичная ошибка: performanceFee = (totalAssets() - lastHarvestTotalAssets) * feePercent / 10000. Здесь totalAssets() может включать unrealized gains, которые потом уйдут при рыночной волатильности. Правильнее: fee от realized profit после конвертации наград.
Reentrancy в vault через ERC-777 / ERC-1363
Если underlying asset — токен с transfer hook (ERC-777 или ERC-1363), то при deposit() хук может быть вызван до обновления totalSupply. Атакующий в хуке вызывает deposit() снова — получает shares по старому курсу до учёта своего первого депозита.
Защита: nonReentrant на deposit, withdraw, redeem, mint. Foundry fuzz-тест с mock ERC-777 токеном, который вызывает повторный deposit из transfer hook.
Как мы строим vault-контракты
Архитектура: vault + strategy separation. Vault хранит assets и управляет shares. Strategy — отдельный контракт с логикой размещения. Это не просто архитектурная чистота: при взломе стратегии vault может быть остановлен (pausable), а funds — в теории — эвакуированы через emergencyWithdraw. Если всё в одном контракте — нет.
Vault (ERC-4626) └── Strategy ├── Aave v3 supply/withdraw ├── Curve LP deposit └── Convex staking Yearn v2/v3 использует эту же концепцию. Мы адаптируем под конкретные требования, не копируем Yearn — там ~5000 строк, из которых клиенту обычно нужна треть.
Стек. Solidity 0.8.x + OpenZeppelin 5.x (ERC4626, AccessControl, Pausable, ReentrancyGuard). Интеграции: Aave v3 через IPool, Compound v3 через IComet, Curve через ICurvePool, Convex через IConvex. Оракулы для swap наград: Chainlink или Uniswap v3 TWAP в зависимости от ликвидности токена. Тесты в Foundry: fork mainnet Ethereum/Arbitrum, 100+ fuzz runs на deposit/withdraw/harvest с рандомными суммами и последовательностями. Property-based инвариант: convertToAssets(totalSupply()) >= totalUserDeposits после любой операции. Все контракты проходят аудит с помощью OpenZeppelin ERC-4626 — это база, которую мы дополняем своими наработками.
| Тип vault | Стратегия | Сложность | Типичный APY источник |
|---|---|---|---|
| Simple lending | Aave/Compound | Низкая | Supply rate |
| LP vault | Curve + Convex | Средняя | CRV + CVX rewards |
| Multi-strategy | 3+ протокола | Высокая | Weighted allocation |
| Leverage vault | Aave self-borrow | Высокая | Leveraged yield |
Процесс работы: этапы и сроки
| Этап | Длительность | Результат |
|---|---|---|
| Аналитика и проектирование | 3–5 дней | Выбор стратегии, storage layout, fee структура |
| Разработка | 1–3 недели | Vault + 1–2 стратегии, fork-тесты |
| Аудит-подготовка | 2–3 дня | Slither, тест-покрытие >95%, проверка граничных случаев |
| Деплой | 1 день | Gnosis Safe, Timelock 24h+ |
| Поддержка | Пост-деплой | Мониторинг, обновление стратегий |
Что входит в работу
- Полная документация: описание архитектуры, описание функций, схема взаимодействия.
- Исходный код с комментариями и тестами.
- Настройка Gnosis Safe для администрирования и Timelock.
- Деплой и верификация контрактов на Etherscan/Arbiscan.
- Поддержка в течение 1 месяца после деплоя (исправление багов, консультации).
Ориентиры по срокам
Простой vault с одной стратегией (Aave/Compound) — 1–2 недели. Multi-strategy vault с rebalancing — 3–5 недель. Сложные leverage-стратегии с liquidation protection — 6–8 недель. Свяжитесь с нами для точной оценки вашего проекта — мы проанализируем требования и предложим оптимальное решение. Закажите разработку vault-контрактов с гарантией безопасности и аудитом.