Агрегатор доходности DeFi: архитектура vault и защита от MEV

Разработка 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%. Сравнение методов:

По сравнению с публичным вызовом, 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 протокол постоянно изымает ликвидность из стратегий.

Поддерживаемые протоколы и стратегии

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-агрегатора с гарантией безопасности и оптимизацией под ваш протокол. Наши инженеры имеют многолетний опыт в DeFi и помогут избежать типичных ошибок. Интересует разработка yield-агрегатора? Свяжитесь с нами для оценки проекта или получите консультацию по архитектуре DeFi-решений.