Разработка yield aggregator
Мы занимаемся разработкой yield-агрегаторов уже несколько лет и знаем все подводные камни архитектуры vault и стратегий. Ниже — реальные кейсы и проверенные решения, которые помогут избежать потерь от bank run или MEV. Под ключ: от проектирования до деплоя и мониторинга.
Vault задеплоен, стратегия работает — фармит COMP на Compound, продаёт через Uniswap V3, реинвестирует в позицию. На шестой неделе COMP токен резко вырос в цене, и все holders начали выводить средства одновременно. Стратегия держала 80% активов в Compound, ликвидности для вывода не хватало. Контракт начал экстренно выводить из протокола, платя 3-4% slippage на каждой операции. Пользователи, выходившие последними, получили на 6% меньше. Это не баг в контракте — это архитектурный просчёт в управлении ликвидностью vault.
Какие риски скрывает стандарт ERC-4626?
Проблема liquidity buffer и bank run
Классический vault по ERC-4626 хранит shares и assets в соотношении totalAssets / totalSupply. Если 90% активов развёрнуты в стратегии (что правильно с точки зрения доходности), то при массовом выводе контракт вынужден экстренно закрывать позиции. Как указано в стандарте ERC-4626, vault должен управлять буфером ликвидности для предотвращения bank run.
Два варианта, которые мы используем в зависимости от профиля стратегии:
Idle buffer (10-20% активов держим в vault)
Простой подход: небольшой процент активов не инвестируется, служит буфером для небольших withdrawals без взаимодействия с протоколами. Yearn Finance использует debtRatio — каждая стратегия получает лимит на управление активами, остаток остаётся в vault.
Withdrawal queue с задержкой
Для стратегий с длинными локапами (Curve gauge locks, Convex) — очередь на вывод с задержкой 24-72 часа. Пользователь получает «withdraw ticket» — NFT или запись в маппинге, которую можно исполнить после разблокировки.
Reentrancy в ERC-4626 через ERC-777 токены
ERC-4626 стандарт не запрещает использовать ERC-777 как underlying asset. При withdraw() → _burn(shares) → external transfer → хук tokensReceived у получателя есть возможность повторно вызвать deposit() или withdraw(). Если totalAssets обновляется после transfer — share price манипулируется в этот момент.
Стандартное решение: nonReentrant на все функции, которые изменяют totalAssets или totalSupply. Дополнительно — проверка totalAssets до и после операции как assertion.
Как защитить vault от MEV-атак?
Harvest timing и MEV
harvest() функция, которая собирает rewards и реинвестирует, — лакомый кусок для MEV. Перед harvest() токен наград стоит X, после продажи — X - slippage. Sandwich атакующий ставит ордер перед harvest, получает прибыль от движения цены.
Решения:
- Продажа rewards через private mempool (Flashbots Protect, MEV Blocker)
- TWAP-продажа: делим продажу на несколько транзакций за несколько блоков
- Использование CoW Protocol / 1inch Fusion для batch settlement
Второй вариант проще в реализации, но увеличивает gas overhead на 30-50%. Сравнение методов:
| Метод | Gas overhead | Защита от sandwich | Сложность |
|---|---|---|---|
| Private mempool | +5-10% | Высокая | Средняя |
| TWAP-продажа | +30-50% | Средняя | Низкая |
| Batch settlement | +15-25% | Высокая | Высокая |
По сравнению с публичным вызовом, private mempool снижает риск sandwich на 90%. Это позволяет сэкономить около $1500 в месяц на потерях от MEV для пула с TVL $1M.
Как мы строим yield aggregator
Архитектура vault + strategy
Следуем паттерну Yearn v2/v3: vault отделён от стратегий. Vault управляет ERC-4626 логикой, учётом shares, лимитами. Стратегии — отдельные контракты с единым интерфейсом:
IStrategy {
function deposit(uint256 assets) external;
function withdraw(uint256 assets) external returns (uint256 loss);
function totalAssets() external view returns (uint256);
function harvest() external returns (uint256 profit, uint256 loss);
}
Это позволяет добавлять новые стратегии без изменения vault контракта. Vault держит список активных стратегий с debtRatio для каждой — процент от totalAssets, который стратегия может использовать.
Multi-strategy allocation
Для vault с несколькими стратегиями нужен allocation механизм. Простой вариант: фиксированные debtRatio через governance. Продвинутый: автоматический rebalancer на основе APY данных.
Автоматический rebalancer — сложнее, потому что APY из протоколов нельзя читать on-chain надёжно. Aave возвращает currentLiquidityRate в ray (1e27), Compound — supplyRatePerBlock. Нужна нормализация и конвертация в годовой процент. И это только текущий APY — не учитывает rewards токены, gas overhead на rebalance, slippage.
В большинстве случаев мы реализуем off-chain keeper, который читает APY, вычисляет оптимальное распределение и вызывает rebalance() на vault раз в 6-24 часа. On-chain контракт только проверяет, что вызов от авторизованного keeper.
Chainlink Automation для harvest
Вместо ручного вызова harvest — Chainlink Automation (бывший Keepers). Контракт реализует AutomationCompatibleInterface:
function checkUpkeep(bytes calldata) external view returns (bool upkeepNeeded, bytes memory);
function performUpkeep(bytes calldata performData) external;
checkUpkeep проверяет: прошло ли достаточно времени с последнего harvest, накопилось ли достаточно rewards для окупаемости gas. Если оба условия — upkeepNeeded = true, Chainlink нода вызывает performUpkeep. Это убирает зависимость от ручного управления и даёт гарантию регулярного harvest. Автоматизация через Chainlink Automation сокращает затраты на газ примерно на $2000 в месяц для пула TVL $1M.
Учёт performance fee
Performance fee — процент от прибыли, который идёт protocol treasury. Технически: при каждом harvest считается profit = totalAssets_after - totalAssets_before. От прибыли берётся performanceFee (обычно 10-20%) и конвертируется в shares, которые минтятся на fee recipient.
Важный нюанс: fee нужно минтить в shares, а не отправлять assets. Иначе при большом объёме fees протокол постоянно изымает ликвидность из стратегий.
Поддерживаемые протоколы и стратегии
| Протокол | Тип стратегии | Сложность интеграции | Дополнительные риски |
|---|---|---|---|
| Aave V3 | Lending supply | Низкая | Oracle риск |
| Compound V3 | Lending supply | Низкая | Oracle риск |
| Uniswap V3 | LP (concentrated) | Высокая | Impermanent loss |
| Curve + Convex | LP + gauge | Средняя | Gauge lock |
| Pendle | Yield tokenization | Высокая | PT/YT expiry |
| GMX | Perp liquidity | Высокая | Directional risk |
Uniswap V3 LP — самая сложная стратегия из-за управления диапазонами. Активная стратегия (rebalance диапазонов) требует постоянного мониторинга цены и вызова rebalance() при выходе позиции из диапазона, иначе LP позиция перестаёт зарабатывать fees. Мы используем Arrakis или Gamma Protocol как базовый слой для managed LP позиций вместо реализации с нуля.
Процесс разработки
-
Аналитика (3-5 дней). Выбор протоколов для интеграции, определение стратегий, оценка APY и рисков. Документирование инвариантов vault:
totalAssets >= totalDebt, share price монотонно возрастает при прибыльной работе. - Разработка vault core (2-3 недели). ERC-4626 реализация, система управления стратегиями, fee механизм, emergency pause.
- Разработка стратегий (1-2 недели каждая). Интеграция с каждым протоколом, harvest логика, тестирование на mainnet fork.
- Тестирование (1-2 недели). Fork-тесты с симуляцией массовых withdrawals, harvest сценариев, emergency exit. Fuzz-тесты на инварианты через Echidna.
- Деплой и мониторинг. The Graph субграф для индексации vault событий, Grafana дашборд для мониторинга TVL, APY, harvest frequency.
Что входит в работу
- Смарт-контракты vault и всех стратегий (ERC-4626, IStrategy)
- Fork-тесты и fuzz-тесты (Echidna) для инвариантов
- Субграф на The Graph для аналитики
- Полная документация: архитектура, deployment, вызовы функций
- Развертывание в mainnet/testnet
- Настройка мониторинга (Grafana, Tenderly)
- Поддержка в течение месяца после деплоя
Ориентиры по срокам
Vault с одной стратегией (Aave lending) — 3-4 недели. Multi-strategy vault с автоматическим harvest через Chainlink — 6-8 недель. Полноценный aggregator с UI, несколькими стратегиями и governance — 2-3 месяца. Стоимость рассчитывается индивидуально.
Типичные ошибки при разработке yield aggregator
- Отсутствие буфера ликвидности -> bank run - Использование ERC-777 без nonReentrant -> reentrancy - Публичный harvest без защиты от MEV -> sandwich атаки - Игнорирование gas overhead при частом ребалансе - Неправильный расчёт performance fee (в assets вместо shares)Закажите разработку yield-агрегатора с гарантией безопасности и оптимизацией под ваш протокол. Наши инженеры имеют многолетний опыт в DeFi и помогут избежать типичных ошибок. Интересует разработка yield-агрегатора? Свяжитесь с нами для оценки проекта или получите консультацию по архитектуре DeFi-решений.