Бот для автоматичного фармінгу: нормалізація APY та мінімізація газу

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Бот для автоматичного фармінгу: нормалізація APY та мінімізація газу
Середній
~3-5 днів
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1351
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    951
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1186
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    922

Тримати гроші в одному yield-протоколі та вручну переносити їх при зміні ставок — означає постійно програвати тому, у кого є автоматизація. APY на Aave, Compound, Curve, Convex, Yearn змінюються кожен блок. Ручний моніторинг дає реакцію за години — бот реагує за хвилини, а то й секунди. Проблема посилюється gas wars та MEV-ботами, які перехоплюють транзакції. Без автоматизації ви втрачаєте до 30% потенційної дохідності через запізнення з перекладкою. Головне завдання — побудувати систему, де вартість ротації (газ) не з'їдає виграш від зміни протоколу, а логіка перемикання стійка до змін інтерфейсів. У цій статті — наш підхід, напрацьований за роки досвіду в DeFi.

Як створити бота для автоматичного фармінгу без втрат на газі?

Де втрачаються гроші при поганій реалізації

Сліпа гонитва за APY без урахування газу

Найчастіша помилка в автоматичному фармінгу: бот бачить різницю в 2% APY між Aave та Compound і робить ротацію. На mainnet Ethereum транзакція виведення + схвалення + депозит обходиться в $20–50 на газі. На позиції в $1000 це 2–5% тіла — ротація стає збитковою. Кожна непотрібна ротація може коштувати $50 на газі. Середня затримка ручного моніторингу — 6 годин, бот реагує за 2 хвилини.

Правило: переносити тільки якщо (APY_new - APY_current) * position_size * time_horizon > gas_cost * safety_factor. time_horizon — передбачуваний час перебування в новому протоколі, safety_factor — 2–3× для врахування невизначеності. На L2 (Arbitrum, Optimism) комісія становить $0.1–0.5, тому поріг значно нижчий.

Несинхронізовані дані про дохідність

APY в DeFi — це не фіксована ставка. Це проекція поточного стану пулу на рік. Compound supplyRatePerBlock рахується з utilization rate прямо зараз. Aave додає reward tokens (AAVE staking), які потрібно клеймити та враховувати окремо. Convex показує boosted APY, який залежить від veCRV балансу вашого vault. Без нормалізації APY ви порівнюєте непорівнянні числа.

Наш yield farming бот для Aave та Compound використовує єдину методологію: base yield (з протоколу) + reward yield (з emission, нормалізований до USD) + compound effect (реінвестування), все приведене до реального 7-денного ковзного середнього. Це дозволяє уникнути хибних спрацювань при короткострокових сплесках.

Чому важлива нормалізація APY?

Без нормалізації APY ви порівнюєте яблука з апельсинами. Наш бот для кожного протоколу застосовує адаптер, який приводить дохідність до єдиного стандарту. Наприклад, для Aave V3 ми враховуємо liquidityRate + aToken реінвестування, для Compound V3 — supplyRate + компенсаційні токени. Всі дані згладжуються ковзним середнім за 7 днів, щоб відсікти короткострокові сплески. Це дає стабільний сигнал для прийняття рішень і дозволяє реалізувати арбітраж дохідності між пулами.

Як розрахувати поріг ротації з урахуванням газу?

Поріг обчислюється динамічно під кожну пару протоколів. Використовуємо формулу:

  • gas_cost — оцінка газу через eth_estimateGas для Multicall3 (одна tx на approve+deposit).
  • profit = (APY_new - APY_current) * position * expected_stay_days / 365.
  • Ротація виконується, якщо profit > gas_cost * 2 (дворазовий запас).

Для мультичейн-бота враховується також вартість bridge — вона може бути значною, тому bridge-ротації ми зазвичай робимо тільки з ручним підтвердженням. Потенційний додатковий дохід при правильному налаштуванні — до $5000 на місяць на позиції в $100k.

Як побудувати стратегію ротації: покроково

  1. Нормалізація APY — приводимо дохідність кожного протоколу до єдиного стандарту, використовуючи 7-денне ковзне середнє.
  2. Розрахунок порогу газу — для кожної пари протоколів динамічно рахуємо, при якій різниці APY ротація окупається.
  3. Застосування ризик-фільтрів — виключаємо протоколи без аудиту, пули з низькою ліквідністю, забороняємо bridge-ротації без ручного підтвердження.
  4. Тестування на форку — проганяємо всі сценарії на реальному стані мережі через Foundry vm.createFork.
  5. Деплой та моніторинг — запускаємо keeper з Telegram-сповіщеннями та алертами при збоях.

Архітектура бота для автофармінгу

Шари системи

Data layer: агрегація даних з протоколів. Для кожного протоколу — окремий адаптер. Aave V3 через IPool.getReserveData(), Compound V3 через CometSupply events + getSupplyRate(), Curve через get_virtual_price() та Convex rewardRate. Дані пишемо в Redis з TTL 60 секунд, щоб не смикати RPC на кожен розрахунок.

Strategy engine: логіка прийняття рішень. Оцінює поточну позицію, всі кандидати на ротацію, рахує net APY з урахуванням газу, приймає рішення. Тут же — ризик-фільтри: не входити в протоколи, які не пройшли аудит, не тримати більше X% в одному протоколі, виключити пули з TVL нижче порогу (ризик ліквідності при виведенні).

Execution layer: збірка та відправка транзакцій. Використовуємо viem для побудови транзакцій — він дає типізовані контракти через ABI та правильну оцінку газу. Для batching: Multicall3 дозволяє об'єднати approve та deposit в одній транзакції, знижуючи газ на 30–40%.

Monitoring: Telegram-сповіщення про кожну ротацію (скільки вклали, куди, очікуваний APY), алерти при помилках транзакцій, дашборд з історією позицій через The Graph або власний індексатор.

On-chain vs off-chain логіка

Два підходи:

Off-chain keeper (простіше, дешевше): бот працює на сервері, тримає приватний ключ (або підключається до Gnosis Safe через Safe Transaction Service API), відправляє транзакції напряму. Мінус — залежність від аптайму сервера та довіра до сервера.

On-chain vault з keeper (складніше, безпечніше): смарт-контракт-vault зберігає кошти, keeper (bot) тільки викликає rebalance(). Стратегія закодована в контракті — користувачі можуть верифікувати логіку. Приватний ключ keeper-бота може тільки викликати rebalance(), не виводити кошти. Це стандарт для Yearn-style vault, описаний в EIP-4626.

Для особистого бота з невеликою сумою — off-chain keeper достатньо. Для протоколу з чужими коштами — тільки on-chain vault з аудитом.

Характеристика Off-chain keeper On-chain vault
Безпека коштів Середня (ключ на сервері) Висока (контракт контролює)
Складність Низька Висока (аудит, газ)
Прозорість Тільки у оператора Повна (верифікація контракту)

Робота з кількома мережами

Мережа Особливості Основні протоколи
Ethereum mainnet Високий газ, високий TVL Aave V3, Compound V3, Curve, Convex
Arbitrum Дешевий газ, багатий DeFi Aave V3, GMX, Radiant, Camelot
Optimism Дешевий газ, Velodrome Aave V3, Velodrome, Extra Finance
Base Нова, зростаючий TVL Aave V3, Aerodrome, Moonwell

Мультичейн фармінг вимагає bridge-ротації, які ми зазвичай не автоматизуємо через ризики експлойтів bridge. Для мультичейн-бота використовуємо тільки ручне підтвердження bridge-операцій.

Стек

TypeScript + viem для on-chain взаємодій. Node.js для keeper-процесу. Redis для кешування даних. PostgreSQL для історії ротацій та аналітики. Docker для деплою. PM2 або systemd для моніторингу процесу.

Hardhat/Foundry для on-chain vault контрактів, якщо вибираємо цей шлях. Тести на fork mainnet через Foundry vm.createFork — проганяємо сценарії ротації на реальному стані мережі.

Що входить в роботу

  • Аналіз вибраних протоколів та мереж, нормалізація APY.
  • Розробка адаптерів для кожного протоколу (включно зі збором даних та відправкою транзакцій).
  • Реалізація стратегічного двигуна з урахуванням газу та ризик-фільтрів.
  • Налаштування моніторингу (Telegram, дашборд).
  • Тестування на fork mainnet (Foundry).
  • Документація з налаштування та експлуатації.
  • Гарантія на код 3 місяці.

Орієнтири за термінами

Off-chain keeper бот для 2–3 протоколів на одній мережі — 3–5 днів. З нормалізацією APY, урахуванням газу та Telegram моніторингом — ближче до 1 тижня. On-chain Yearn-style vault з окремими стратегіями — 2–4 тижні включаючи тести. Вартість розраховується після уточнення протоколів та мереж. Отримайте консультацію — оцінимо ваш проект безкоштовно.

Приклад конфіга для off-chain keeper
protocols:
  - name: aave-v3-eth
    adapter: aave-v3
    pool: 0x...
    gas_estimate: 200000
  - name: compound-v3-eth
    adapter: compound-v3
    comet: 0x...
strategy:
  min_profit_multiple: 2
  max_rotations_per_day: 10
  excluded_protocols:
    - convex (застарілий аудит)

Замовте розробку у нас — ми вже побудували 15+ таких систем для різних протоколів. Гарантуємо прозорий код та регулярні оновлення адаптерів. Зв'яжіться з нами, щоб обговорити ваш сценарій. Отримайте консультацію — оцінимо ваш проект безкоштовно.

Послуги з розробки DeFi-протоколів повного циклу

Ми проектуємо модульні DeFi-протоколи, в яких математика стейблкоїнів, ліквідності та оракулів працює без збоїв. Mango Markets — краш-тест: атакуючий маніпулював spot price через один акаунт, взяв кредит під завищений колатераль і вивів велику суму. Оракул брав ціну з єдиного джерела без TWAP. Не баг у коді — це архітектурне рішення, яке стало вразливістю. Наш досвід показує: будь-який DeFi-протокол — це система ставок на те, що всі компоненти, від розрахунків до економічних стимулів, вибудовані правильно одночасно.

Ми не пишемо код під «якщо все працює, не чіпай». Ми моделюємо стрес-сценарії: каскадні ліквідації, депег, флеш-позики. І тільки після цього — події, які не зламають протокол. Наші послуги з розробки DeFi-протоколів повного циклу охоплюють усі етапи — від архітектури до запуску та підтримки.

Чому оракули є критичним компонентом DeFi?

Більшість великих зломів DeFi починалися з маніпуляції оракулом. Розберемо три шари, які ми використовуємо в кожному проекті.

Spot price як оракул — не варіант. Uniswap v2 spot price можна зсунути flash loan за одну транзакцію. Ціна в кінці блоку — єдине, що потрапляє в state, її і читає оракул. Схема атаки: зайняти через flash loan → купити актив у пул → ціна піднялася → взяти кредит під завищений колатераль → продати актив → повернути flash loan. Одна транзакція.

TWAP як захист. Uniswap v3 observe() усереднює ціну за період (30 хвилин). Маніпуляція вимагає утримувати ціну кілька блоків — це коштує дорого. Але TWAP повільно реагує на легітимні зміни, що відкриває вікно для arbitrage на ліквідації при різких рухах.

Chainlink Price Feeds — агрегація від багатьох data providers з медіаною. Стандарт для lending. Проблема: heartbeat 1–24 години та deviation threshold 0.5%. Якщо ціна не рухається, фід може не оновлюватися добу. У волатильному ринку — lag.

Оракул Механізм Захист від маніпуляції Затримка
Chainlink Медіана від незалежних провайдерів Висока (децентралізація) До 24 год при 0% руху
Uniswap v3 TWAP Середня ціна за N блоків Висока (складно утримувати) 30 хв — 1 год
Pyth Network Cross-chain low-latency Середня (залежність від publisher) Секунди

У продакшені ми використовуємо дворівневу перевірку: Chainlink aggregator + Uniswap v3 TWAP як верифікатор. Якщо розбіжність більша за N% — транзакція відхиляється, система ставиться на паузу.

Як захистити DeFi-протокол від атак флеш-позик?

Flash loan перетворює будь-якого користувача на володаря необмеженого капіталу на одну транзакцію. Тому при проектуванні контрактів ми припускаємо: доступ до необмеженого капіталу є у всіх. Це змінює threat model повністю.

Легітимні застосування flash loan — арбітраж, ліквідація, самоліквідація. Але протокол повинен перевіряти, що позика не використовується для маніпуляції: оракул не повинен читати ціну з пулу, який можна зсунути за одну транзакцію. Ми додаємо перевірки на block.timestamp та мінімальну глибину ліквідності.

Як ми забезпечуємо безпеку DeFi-протоколу?

Ми не покладаємося на один шар захисту. Кожен контракт проходить формальну верифікацію математичної моделі, стресове тестування на форку mainnet та аудит щонайменше двома незалежними командами (серед яких сертифіковані аудитори ConsenSys Diligence). Гарантія — багаторічний досвід розробки та супроводу протоколів із сукупним TVL понад $500M.

Ключові компоненти DeFi-архітектури

Тип протоколу Основна механіка Головний ризик
DEX (AMM) x*y=k або concentrated liquidity impermanent loss, oracle manipulation
Lending collateral ratio, liquidation bad debt при каскадних ліквідаціях
Yield aggregator автокомпаундинг стратегій rug через strategy upgrade
Derivatives / Perps funding rate, mark price liquidation cascades, socialized losses
Liquid staking stETH-style rebasing depegging при mass unstake

AMM: від x*y=k до concentrated liquidity

Uniswap v2 використовує x * y = k. LP-токени ERC-20 — кожен пул випускає свій токен пропорційно частці. Проблема: ліквідність розмазана по всій кривій, більша частина не використовується.

Uniswap v3 та позиції ERC-721: concentrated liquidity — LP надає ліквідність у діапазоні [priceLow, priceHigh]. Capital efficiency до 4000x для стабільних пар. Але ERC-721 ламає vault-стратегії під ERC-20. Управління ranges — окрема інженерна задача: позиція виходить з діапазону при русі ціни, перестає заробляти fees, стає single-asset. Протоколи типу Arrakis Finance автоматично rebalance. Якщо будуєте vault поверх v3, потрібен власний range manager або інтеграція з існуючим.

Slippage у v3 розраховується через sqrtPriceX96 — 96-бітна fixed-point математика. Помилки на фронтенді призводять до розбіжності між видимим і фактичним slippage.

Curve для пар з близькими цінами (stablecoin/stablecoin, stETH/ETH) використовує інваріант, що комбінує constant product і constant sum. Менше slippage в діапазоні peg. Контракти на Vyper, код математично щільний, аудитувати складно.

Lending протоколи: collateral, liquidation, bad debt

LTV визначає максимальний кредит під колатераль. Liquidation threshold — рівень ліквідації. Різниця — буфер для liquidator. Типовий приклад: LTV 75%, liquidation threshold 80%, bonus 5%. Якщо ціна падає на 20%+, позиція відкрита до ліквідації.

Каскадні ліквідації: багато позицій ліквідується одночасно → ліквідатори продають колатераль → ціна падає → наступна хвиля. LUNA/UST — класичний каскад.

Якщо колатераль знецінюється швидше ліквідації, протокол отримує bad debt. Aave використовує Safety Module (застейканий AAVE), Compound — reserves. Без backstop bad debt соціалізується через dilution supply-токена або взаємозалік.

Проектування системи ліквідації вимагає моделювання стрес-сценаріїв: падіння єдиного liquidation bot, високий gas, делістинг колатералю.

Yield farming та incentive mechanics

Liquidity mining — роздача токенів управління LP-провайдерам. Проблема mercenary capital: фармери приходять, продають токени, йдуть. TVL фіктивний.

Стійкі механіки: protocol-owned liquidity (Olympus bonding), veToken (CRV locked → boost + governance), locked staking з penalty. Ve-модель при неправильній реалізації створює governance concentration. Потрібен timelock на зміни gauge weights та ліміти на votingPower.

Що входить у нашу розробку DeFi-протоколів

  • Архітектурна документація: діаграми взаємодії контрактів, стрес-тести ліквідацій, розрахунки оракулів.
  • Реалізація на Solidity 0.8.x з OpenZeppelin 5.x (AccessControl, ReentrancyGuard, Pausable, TimelockController) та Solmate для gas-optimised base contracts.
  • Foundry fork-тести на реальному mainnet (Uniswap, Chainlink, Aave) — тести до деплою покривають всі сценарії. Завдяки Foundry час тестування скорочується на 80% порівняно з Hardhat.
  • Аудит: мінімум два незалежних аудитори для TVL від значного рівня. Code4rena або Sherlock для bug bounty.
  • Деплой з Gnosis Safe 3/5 multisig + timelock 48–72 години.
  • Моніторинг через Tenderly (alerts, симуляції), OpenZeppelin Defender (automation), Forta (on-chain threat detection).
  • Підтримка після запуску: оновлення, патчі, апгрейди через proxy.

Наші компетенції та досвід

Ми розробляємо DeFi-протоколи з моменту активного розвитку ринку — за цей час реалізували 30+ проектів із загальним TVL понад $500M. Серед клієнтів — протоколи в топ-20 за TVL на Ethereum, Arbitrum та Base. Команда сертифікованих розробників Solidity, які пройшли аудиторські треки ConsenSys Diligence. Гарантія якості підтверджена багаторічним досвідом та відсутністю інцидентів після запуску.

Терміни

  • DEX з AMM (Uniswap v2 fork): 6–10 тижнів
  • Lending protocol (Aave-style, один колатераль): 3–5 місяців
  • Yield aggregator з кількома стратегіями: 2–4 місяці
  • Повноцінний DeFi-протокол з governance: 5–8 місяців включаючи аудит

Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту. Отримайте консультацію з архітектури DeFi-протоколу — ми проаналізуємо ризики та запропонуємо оптимальне рішення.