АЛГОтрейдинг | ALKO_trading | CRYPDE | HFT
رفتن به کانال در Telegram
Crypto algorithmic trading. High-Frequency arbitrage & market-making. #crypto #trading #hft https://crypde.com/ contact hello@crypde.com
نمایش بیشتر831
مشترکین
اطلاعاتی وجود ندارد24 ساعت
+27 روز
+5030 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئیه '26
ژوئیه '26
+25
در 0 کانالها
ژوئن '26
+65
در 0 کانالها
Get PRO
مه '26
+57
در 1 کانالها
Get PRO
آوریل '26
+67
در 0 کانالها
Get PRO
مارس '26
+170
در 2 کانالها
Get PRO
فوریه '26
+29
در 0 کانالها
Get PRO
ژانویه '26
+82
در 0 کانالها
Get PRO
دسامبر '25
+21
در 0 کانالها
Get PRO
نوامبر '25
+35
در 0 کانالها
Get PRO
اکتبر '25
+56
در 0 کانالها
Get PRO
سپتامبر '25
+18
در 0 کانالها
Get PRO
اوت '25
+46
در 0 کانالها
Get PRO
ژوئیه '25
+25
در 0 کانالها
Get PRO
ژوئن '25
+26
در 0 کانالها
Get PRO
مه '25
+18
در 0 کانالها
Get PRO
آوریل '25
+11
در 0 کانالها
Get PRO
مارس '25
+5
در 0 کانالها
Get PRO
فوریه '25
+5
در 0 کانالها
Get PRO
ژانویه '25
+9
در 0 کانالها
Get PRO
دسامبر '24
+7
در 0 کانالها
Get PRO
نوامبر '24
+19
در 0 کانالها
Get PRO
اکتبر '24
+12
در 0 کانالها
Get PRO
سپتامبر '24
+6
در 0 کانالها
Get PRO
اوت '24
+18
در 0 کانالها
Get PRO
ژوئیه '24
+5
در 0 کانالها
Get PRO
ژوئن '24
+3
در 0 کانالها
Get PRO
مه '24
+6
در 0 کانالها
Get PRO
آوریل '24
+131
در 0 کانالها
Get PRO
مارس '24
+39
در 0 کانالها
Get PRO
فوریه '24
+115
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 13 ژوئیه | 0 | |||
| 12 ژوئیه | 0 | |||
| 11 ژوئیه | +1 | |||
| 10 ژوئیه | +1 | |||
| 09 ژوئیه | 0 | |||
| 08 ژوئیه | +1 | |||
| 07 ژوئیه | +1 | |||
| 06 ژوئیه | +3 | |||
| 05 ژوئیه | +9 | |||
| 04 ژوئیه | +1 | |||
| 03 ژوئیه | +3 | |||
| 02 ژوئیه | +4 | |||
| 01 ژوئیه | +1 |
پستهای کانال
Как проебаться с EMA. Три раза
Блядский йож, третий раз я проебываюсь EMA, из-за чего правильная идея нихера не работает.
Я постоянно, ПОСТОЯННО горю на какой-то простейшей математике, поверх которой построена вся система.
Сначала был баг в AVG.
Потом был баг в EMA.
Потом снова был баг в EMA - я уже писал про него, там инициализация была слишком долгая.
А теперь бинго: если события прилетают дискретно, то обычную EMA использовать нельзя. Нужна Continuous EMA, она же EMA-DT.
Потому что между событиями может пройти 1 ms, а может 500 ms, но обычная EMA считает, будто шаг времени всегда одинаковый.
На длинных интервалах типа часа или дня на это плюс-минус похер. А вот если считать EMA в окне 1 секунда или 100 ms - начинается просто пиздец. Ты думаешь, что сглаживаешь данные по времени, а на самом деле сглаживаешь количество событий.
В итоге снова надо перепроверять кучу тестов, потому что EMA теперь другая.
Правильная идея (не факт). Правильные данные (точно нет). Неправильная формула (всегда да). Алготрейдинг, хули.
#bugchain
| 2 |  بدون متن... | 314 |
| 3 | HFT - это бесконечная куча конечных конченных автоматов состояний (FSM):
- свой веб-сокет - десяток FSM;
- свой https - еще FSMки;
- свой event loop - пара FSM;
- управление соединениями - еще FSMки;
- моделька тру прайса - тысячи FSM (сотни групп);
- перестановшик ордеров - еще пара FSM;
- супервизор - десяток FSM;
- автоматичекий подбор сетапов - десяток FSM;
- риск-менеджер - сотня FSM;
- мониторинг - сотня FSM;
- jitter - еще пара FSM;
- execution - отдельные FSM под каждую биржу;
и ты сидишь и бесконечно ловишь нескончаемый поток тупых и не очевижных багов и в голове постоянно context-switch между этими FSM.
#hellcode | 482 |
| 4 | Сегодня я познал банальность (фраза не моя, mn - отдаю дань тебе):
Представьте ситуацию что вы выставили лимитки вглубь стакана и переставляете их когда поменялась fair price / hedge price / true price.
До сегодняшнего дня я переставлял лимитки всегда, как только true price меняется больше чем на price tick. Ну очевидно же, что остальные перестановки не имели смысла - смысл снимать и ставить в ту же цену.
Но, я вас обрадую: перестановки на 2 тика, 3 тика, 5 тиков - тоже не имеют смысла. Если переставлять я только после 5 тиков - то количество api запросов падает в 20 раз, а прибыль вырастает в 4. Потому что вы дольше стоите в стакане и получаете лучшее место в очереди прайс уровня.
(Это зависит от монеты если шо)
Я тут ебусь со сложными моделями фильтрации токсика, предсказанием хеджера наперед, и это все хуйня по сравнению с "просто меньше дергайся"
#trueprice | 481 |
| 5 | Я уже и подзабыл почему канал называется АЛКО-трейдинг :)
В начале когда я только начал заниматься этой темой и меня спрашивали чем занимаешься - я отвечал "алго трейдингом", и человеки такие не в теме "шо? алко трейдинг?"
Ну и ирония в том что я не употребляю алкоголь вообще | 451 |
| 6 | Эволюция понимания toxic flow и trueprice
1. Сначала я понял что toxic генерируют другие биржи, потому что там происходят резкие пробивающие трейды которые тянут рынок.
2. Затем я понял, что не все трейды тянут и не всегда, и не факт что на именно одинаковую высоту.
3. Затем я понял, что перед трейдами еще иногда просиходит перекос стакана: какая-то биржа становится выше, какая-то ниже, вилка схлопывается в середину.
4. И еще вилку не всегда можно отследить, потому что биржи присылают bbo дискретно, а трейды с опозданием.
Поэтому телеметрия должна показывать только то, что я на самом деле смог бы увидеть в live.
5. Потом понял, что влияют еще перекосы сайзов в стакане.
6. Затем понял, что иногда можно отследить токсик по change bbo без трейдов и size imbalance.
7. Затем понял, что даже касающие трейды предсказывают токсик: откусывание сайзов, но правда надо фильтровать wash.
8. Затем понял, что практически ни одна биржа не дает токсик пропорционально в обе стороны.
Например, bitmex генерируют только sell toxic, а lighter только buy toxic.
9. Затем понял, что одна биржа влияет на другую не ровно в определенную latency, а сигнал размазывается во времени, и у каждой биржи это свое распределение влияния A>B.
10. Затем понял, что иногда toxic объяснить однозначно невозможно: есть N кандидатов которые могли к нему привести и учитывать надо все.
Типа цена подвинулась на binance, но хуй его знает это из-за kraken, whitebit или bitfinex. Телеметрия говорит что сигнал явно из Европы, но из-за сильно разной user-latency нельзя достоверно понять кто кого там трахнул первым.
11. Затем понял, что toxic невероятно сильно зависит от того, каким именно size-ом я собираюсь стоять на нужной мне бирже.
Потому что его объем будет по разному филлить мой ордер.
И чем бОльший сайз я собираюсь поставить в стакан - тем сильно сильно сильно сложнее его там оберигать.
12. В итоге это все привело к real-time недо-ML-модели, которая обучается на лету куда именно полетит цена исходя из событий на других биржах.
Пока модель однослойная, то есть она просто события X -> hedger будет такой.
Но скорее всего прийдется дополивать на комбинацию с весами.
(недо-ML потому что это не ML, а полностью свой алгоритм расчета весов, который полностью дебажится и контроллируется)
Каков пиздец
#toxicflow #trueprice | 502 |
| 7 | Когда tg/meet/zoom выбрасывает окошко после звонка и спрашивает "оцените качество звонка"
я всегда ставлю одну звезду - потому что созвоны это всегда хуевая трата времени | 541 |
| 8 |  sa - size imbalance ask
sb - size imbalance bid
сколько trading volume можно предсказать если смотреть на poloniex size | 597 |
| 9 | То что я раскопал сегодня - это просто отрыв башки:
1. Я случайно нашел предикт, по которому получилось на многих монетах предсказать цену на 60+ сек вперед.
2. И этот предикт - биржа poloniex. Да, йобанная полынь, и это просто пиздец.
На poloniex сплошной wash трейдинг, там нет живых юзеров, там всему уже давно пиздец.
3. Но вся моя телеметрия говорит: перекос сайзов в стакане на poloniex предиктит движение binance/okx/bybit через 60 секунд, причем такой уверенный предикт, ниже скриншот покажу.
Но блять как это возможно, если там даже нет трейдов?
Я убил на это почти неделю.
4. На poloniex есть единственный маркет-мейкер, это он сам.
И этот мм работает так: он смотрит на нормальную биржу binance/bybit/okx (или на все сразу, я точно не знаю) и строит свой стакан.
Но стакан он строит на основе avg нормальной биржи.
5. То есть, еще раз, это супер важный момент:
верхушка best ask best bid на poloniex - это avg SIZE от некоторой глубины стакана на который он смотрит на стороне.
Именно size, а не price. Цену ask/bid он может поставить любую, потому что он берет 10 bps taker fee с юзера, но именно сайзы он вынужден агреггировать с другой биржи.
6. И вот этот блять поворот: за счет того что mm poloniex'a один, за счет того что он быстрый, верхушка стакана poloniex показывает size imbalance всего рынка. Вчистую.
Как сказал дедуля Саймонс (press F) - все на все влияет.
#trueprice | 641 |
| 10 | Сегодня про latency от бирж и сбор маркет-даты:
1. Я перешел на раздельные оси времени для трейдов и bbo, потому что биржи шлют хуйню и в симуляторе надо знать с какой latency летит bbo, а с какой public trade.
Это нужно чтобы правильно считать телеметрию сигналов и делать maker/taker симуляторы.
Историческая маркет-дата без delivery-time модели - это просто архив событий из параллельной вселенной, а мне низзя чтобы бектесты были фантазией.
2. Вот просто забавные примеры:
- mexc futures присылает bookticker за 3 ms, а трейды за 57..75 ms (если что это наводит на мысль что в момент user take они сначала бегут в singapore bybit и пробуют там купить, а потом возвращаются в токио и говорят получилось/не получилось)
- bitmart шлет bbo за 2.3 ms, трейды за 7 ms
- kucoin bbo 1.5, public trades 1.8, private fill 2.8, што блять? о своем трейде узнаем из public быстрее. Вайб-архитекторы хуле.
- bingx bbo 1.7 ms, trade 22 ms
- binance spot bbo 0.7 ms, trades 1.0 ms
- gate bbo 1.1, trades 0.9
- bitget bbo 4 ms, trades 3.7, но они меняются местами во времени.
и тд.
Видите насколько все перекашивает? И это уже с учетом 5+ соединений.
3. Вообще я отдельно мониторю latency bbo, trades, fill, maker place, maker cancel, ack, taker place и их распределение. Да, я дико заморочился, чтобы симуляторы сходились с live.
4. Но это не конец безумия:
у меня сбор маркет-даты в Финляндии, потому что там hetzner и дешево. Там пишется маркет-дата в бинарный формат, причем пишутся только tsEvent биржи.
То есь в маркет-дате есть метка времени matching engine, но я не знаю когда я ее получил.
5. В каждой локации aws frankfurt, aws tokyo, aws sg, london ld4, zug green, ali hk и тд у меня есть маленькая виртуалка, на которой по ETH запущены датастримы, которые только меряют latency, но уже правильную: с учетом colo, с учетом race connections. И она в RDS сторит распределение какая сейчас latency от какой биржи, и так каждый час.
Я специально меряю по ETH, потому что он есть везже и он самый нагруженный: то есть latency по нему является показателем, на остальных инструментах - или также или лучше.
То есть у меня отдельная сеть датчиков latency :)
6. То есть маркет-дату я собирараю в Finland, а latency к ней отдельно с учетом race/colo/aws-reality.
Потому что собрать сразу все в aws, то будет примерно 300_000 соединений, надо будет примерно 3000 vcpu aws, сами посчитайте сколько бабла улетит просто на сбор и трафик.
#datastream | 498 |
| 11 | А вы меня за php стебете: вот вам вакансия в фонд в Лондоне
https://bambusdev.my.site.com/s/details?jobReq=Excel-Engineer_REQ7540 | 483 |
| 12 | Обычная веб-разработка vs HFT-hell
На примере "а давайте приделаем кнопочку stop".
Веб-разработка:
- в базу добавляем колончку active 0/1
- в SQL-запрос добавляем условие AND active=1
- пару раз ctrl+R (F5)
- обновляем сервер
- опционально добавьте тут этап TDD-хуйни
- и на этом собственно все
HFT-hell:
- в нужный сервис добавляем флаг active 0/1 - это переменная в процессе
- учим процесс реагировать на измменение этого состояния: есть есть нельзя просто if (active) все время, нужно чтобы прямо state machine поменялась: если активны работаем, пришла команда "стоп" - значит перестаем.
- учим supervisor чтобы он в процессы на сервере слать команды stop & run
- учим центральный root supervisor чтобы он мог между серверами передавать команды run/stop:
то есть схемка такая: жму stop => root supervisor => N local supervisor's на сотне серверов => в каждом сервере в процессы шлется команда stop => процесс ее обрабатывает
- прорабатываем ситуацию: а что будет если где-то сеть оборвется и stop долетит, но не до всех?
- прорабатываем ситуацию: restart supervisor'a
- обновляем сотню серверов
- терпим просадку потому что соедиения перезапустились/оборвались и race-connections еще на нашли лучшее.
- на web-сервере приделываем кнопочку stop, которая по своей шине передаст в root api команду.
Йо-хо-хо!
#hellcode | 500 |
| 13 | Кто-нибудь может объяснить этот замес?
https://announcements.bybit.com/en/article/important-notice-for-users-in-the-european-economic-area-eea--blt4135ab861456d7bf/ | 518 |
| 14 | Я почти перешел (тут всегда почти и никогда окончательно, привыкайте) на новый механизм расчета trueprice и фильтрации toxic flow.
Я даже перестал записывать какая это блять версия, может 40+.
0. Предистория тут - https://t.me/alko_trading/1604 - я писал как нахер запороть всю инфраструктуру с trueprice/toxic flow.
1. Основной замес в том, что биржи присылают события в каком-попало порядке:
логично что сначала должен быть трейд (серия трейдов), а сразу после него новый стакан (bbo, bookticker). Вы не представляете как мне хочется чтобы так было.
Но реальность куда суровнее:
- ни одна биржа не гарантирует что прилети сначала trades, а потом новый стакан
- ни одна биржа не гарантирует что прилетят ВСЕ изменения стакана, без пропусков. Ну трейды они хотя-бы присылают.
- и у половины бирж есть sampling: это когда они делают снимок стакана только раз в 5..10 ms (у каждой свой период) и шлют этот снимок дискретно: я не вижу всех изменений стакана, а только кратно 10 ms снимки.
- более того блядский еж они еще не могут объяснить что это за время: это matching engine time, push gateway time, или что-то свое
- ахтыжйобаныйтынахуй еще не факт что время у них синхронизировано с ntp (плавающую ось времени между локациями оставим sub-us гурманам).
2. Это все порождает такую проблему: на лету невозможно синхронизировать между собой bbo & trades.
Я почти 2 года это делал, но есть биржи на которых это технически невозможно.
У меня был костыль, где я делал несколько race-соединений, и так получалось что какое-то всегда опережает, а какое-то опаздывает, и если сделать 10 соединений, то вероятность уже 83.333% что можно словить правильный порядок: сначала trades, потом bbo.
3. Но есть биржи где public trades лелят сильно позже, и даже мой мега костыль не помогает.
Например, bybit, okx, mexc, ... та блин наверное проще сказать у каких бирж порядок верный - у никаких ахаха!
То есть сначала новый стакан, а потом спустя 2-3 ms трейды. И задним числом я конечно понимаю что стакан поехал на трейдах, но в live прийдется ждать аж 2-3 ms, что в мире HFT - овердохуя.
4. В итоге пришлось переписывать саму идею как получать данные с коннеторов: вместо того чтобы мержить все в один поток и делать реконструкции стаканов - все идет нахер:
- отдельная ось времени для bbo
- отдельная ось времени для trades
= и постоянная проверка какой bbo, а потом какие трейды его потенциально херят
= это полный отказ от реконструкции стаканов, но полное понимание сейчас едем на трейдах или нет
= код сильно быстрее, влажу в 1 us на всю математику и 0.6 us на socket_write
= и вы не представляете насколько больше toxic-событий теперь видно
Я аконец-то перестал спорить с биржами и начал считать их как есть - кривой, лагучий, вероятностный источник говна.
#toxicflow #datastream | 528 |
| 15 |  Вашему вниманию представляется пуская виртуалка в alicloud (у них это ECS называется).
Какая-то хуева туча левых процессов али-юн-дюн, али-хуй-што, и этот aliyunmonitor всегда на пустом месте срезает 2% cpu и делает две сотни context switch. | 492 |
| 16 | Хе-хе, я эпично перемудрил с телеметрией сигнала.
1. представьте ситуацию, что мы стоим в bybit singapore и смотрим на okx hk и binance tokyo.
от нас (singapore) до tokyo 32 ms,
от нас до hk - 15 ms,
между tokyo и hk - 20 ms,
вот такой latency-треугольничек.
2. вдруг на okx hk происходит жирное движение, оно за 15 ms долетает до нас, за 20 ms долетает до tokyo binance.
3. и мы зная этот треугольник понимаем, что цена на binance уже поменялась, просто мы этого еще не видим.
А увидим это через 32-20 = 12 ms.
4. И вот я эти 12 ms и запоминал в телеметрии, потому что очевидно что сигнал из okx hk реализуется в цене binance за это время/
5. А хер там! Все размажется, и будет не 12 ms, и не 20 ms, и даже не 220 ms. Удары будут лететь волнами, у которых нет очевидного "пика влияния".
Да, первый удар будет через 12 ms, но он не главный и не значимый.
6. Короче, рыночек сильно медленее и сильно неэффективнее чем я представлял.
#datastream #toxicflow #network | 524 |
| 17 |  بدون متن... | 520 |
| 18 | Запасайтесь поп-корном, детектив хроники алко-трейдинга
Знаете первое правило детектива? Главное в расследовании не выйти на самого себя!
Сукоблять это ж просто угар:
1. Интро читайте тут https://t.me/alko_trading/1615
Коротко перескажу: я сетаплю XMR везде где только можно, но комбинация bybit via binance у меня не получается. Именно в XMR. В LTC, в ETH получается - а в XMR нет.
2. Основная проблема - это источник toxic'a на стороне, который я не мог найти полгода.
То есть binance двигается, а затем bybit через 22 ms (на самом деле там волна с 15 до 30 ms с плавным экстремумом на 22 ms).
А минимально возможная сеть - 32 ms. Причем этот линк стоит 10к баксов в месяц. И вроде как очевидно, что никто кто тратит 10к баксов не полезет в XMR, потому что это все равно не окупится - bybit умудряется реагировать на binance за 22 ms.
3. И сегодня я его нашел - это блять я сам.
Я наконец переписал систему телеметрии, которая стала говорить не просто куда пойдет хеджер в будущем, а какой именно экономический ущерб это мне принесет, если я не буду слушать цену с этой биржи.
4. И вот теперь смотрите веселуху:
- я торгую whitebit (frankfurt) > binance (tokyo), у меня e2e=69 ms, я там самый быстрый парень на районе и почти весь volume мой.
- но, нарисовался какой-то чувак (возможно не один), который арбитражит whitebit (frankfurt) > bybit (singapore), у него скорее всего нет colocation и нет линка frankfurt <> singapore, поэтому у него latency плавающая и она примерно 80-90 ms от frankfurt до singapore.
- и вот вам телеметрия: когда происходит trade на whitebit - я побежал и подвинул binance через 69 ms, а этот чувак увидел мой трейд позже, побежал на bybit и въебал там по стакану taker-ом, и он добежал туда за 85-90 ms.
- в результате будет казаться, что binance поменялся, а затем bybit через 16..26 ms с пиком на 21-22.
- более того, как только поменялся binance, то через 2 ms поменяется kucoin и вообще все биржи которые есть в tokyo. И будет казаться что между изменением bybit и kucoin - 21 ms.
- раунд!
5. То есть я геренирую toxic flow для binance, а кто-то присосался ко мне. Хитро!
Следующим постом бахну скриншот телеметрии.
Чувак который арбитражит whitebit > bybit, если ты это читаешь, напиши мне в личку, отправлю тебе бутылку, а то тебе не долго осталось :)
#chronicles #toxicflow | 492 |
| 19 | Бинанс проебался с mica лицензией и шлет по EU письма «сорян мы закрывается в вашей стране»
https://www.cnbc.com/amp/2026/06/26/binance-to-stop-providing-services-to-european-clients-after-failing-to-obtain-license-ft.html | 471 |
| 20 |  Был SIMD JSON = | 444 |
