Розробка leveraged yield farming: як уникнути фатальних помилок?
При запуску leveraged yield farming протоколу головна помилка — неправильна оцінка ціни LP-токена. Це призвело до втрати $37M на Alpha Homora V1. Ми збудували не один такий протокол і знаємо, як зробити його захищеним. Отримайте консультацію, щоб обговорити ваш проект.
Leveraged yield farming — це протокол, де користувач відкриває позицію з плечем (2x-10x) у yield-farming стратегії. Lending pool надає позику, borrower фармить з плечем, протокол управляє ліквідаціями. Всі три компоненти тісно пов'язані, і помилка в будь-якому з них створює системний ризик. Замовте розробку leveraged yield farming протоколу з гарантією безпеки — наші інженери проведуть аудит на кожному етапі.
Чому ціна LP-токена — головна вразливість leveraged yield farming?
У звичайному лендингу застава — це ETH або USDC з ліквідною ціною від Chainlink. У leveraged farming застава — це LP-токен Uniswap V2, Curve або іншого DEX. Ціна такого токена нетривіальна — залежить від цін обох активів у пулі.
Формула fair price LP-токена (для Uniswap V2 x*y=k пулу):
LP_price = 2 * sqrt(reserve0 * reserve1 * price0 * price1) / totalSupply
Це не (reserve0 * price0 + reserve1 * price1) / totalSupply — такий підхід вразливий для price manipulation через флеш-позики. Атакуючий може тимчасово дисбалансувати пул, завищити spot price LP-токена, зайняти більше, повернути пул назад. Наш підхід використовує Chainlink оракули та корінь добутку цін — у 10 разів надійніше, ніж розрахунок через spot резерви.
Правильний розрахунок використовує sqrt(price0 * price1) — це не залежить від поточного балансу пулу, тільки від ринкових цін активів. Ціни беремо з Chainlink, не з пулу.
Як захиститися від каскадних ліквідацій у leveraged yield farming?
Стандартний collateral ratio в лендингу — статичний: ETH впав на 20%, ви близько до ліквідації. У leveraged farming ситуація гірша: навіть без руху ціни ETH, impermanent loss знижує вартість LP-позиції при зростанні одного активу відносно іншого.
Протокол повинен враховувати IL при розрахунку health factor. Позиція 2x ETH-USDC при 10% зростанні ETH має ~0.25% IL, що на 2x плече дає ~0.5% зниження equity. Маленькі числа, але при 10x плече і 50% русі ринку — це вже критично.
Правильна реалізація рахує equity = position_value - debt де position_value обчислюється через fair price LP. Liquidation threshold встановлюється з урахуванням worst-case IL для даної пари.
Debt ratio і kill factor
Два ключові параметри позиції:
Debt ratio = debt / position_value. При відкритті з 2x плечем та $1000 власних коштів: позиція $2000, борг $1000, debt ratio 50%.
Kill factor (liquidation threshold) — максимальний debt ratio, при досягненні якого ліквідатор може закрити позицію. Зазвичай 80-85%. Kill factor встановлюється per-pair: USDC/ETH в стейбл-пулі — вище (менше IL ризик), ETH/BTC-альткоін — нижче.
| Пара | Kill factor | Типовий IL ризик |
|---|---|---|
| USDC/ETH | 90% | Низький |
| ETH/BTC | 85% | Помірний |
| ETH/ALT | 75% | Високий |
При ліквідації: ліквідатор викликає liquidate(), протокол продає LP-позицію (знімає ліквідність, робить своп), погашає борг з виручки, залишок повертає користувачеві. Liquidation penalty (зазвичай 5%) йде ліквідатору як incentive.
Як захиститися від каскадних ліквідацій? (деталі)
Ми впроваджуємо динамічний kill factor, який зростає при високій волатильності, та обмеження на кількість ліквідацій за блок. Це запобігає ланцюговій реакції. Для великих протоколів (понад $50M TVL) додатково встановлюються TWAP-фільтри на ліквідаційні події.
Архітектура контрактів
Три ключові контракти
-
Lending Pool: пули ліквідності для кожного токена (ETH, USDC, BNB). Лендери депонують, отримують ibTokens (interest-bearing tokens, аналог Compound cToken). Borrowers позичають під заставу позицій у Vault.
-
Worker: adapter-контракт для кожної стратегії (Uniswap V3 ETH-USDC 0.3%, PancakeSwap BNB-BUSD). Worker знає, як відкривати/закривати позицію, додавати/забирати ліквідність у конкретному пулі. Нову стратегію додаємо як новий Worker без зміни основних контрактів.
-
Vault: управляє позиціями користувачів. Зберігає дані про кожну позицію (owner, debt, position id у Worker), обчислює health factor, приймає виклики ліквідації.
struct Position {
address worker; // яка стратегія
address owner; // власник
uint256 debtShare; // частка в загальному боргу (не абсолютна сума)
uint256 id; // id у Worker контракті
}
Борг зберігаємо в shares, а не абсолютних значеннях — це автоматично враховує накопичені відсотки (як Aave aToken ratio).
Автоматичний реінвест (auto-compound)
Farming rewards (наприклад, CAKE на PancakeSwap) потрібно регулярно клеймити, продавати в базові токени та додавати назад у позицію. Це reinvest. Чим частіше — тим вище APY за рахунок складного відсотка, але вище gas costs.
Reinvest викликають боти-кіпери (будь-хто за невелику винагороду) через reinvest() на Worker контракті. Optimum frequency залежить від розміру позиції та вартості газу — для маленьких позицій раз на день достатньо, для великих — раз на годину.
Деталі механізму реінвесту
Кіпери викликають reinvest() на відповідному Worker. Worker клеймить нагороди (наприклад, CAKE), свопує їх у базові активи через DEX, додає ліквідність у стратегію та збільшує позицію користувача. Повернення комісії кіперу — виплата з нагород (наприклад, 0.1% від суми реінвесту).
Управління ризиками governance
Параметри, які повинні бути під governance timelock:
- Kill factor per-pair
- Min debt size (захист від dust атак)
- Max leverage per-pair
- Reinvest bounty rate
- Нові Workers (додавання нових стратегій)
Жоден із цих параметрів не повинен змінюватися миттєво. Timelock мінімум 48 годин для критичних параметрів (kill factor), 24 години для менш критичних.
| Параметр | Timelock | Приклад зміни |
|---|---|---|
| Kill factor | 48 годин | З 85% до 80% |
| Max leverage | 24 години | З 10x до 8x |
| Min debt size | 24 години | З $100 до $200 |
Ризики, які потрібно прийняти заздалегідь
- Smart contract risk: контракт складний, attack surface великий. Зовнішній аудит обов'язковий. Наш досвід 7+ років у блокчейн-розробці дозволяє гарантувати безпеку.
- Liquidation cascade: при різкому падінні ринку багато позицій одночасно досягають kill factor. Ліквідатори виходять на ринок з великими обсягами, ціна падає ще сильніше, нові ліквідації. Протокол повинен мати emergency pause та параметри максимального обсягу ліквідацій за блок.
- Oracle manipulation: критично захистити LP-price від spot manipulation. TWAP мінімум 30 хвилин + Chainlink secondary source.
Що входить в роботу
- Проектна документація (токеноміка, розрахунки kill factor)
- Смарт-контракти Lending Pool, Vault, Workers
- Інтеграція з оракулами Chainlink
- Keeper інфраструктура для реінвесту та ліквідацій
- Повне unit-тестування та інтеграційне тестування
- Керівництво з експлуатації та документація для governance
- Підтримка після запуску (3 місяці)
Процес розробки
- Токеноміка та параметри (1-2 тижні). Розрахунок kill factor для кожної пари, модель interest rate (utilization-based як Compound), incentive для ліквідаторів. Агентне моделювання liquidation cascade.
- Core контракти (3-5 тижнів). Lending Pool з ibToken, базовий Vault, один тестовий Worker.
- Workers для цільових стратегій (1-2 тижні на Worker). Інтеграція з Uniswap V3, PancakeSwap V3, або Curve залежно від цільових пулів.
- Keeper infrastructure (1 тиждень). Автоматизація reinvest та ліквідацій.
- Аудит (обов'язковий). Не запускати з реальними коштами без зовнішнього аудиту. Мінімум 3-4 тижні для повного аудиту протоколу такої складності.
Строки від проектування до готовності до аудиту: 2-3 місяці. Вартість розраховується після фіналізації цільових пулів та мереж. Замовте розробку leveraged yield farming протоколу під ключ — наші інженери проведуть аудит на кожному етапі.
Зв'яжіться з нами, щоб обговорити ваш проект. Отримайте консультацію по вашому конкретному сценарію.