АЛГОтрейдинг | ALKO_trading | CRYPDE | HFT
前往频道在 Telegram
Crypto algorithmic trading. High-Frequency arbitrage & market-making. #crypto #trading #hft https://crypde.com/ contact hello@crypde.com
显示更多835
订阅者
+224 小时
+37 天
+3430 天
数据加载中...
相似频道
标签云
进出提及
---
---
---
---
---
---
吸引订阅者
七月 '26
七月 '26
+31
在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个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 22 七月 | 0 | |||
| 21 七月 | +2 | |||
| 20 七月 | 0 | |||
| 19 七月 | 0 | |||
| 18 七月 | 0 | |||
| 17 七月 | +1 | |||
| 16 七月 | 0 | |||
| 15 七月 | +1 | |||
| 14 七月 | +2 | |||
| 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 |
频道帖子
| 2 | Щас буду ныть, терпите.
Хроники алко-симуляции.
Я очень очень проебался с симуляцией маркет-даты. Как обычно идея верная, а в реализации допустил баги.
---
Баг номер один:
Представьте ситуацию что вам летит поток:
ts - bbo
ts - bbo
ts - trade buy
ts - bbo
ts - bbo
ts - trade buy
ts - trade buy
ts - trade buy
ts - bbo
и в среднем latency для trade 2 ms, а latency для bbo 1.8 ms.
И если взять и просто к ts биржи приплюсовать эти средние latency, то все будет норм, но блять нет.
В очень редких случаях так окажется, что bbo будет приходить из будущего. И эти редкие случаи поменяют структуру потока маркет-даты, будет казаться что предиктов нет, как раз потому что сам поток смотрит в будущее.
(на самом деле у меня latency это распределение, но даже если сделать фиксированные числа то проблема никуда не денется)
---
Баг номер два:
float / decimal в маркет-дате. Думаете я не знаю про прикольчики чисел с плавающей точкой? Конечно знаю, но это помешало мне проебаться с ними в очередной раз.
Берем timestamp от биржи $x (он обычно обрезан до 1 ms).
Добавляем к нему latency, например, 2.1 ms.
Получаем в одном случае 1784327611.3758000, а в другом 1784327611.3758001
Сортируем события по времени доставки - и тем самым меняем порядок потока. Ахаха блять, пора переходить на int us.
---
Комбо из этих двух багов заставит переделать ВСЕ тесты и пересмотреть ВСЕ решения за последние полгода. Хнык-хнык типа?
#hellcode #datastream #chronicles | 157 |
| 3 |  Эта картинка идеально иллюстрирует всю суть дебага алготрейдинга: хер пойми шо происходит | 287 |
| 4 |  ALKO_trading Chat is being protected by @Safeguard
Click below to verify you're human | 1 |
| 5 | Хотите расскажу самый простой способ филировать toxic flow?
Это никогда не стоять на верхушке стакана.
То есть вам надо напилить проверку, что если ваш ордер вдруг стал лучшим в стакане - то надо сняться и переставить я глубже.
Это не отфильтрует токсичные сделки полностью, но это самый простой и быстрый способ срезать половину говна. В каком-то смысле вы перекраивание ответственность за фильтрацию на того, кто стоит выше вас - его снесут первым.
Почему это работает? Потому то токсик это информированный тейкер, и он тейкает обычно именно верхушку стакана. И если верхушка улетает - то пора и нам сниматься.
#toxicflow | 315 |
| 6 |  没有文字... | 419 |
| 7 |  я не могу это не запостить:
турбо-крипто-анал-безнал | 515 |
| 8 | Как раскладыдвается PNL
У меня есть система, которая раскладывает итоговый PNL каждой сделки (и любые группы/срезы) на формулу, по которой я могу понять где была пройобка и почему.
Это все встроено в execution и статистика пишется почти real-time.
PNL состоит из (считайте сумму всех параметров):
1. jitter main/hedge
2. clamp = как именно я перенес цену hedger в main space и сколько там bps добавилось/отнялось
3. true price = сколько bps добавил trueprice и почему;
4. offset = с каким отступом от trueprice я стоял (сетка ордеров)
5. toxic hedge = насколько hedger был хуже в момент trade
6. toxic fill = насколько hedger был хуже в момент fill (trade time это на hedger'e, а fill у меня)
7. hedger loss = насколько похерился hedger пока я добежал до него по сети;
8. hedger slippage = какое проскальзывание на hedger'e я получил.
9. fees
То есть PNL = jitter + clamp + true + offset + toxic hedge + toxic fill + hedger loss + hedger slippage + fee maker main + fee hedger taker.
И я вижу каждую из этих колонок в симуляторе и в real-time исполнении, по этим колонками можно понять что происходит. Например
- высокий hedger slippage - надо уменьшать сайзы или увеличивать offset или не хеджироваться (если возможно)
- hedger loss - у меня не хватает latency чтобы добежать до hedger'a
- toxic hedge - в момент когда мне прилелел fill - цена hedger'a уже была в жопе, и я проигрываю потому что не увидел удар со стороны - ищем источник toxic'a
- toxic fill - я видел новую цену, но не успел отмениться, надо шлифовать latency cancel.
- и тд
То есть я не гадаю почему не работает, я знаю причину сразу.
#chronicles | 500 |
| 9 | У вас тоже пост на английском стал? какого хера телега его перевела сама? | 403 |
| 10 | Биржи bitmart & bingx вышли на новый уровень wash'a
Бля, я не хотел это писать, но раз они УЖЕ это сделали - можно и написать :) Хотя я не исключаю что они это сделали случайно.
Занимательная история в духе poloniex size-imbalance, только с фейковыми торгами.
1. Обычно когда биржа рисует торги, то она ставит ордер в стакан, потом сама его тейкает - и получается создается видимость реальной активности.
Есть разные способы это красиво маскировать: несколько ордеров за раз, разные сайзы, разный интервал.
2. Но все способы маскировки херовые, потому что все эти fake-трейды не приводят к price discovery: трейд никак не влияет на цену, ни на какой другой бирже это никак не отражается.
3. Но вот у bitmart трейды начали предсказывать движение на binance. При этом я на 100500% уверен что это wash. Но суко как?
Не могу сказать что это прям лютый предикт, но примерно EV=60/40 (оно считается по-сложнее, я упростил)
4. Оказалось, что bitmart копирует не только стаканы с других бирж, но и делает wash на основе ленты принтов (трейдов).
5. Например, они по быстрому линку смотрят на ленту принтов okx и у себя рисуют точно такие же трейды.
Прикиньте какие хитрецы?
6. В итоге часть трейдов (не все конечно) на 0.5-1 ms будут раньше, чем это отразится на binance.
PS: даже если не иметь супер-быстрые линки за много-денег - все равно есть какие-то ну очень извращенные способы получить сигнал с другой биржи быстрее public internet / aws-ali-backbone.
#datastream #toxicflow | 417 |
| 11 | Спасибо! | 395 |
| 12 | Премиум подписчики, нажмите пожалуйста сюда - https://t.me/boost/alko_trading | 396 |
| 13 |  没有文字... | 426 |
| 14 |  Книга наглядно иллюстрирует как из opensource-решений собирать HFT/low-latency-infra.
ЗЫ: все остальные совпадения случайны | 365 |
| 15 | Продолжение поста, все не влезло в один:
5. В зависимости от биржи будет разный алгоритм cancel-place:
- если на бирже есть команда move - то при росте мы для sell-side делаем cancel+place, для buy-side - move. И наоборот.
- но на некоторых move конченный и так нельзя.
- нужно делать force cancel: не важно мы сейчас размещаем ордер или нет - cancel шлется всегда досрочно (а это подразумевает адресацию ордеров по clientOrderId, которая на всех биржах разная)
- нужно делать parallel cancel: если надо отменить ордера, то сначала делаем cancel в N потоков в разные соединения, потом дожидаемся cancel ack, потом только делаем place.
- но на самом деле нихуя, потому что после cancel-ack надо убедиться что у нас есть новая цена и мы никуда не едем, и только потом делалем place.
- и надо считать hitrate performance на каждое cancel/place соединение, чтобы знать какое быстрее отменяет, какое быстрее размещает, и рубать слабые.
- а потом на некоторых tier1-монетах без линейной апроксимации цены невозможно выставить ордер: то есть надо считать не просто какая цена, а какая цена будет через reaction latency, которая равна скорости hedge > main > hedge.
---
6. И это еще без контроля api limits (о май гад), без мониторинга latency degradation: потому что нельзя ставить ордер, если ты не сможешь его отменить вовремя. Иногда спасает dead switch, но он не у всех есть.
---
7. И это еще без trueprice (toxic flow фильтрации), который возводит этот пиздец в куб.
---
Ставь лайк если хоть что-то понял. А если понял все - скорее всего, у тебя уже есть своя такая же ебаная FSM и ты сейчас ловишь в ней race condition.
#chronicles | 389 |
| 16 | Сегодня поговорим за алгоритм котирования (алгоритм перестановки ордеров в стакане)
Это достаточно адовая FSM-машина, и там есть пачка приколов, которые не сразу понимаешь, а даже если и понял - хер сделаешь быстро.
---
1. На первом уровне hello-world-art:
- у нас есть main - биржа где выставляем ордера, где котируем
- есть hedger - биржа с fair/reference-price на которую будем бежать хеджироваться
- мы берем цену hedger'a, к ней добавляем/отнимаем желаемую высоту и вставляем лимитку в main
- как только цена hedger'a поменялась - переставляем лимитку на новую высоту hedger +/- profit
На этом экскурсия в beginner-level закончилась, а теперь ебучая жесть:
---
2. Что делать если hedger и main ходят на разных высотах?
Надо высчитать jitter - смещение насколько hedge выше/ниже main, и постоянно его учитывать.
Правильно оно называется bias - но я называю jitter, и хули вы мне сделаете :)
Смещение динамическое, меняется во времени, поэтому надо считать real-time EMA. Надо понять ее период - а это огород математики и симуляций.
2.1. На ебанутых монтетах (почти на всех) этот jitter надо считать в log space, а не линейно.
То есть jitter = main/hedge, а не main-hedge.
2.2. На ебанутых монетах (почти на всех) jitter может меняться очень быстро, поэтому нужна защита которая не будет позволять его двигать быстрее условного 1 bps/hour, иначе появится конченный PNL drift: мы купили, потом jitter поменялся, мы продали - и фиксанули минус (или лютый плюс, но на tier1 это будет лютый минус).
2.3. только на один расчет jitter'a можно смело всадить полгода времени, и там не будет конца.
---
3. Нужен механизм main clamp: перенос цены hedger*jitter в main space. И это просто пиздец, я даже не уверен что это поймут:
- что делать, если у вас есть hedger, есть jitter (которный защищен от дрейфа и поэтому всегда отстает) - и вы просто берете hedger x jitter, а потом все равно оказывается что спред main выше или ниже?
- То есть вы как-бы временно НЕпопадаете в спред - и при размещении ордера вы получите post_only rejected. Шо делать? Это прекрасно если main спред широкий и вы всегда попадаете. А для tier1 вы не попадаете в 90% времени.
- Поздравляю, надо одну сторону начинать котировать по main price: например, если main выше hedge, то sell вы будете котировать по main, а buy по hedge.
- Поздравляю еще раз, так тоже делать нельзя: потому что если в этот момент hedger прыгнет вверх, то вы продолжаете котировать sell по main (который не меняется), а buy по hedge: вы просто поднимете buy выше, а sell не подвинете - и вас разъебут сразу же. У вас ведь jitter неверный, на самом деле он другой и hedge влияет на main все равно. Надо переносить движение hedger'a в main space, но у вас нет точки отсчета, которую еще хер посчитаешь правильно.
---
4. Нужен порог котирования (tolerance threshold): если цена hedger'a поменялась чуть чуть, то мы пока не переставляем ордера.
4.1. Порог котирования разный для разных монет:
- меняется в зависимости от волатильности (привет нужна новая система которая считать real-time волатильность),
- меняется от price.tick (привет тем биржам у которых price.tick динамический - вот вам бревно в жопу),
4.2. порог меняется зависимости от строны: если монета растет, то сначала надо отменять sell orders, а buy двигать плавнее, и наоборот. То есть в коде должен быть разный порядок cancel-place в зависимости от стороны.
#chonicles | 351 |
| 17 | Как проебаться с EMA. Три раза
Блядский йож, третий раз я проебываюсь EMA, из-за чего правильная идея нихера не работает.
Я постоянно, ПОСТОЯННО горю на какой-то простейшей математике, поверх которой построена вся система.
Сначала был баг в AVG.
Потом был баг в EMA.
Потом снова был баг в EMA - я уже писал про него, там инициализация была слишком долгая.
А теперь бинго: если события прилетают дискретно, то обычную EMA использовать нельзя. Нужна Continuous EMA, она же EMA-DT.
Потому что между событиями может пройти 1 ms, а может 500 ms, но обычная EMA считает, будто шаг времени всегда одинаковый.
На длинных интервалах типа часа или дня на это плюс-минус похер. А вот если считать EMA в окне 1 секунда или 100 ms - начинается просто пиздец. Ты думаешь, что сглаживаешь данные по времени, а на самом деле сглаживаешь количество событий.
В итоге снова надо перепроверять кучу тестов, потому что EMA теперь другая.
Правильная идея (не факт). Правильные данные (точно нет). Неправильная формула (всегда да). Алготрейдинг, хули.
#bugchain | 481 |
| 18 |  没有文字... | 502 |
| 19 | HFT - это бесконечная куча конечных конченных автоматов состояний (FSM):
- свой веб-сокет - десяток FSM;
- свой https - еще FSMки;
- свой event loop - пара FSM;
- управление соединениями - еще FSMки;
- моделька тру прайса - тысячи FSM (сотни групп);
- перестановшик ордеров - еще пара FSM;
- супервизор - десяток FSM;
- автоматичекий подбор сетапов - десяток FSM;
- риск-менеджер - сотня FSM;
- мониторинг - сотня FSM;
- jitter - еще пара FSM;
- execution - отдельные FSM под каждую биржу;
и ты сидишь и бесконечно ловишь нескончаемый поток тупых и не очевижных багов и в голове постоянно context-switch между этими FSM.
#hellcode | 632 |
| 20 | Сегодня я познал банальность (фраза не моя, mn - отдаю дань тебе):
Представьте ситуацию что вы выставили лимитки вглубь стакана и переставляете их когда поменялась fair price / hedge price / true price.
До сегодняшнего дня я переставлял лимитки всегда, как только true price меняется больше чем на price tick. Ну очевидно же, что остальные перестановки не имели смысла - смысл снимать и ставить в ту же цену.
Но, я вас обрадую: перестановки на 2 тика, 3 тика, 5 тиков - тоже не имеют смысла. Если переставлять я только после 5 тиков - то количество api запросов падает в 20 раз, а прибыль вырастает в 4. Потому что вы дольше стоите в стакане и получаете лучшее место в очереди прайс уровня.
(Это зависит от монеты если шо)
Я тут ебусь со сложными моделями фильтрации токсика, предсказанием хеджера наперед, и это все хуйня по сравнению с "просто меньше дергайся"
#trueprice | 618 |
