Розробка бота для автоматичного фарминга
Тримати гроші в одному yield-протоколі й вручну переносити їх при зміні ставок — означає постійно програвати тому, у кого є автоматизація. APY на Aave, Compound, Curve, Convex, Yearn змінюються кожен блок. Ручний моніторинг дає реакцію в годинах. Бот — в хвилинах або секундах.
Завдання не в тому, щоб «написати скрипт, який перекладає гроші». Завдання — побудувати систему, де вартість ротації (газ) не з'їдає виграш від смени протоколу, а сама логіка переключення не ломається при зміні інтерфейсів протоколів.
Де теряються гроші при поганій реалізації
Сліпа погоня за APY без урахування газу
Найчастіша помилка: бот бачить різницю в 2% APY між Aave та Compound і робить ротацію. На mainnet Ethereum транзакція виводу + дозвіл + депозит обходиться в $20-50 на газі. На позиції в $1000 це 2-5% тіла — ротація стає збитковою.
Правило: переносити тільки якщо (APY_new - APY_current) * position_size * time_horizon > gas_cost * safety_factor. time_horizon — передбачуване время в новому протоколі, safety_factor — 2-3x для урахування невизначеності. На L2 (Arbitrum, Optimism) порог значно нижче через дешевий газ.
Несинхронізовані дані про дохідність
APY у DeFi — не фіксована ставка. Це проекція поточного стану пула на рік. Compound supplyRatePerBlock розраховується з utilization rate прямо зараз. Aave додає reward tokens (AAVE staking), які потрібно клеймити окремо. Convex показує boosted APY, який залежить від вашого veCRV балансу.
Бот, який порівнює «APY» з різних джерел без нормалізації, приймає рішення на основі несопоставимих чисел. Потрібна єдина методологія: базовий дохід (з протоколу) + дохід від нагород (з емісії, нормалізований до USD) + compound effect (реінвестування), всім приведене до реального 7-денного ковзного середнього.
Архітектура бота
Шари системи
Data layer: агрегація даних з протоколів. Для кожного протоколу — окремий адаптер. Aave V3 через IPool.getReserveData(), Compound V3 через CometSupply события + 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 проти off-chain логіки
Два підходи:
Off-chain keeper (простіше, дешевше): бот працює на сервері, тримає приватний ключ (або підключається до Gnosis Safe через Safe Transaction Service API), відправляє транзакції напряму. Мінус — залежність від аптайму сервера та довіра до сервера.
On-chain vault з keeper (складніше, безпечніше): смарт-контракт-vault зберігає засоби, keeper (бот) тільки викликає rebalance(). Стратегія закодована в контракті — користувачі можуть верифікувати логіку. Приватний ключ keeper-бота може тільки викликати rebalance(), не виводити засоби. Це стандарт для Yearn-style 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 |
Мультичейн-бот працює з кількома RPC через провайдери ethers.js/viem. Bridge ліквідності між мережами — окремого завдання з окремими ризиками (bridge эксплойти), зазвичай не включаємо в автоматику без ручного підтвердження.
Стек
TypeScript + viem для on-chain взаємодій. Node.js для keeper-процесу. Redis для кэширування даних. PostgreSQL для історії ротацій та аналітики. Docker для деплоя. PM2 або systemd для моніторингу процесу.
Hardhat/Foundry для on-chain vault контрактів, якщо вибираємо цей шлях. Тесты на fork mainnet через Foundry vm.createFork — гоняємо сценарії ротації на реальному стані мережі.
Орієнтири за часом
Off-chain keeper бот для 2-3 протоколів на одній мережі — 3-5 днів. З нормалізацією APY, урахуванням газу та Telegram моніторингом — ближче до 1 тижня. On-chain Yearn-style vault з окремими стратегіями — 2-4 тижні включаючи тесты. Вартість розраховується після уточнення протоколів та мереж.