Розробка бота для сендвіч-атак

Розробка бота для сендвіч-атак

Сендвіч-бот — це легальний MEV-інструмент. Арбітраж, ліквідації, сендвічи — три основні стратегії MEV-видобутку в продакшені. Сендвіч конкретно експлуатує slippage tolerance користувачів DEX: бот бачить жертву в mempool, вставляє свою покупку перед нею (frontrun), жертва рухає ціну вгору, бот продає після (backrun). Різниця — прибуток бота, убиток жертви в межах її власної slippage tolerance. Це арбітраж на інформації про порядок транзакцій.

Розробка такого бота — це одночасно задача про швидкість (latency mempool), економіку (калькулятор прибутковості), та інфраструктуру (надійний деплой без втрат).

Де більшість ботів втрачають гроші

Неточний розрахунок прибутковості

Найчастіша помилка початківців MEV-розробників — розрахунок profit без урахування всіх costs. Здається очевидним, але в практиці зустрічається регулярно.

Реальний P&L сендвіча:

profit = amountOut_backrun - amountIn_frontrun
costs = gasCost_frontrun + gasCost_backrun + builderTip
netProfit = profit - costs

gasCost при агресивних tips на Ethereum mainnet — це не дрібниця. Якщо сендвіч приносить $2, а builder tip становить $1.5 — угода збиткова. Бот повинен симулювати весь пакет транзакцій перед відправкою і відкидати угоди з негативним net profit.

Симуляція через eth_call на поточному стейті — повільна. Продакшн-боти використовують власні in-process EVM симуляторы (revm на Rust або аналоги) для мікросекундної оцінки.

Revert через неправильний розрахунок price impact

Бот розрахував прибуток у момент T, але відправив транзакцію в момент T+50ms. За цей час інший бот виконав свій frontrun. Стан пулу змінився. Власний frontrun бота тепер рухає ціну сильніше розрахованого, жертва потрапляє за межі slippage tolerance та її транзакція ревертується. Backrun не потрібен, але gas за frontrun вже витрачений.

Захист: backrun транзакція повинна бути conditional — перевіряти, що цільова транзакція жертви дійсно була включена перед нею. У Flashbots bundle це реалізується через reverting_tx_hashes — якщо жертва ревертилась, весь bundle не включається.

Конкуренція та builder relationship

На Ethereum після The Merge 95%+ MEV-bundles проходять через block builders (Flashbots, beaverbuild, rsync-builder). Бот, який відправляє транзакції в публічний mempool напряму, програє конкурентам з private relay у всіх випадках.

Правильна інфраструктура: MEV-Share (Flashbots matchmaker для user-refund MEV), прямі з'єднання з топ-builders через їхні private endpoints, моніторинг mev-boost relay для розуміння поточного winning builder.

Архітектура production сендвіч-бота

Мемпул моніторинг

Стандартний eth_subscribe("pending") через WebSocket — занадто повільно. Між появою транзакції в приватних мемпулах великих нод та публічним анонсом проходить 50–200ms. За цей час професійні боти вже прийняли рішення.

Оптимальна схема:

1. Прямі пірингові з'єднання з кількома Ethereum-нодами (Geth, Erigon) для отримання транзакцій до їхнього широкого розповсюдження.
2. Блоб мемпул фід від спеціалізованих провайдерів (bloXroute, Blocknative) — платний, але дає доступ до транзакцій на 100–300ms раніше публічного анонсу.
3. Власна нода з --txpool.pricelimit 0 — приймає всі транзакції без мінімального gas price фільтра.

Фільтрація та оцінка кандидатів

З тисяч pending-транзакцій потрібно швидко вибрати сендвіч-кандидатів. Критерії:

• to адреса = відомий DEX router (Uniswap V2/V3, Sushiswap, Curve, Balancer)
• Декодований calldata: swap зі slippage tolerance > 0.5%
• amountOutMinimum значно нижче поточного amountOut за getAmountsOut
• Gas price достатній для включення в наступний блок

Декодування calldata для Uniswap V3 exactInputSingle та exactInput (multi-hop) — обов'язковий компонент. Для multi-hop свопів розрахунок складніший: потрібно симулювати кожен hop по черзі.

Розрахунок оптимального frontrun amount

Ключова математика: скільки купити в frontrun, щоб максимізувати прибуток?

Для Uniswap V2 з формулою x * y = k існує аналітичне рішення для оптимального input amount. Для V3 з concentrated liquidity та tick-based ціною — чисельна оптимізація (бінарний пошук по amount).

Приблизна формула для V2:

optimalInput ≈ sqrt(k * victimAmount) - reserveIn

Але без урахування gas costs та builder tip. Реальна оптимізація враховує marginal cost кожного додаткового долара frontrun amount.

Execution через Flashbots

const bundle = [
  { signer: wallet, transaction: frontrunTx },
  { hash: victimTxHash },           // цільова транзакція жертви
  { signer: wallet, transaction: backrunTx }
];

const bundleResponse = await flashbotsProvider.sendBundle(
  bundle,
  targetBlockNumber,
  { minTimestamp: 0, maxTimestamp: 0, revertingTxHashes: [victimTxHash] }
);

revertingTxHashes: [victimTxHash] — ключовий параметр: якщо жертва ревертилась (наприклад, інший бот вже виконав свій сендвіч), весь bundle дропається. Бот не втрачає gas на frontrun без backrun.

Мультичейн та L2 специфіка

На Arbitrum та Optimism немає публічного mempool в класичному сенсі — sequencer отримує транзакції напряму та публікує їх атомарно в батчах. MEV-можливості обмежені, але не виключені: DEX arbitrage між різними протоколами на L2 працює.

На BSC сендвічи активні, конкуренція нижча ніж на Ethereum mainnet, але validator tips працюють по іншій схемі — прямі з'єднання з BSC validators через їхні private endpoints.

Base (OP Stack) — sequencer власний Coinbase, MEV політика обмежує класичні сендвічи. Арбітраж між Aerodrome, BaseSwap, Uniswap V3 на Base працює краще.

Стек розробки

Бот пишемо на Rust з бібліотекою ethers-rs (або новішою alloy) для максимальної продуктивності. Критичні компоненти — EVM симулятор (revm), мемпул стриминг, bundle submission — в одному процесі без міжпроцесної комунікації.

Смарт-контракт для atomic execution (щоб backrun та frontrun виконувались атомарно з одного контракту, економлячи на gas) — Solidity 0.8.x з мінімальним footprint. Контракт не зберігає state, тільки delegatecall до логіки виконання.

Моніторинг: кастомний Prometheus + Grafana дашборд з метриками: бандли в годину, inclusion rate, середній profit per bundle, revert rate.

Процес розробки

Дослідження (2–3 дні). Аналіз цільового чейна та DEX-екосистеми, оцінка MEV-opportunity розміру через dune analytics дані.

Розробка (2–3 тижні). Мемпул стриминг, декодер транзакцій, калькулятор прибутковості, Flashbots/relay інтеграція, atomic execution контракт.

Тестування (3–5 днів). Backtesting на історичних блоках через Foundry fork, simulated competition, paper trading на testnet.

Запуск та оптимізація (ongoing). Перший деплой на mainnet з обмеженим розміром позицій, потім поступове масштабування по мірі валідації прибутковості.

Орієнтири по строкам

Базовий Uniswap V2/V3 сендвіч-бот — 1–2 тижні. Multi-DEX з підтримкою Curve, Balancer, Sushiswap + мультичейн — 3–5 тижнів. Включаючи оптимізацію latency та builder relationships.