Zavod MEV bot

Введение

Порог входа

Эта статья написана для крипто-энтузиастов, которые совсем не знакомы или уже сталкивались с MEV, но не погружались в его механику. ‼️Дальше идёт описание общего принципа MEV, функционал нашего же бота описан в разделе "Как работает наш бот?".

Некоторые части могут показаться сложными — это нормально.
Команда Завода искренне верит, что именно ты дочитаешь до конца ❤️
А если в процессе что-то станет неочевидным — можно:

• перечитать,
• заглянуть в словарь,
• или обратиться к высшим силам

Немного о блокчейне Solana

Прежде чем углубляться в MEV, стратегии и параметры, важно договориться о базовых вещах. Без этого всё остальное начинает выглядеть как набор заклинаний.

Что такое блокчейн Solana простыми словами

Блокчейн Solana — это очень быстрый журнал действий.
В этот журнал постоянно записываются транзакции: обмены, переводы, работа децентрализованных программ (смарт-контрактов).

Что такое блок в Solana

Блок — это набор транзакций, которые были:

• приняты сетью,
• отсортированы,
• и подтверждены валидатором-лидером.

Важно понимать:
блок — это не просто «мешок транзакций», а упорядоченная структура.

Внутри блока транзакции:

• идут в определённом порядке,
• обрабатываются последовательно,
• и могут влиять друг на друга.

Немного забегая вперёд сообщаем, что порядок исполнения вашей транзакции относительно других транзакций очень важен. Запоминаем, что внутри блока каждой транзакции присвоено своё место.

Пример блока в обзорщике Solscan. Содержит 1192 транзакции, которые были исполнены в порядке приоритета.

Общий принцип

Основные понятия

MEV (Maximum Extractable Value) — это методы и автоматизированные решения, которые сканируют сеть в поиске возможностей извлечения профита. Простыми словами, программы для заработка напрямую на блокчейне. В нашем случае основной интерес представляет DEX-арбитраж внутри блокчейна Solana.

DEX (Decentralized Exchange) - тип биржи, полностью работающей на блокчейне. Обычно такие биржи имеют веб-интерфейс, но по своей сути, являются набором программ (смарт-контрактов). Примеры: Raydium, Orca. Биржи вроде Binance, OKX являются централизованными, так как у них есть явный владелец, а данные и инфраструктура хранятся на обычных физических серверах.

DEX-арбитраж — это стратегия, основанная на разнице цен одного и того же актива. Если на одной из бирж происходит крупный обмен, то цена на данный актив на данной бирже меняется, в результате возникает дисбаланс, который и становится арбитражной возможностью.

Мы как раз и используем этот дисбаланс: мев-бот покупает токен там, где он дешевле, и сразу продаёт там, где дороже. Всё происходит в одной сети Solana и в рамках одной транзакции, поэтому риск потери средств отсутствует — либо операция целиком успешна, либо не происходит вовсе.

По сути, DEX-арбитраж на Solana — это автоматическое выравнивание цен между пулами после резких сделок. Мы не «угадываем рынок», а просто пользуемся краткосрочной разницей цен, которая возникает на несколько миллисекунд.

Принцип атомарного арбитража заключается в том, что покупка и продажа происходят в рамках одного набора транзакций, отправляемых через смарт-контракт. Если все условия для исполнения каждой транзакции выполнены — сделка проходит и мы извлекаем профит из сети. Если хотя бы одно из условий не выполнено (невозможно купить, невозможно продать, изменилась цена и т.д.) — транзакция фейлится. В этом и заключается атомарность: либо всё, либо ничего.

Покупка и продажа при помощи бота происходят после оценки пулов ликвидности популярных обменников
(Raydium, Orca и др.), а также протоколов со схожей логикой, например Meteora.

Большинство стратегий подразумевает спам транзакциями — многократную отправку, которая повышает шанс успешного арбитража.
При этом в процессе спама мы:

• сжигаем SOL на комиссиях,
• или платим *Jito tips*.

Залог успешного атомарного арбитража — грамотная инфраструктура. Недостаточно просто отправлять транзакции: важно видеть токены, анализировать происходящее, иметь преимущество в скорости софта и настраивать параметры под известные профитные сценарии.

Краткий принцип работы

Принцип работы бота Завода следующий.

Программа, условно называемая «монитором», сканирует токены, на которых есть реальная арбитражная активность — то есть работа других арбитражных ботов.
Часто такую активность можно определить по адресам смарт-контрактов сторонних систем.

Далее эти токены проходят через набор фильтров:

• количество пулов ликвидности,
• объёмы ликвидности,
• торговую активность,
• и другие параметры.

На токенах, прошедших фильтры, бот запускает арбитраж выбранным вами методом - например, RPC, Jito с UUID, forwarder с прокси и др. (если слова не знакомы, просто читаем дальше, чтобы узнать что это такое) и с заданными параметрами: количество транзакций в единицу времени, количество минтов в транзакции, значения *compute units*, *Jito tips* и другие настройки.

Если фильтры настроены корректно и на рынке присутствует нужная активность, профит с арбитражей перекрывает затраты на газ. Иногда одно удачное «приземление» в нужное место блока может принести доход, покрывающий сутки или даже недели спама. При этом уровень риска полностью задаётся пользователем: более агрессивные комиссии в отдельных случаях дают больший потенциальный профит, но при ошибках в фильтрах можно потратить SOL впустую.

Всё в ваших руках.
При осознанном подходе, хорошо настроенном софте и удачных рыночных условиях арбитраж может приносить стабильный результат — но только если действительно разбираться в механике ⚙️

MEV dictionary

MEV (Maximum Extractable Value)

Фактическая возможность извлечения прибыли путём прямого ончейн-взаимодействия с сетью. В широком смысле MEV включает разные подходы: арбитраж, фронтран, бэкран, выкуп ликвидаций и другие механики.
В контексте этого бота MEV рассматривается исключительно как ончейн-арбитраж. Функционал бота на текущий момент не выходит за рамки арбитражных сценариев.

Searcher

Человек (или система), ищущий и реализующий MEV-возможности в сети.
Если вы читаете этот гайд и запускаете бота — поздравляем, вы searcher.

Mint

Адрес контракта токена в сети Solana.
Любой SPL-токен имеет свой уникальный mint-адрес.

Base mint

Токен, относительно которого совершается арбитраж.
Чаще всего это wSOL или USDC, но в нестандартных стратегиях base mint может быть любым токеном.

To land / landing

«Приземлить» транзакцию — означает успешно включить её в блок.
Термин часто используется для описания удачного попадания в нужное место блока.

Arb (arbitrage)

Успешно выполненный арбитраж, при котором покупка и продажа прошли атомарно и принесли профит.

wSOL (Wrapped SOL)

«Обёрнутая» SOL — та же самая SOL, представленная в виде токена в сети SOL. Обычный SOL особенный, он требует других методов взаимодействия. Разработчикам часто удобно работать с WSOL, так как он является обычным токеном, как и любой другой и имеет ту же ценность, что и SOL 1:1.
По умолчанию wSOL является base mint в большинстве стратегий.

Важно:

• комиссии всегда платятся в SOL,
• профит от арбитража чаще всего получается в wSOL,
• unwrap(обмен одного на другое) выполняется вручную (например, через интерфейс Raydium).

Validator

Нода, участвующая в консенсусе сети Solana и имеющая право включать транзакции в блоки.

Leader

Валидатор, который в конкретный слот является ответственным за формирование блока.
Последовательность лидеров известна заранее, что позволяет строить инфраструктуру с учётом расписания.

RPC (Remote Procedure Call)

Прокси-нода, через которую транзакции и запросы отправляются в сеть.
RPC не принимает решений о включении транзакций, а лишь передаёт их валидаторам.

Mempool

Очередь транзакций, ожидающих включения в блок.
В Solana нет публичного мемпула, как в Ethereum. Это усложняет пассивное наблюдение за транзакциями и влияет на механику MEV.

Ранее валидаторы могли активно манипулировать порядком транзакций, в том числе с MEV-целями. После обновлений протокола такие возможности были существенно ограничены.

Jito

Крупная инфраструктура и экосистема вокруг MEV в Solana.
Включает:

• валидаторов,
• off-chain анализ транзакций,
• инструменты приоритизации,
• систему tips.

Jito играет важную роль в современных MEV-сценариях.

Tips (Jito tips)

Дополнительная плата за включение транзакции в блок при использовании Jito.
Аналог приоритетной комиссии в классическом RPC-кастинге, но с другой логикой распределения.

Classic Jito

Исторический подход к работе с Jito, при котором транзакции отправляются на off-chain endpoint Jito для оценки их потенциальной выгодности.
Транзакции включаются в блок только при соответствии внутренним критериям вероятности профита, за что Jito получает tips.

В условиях низкой конкуренции стратегия была доступна и эффективна.
Сегодня она остаётся рабочей, но, как правило, только для участников с серьёзной инфраструктурой. Существуют неподтверждённые предположения о наличии механизмов приоретизации или фильтрации качества транзакций.

UUID (Jito UUID)

Уникальный идентификатор пользователя Jito.
Добавляется в транзакции и увеличивает лимит запросов к Jito endpoint’ам (например, до 5–10 запросов в секунду вместо стандартного).

UUID можно получить через Jito или сторонние каналы, но его эксклюзивность не всегда гарантирована.

Microlamports

Единица измерения приоритетной комиссии.
1 lamport = 0.000000001 SOL
Microlamports используются для тонкой настройки комиссий и tips.

Memo

Опциональная текстовая метка в транзакции.
Используется для удобного поиска, фильтрации и последующего анализа транзакций.

LUT (Lookup Table)

Механизм Solana для сокращения размера транзакций за счёт вынесения адресов в отдельные таблицы.
Неправильная работа с LUT — частая причина неуспешных транзакций.

Slot / Block

Slot — временной интервал, в рамках которого формируется блок.
В разговорной речи часто используется просто «блок».

Методы отправки транзакций

Связь методов отправки и стратегий

Прежде чем рассмотреть стратегии применения наших орудий, давайте рассмотрим что они из себя представляют.

Инфраструктура отправки транзакций не менее важна, чем стратегия, по которой вы работаете. При этом важно понимать: при хорошем рынке любой метод отправки может быть профитным. В этом разделе мы говорим не про «единственно верный путь», а про cost-эффективность и способы общения с сетью.

Методы отправки транзакций можно воспринимать как часть стратегии. У каждого из них есть свои сильные и слабые стороны: есть более универсальные варианты, есть решения под конкретные сценарии.

Ваша идеальная картина выглядит так:

• Попадание в каждый блок Минимум пропусков, постоянное присутствие в блоках.
• Отсутствие переплаты за комиссии Cost-efficiency важнее агрессии, если рынок это позволяет.
• Стабильная работа при высокой нагрузке сети Транзакции продолжают отправляться даже в пиковые моменты.
• Попадание в разные места блока Не застревать в одном и том же слое, а распределяться по блоку. На этом пункте остановимся поподробнее: транзакция может попасть в начало блока, в середину или в конец, то есть ей присваивается номер. Почему нам это важно? Допустим, в блоке исполнился крупный свап → цена изменилась после этой транзакции. Если наш арбитраж попал в блок до транзакции - мы не сможем получить профит, после - сможем. Раньше ≠ лучше всегда; позже ≠ хуже всегда. Важно попасть в правильное место, а не просто в блок.

Эти четыре пункта — хорошая модель для оценки любого метода отправки.

К способам

Классический RPC-спам

Solana RPC (Remote Procedure Call) — это ключевой мост, который позволяет децентрализованным приложениям (dApp’ам), кошелькам и инструментам взаимодействовать с блокчейном Solana, отправляя структурированные запросы (JSON) к нодам. Через RPC они могут запрашивать данные (например, балансы и транзакции) и отправлять новые транзакции, не запуская собственную валидатор-ноду, получая доступ к высокой скорости и низким комиссиям Solana.
Проще говоря, это способ, с помощью которого ваше приложение «разговаривает» с блокчейном.

Классический RPC-спам — это самый простой и прямой способ попытаться забрать арбитражную сделку. Идея такая: мы отправляем одну и ту же транзакцию через один или несколько RPC, пытаясь как можно быстрее донести её до сети Solana.

При этом возможны три сценария:

Успех — транзакция попала в блок (все условия выполнены).

«Успешный неуспех» — мы всё сделали правильно, часть условий не выполнены (невозможно купить / продать с разницей цены, недостаточно средств для осуществления арбитража и т.д.). В данном случае мы сожгли немножко SOL на попытку пропихнуть свой bundle транзакций в сеть.

Неуспех — что-то сломалось: параметры, LUT, перегруженные данные или другие ошибки.

RPC-спам позволяет выставлять практически любую скорость. Ограничения здесь простые и приземлённые: стоимость RPC, их количество и готовность тратить SOL. Иногда такие траты оправданы, иногда — нет, и риск просто сжечь бюджет становится заметным.

Конкретно в нашем боте RPC-спам остаётся базовым и наиболее универсальным способом доставки транзакций. Большинство стратегий вполне способны работать только на нём.

Jito

Jito — специализированная инфраструктура доставки транзакций в сети Solana.

Вместо того чтобы просто отправлять транзакцию через RPC, бот формирует bundle и отправляет его напрямую в Jito Block Engine. Далее Jito пытается доставить транзакцию валидатору через собственную инфраструктуру.

Попасть в блок помогает система tip-аукциона. Чем выше ваш tip относительно конкурентов, тем выше шанс успешного landing.

Jito иногда позволяет попадать в блок дешевле, но далеко не всегда. Метод стоит воспринимать как альтернативный и учитывать, что здесь появляется зависимость от нагрузки на Jito и элемент рандома при попадании в блок (сложно попадать в определённые места блока).

Jito UUID

При наличии уникального идентификатора UUID ваша пропускная способность повышается до 5–10 запросов в секунду вместо стандартных лимитов.

UUID можно получить через инфраструктуру Jito либо найти на просторах интернета, надеясь, что он продан не сотне человек одновременно.

Важно понимать, что UUID увеличивает количество попыток, но не делает транзакции автоматически прибыльными или успешными.

Sender-инфраструктура

Помимо RPC и Jito в боте присутствуют дополнительные sender'ы:

• Helius
• Helius SWQOS
• Temporal
• Falcon
• Circular

По сути это альтернативные способы доставки транзакций до валидаторов.

Главная идея большинства sender'ов заключается в том, что вы платите небольшую комиссию за попытку, а основная конкуренция происходит через систему tip'ов.

В классическом RPC-спаме высокая вероятность landing обычно достигается повышением комиссии и увеличением количества отправок. Sender'ы работают немного иначе.

Пока транзакция не забрала арбитраж:

• вы платите только небольшой priority fee;
• стоимость каждой отдельной попытки остаётся относительно низкой.

Если же арбитраж успешно выполняется:

• sender дополнительно списывает tip;
• транзакция получает приоритет так, будто вы спамили значительно более высокой комиссией.

SWQOS и стейкнутые соединения

Отдельно стоит упомянуть Helius SWQOS.

По своей логике это что-то среднее между RPC и sender-инфраструктурой.

Транзакции доставляются через стейкнутые соединения Helius, что даёт хороший шанс попадания в блок даже в конкурентных условиях.

Минус заключается в том, что tip списывается при каждой отправке независимо от результата арбитража. Поэтому SWQOS способен довольно быстро расходовать баланс при агрессивном спаме.

С другой стороны, если рынок активный и возможности появляются часто, такой подход может показывать очень хорошие результаты.

Именно поэтому sender'ы часто используются для охоты за крупными арбитражами. Вы можете долго отправлять дешёвые попытки и заплатить основную часть комиссии только в момент успешного landing.

То есть:

• RPC-спам — про максимальный контроль и гибкость.
• Jito — про дешёвые попытки и работу через bundle-инфраструктуру.
• Helius / Temporal — про дешёвый спам и дорогой успешный landing.
• Falcon — про агрессивную борьбу за блок в конкурентной среде.
• Circular — про дополнительный канал доставки транзакций.
• SWQOS — про максимальный шанс попадания в блок ценой постоянных tip'ов.

Методов отправки можно придумать больше, в зависимости от того как это и описывать и какие явления брать во внимание, как и что можно комбинировать становится довольно очевидным после чуть более глубокого погружения в мир соланы.

Стратегии

Что есть стратегия

Даже если сейчас весь процесс кажется сложным и перегруженным, на практике многие вещи оказываются гораздо проще. Это похоже на вождение автомобиля. Не обязательно досконально разбираться в устройстве двигателя, чтобы уверенно ехать по маршруту. Достаточно понимать базу: у машины есть колёса, руль и педали. А вот куда ехать, как выбирать дорогу и зачем — гораздо важнее.

В MEV примерно та же логика. Важно не только как работает бот, но и куда вы его направляете, какую цель перед ним ставите и как оцениваете результат. И да — мы всё ещё в вас верим 🙂

Общий взгляд на работу сёрчера

Рабочий процесс сёрчера удобно разбить на три точки приложения усилий:

1. Разработка стратегий
2. Разработка решений под выбранные стратегии
3. Поддержание и адаптация успешно работающих стратегий

Рассмотрим каждую из них подробнее.

Разработка стратегий

Стратегии рождаются из наблюдений. Как правило — при анализе активности в блокчейне с помощью аналитических инструментов. Мы смотрим на поведение сильных игроков, анализируем их успех, параметры сделок, методы отправки транзакций и условия извлечения профита.

Solscan — важный инструмент, но далеко не единственный. Существуют более общие аналитические решения, позволяющие увидеть картину шире: движение ликвидности, активность пулов, типы арбитражных сценариев. Изучая успешные сделки других игроков, можно попробовать воспроизвести их логику и адаптировать параметры под свою инфраструктуру.

Если что-то не работает — важно задавать вопрос почему. Ответ почти всегда существует. Часто его можно найти в чате, иногда — просто поиском по ключевым словам. Широкий набор инструментов, умение искать пользователей, токены, анализировать типы пулов ликвидности и, конечно, собственные идеи — всё это со временем становится частью вашего арсенала.

Разработка решений под стратегии

Большинство описанных стратегий в той или иной степени реализуемы с использованием нашего софта. Мы постоянно его дорабатываем, добавляем новые возможности и улучшаем существующие механики.

При этом важно понимать: не все стратегии универсальны. Некоторые идеи изначально рассчитаны на узкий круг пользователей или требуют нестандартных решений. MEV-арбитраж — сложная и конкурентная среда, и у непопулярности этой сферы есть обратная сторона: готовых решений под всё не существует.

Если вы опытный разработчик — часть идей можно реализовать самостоятельно. В других случаях имеет смысл привлекать сторонних специалистов или заказывать дополнительные инструменты. Так или иначе, разработка решений почти всегда требует времени и ресурсов. Со своей стороны мы планируем оказывать поддержку в этом направлении по мере развития проекта.

Поддержание работающих стратегий

Даже при высокой степени автоматизации полностью уйти от ручной операционки не получится. Что-то придётся обновлять, подкручивать параметры, перезапускать процессы, переливать токены, следить за логами и профитностью.

Кроме того, рынок меняется. Стратегия, которая хорошо работала вчера, может потерять актуальность через неделю или месяц. Важно не закапываться в одну идею, оставаться гибким и смотреть на картину целиком. В Web3 у нас есть огромное преимущество — почти всё видно ончейн в реальном времени. Вопрос лишь в том, умеем ли мы это правильно интерпретировать.

Примеры стратегий

Для оживления материала мы даём стратегиям романтические названия. Немного поэзии в пыльных цехах MEV ещё никому не мешало.

Ленивая река

Самая простая и самая универсальная стратегия.

Бот работает на популярных mint'ах, использует умеренные фильтры и старается не переплачивать за landing. Дополнительно можно включить динамические комиссии (автогаз), чтобы автоматически подстраиваться под текущую ситуацию в сети.

Когда рынок спокойный — бот работает дёшево.

Когда начинается всплеск активности — комиссии автоматически подтягиваются вслед за другими игроками.

Получается максимально cost-efficient подход без необходимости постоянно сидеть и крутить настройки вручную.

Охота за всплесками

Эта стратегия построена вокруг идеи, что самые интересные арбитражи появляются не в спокойном рынке, а в моменты резких всплесков активности.

В качестве фильтров можно использовать:

• количество транзакций;
• объёмы;
• ликвидность;
• профит;
• ROI.

Как только бот замечает резкий рост активности, он начинает работать агрессивнее.

Здесь особенно полезен автогаз, потому что комиссии автоматически подстраиваются под рынок. Пока рынок спокоен — мы не переплачиваем. Как только начинается драка за блок — бот начинает платить примерно столько же, сколько остальные участники.

Тень за лидером

В боте присутствует возможность работать не только от автоматического подбора mint'ов, но и от заранее известных токенов.

Если у вас есть собственный источник сигналов, любимый searcher или внешняя аналитика, можно передавать боту нужные mint'ы самостоятельно.

По сути это автокопирование чужих идей с собственной инфраструктурой.

Следует понимать, что здесь почти всегда потребуется дополнительная автоматизация:

• написание небольшого терминала;
• скрипта;
• парсера;
• или другой прослойки между источником сигнала и ботом.

Хорошая новость заключается в том, что все необходимые знания для этого являются базовыми.

Раненый зверь

Поиск возможностей там, куда обычно никто не смотрит.

Вместо популярных mint'ов можно использовать фильтрацию по:

• небольшим объёмам;
• низкой ликвидности;
• нестандартным base mint;
• редким маршрутам;
• необычным сочетаниям фильтров.

Чем меньше конкуренция — тем дешевле landing.

Минус очевиден: далеко не каждый такой токен вообще способен приносить профит.

Зато иногда именно здесь появляются самые приятные сюрпризы.

Течение рынка

Со временем любой активный пользователь начинает замечать, что разные способы отправки работают по-разному в зависимости от состояния сети.

Где-то лучше работает RPC.

Где-то Jito.

Где-то sender'ы.

Где-то SWQOS.

Вместо того чтобы выбирать один инструмент навсегда, можно наблюдать за сетью и постепенно менять инфраструктуру под текущие условия.

По сути это стратегия не выбора токенов, а выбора способа доставки транзакций.

Шерлок

Если есть много времени и понимание рынка, движений вокруг конкретного токена, можно рассмотреть поиск паттернов как одну из стратегий.

Например:

• на токене появляется всплеск раз в 10 минут;
• крупный игрок регулярно разгружается по определённому таймингу;
• ожидается буст;
• ожидается листинг;
• ожидается раг;
• или вам просто известна информация раньше большинства участников рынка.

В таком случае бот используется не для поиска идеи, а как инструмент исполнения.

Самая сложная часть стратегии находится не в настройке параметров, а в поиске самого инсайта.

Связь стратегий и методов отправки

### Как читать таблицу

**Риск** — субъективная оценка вероятности сжигания газа и получения отрицательного результата при ошибках настройки.
**Основной акцент** показывает, на чём в первую очередь строится стратегия:
- Cost-efficiency — минимизация расходов
- Скорость реакции — борьба за свежие возможности
- Аналитика — использование внешних сигналов
- Низкая конкуренция — поиск мест, где мало других searcher'ов
- Инфраструктура — подбор способа доставки транзакций
- Собственные идеи — использование знаний о рынке и конкретных токенах

Таблица не заменяет мышление, но даёт быструю опору для понимания процессов. Стратегии описаны для демонстрации возможных способов взаимодействия бота с рынком. Все ситуации и способы извлечения прибыли невозможно физически описать, поэтому мы берём лишь наиболее очевидные примеры.

FAQ (Часто задаваемый вопросы)

Сколько стоит ваш бот?

Бот условно бесплатный.
Вы платите небольшой процент (10%) от профита за прибыльный арбитраж. Этого достаточно, чтобы мотивировать нас развивать проект, улучшать инфраструктуру и делиться рабочими подходами.

Сколько мне нужно SOL, чтобы начать?

Столько, сколько вы готовы безболезненно сжечь. И 0.1 и 0.5 SOL будет достаточно, чтобы всё прощупать и понять.
Сценарий, в котором вы начинаете стабильно зарабатывать без потерь с первого дня, — скорее приятное исключение, чем правило. MEV — это процесс, а не мгновенный результат.

Могу ли я поймать хороший арбитраж на 1 SOL? А на 10 SOL?

Да. Вам не нужны сотни солан на вашем кошельке, чтобы поймать хороший арбитраж.
При включённой опции flashloan = true бот может атомарно использовать предоставляемую нами ликвидность. Если транзакция потенциально успешна, вы отправляете запрос на использование нашей SOL для выполнения арбитража. Всё происходит автоматически и только в рамках успешной сделки.

На каком конфиге у вас едет? Дайте готовый конфиг!

Сегодня едет, завтра — рынок поменялся 🙂 В то же время мы дадим и будем подстраивать готовый консервативный конфиг, который будет работать и приносить профит, но дальше всё в ваших руках. Если хочется больше профита, то придётся разобраться, что и зачем вы настраиваете. В этом и заключается суть: построение и поддержание инфраструктуры, а не копирование чужих параметров.

Я боялся, что моя «тихая» идея станет массовой. Всё пропало?

Не переживайте.
На практике до большого успеха доходит не больше 10% попробовавших. Существенного влияния на рынок мы не оказываем. Есть игроки, в соло отправляющие больше транзакций, чем всё наше сообщество суммарно. В долгосрочной перспективе любая «темка» всё равно либо масштабируется, либо перестаёт работать — с нами или без нас. Если на рынке есть ликвидность, то её точно хватает на всех.

Что считается «много» и «мало» в microlamports и Jito tips?

Примерная градация:

• до 1k — очень мало
• 1k–20k — мало
• 20k–100k — повышенные обороты
• 100k+ — как правило, низкая конкуренция
• 500k+ — зона повышенного риска (≈ 1 SOL в минуту)
• 2M+ — точечная охота почти без конкуренции

Цифры не догма, а ориентир. Рынок и конкуренция постоянно меняются.

Есть ли смысл спама с маленькой комиссией?

Есть.
Успех часто зависит от рыночных возможностей, а не только от агрессии. При таком подходе мы смотрим на профит на дистанции — час, несколько часов — относительно затрат на спам. Иногда удаётся перехватить хороший арбитраж у более агрессивных игроков, так как транзакции распределяются по диапазону комиссий внутри блока.

Можно ли получить консультацию в формате созвона?

Можно! Бесплатно и без смс тегаем Сашу в чате.
Мы не позиционируем себя как абсолютных экспертов атомарного арбитража (пока), но во время всплеска интереса готовы практиковать платные консультации в частном порядке. Чат же доступен 247, пожалуйста, задавайте любые вопросы, мы с радостью на них ответим.

Можно дешевле?

Можно 🙂
Приходите на community calls — время и дни будут анонсированы отдельно.

Спасибо, что дочитал до конца. Именно у тебя всё получится <3

Dashboard: https://zavodmevbot.com
Telegram: https://t.me/ZavodMevBot
Telegram monitor: https://t.me/ZavodMevBotMonitor
Discord: https://discord.gg/xkkhdFrg
Github: https://github.com/ZavodVenture/ZavodMevBot

Минимальная настройка

1) [rpc].url — вставьте вашу основную RPC для
2) [spam].sendingrpcurls — вставьте 1–3 SEND RPCs для отправки транзакций
3) [wallet].private_key — вставьте своей private key
4) [auto.filters] — настройте фильтры:
duration - время, за которое собираем транзакции и профит
mintxlen - количество транзакций, чтобы запустить спам
min_profit - достаточный профит на токене(других ботов в сети), чтобы запустить спам
5) [spam].priority_fee — настраиваем шанс успеха за счёт цены в единицу времени

Пример конфига

[wallet]
private_key = ""

[rpc]
url = ""

[flashloan]
enabled = true

[stop]
min_balance_lamports = 100_000_000
should_unwrap = true
unwrap_amount_lamports = 500_000_000

[cashback_autoclaim]
enabled = true
claim_threshold_lamports = 100_000_000
check_interval_secs = 3600

[bot]
compute_unit_limit = 370_182
log = true
merge_mints = true
dlmm_bin_range_to_search = 20

[dynamic_fees]
enabled = false
window_ms = 5_000
min_samples = 50
sample_scope = "all"

[auto]
enabled = true
refresh_interval_in_secs = 1
force_two_mints = true

[auto.filters]
limit = 2
duration = 20
min_tx_len = 2
min_volume_lamports = 10_000_000_000
max_volume_lamports = 100_000_000_000_000_000
min_profit = 200000000
min_profit_per_arb = 40000000
min_roi = 0
ignore_offchain_bots = true

[auto.markets]
max_pool_len = 4
min_pool_liquidity_lamports = 6_000_000_000
max_pool_liquidity_lamports = 780_000_000_000_000
route_relevance_max_window_secs = 120
route_relevance_half_life_secs = 20
profit_weight = 0.75
count_weight = 0.25

#need only if [auto]=false
#[[markets_file]]
#enabled = false
#path = "markets.toml"
##update_seconds = 0
#auto_luts = false

#[[lookup_tables_file]]
#enabled = false
#path = "lookup-tables.txt"
#update_seconds = 0

[spam]
enabled = true
process_delay = 300

sending_rpc_urls = [
  "",
  "",
  "",
]

priority_fee = { from = 1111, to = 10333 }
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 1111, max = 23333 }

[jito]
enabled = false
uuid = ""
process_delay = 1000

block_engine_urls = [
  "https://ny.mainnet.block-engine.jito.wtf/api/v1",
  "https://tokyo.mainnet.block-engine.jito.wtf/api/v1",
  "https://slc.mainnet.block-engine.jito.wtf/api/v1",
  "https://amsterdam.mainnet.block-engine.jito.wtf/api/v1",
  "https://frankfurt.mainnet.block-engine.jito.wtf/api/v1",
  "https://singapore.mainnet.block-engine.jito.wtf/api/v1",
  "https://london.mainnet.block-engine.jito.wtf/api/v1",
]

tip_config = { from = 1111, to = 8333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 20333 }

[helius]
enabled = false
process_delay = 150
priority_fee_lamports = { from = 1000, to = 3000 }
tip_lamports = { from = 1_000_000, to = 3_000_000 }  # min 200_000  tip
dynamic_priority_fee = { enable = false, min_percentile = 10, max_percentile = 85, min = 111, max = 8333 }
dynamic_tip = { enable = false, min_percentile = 10, max_percentile = 85, min = 200_000, max = 100_000_333 }

[helius_swqos]
enabled = false
process_delay = 150
priority_fee_lamports = { from = 500, to = 1000 }
tip_lamports = { from = 100_000, to = 200_000 } # min 5_000  tip
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 6333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 5111, max = 10_000_333 }

[circular]
enabled = true
api-key = ""
endpoint = "https://fast.circular.fi/transactions"
process_delay = 400
priority_fee_lamports = { from = 111, to = 2333 }
tip_lamports = { from = 100_000, to = 50_011_111 } # min 1  00_000  tip
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 6333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 1_000_011, max = 30_000_333 }

[temporal]
enabled = false
uuid = ""
process_delay = 150
priority_fee_lamports = { from = 500, to = 1500 }
tip_lamports = { from = 10_000_000, to = 50_000_000 } # min 1_000_000  tip
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 6333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 1_000_011, max = 30_000_333 }

[falcon]
enabled = false
uuid = ""
process_delay = 300
priority_fee_lamports = { from = 500, to = 1500 }
tip_lamports = { from = 10_000_000, to = 50_000_000 } # min 1_000_000  tip
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 6333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 1_000_011, max = 30_000_333 }

Подробный принцип работы

Данный раздел описывает полный цикл работы бота — от подключения к сети до отправки транзакций и защиты кошелька. Более подробное описание конфигурации.

[wallet] - настройка кошелька бота

Параметр [wallet].private_key принимает приватный ключ пользователя.

Не используйте основной кошелёк с крупным балансом — для бота лучше завести отдельный кошелёк.

Пример:

[wallet]
private_key = ""

[rpc] - основной RPC для чтения данных Solana

Бот подключается к сети Solana через параметр [rpc].url.

Этот RPC используется только для операций чтения:

• получение данных пулов ликвидности и ончейн-состояния,

• поиск возможных swap-маршрутов,

• расчёт потенциального профита.

❗ Важно: этот RPC не используется для отправки транзакций. Тем не менее никто не запрещает использовать один и тот же RPC и для отправки и для чтения. В большинстве опций лимиты на чтение гораздо более резиновые, по сравнению с отправкой.

Пример:

[rpc]
url = ""

[flashloan] - использование flashloan'ов в транзакциях

Блок [flashloan] отвечает за режим flashloan. При flashloan.enabled = true:

• бот может использовать flashloan'ы при построении маршрутов,

• пользователю не нужно держать большие балансы токенов,

• SOL всё равно требуется для комиссий,

• SOL также нужен для обслуживания аккаунтов.

Если flashloan-пул недоступен или ограничен, некоторые маршруты могут не исполниться.

Пример:

[flashloan]
enabled = true

[stop] - параметры защиты кошелька и остановки бота

Блок [stop] защищает кошелёк от полного опустошения.

Если баланс кошелька опускается ниже min_balance_lamports:

• при should_unwrap = true бот разворачивает unwrap_amount_lamports из wSOL обратно в SOL и продолжает работу,

• при should_unwrap = false бот останавливает выполнение.

Это предотвращает работу бота без достаточного баланса для оплаты комиссий.

Пример:

[stop]
min_balance_lamports = 100_000_000
should_unwrap = true
unwrap_amount_lamports = 500_000_000

min_balance_lamports

1 SOL = 1_000_000_000 lamports. В данном примере порог равен 0.1 SOL.

Если баланс падает до этого уровня, бот проверяет, можно ли пополнить SOL через unwrap. Это предотвращает ситуацию, когда бот продолжает работать без достаточного баланса для оплаты комиссий.

[cashback_autoclaim] - параметры автоматического клейма кешбека

Этот блок отвечает за автоматический клейм кешбэка с Pump.fun.

Бот может периодически проверять доступный кешбэк и забирать его без ручного вмешательства. Это удобно, если бот работает долго и накапливает небольшие суммы, которые иначе пришлось бы забирать вручную.

Как работает:

• бот проверяет доступный кешбэк с заданным интервалом,

• если сумма превышает заданный порог — происходит автоматический клейм,

• если нет — бот просто продолжает работу без действий.

Пример:

[cashback_autoclaim]
enabled = true
claim_threshold_lamports = 100_000_000
check_interval_secs = 3600

claim_threshold_lamports

Минимальная сумма кешбэка, при которой бот выполнит клейм.

Это нужно, чтобы:

• не тратить комиссии на слишком маленькие суммы,

• не засорять сеть лишними транзакциями.

[bot] - базовые настройки исполнения и маршрутизации

Блок [bot] содержит общие параметры работы бота: лимиты транзакций, логирование, поиск DLMM-маршрутов и объединение mint'ов.

Пример:

[bot]
compute_unit_limit = 370_182
log = true
merge_mints = true
dlmm_bin_range_to_search = 20
gas_file = false

compute_unit_limit

Параметр compute_unit_limit определяет максимальную сложность транзакции.

• слишком низкое значение → сложные маршруты или бандлы из 2 минтов могут не влезть,

• слишком высокое значение → увеличивается размер транзакции и нагрузка, что может ухудшить шанс приземления.

Текущее значение (~350k) — разумный компромисс. Оптимальные значения зависят от используемых пулов и маршрутов.

dlmm_bin_range_to_search

По умолчанию бот может использовать более консервативное значение. Увеличение диапазона позволяет искать более крупные профиты в DLMM, но делает маршруты тяжелее и может потребовать увеличения compute_unit_limit.

merge_mints

Бот пытается объединить выбранные минты в одну транзакцию (максимум 2 mint'а), что снижает накладные расходы и повышает общую эффективность.

На практике включённый режим помогает реже тратить комиссию впустую и эффективнее использовать пространство транзакции.

gas_file

При gas_file = true бот создаёт отдельный файл current_gas_settings.toml, который можно редактировать в реальном времени, чтобы менять комиссии для sender, spam и Jito без перезапуска бота.

В этом файле автоматически появятся шаблоны только для тех сендеров и режимов, которые включены в config.toml через enabled = true.

После изменения значений в current_gas_settings.toml бот начинает использовать новые fee-настройки в реальном времени.

Это удобно для быстрой подстройки priority fee / tip под текущую нагрузку сети.

[bot]
gas_file = true

[DataSizeEstimation] - оценка размера данных транзакции

Опциональный блок. Управляет тем, добавляет ли бот инструкцию DataSize к транзакциям.

По умолчанию enable = true, поэтому если менять поведение не нужно — можно ничего не добавлять в конфиг.

• enable = true — поведение как раньше, оценка DataSize работает;

• enable = false — оценка DataSize не производится, инструкция DataSize не добавляется к транзакциям.

Пример:

[DataSizeEstimation]
enable = true

[dynamic_fees] - общие настройки динамического расчета комиссий

Блок [dynamic_fees] задает общие параметры для динамических fee-фильтров. Эти настройки помогают боту опираться не только на фиксированные значения, но и на статистику последних отправок.

Пример:

[dynamic_fees]
enabled = false
window_ms = 5_000
min_samples = 50
sample_scope = "all"

window_ms

В данном примере окно равно 5 секундам. Чем меньше окно, тем быстрее бот реагирует на изменения рынка, но тем выше риск реагировать на случайный шум.

min_samples

Если сэмплов меньше, статистика считается недостаточно надежной. Это защищает бота от решений на основании слишком маленькой выборки.

sample_scope

Значение "all" означает, что бот может учитывать весь доступный набор релевантных сэмплов. Если в будущих версиях появятся более узкие области, этот параметр можно будет использовать для ограничения источника статистики.

Автогаз: динамические комиссии

Функция динамических комиссий (автогаз) автоматически подстраивает priority_fee и tip на основе данных о комиссиях, которые в реальном времени собираются по сети (в том числе по транзакциям других пользователей).

Общий режим включается в блоке [dynamic_fees] через enabled = true. Здесь же задаются параметры сбора статистики:

• window_ms — окно поиска транзакций в миллисекундах, за которое собираются свежие fee-сэмплы;

• min_samples — минимальное количество сэмплов, необходимое для построения статистики (если сэмплов меньше — динамика не применяется);

• sample_scope — какие транзакции учитывать: "all" (все) или "success_only" (только успешно приземлившиеся).

[dynamic_fees]
enabled = true
window_ms = 5_000
min_samples = 50
sample_scope = "all"

Персентили: min_percentile и max_percentile

После включения общего режима динамику нужно настроить у каждого сендера отдельно — внутри его dynamic_priority_fee и dynamic_tip. Сами блоки сендеров при этом трогать не нужно, достаточно этих полей.

У каждого dynamic_priority_fee и dynamic_tip есть параметры:

• enable — включает динамический расчёт для этого сендера и этого типа комиссии;

• min_percentile / max_percentile — диапазон персентилей статистики комиссий, из которого бот берёт значение;

• min / max — жёсткие границы допустимых значений (бот не выйдет за них, какой бы ни была статистика).

Персентили нужны, чтобы отсекать экстремальные значения. Например, при min_percentile = 15 и max_percentile = 85 система берёт диапазон от 15-го до 85-го персентиля статистики, а не самые низкие и самые высокие (экстремальные) комиссии.

Примеры настройки по сендерам

Ниже — как правильно прописать динамику для разных типов отправки. Границы min / max подбирайте под свою стратегию и текущую нагрузку сети. Блоки сендеров при этом не редактируются — меняются только поля dynamic_priority_fee и dynamic_tip внутри них.

Spam (RPC) — только priority fee:

[spam]
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 1111, max = 23333 }

Jito — только tip:

[jito]
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 20333 }

Сендеры с priority fee и tip (Helius, Helius SWQOS, Circular, Temporal, Falcon) — на примере Circular:

[circular]
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 6333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 1_000_011, max = 30_000_333 }

Аналогично настраиваются helius, helius_swqos, temporal и falcon — у каждого свои dynamic_priority_fee и dynamic_tip.

Логирование (logs/fee_quote)

При включённом bot.log = true отчёты по расчёту комиссий пишутся в папку logs/fee_quote.

Если в отчёте встречается ok: false — значит, сэмплов пока недостаточно для надёжной статистики, и динамика в этот момент не применяется (используются фиксированные значения из блока сендера).

[auto] - автоматический выбор mint'ов и запуск торговли

Блок [auto] включает автоматический режим, в котором бот сам выбирает mint'ы и запускает торговлю.

Каждые refresh_interval_in_secs секунд бот обновляет список кандидатных минтов и прогоняет их через заданные фильтры.

Ключевой параметр — duration (в блоке [auto.filters]). Duration задаёт скользящее временное окно: например, duration = 10 означает, что бот анализирует только последние 10 секунд активности по каждому минту.

Пример:

[auto]
enabled = true
refresh_interval_in_secs = 1
force_two_mints = true

force_two_mints

Параметр force_two_mints заставляет бота всегда работать с двумя mint'ами одновременно.

Логика следующая:

• если по фильтрам найдено два подходящих токена — используются оба,

• если найден только один — бот автоматически подбирает дополнительный активный mint за последний час и добавляет его во вторую позицию.

Это бесплатный способ повысить эффективность. Покуда в бандлах есть место под дополнительный минт, давайте его использовать. Жрать оно не просит.

Математика поиска дополнительного минта основывается на рейтинге. Мы оцениваем минты не только по профиту, но и по количеству успешных транзакций на них. В приоритете мы хотим брать минты не просто профитные, а ещё и с большой активностью разных ботов, таким образом мы отсеиваем снайперские офчейн попадания и увеличиваем вероятность забрать хороший арб. То есть при включённом параметре бот дополнительно анализирует активные минты (пусть даже они не проходят по фильтрам), высчитывает рейтинг исходя из профитности и количества успешных арбитражей, подкладывает наиболее интересные в наш бандл.

На практике это означает, что бот реже тратит комиссию впустую и чаще использует доступное пространство транзакции максимально эффективно.

[auto.filters] - фильтры автоматического выбора mint'ов

Блок [auto.filters] задаёт условия, по которым mint считается достаточно активным и выгодным для торговли.

Внутри окна duration каждый mint проверяется по активности и ликвидности, а параметры профита и ROI отвечают за качество арбитражных сигналов — их задача не дать боту спамить транзакции в ситуациях, когда комиссии уже «съедают» потенциальный профит.

Пример:

[auto.filters]
limit = 2
duration = 20
min_tx_len = 2
min_volume_lamports = 10_000_000_000
max_volume_lamports = 100_000_000_000_000_000
min_profit = 200000000
min_profit_per_arb = 40000000
min_roi = 0
ignore_offchain_bots = true

limit

Максимальное количество mint'ов, которое фильтр может выбрать одновременно.

Значение работает вместе с force_two_mints: бот отбирает не больше limit подходящих mint'ов на один цикл, а лишние кандидаты остаются за пределами текущей транзакции.

min_tx_len

Внутри окна duration каждый mint проверяется по активности: количество подходящих сделок должно быть не меньше min_tx_len. Если событий меньше, mint не считается достаточно активным.

Этот фильтр вместе с фильтрами ликвидности отсекает:

• слишком маленькие или пустые пулы (высокий риск, большое проскальзывание),

• слишком крупные пулы, если стратегия на них не рассчитана.

duration

duration задаёт скользящее временное окно, внутри которого считаются активность и статистика по каждому mint'у.

Пример: duration = 10 означает, что бот анализирует только последние 10 секунд активности по каждому минту.

Чем меньше окно, тем быстрее бот реагирует на свежие всплески, но тем «короче память» у статистики.

min_profit

Параметр min_profit задаёт минимальный суммарный профит, необходимый для того, чтобы mint был триггернут в рамках окна duration.

Проще говоря: бот смотрит на все арбитражные сделки по одному mint'у за последние duration секунд и складывает их профит.

Если суммарный профит меньше min_profit, mint не активируется, и бот не переходит к фазе агрессивной отправки транзакций.

Это позволяет:

• игнорировать слабые и случайные всплески,

• не включаться в борьбу за блок ради копеек,

• снизить бессмысленный расход SOL на комиссиях.

min_roi

Параметр min_roi задаёт минимальный допустимый ROI, при котором mint может быть триггернут.

ROI считается на уровне mint'а, внутри окна duration, по формуле:

roi = total_profit / total_fee

Где:

• total_profit — суммарный профит всех учтённых арбитражных транзакций по этому mint'у за duration,

• total_fee — суммарные комиссии всех этих транзакций (включая как профитные, так и непрофитные, но успешно приземлившиеся).

❗ Важно: в расчёт total_fee попадают все landed arb-транзакции, а не только успешные.

Если roi < min_roi — mint не триггерится, даже если абсолютный профит выглядит неплохо.

Этот фильтр защищает от ситуации, когда:

• рынок уже перегрет,

• комиссии выросли,

• профит есть, но он не покрывает расходы в разумной пропорции.

min_profit_per_arb

Параметр min_profit_per_arb — статистический фильтр, который задаёт минимальный профит одной арбитражной сделки, учитываемой при расчёте статистики в рамках окна duration.

Любая арбитражная транзакция с профитом меньше min_profit_per_arb:

• игнорируется,

• не участвует в подсчёте количества транзакций, суммарного профита, суммарных комиссий и ROI,

• не влияет на триггеринг mint'а.

Цель этого параметра — отфильтровать шум:

• микроскопические арбы,

• случайные попадания,

• ситуации, где профит формально есть, но практического смысла — ноль.

В результате бот реагирует только на действительно значимые возможности, а не на статистический мусор.

min_volume_lamports

Минимальный объём торгов, необходимый для того, чтобы mint участвовал в фильтрации.

Помогает:

• убрать мёртвые токены,

• убрать случайные микросвечки,

• и не реагировать на единичные арбитражи без настоящей активности.

max_volume_lamports

Максимальный допустимый объём торгов.

Используется для:

• отсечения слишком перегретых mint'ов,

• ограничения ultra-high-volume рынка,

• и фильтрации ситуаций, где конкуренция уже слишком высокая.

ignore_offchain_bots

Параметр ignore_offchain_bots позволяет исключать из статистики сделки, сгенерированные офчейн-ботами.

Офчейн-боты часто создают искусственную активность, искажают реальную картину рынка и генерируют шум в данных.

При включённом параметре бот не учитывает такие транзакции в своих расчётах, опирается в основном на ончейн-активность и получает более «чистую» статистику.

Практический эффект:

• меньше ложных срабатываний,

• меньше бесполезного спама,

• более стабильные сигналы для входа.

Как эти фильтры работают вместе

Если обобщить:

• min_profit_per_arb → отсекает мелкий шум на уровне отдельных сделок,

• min_profit → требует достаточный абсолютный профит по mint'у,

• min_roi → контролирует эффективность этого профита относительно комиссий.

Вместе они формируют трёхуровневый фильтр качества, который снижает бессмысленный спам, делает поведение бота более устойчивым и помогает концентрироваться на реально интересных арбитражных ситуациях.

[auto.markets] - параметры выбора пулов и оценки маршрутов

Блок [auto.markets] управляет тем, какие пулы и маршруты бот рассматривает при построении сделок.

Пример:

[auto.markets]
max_pool_len = 4
min_pool_liquidity_lamports = 6_000_000_000
max_pool_liquidity_lamports = 780_000_000_000_000
route_relevance_max_window_secs = 120
route_relevance_half_life_secs = 20
profit_weight = 0.75
count_weight = 0.25

max_pool_len

Максимальное количество пулов, которое бот может вернуть для одного токена.

Чем больше значение, тем шире поиск маршрутов, но тем выше вычислительная нагрузка.

min_pool_liquidity_lamports

Фильтры ликвидности пулов определяют минимальную и максимальную ликвидность для пулов, которые участвуют в подборе маршрутов.

⚠️ Важное изменение: теперь значения задаются в lamports, а не в SOL. Пример: 6_000_000_000 = 6 SOL. Это сделано для унификации формата значений в конфиге.

max_pool_liquidity_lamports

Верхний фильтр ликвидности пула. Помогает не тратить ресурсы на слишком крупные пулы, на которые стратегия не рассчитана.

Как и минимальная граница, значение задаётся в lamports (1 SOL = 1_000_000_000 lamports).

route_relevance_max_window_secs

Окно актуальности маршрутов. После того как бот находит hot mint:

• он идёт в базу известных route'ов,

• исключает маршруты, которые не использовались слишком давно,

• и оценивает только актуальные route'ы внутри этого окна.

Проще говоря: duration отвечает за поиск hot mint'ов, а route_relevance_max_window_secs — за поиск актуальных пулов для этих mint'ов.

route_relevance_half_life_secs

Параметр затухания веса старых событий. Каждая транзакция внутри route'а имеет свой «вес», который со временем постепенно уменьшается.

Примерно каждые 20 секунд значимость события уменьшается примерно в 2 раза.

Это позволяет:

• отдавать приоритет свежим маршрутам,

• быстрее адаптироваться к изменению рынка,

• и не переоценивать старые успешные арбитражи.

profit_weight

Определяет, насколько сильно профит влияет на итоговый score маршрута.

Чем выше значение, тем сильнее бот предпочитает route'ы с крупным профитом, даже если они происходят реже.

count_weight

Определяет, насколько сильно количество транзакций влияет на итоговый score маршрута.

Чем выше значение, тем сильнее бот предпочитает стабильные и часто используемые route'ы, даже если отдельные арбитражи на них менее прибыльны.

[[markets_file]] - опциональная загрузка списка рынков из файла

Опциональный блок для подключения внешнего файла с рынками. В примере он закомментирован, поэтому по умолчанию не используется.

Пример:

[[markets_file]]
enabled = false
path = "markets.toml"
update_seconds = 0
auto_luts = false

auto_luts

Управляет источником lookup tables (LUT) при работе через внешний файл рынков.

• при auto_luts = true бот игнорирует LUT, указанные в markets.toml, и примерно каждые 5 секунд сам подтягивает актуальные LUT для активных аккаунтов;

• при auto_luts = false используется стандартное поведение — LUT берутся напрямую из файла markets.toml.

Режим true удобен, когда набор пулов часто меняется и держать актуальные LUT в файле вручную неудобно.

Формат файла markets.toml

Файл markets.toml используется в CLI-режиме, когда вы выбираете токены и пулы вручную, без авто-фильтра. Один блок [[group]] описывает содержимое одной отправляемой транзакции, а несколько блоков [[group]] — несколько одновременно отправляемых транзакций.

Один блок может содержать до двух минтов — mint_a и mint_b, каждый со своим списком пулов:

[[group]]
mint_a = "MINT1_ADDRESS"
markets_a = ["pool1", "pool2"]

mint_b = "MINT2_ADDRESS"
markets_b = ["pool1", "pool2"]

luts = ["lut1", "lut2"]

Ограничения по количеству пулов в одном блоке [[group]]:

• для одного минта — от 2 до 5 пулов;

• для двух минтов — по 2–3 пула на каждый, но суммарно не более 5 (то есть 3 + 2 или 2 + 3).

Команда create-markets-file берёт токены из tokens.toml и создаёт корректный markets.toml актуальным способом поиска пулов. Если по одному из токенов пулы найти не удалось, файл всё равно будет создан на основе найденных данных.

Команда get-lookup-tables подбирает актуальные LUT на основе содержимого markets.toml и заменяет ими старые LUT в файле.

[[lookup_tables_file]] - опциональная загрузка lookup tables из файла

Опциональный блок для подключения внешнего файла с lookup tables. В примере он закомментирован, поэтому по умолчанию не используется.

Пример:

[[lookup_tables_file]]
enabled = false
path = "lookup-tables.txt"
update_seconds = 0

[spam] - классическая отправка транзакций через RPC

Блок [spam] отвечает за классический RPC-спам. Бот отправляет одну и ту же подписанную транзакцию через один или несколько RPC, чтобы быстрее донести ее до сети Solana.

Пример:

[spam]
enabled = true
process_delay = 300

sending_rpc_urls = [
  "",
  "",
  "",
]

priority_fee = { from = 1111, to = 10333 }
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 1111, max = 23333 }

priority_fee

Priority fee регулирует шанс попадания транзакции в блок. Более высокие значения могут улучшить landing, но увеличивают стоимость каждой попытки.

dynamic_priority_fee

enable = true позволяет боту подбирать priority fee по свежей статистике. Перцентили задают рабочую область выборки, а min и max ограничивают итоговое значение, чтобы бот не уходил в слишком дешевые или слишком дорогие комиссии.

[jito] - отправка транзакций через Jito Block Engine

Jito — это классический bundle sender для Solana MEV, альтернативный спаму способ отправки транзакций.

Вместо обычной отправки транзакции в сеть бот отправляет bundle напрямую в block engine Jito, а Jito пытается встроить транзакцию в блок через свою инфраструктуру валидаторов.

Главная идея Jito: не просто попасть в блок, а попасть туда раньше и выгоднее других searcher'ов.

Как работает:

• транзакции отправляются в Jito block engine,

• используется система tip-аукциона,

• landing зависит от размера tip, нагрузки сети, конкуренции и качества route'а.

Важно понимать: Jito не гарантирует профит. Он лишь даёт инфраструктуру для более конкурентной борьбы за блок.

Пример:

[jito]
enabled = false
uuid = ""
process_delay = 1000

block_engine_urls = [
  "https://ny.mainnet.block-engine.jito.wtf/api/v1",
  "https://tokyo.mainnet.block-engine.jito.wtf/api/v1",
  "https://slc.mainnet.block-engine.jito.wtf/api/v1",
  "https://amsterdam.mainnet.block-engine.jito.wtf/api/v1",
  "https://frankfurt.mainnet.block-engine.jito.wtf/api/v1",
  "https://singapore.mainnet.block-engine.jito.wtf/api/v1",
  "https://london.mainnet.block-engine.jito.wtf/api/v1",
]

tip_config = { from = 1111, to = 8333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 20333 }

tip_config

Настройки Jito tip. Tip — это внутренняя ставка внутри Jito-аукциона.

Чем выше tip:

• тем выше шанс landing,

• но тем выше расход SOL.

Низкие значения: дешевле, но в перегретом рынке могут почти не лендиться.

Высокие значения: помогают бороться за жирные арбитражи, но могут быстро сжигать баланс при плохих фильтрах.

dynamic_tip

enable = true включает расчет tip на основе статистики. min_percentile и max_percentile задают диапазон перцентилей, из которого бот выбирает рабочее значение. min и max ограничивают итоговый tip снизу и сверху, чтобы бот не ставил слишком маленькие или слишком дорогие значения.

[helius] - sender через Helius с оплатой tip при успехе

Helius в стандартном режиме — это более агрессивный dual-routing sender.

Здесь используется внутренняя маршрутизация транзакций через инфраструктуру Helius, которая пытается доставить транзакцию оптимальным путём.

Как работает:

• транзакция отправляется через инфраструктуру Helius,

• routing происходит динамически,

• landing случается реже, но качественнее.

Главное отличие: tip платится только если арбитраж действительно выполнен. Если транзакция не принесла профит — оплачивается только priority fee, основной tip не списывается.

Такой режим почти не расходует баланс при неудачах, хорошо подходит для охоты за крупными возможностями и снижает стоимость долгой работы бота. Минус — попадание в блок происходит реже, чем у SWQOS.

Пример:

[helius]
enabled = false
process_delay = 150
priority_fee_lamports = { from = 1000, to = 3000 }
tip_lamports = { from = 1_000_000, to = 3_000_000 }  # min 200_000  tip
dynamic_priority_fee = { enable = false, min_percentile = 10, max_percentile = 85, min = 111, max = 8333 }
dynamic_tip = { enable = false, min_percentile = 10, max_percentile = 85, min = 200_000, max = 100_000_333 }

priority_fee_lamports

Priority fee влияет на вероятность входа транзакции в блок. Для sender'ов нет смысла без необходимости сильно завышать priority fee: часто достаточно разумного диапазона, а основную работу по доставке делает sender.

tip_lamports

Для Helius tip платится только если арбитражная транзакция успешно приземлилась и была исполнена. Если арбитраж не забрали, обычно оплачивается только priority fee.

Такой режим подходит для крупных или качественных возможностей, потому что не выжигает баланс на каждом неуспешном арбе.

dynamic_priority_fee

В текущем примере enable = false, поэтому используется фиксированный диапазон priority_fee_lamports. Если включить динамический режим, бот будет подбирать priority fee по статистике и ограничивать ее значениями min и max.

dynamic_tip

В текущем примере динамический tip выключен. Если включить его, бот сможет менять tip в зависимости от рыночной конкуренции и свежих сэмплов, но итоговое значение останется внутри заданных границ.

[helius_swqos] - отправка через Helius staked connections

Helius SWQOS — это режим отправки транзакций через staked connections инфраструктуры Helius.

По своей логике он близок к Jito-отправке, но:

• не требует UUID,

• не имеет жёстких rate-limit ограничений,

• использует один из крупнейших stake в сети Solana.

Фактически ваши транзакции отправляются через валидаторов с высоким весом, что заметно повышает шанс попадания в блок.

⚠️ Важная особенность: tip списывается при каждой отправке, даже если арбитраж не был забран. Это делает SWQOS очень стабильным по landing, но дорогим при агрессивном спаме.

Подходит для стабильного спама, активных рынков и ситуаций, где важно постоянно попадать в блок.

Пример:

[helius_swqos]
enabled = false
process_delay = 150
priority_fee_lamports = { from = 500, to = 1000 }
tip_lamports = { from = 100_000, to = 200_000 } # min 5_000  tip
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 6333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 5111, max = 10_000_333 }

priority_fee_lamports

Priority fee является стандартной платой за вход в блок и влияет на порядок исполнения транзакции.

tip_lamports

Важная особенность SWQOS: tip платится за каждую транзакцию, даже если арбитражная возможность была упущена. Поэтому при агрессивном спаме баланс SOL может уменьшаться быстро.

dynamic_priority_fee

При enable = true бот может подбирать priority fee на основе свежей статистики. min и max ограничивают значение, чтобы комиссия не становилась слишком низкой или чрезмерно дорогой.

dynamic_tip

Динамический tip помогает адаптироваться к конкуренции в сети. При этом важно помнить, что в SWQOS tip списывается на каждой отправке, поэтому верхний лимит должен соответствовать вашему риск-профилю.

[circular] - отправка через инфраструктуру Circular

Circular — альтернативный sender для доставки транзакций через инфраструктуру Circular. По логике близок к Helius / Temporal и используется как дополнительный способ повысить шанс landing.

Работает так:

• отправка идёт через endpoint'ы Circular,

• используется собственная routing-инфраструктура,

• sender хорошо подходит для смешанных sender-сетапов.

💰 Минимальный tip: 100 000 lamports

🔑 Требуется Circular API key

✔️ Хорошо сочетается с spam RPC и другими sender'ами

❌ Эффективность сильно зависит от рынка и выбранных комиссий

Плюс — дополнительный источник landing без необходимости держаться только за один sender. Минус — при слабых настройках и низкой активности рынка может не давать заметного преимущества.

Пример:

[circular]
enabled = true
api-key = ""
endpoint = "https://fast.circular.fi/transactions"
process_delay = 400
priority_fee_lamports = { from = 111, to = 2333 }
tip_lamports = { from = 100_000, to = 50_011_111 } # min 1  00_000  tip
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 6333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 1_000_011, max = 30_000_333 }

priority_fee_lamports

Priority fee помогает транзакции попасть в блок. Для sender'ов обычно достаточно держать этот параметр в разумных пределах, потому что основную доставку выполняет sender-инфраструктура.

tip_lamports

Tip платится только если арбитраж успешно исполняется. Это делает Circular более cost-efficient по сравнению с режимами, где tip списывается на каждой попытке.

dynamic_priority_fee

Бот может подбирать priority fee по свежей статистике и удерживать итоговое значение внутри диапазона min и max.

dynamic_tip

Позволяет повышать или снижать tip в зависимости от рыночной конкуренции. Это полезно, когда один и тот же фиксированный tip то слишком дешевый для landing, то слишком дорогой для спокойного рынка.

[temporal] - отправка через Temporal sender

Temporal — альтернативный sender, работающий по схожей логике с Helius, но через независимую инфраструктуру endpoint'ов. Для работы требуется Temporal UUID (API key).

Как работает:

• транзакции отправляются через собственные endpoint'ы Temporal,

• используется внутренняя система приоритизации,

• шанс landing находится на хорошем среднем уровне.

Как и в Helius: tip списывается только при успешном арбитраже, при неудаче оплачивается лишь priority fee.

Temporal требует более высокий минимальный tip, поэтому чаще используется для средних и крупных арбитражей, точечной охоты и как дополнительный sender параллельно spam RPC. Минус — landing происходит реже, чем при постоянном spam-подходе.

Пример:

[temporal]
enabled = false
uuid = ""
process_delay = 150
priority_fee_lamports = { from = 500, to = 1500 }
tip_lamports = { from = 10_000_000, to = 50_000_000 } # min 1_000_000  tip
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 6333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 1_000_011, max = 30_000_333 }

priority_fee_lamports

Priority fee оплачивается как плата за вход в блок. Ее не стоит завышать без необходимости: в sender-режимах основная ставка делается через tip.

tip_lamports

Temporal обычно требует более высокий практический tip и лучше подходит для средних и крупных арбитражей. Tip списывается только при успешном арбитраже, а при неудаче оплачивается только priority fee.

dynamic_priority_fee

При включенном режиме бот адаптирует priority fee к текущей статистике, но не выходит за пределы min и max.

dynamic_tip

Помогает менять tip в зависимости от конкуренции. Нижняя граница защищает от слишком слабой ставки, верхняя - от случайного перерасхода SOL.

[falcon] - агрессивный sender для конкурентного рынка

Falcon — это агрессивный sender, рассчитанный на работу в перегретой и конкурентной среде. По логике близок к Helius / Temporal, но требует более высоких комиссий и используется как инструмент «пробития» блока. Для работы необходим Falcon UUID (API key).

Falcon — это не про экономию, а про приоритет:

• используются повышенные priority fee,

• применяются крупные tip значения,

• бот получает дополнительный шанс попасть в блок, когда обычные методы уже не справляются.

💰 Минимальный tip: 1 000 000 lamports

🔑 Нужен falcon_uuid, взять его можно тут: https://dashboard.corvus-labs.io/falcon — просто напишите, что вам нужен Falcon Api key

✔️ Tip платится только если арб реально забрали

❌ Если арб не забрали — платится только priority fee (обычно 100–500)

Плюс — не расходует много при неудачах. Минус — попадает реже.

Пример:

[falcon]
enabled = false
uuid = ""
process_delay = 300
priority_fee_lamports = { from = 500, to = 1500 }
tip_lamports = { from = 10_000_000, to = 50_000_000 } # min 1_000_000  tip
dynamic_priority_fee = { enable = true, min_percentile = 10, max_percentile = 85, min = 111, max = 6333 }
dynamic_tip = { enable = true, min_percentile = 10, max_percentile = 85, min = 1_000_011, max = 30_000_333 }

priority_fee_lamports

Priority fee помогает транзакции попасть в блок. Falcon чаще используют, когда landing важнее экономии, но даже здесь нет смысла бесконтрольно завышать priority fee.

tip_lamports

Falcon рассчитан на high-competition сценарии, поэтому tip обычно выше, чем у более спокойных sender'ов. Tip платится только если арбитражная транзакция успешно исполнилась.

dynamic_priority_fee

Бот может адаптировать priority fee к текущей ситуации, удерживая значение между min и max.

dynamic_tip

Позволяет менять tip под конкуренцию. Это полезно для перегретого рынка, но верхнюю границу важно выбирать аккуратно, чтобы не отдавать слишком большую часть профита sender'у.

Dashboard: https://zavodmevbot.com
Telegram: https://t.me/ZavodMevBot
Telegram monitor: https://t.me/ZavodMevBotMonitor
Discord: https://discord.gg/xkkhdFrg
Github: https://github.com/ZavodVenture/ZavodMevBot

Использование бота без фильтров

Этот режим позволяет запустить CLI с ручным выбором токенов и пулов через файл markets.toml — без auto-режима. Вы сами задаёте, какие минты и пулы бот будет использовать.

Шаг 1. Отключите auto-режим:

[auto]
enabled = false

Шаг 2. Включите загрузку рынков из файла:

[[markets_file]]
enabled = true
path = "./markets.toml"
update_seconds = 10
auto_luts = true

• path — путь до файла;

• update_seconds — частота перечитывания файла (в секундах);

• auto_luts — режим автоматического подбора LUT под указанные пулы. true — CLI сам подбирает LUT под переданные пулы через Assist раз в несколько секунд; false — используются LUT из файла markets.toml.

Как заполнить markets.toml

Сам файл нужно заполнить. Формат — как в примере ниже.

Блоков [[group]] может быть несколько. Один блок [[group]] — это одна транзакция, которая спамится, а содержимое блока — это содержимое транзакции.

Блок может содержать один или два минта и до 5 пулов суммарно. Каждый минт должен иметь минимум два пула. То есть если указан один минт — для него можно задать от 2 до 5 пулов. Если указано два минта — у каждого тоже минимум по два пула. Возможные комбинации для двух минтов: 2 + 2, 3 + 2 или 2 + 3 пула.

Пулы могут быть: Meteora DLMM, Meteora DAMM v2, Raydium AMM v4, Raydium CPMM, Pump Fun AMM.

[[group]]
mint_a = "2kBH6UcR8TitebUbKNYNvjUkSFWaiFBJ7nAPTKQwpump"
markets_a = [
    "H9h8qEG41S2Sb4VfV2kQ9ba48anywfxaDGxnwDjaPGJn",
    "Hy38ks9sS5w3wwZY4Rbsnq1JMZGWS16z4TE42MjcQqho",
    "hGRWuGFxjA8oXyKM1RjPUufyf7rMsQkJTAbtiaNXd4w",
]
mint_b = "3x6apzqJKgf33zet8CbkAx7LogqkRhNX6FiRzVA5pump"
markets_b = [
    "4gpyCFwGaGcHjqQCMPCQag3KCRzvEkmTpoLS6LJP16LH",
    "UvN1ZVZJom7D4CPuhjJrbD6y82k5TSefRQMZHHXjjfM",
]
luts = [
    "6EXoKhhK6erhjDb1VpSFJ1guA18rtkVB3q5JNGooBcXG",
    "7AmVzYWeBx7gwS17bZFHfMMwx99hXV6gypEvzaZSMnpm",
    "AbqbhzaS2obrKbU2p8nnJtCwToNGFETa2hUwZpqavnsZ",
]

• mint_a — адрес первого минта;

• markets_a — список пулов первого минта;

• mint_b (опционально) — адрес второго минта;

• markets_b (если указан mint_b) — список пулов второго минта;

• luts (опционально) — список LUT-аккаунтов для транзакции.

Поле luts: три варианта

1. Использовать свои LUT постоянно. Перечислите их в поле luts в файле и отключите auto_luts в [[markets_file]] (если auto_luts включён, CLI игнорирует LUT из файла и периодически подбирает их сам через Assist).

2. Один раз заполнить luts через Assist. Оставьте поле luts пустым, отключите auto_luts и запустите CLI командой:

./zavod-mev-bot-rust-version-cli get-lookup-tables

После этого CLI подберёт и заполнит LUT для каждого вашего блока [[group]]. Важно: он перезаписывает даже уже заполненные секции luts.

3. Не указывать luts вовсе и поставить auto_luts = true. Тогда бот будет игнорировать luts из файла и подбирать их сам периодически.

Запуск

Дальше запускайте бота как обычно. CLI будет непрерывно спамить заполненными вами блоками [[group]] до тех пор, пока при следующем чтении файла (интервал update_seconds) они не изменятся или не пропадут из файла.

При update_seconds = 0 бот всегда спамит тем, что было в файле в момент запуска.