Разработка vault-контрактов

Разработка vault-контрактов

Vault — это контракт, который принимает токены от пользователей, размещает их в стратегии (Aave, Compound, Curve, Convex, Yearn), и выдаёт share-токены в обмен. Звучит просто. На практике 80% проблем vault-архитектуры — это не ошибки в стратегии, а ошибки в логике расчёта shares при депозитах/выводах, или неправильный учёт fee при harvesting. Несколько протоколов потеряли пользовательские средства именно здесь, не в самой стратегии.

Проблема инфляционной атаки и ERC-4626

Первый депозит и атака на shares

ERC-4626 — стандарт tokenized vault, принятый в апреле 2022. До него каждый vault изобретал велосипед для расчёта convertToShares / convertToAssets. После — появился консенсус, но не исчезли уязвимости.

Классическая атака на 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 после любой операции.

Таблица vault типов

Процесс работы

Проектирование (3-5 дней). Выбор стратегии, анализ интеграций, storage layout vault + strategy. Определяем fee структуру: management fee (% от AUM в год), performance fee (% от прибыли), withdrawal fee (редко, но бывает).

Разработка (1-3 недели). Vault core + одна-две стратегии. Fork-тесты на Ethereum mainnet или Arbitrum (где ниже газ для тестирования).

Аудит-подготовка. Slither, тест-покрытие >95%, проверка всех fee расчётов на граничных случаях (0 assets, 1 wei deposit, harvest сразу после деплоя).

Деплой. Gnosis Safe для owner/admin функций. Timelock на изменение стратегии — минимум 24 часа.

Ориентиры по срокам

Vault с одной стратегией (Aave/Compound): 1-2 недели. Multi-strategy vault с rebalancing: 3-5 недель. Сложные leverage-стратегии с liquidation protection: 6-8 недель.