Comments 52
А вы не рассматривали стратегию, при которой на нескольких биржах заранее лежат депозиты, и сделки совершаются синхронно с обеих сторон без перевода средств между биржами? Такой подход может минимизировать задержки и устранить комиссии сети.
Да, стратегия с распределёнными депозитами на нескольких биржах — действительно, позволяет обойти необходимость в on-chain переводах и существенно снизить задержки. Однако у этой схемы есть свои особенности:
Требуется заранее держать ликвидность на всех целевых биржах, что увеличивает нагрузку на капитал по крайне мере вдвое.
Необходима синхронизация сделок, чтобы избежать перекоса в позициях (например, закупился, но не успел продать). В своем эксперименте я намеренно пошёл по пути "классического" арбитража с физическим перемещением активов, чтобы понять, насколько вообще сейчас доступны такие возможности для розничного участника без больших финансовых затрат.
Но такой подход, безусловно, имеет практическую ценность. Спасибо за мысль!
Это ещё не всё. На некоторых биржах не доступны шортовые операции по споту - mexc для примера. Во время резкого роста цены, даже на тех биржах где есть возможность шортить может не оказаться монеты для кредитного плеча(шорт). Я перевел mexc на protobuf и по одной паре приходит 50 сообщений в сек. Этих пар 247. + Ещё 2 биржи примерно по столько же пар, но там json и 3-7 сообщений в сек на пару. Нагрузка на сеть 25-40 Мбит/сек. 100% на процессоре. И да есть скамные пары которые надо фильтровать ticker один а по факту разные сети, на них сразу арбитраж и 600% будет :)
Здравствуйте. Расширьте границы своего крипто познания. Копните глубже. В пулы дексов...Арбитраж на сек'сах кардинально отличается от арбитража на декс'ах. И в последних как раз океан возможностей
Там тоже уже все занято. Нужны серьезные ресурсы для того чтобы конкурировать с уже существующими ботами
Ну не совсем прям занято ))... Я бы сказал , что там мест ещё очень и очень много....По поводу конкуренции с существующими ботами, Ла , вы правы, ресурсы нужны, но если копнуть в суть ресурсов, то выяснится, что вполне достаточно не совсем заоблачные суммы, я имею ввиду в пределах полумиллиона в рублях достаточно будет...важнее ресурсов только правильно структурированный и написанный скрипт бота...протестированный не один день. Скажу так, только на тесты и отладку займет около 25-30% от всего капитала. Так как ни одно тестирование на девнете не будет близко к реальности, поэтому приходиться тесты делать сразу на мэйн'е, затрачивая реальные активы..Ну и естественно, все это дело писать на rust, разворачивать на мощном онлайн сервере с Ubuntu если , например, захотите быть в тренде, использовав дексы с соланой..ах да, ещё надо будет настроить и сервер под ваши нужды...
Допустим у меня есть пол миллиона). Т е написать бота на расте, сделать набор смартконтрактов, арендовать сервак, настроить и запустить в эту сумму получится уложиться? Есть сомнение... Или вы имеете в виду, что 500 тыщ нужно будет только в инфру вложить? Я почему интересуюсь. Был интерес самому попробовать это сделать, но я только на ноде умею прогать и знаком только с evm сетями
Да, я имел ввиду, 500 тыс вполне хватит написать, развернуть и отладить бота. Само собой здесь уже включены расходы на аренду сервера и ноды. Далее останется внести, назовем, например, -"рабочий депозит". Сумма рабочего депозита может быть разная. Смотря какую тактику вообще заложили в бота. К примеру, под мои цели (я сейчас занимаюсь отладкой бота, скажем, микроарбитраж), вполне достаточно будет и 500 баксов рабочего депозита.
Специально для читателей в РФ, вы не сможете нормально распоряжаться деньгами на б.картах российских. Вас будут постоянно блочить за подозрительные операции. Это основной, но очень жирный, минус.
Так оно и есть, однако если тут автор рассматривает меж.биржевой обмен, то есть переливать денежную массу с одной биржи на другую и зарабатывать на разнице цен на биржах, поэтому участие банковских карт в данной схеме никак не учитывается и не должно учитываться, только в момент покупки самой криптовалюты и в момент вывода средств уже себе на карту
Существуют ОООшки уровня "рога и копыта" которые заведут вам на счета вполне белые и чистые ярды вечнодеревянных за ваши тезеры, правда за 13-15% комсы.
Надо быть дурачком, чтоб сводить свои деньги только в одну карту одного банка....
Интересная статья. Расскажите, вы все 2 870 "токенов" используете? Если да, то каким алгоритмом пользуетесь для поиска возможностей?
Интересно что с API? Сколько запросов и как часто? Это платно или нет?
В целом, какая цель сканера?
Спасибо.
2 870 — это общее количество криптовалютных пар, которые сканировались на 16 биржах.
Как работает алгоритм:
Сканер попарно сравнивает цены покупки и продажи между биржами по всем доступным валютам: сначала между двумя, затем следующими двумя, и так далее по списку. Общее число сравнений получается значительно больше — вручную такой объём проверить невозможно.
Если находится положительная разница в ценах (когда можно купить дешевле, а продать дороже), сканер уведомляет пользователя о потенциально прибыльной сделке.
Однако важно понимать: число действительно подходящих сделок на выходе существенно меньше, чем общее количество проверок.
Цель проекта чисто академическая - проверить существуют ли реально арбитражные возможности и можно ли их использовать.
API у бирж бесплатный, но некоторые требуют регистрацию. По частоте запросов так же могут быть ограничения, но это не критично.
C 2021 занимался разработкой программ (rest, websocket) для синхронного арбитража фьючерсов (binance, okx, huobi, gate, kucoin, bybit). За два года сделал на ней примерно 500-700%. Сравнительный анализ показал, что существуют быстрые всплески разницы цены порядка 1-5% за времена меньше секунды и моя прога их отрабатывала. Спот арбитраж не рассматривал ввиду очевидной причины, а именно за время транзакции цена измениться. На данный момент то ли рынок устраняет дисбаланс цены, то ли из за спада рынка, арбитраж фьючерса не так уже эффективен, но я уверен, что ещё выстрелит, так как дисбаланс является фундаментальным свойством динамической системы.
А сейчас чем занимаетесь?
Если, этот вопрос ко мне, то потихоньку наращиваю мощности совершенствую код, мониторю (сижу в засаде):), посматриваю на dex с api и фьючом. А вообще было бы интересно найти единомышленников, так как уверен, что потенциал есть.
Привет, потиху занимаюсь ботом binance - dydx. Если интересно, давай пообщаемся.
Тоже интересно. Я работаю со спотом, но это реально очень тяжело, время от момента как засек арбитражную ситуацию до выставления заявки 0.2 - 3 мсек и в большинстве случаев она не срабатывает. Правда я ставлю ioc ордера. На python уже не знаю как оптимизировать, учу golang :). Хотя имхо тут уже и golang не поможет.
Каким провайдером пользуютесь?
Код запускаю на виртуальной машине serv.host где-то в Нидерландах, какой там провайдер хз, пинг до api серверов примерно 6-10 мс. Дома МТС 500 Мбит/сек. и 20-60 мс пинг. если конечно правильно контекст понял :)
Тоже готов пообщаться :)
Автор копал очень усердно но совсем не в ту сторону. Первая ошибка - это то, что рассматривал спот а не фьючерсы либо dex-cex арбитраж, все сливки именно там. Второе - в списке мониторинга мало бирж, да и я не вижу там тех площадок, которые склонны "люфтить" курсом всяко разных щиткоинов в рамках 1-4% курсовой разницы на протяжении 15-45 минут. На личном опыте уверенно скажу, что из темы реально "поднимать" 25-75% от депозита в месяц, и это реальность. Главная задача - это не спалиться, чтобы площадка не просекла, что вы завели на неë 5к usdt а через три месяца волшебным образом "наторговали" до ~18к usdt и хотите вывести. Там не болванчики сидят, давно мониторят "токсичные" сделки и выдают неопытным бан. Очень повезëт, что вернëте стартовый капитал через пару месяцев. Хотя и существуют хитрые ходы как не попасть в черный список биржи.
И ещë одно - для любителей инвестировать незнакомым и отдавать трейд ключи по API. Знайте, что есть как минимум пара железобетонных вариантов вывести ваши кровные имея на руках апи ключи только для совершения торговых сделок с заблокированным выводом средств по апи. Это касается совершенно любой биржи.
Главную тему на чем сейчас без рисков рубят бабки не рассказали :)
Ещё любопытно, как автор обходит ограничения биржи на количество запросов? Если просто опрашивать по REST IP, то в лучшем случае, состояние стакана будет будет получатся раз в 2-3 минуты
Да, действительно ограничения есть, и у каждой биржи они разные. У OKX например максимум 10 запросов в 2 секунды. Но хитрость в том, что поиск проходит в 2 этапа. На первом - мы выкачиваем все тикеты оптом, в одном запросе и производим первоначальное сравнение цен. Происходит отсев подавляющего большинства комбинаций. А по найденным сделкам уже полностью запрашиваем весь стакан и проверяем более тщательно с учетом глубины и комиссий. Их не так много на самом деле остается. На 16 бирж уходит меньше минуты.
Кроме того, как я писал, в используемую библиотеку ccxt авторами включена система таймингов. И она сама знает к какой бирже, как часто можно обращаться. Если просишь слишком часто - выдаст данные из кэша.
А вот если бирж подключить больше - тут без вебсокетов не обойдешься. Но это уже другая история.
По rest примерно раз в секунду, а через websocket порядка 20-100мс и без ограничений. Все это есть в описании api. Можно даже ордера через wss выставлять, пробовал, но особой разницы не почувствовал. В итоге опрос через wss (но можно и rest), ордера rest. Вот было бы интересно на dex все это реализовать, но что нормального api на dex пока не нашел, может плохо искал. Есть например dxdy. A что касается количества бирж, то не очень понятно зачем вам много, у вас на каждой депозит будет?
Много бирж просто чтоб статистику собрать-изучить. В реальности то конечно много не надо.
Да, изучить это правильно, но надо также учесть, что полезный дисбаланс цены происходит вследствии крупных событий на рынке и в этот момент api многих бирж начинает колбасить, так что реализовать полезный сигнал может не получиться (пробовал, например gate не очень). Не уверен, что и руками получиться без сильной задержки.
1) Если сервер использует общую инфраструктуру для обработки и REST, и WebSocket-запросов, перегрузка одного канала (например, тысячи wss-соединений) может привести к ограничениям для всех пользователей, включая REST. Многие API устанавливают общие лимиты запросов на аккаунт, независимо от протокола (HTTP/REST или WebSocket). Если вы превысите лимит через wss, REST-запросы также могут быть заблокированы. 2) имелись ввиду платные тарифы для высокочастотных wss-каналов с увеличенным лимитом сообщений. Blockchain-ноды (Квикнод, Дизнод, Алхеми, Хелиус и тд) предлагаю различные тарифные планы с приоритетным доступом к wss в том числе.
Это не так. Вы не совсем правильно понимаете работу WebSocket-каналов. Они не имеют таких ограничений как REST.
В REST каждый запрос требует отдельного соединения, его каждый раз инициирует клиент. И каждое такое соединение дает нагрузку на сервер. Поэтому их кол-во в единицу времени ограничивают.
При использовании WebSocket, соединение устанавливается одно на каждый тип данных, и оно постоянно открыто. Практически нет накладных расходов. Передачу данных по каналу инициирует сервер. Это позволяет транслировать котировки постоянным потоком в режиме реального времени. Тут больше вопрос к клиенту - он должен успевать их обрабатывать. Тысяч соединений не требуется, для одной биржи достаточно 3-4 каналов.
И еще никаких лимитов по WebSocket со стороны сервера не существует. И их использование не приводит к ограничениям по REST. Эти сервисы обычно никак не связаны.
Все правильно. Но лимит все таки есть - по умолчанию один сервер может обрабатывать 65 536 соединений WebSocket на один IP-адрес.
Также есть информация, что при правильной настройке системы (много CPU, RAM и быстрая сеть), настроенной серверной системе и оптимизированном серверном программном обеспечении возможно до 1 миллиона одновременных активных соединений.
Я вас немного поправлю, я не совсем правильно понимаю работу rest, но очень хорошо понимаю и активно использую wss...На практике провайдеры вводят ограничения на кол-во соединений, скорость сообщений и общую нагрузку, чтобы предотвратить злоупотребления. И влияние wss на REST возможно при перегрузке общих серверных ресурсов или при превышении единой аккаунт-квоты. К примеру Binance и Kraken, там это описано. Ну а если в вашем опыте не было таких лимитов — вам повезло с провайдером ))
Спасибо за интересную статья, сам немного писал подобное на Python. У меня возник вопрос, не увидел, чтобы осветили. Частота обновления данных в REST API ведь может варьировать даже в рамках разных конечных точек на одной бирже, а вы смотрите несколько бирж. Может ли быть такое, что часть сделок просто теряется, а какие-то вообще уже не отражают действительность за счет разной частоты обновления данных в REST API?
Безусловно часть сделок может теряться — это связано с тем, что REST API не предоставляет котировки в реальном времени. В результате возможны и ложные срабатывания: мы сравниваем не актуальные данные с биржи, а кэшированную копию, которая могла устареть.
Тем не менее, важно понимать: если сделка все же найдена, она проходит в сканере регулярную повторную проверку. И каждый раз — уже на обновленных данных. Это позволяет с высокой (практически 100%) уверенностью утверждать, что сделка действительно существует.
Почему rest или wss не предоставляет котировки в реальном времени или что вы называете реальным временем? Я вижу, что книга ордеров на сайте биржи и через rest совпадает, более того ордера которые я выставляю находятся в соответствии с данными этой книги. Конечно существуют задержки, сбои и ошибки в api, но это как правило происходит при сильных колебаниях цены и особенно у таких бирж как gate, kucoin, bybit и др., и я думаю не случайно, так как это происходит не у всех. В сухом остатке, выбирать биржи надо с надёжным api, книга ордеров через wss, так сразу получаете данные по всем парам, а не перегружаете rest, например если нужно получить данные для 500 пар.
Вы правы - если рассуждать строго, "реального времени" как такового не существует - любые данные, полученные через API, уже устарели на момент их обработки. Я использовал этот термин условно, имея в виду, что задержки при получении данных через REST, как правило, существенно выше, чем при работе через WebSocket.
Как я уже упоминал, текущий проект — это эксперимент, и REST был выбран в первую очередь ради простоты реализации. Для полноценной работы, особенно если нужно отслеживать множество торговых пар одновременно, использование WSS, безусловно, предпочтительнее.
А что предлагаете делать с ситуацией, когда эти 500 пар являются достаточно ликвидными и по wss приходит большое количество данных, например в реальном времени (а ведь ещё и не все биржи удобно собирают все апдейты в список, часто нужно подписаться на интересующие пары отдельно)? Вам же еще нужно сделать по крайней мере попарное сравнение, а это O(n^2), достаточно долго получается. Пытаться как-то распараллеливать и смотреть уже нагрузку по потокам/процессам?
Хороший вопрос. Чтобы ответить подробно, нужно немного углубиться в реализацию.
В сканере большинство процессов работают асинхронно и параллельно — у каждого этапа своя очередь и свой поток. На первом этапе мы используем так называемые тикеры — это краткая информация по каждой паре (например, текущие bid/ask), но без глубины стакана. При использовании REST большинство бирж позволяют получить тикеры по всем парам одним запросом. Это позволяет быстро пробежать по тысячам пар (например, с 16 бирж) за несколько секунд.
На этом этапе применяется простая проверка: если bid ≤ ask, то арбитража нет — такая пара сразу отбрасывается. Остаются только те, где есть потенциальная разница — их, как правило, немного. Эти пары попадают в отдельную очередь для более глубокой проверки.
На втором этапе для проверки ликвидности мы уже загружаем стакан (orderbook) по каждой отфильтрованной паре — да, тут запросы идут по одной паре, но объём данных гораздо меньше, и вся цепочка проверки по всем биржам обычно укладывается в менее чем минуту.
Такой подход позволяет избежать O(n²) для всех пар — мы сначала отбрасываем "явно неинтересные" комбинации, а затем более точно обрабатываем только потенциально релевантные.
ниже ответил
И всё-таки утверждать на 100 %, что сделка существует не корректно. Нет, вы конечно можете что то купить на одной бирже и это же продать на другой, но когда и с каким профитом это произойдет вы точно не знаете. Конкретная информация относительно этого содержится в торговом опыте.
Согласен, гарантировать 100% исполнение сделки невозможно — цепочка действий не является атомарной и содержит неизбежные задержки.
Процесс выглядит следующим образом:
изменение цены на бирже → получение данных (REST) → анализ → уведомление пользователя → формирование и отправка ордера → исполнение на бирже.
Основные риски сосредоточены на последних двух этапах: отправка ордера и его исполнение занимают наибольшее время и подвержены внешним факторам — таким как волатильность, задержки на стороне пользователя (человеческий фактор) или отказ API.
Когда я говорил о "практически 100%" - это касалось достоверности сигнала на момент его генерации. Сделка с положительным профитом действительно существовала в рыночных данных, проверялась повторно и подтверждалась на уже обновлённых котировках. Однако это не означает, что её удастся реализовать - вероятность "устаревания" сигнала возрастает именно в момент исполнения, особенно при высокой волатильности. Таким образом, точность детекции близка к 100%, но успех исполнения зависит от внешних условий и скорости реакции.
Не очень понятен вопрос про ликвидность и большое количество данных. Например, через websocket binance вы получаете книгу ордеров каждые 100 мc и данными по 500 парам (это сколько вам надо, может вас только одна интересует). Через это время какие то пары уже успели измениться, а другие нет. Но вы просто каждые 100 мс получаете строку данных определенной длины, например 100 тыс. символов (там есть какое-то ограничение ), а по другой бирже тоже самое (ну может какие-то пары не совпадают, другой тайминг, ну это не принципиально). Далее ваша программа сравнивает эти строки и рассчитывает разницу в цене и если есть полезный сигнал выставляет ордера. Например, моя программа на моем скромном железе успевает за 100 мс (даже за 5 мс) сравнить все пары с двух бирж (и выставить ордера, если есть сигнал). Поэтому вопрос объема данных и скорости их обработки важен, но пока не принципиален.
Арбитраж криптовалют — или переливаем из пустого в порожнее