nerd https://nitter.cf/t.co/0Qa3nBSEzo ex: @makerdao
?
Joined May 2020
- Tweets3.7K
- Following2.8K
- Followers2.6K
- Likes6.1K
Pinned Tweet
if you're doing 100M+ monthly volume on hyperliquid/lighter and your strategy is not performing as you want because of the fees, I have a solution for you.
DMs open.
always make sure you have multiple sources and take the minimum, the best in p50 can be the worst in p99
Among quant devs most are happy that they built the foundation of their codebase pre-AI and I cannot agree more, for these systems we were forced to build the right abstractions in an efficient way
Wonder if anyone had success on building a solid foundation post-AI ?
modify is literally the most arbitrary exchange endpoint, everyone just handles it in completely different ways
hyperliquid literally the only exchange to have an `always_place` flag
the underlying intent of traders is only
- do i want to keep that order in the book at all time
- do i want to place an order if what I wanted to modify is not possible
algo traders should be served better and shouldn't need to understand all these quirks, rather focus on your pricing and alfa
matthias 0️⃣ retweeted
one thing every hft dev has to fight: transitions
01/ every transition is a way to lose or win big
your fair value changes at every transition, and volume moves: the nyse auctions, after-hours, blue ocean's overnight book
02/ it's not that easy
- make sure your slow signals are warmed up in time
- widen your quotes preemptively
- reduce size
- fc*kin timezones and holiday calendars
- every feed handler has a hard time at transitions, watch your p99 there
- filter outliers too: liquid -> illiquid is where bad prints show up
03/ where the money is
- snipe anyone who's mispricing instead of giving free options to arbers. don't be a chicken
- funding gets mispriced when the book goes thin: be the one collecting it
exchanges deploy too, downtime exist.
use that as an edge.
01/ for example
recently lighter added a shutdown notice before closing:
{"close_in_ms":12943,"type":"shutdown"}
then closes with code 1012 "server shutting down". they say within 30s
02/ ok then what ?
all sockets got the notice within 13ms of each other. close_in_ms ranged from ~5.3s to ~13.8s, different per socket.
every close landed between 10ms before and 4ms after the deadline. data kept flowing until the close
think about it. everyone has the same constraints, if you're the first to reconnect, you're basically alone for a few seconds.
won't matter in most cases, sure, but during high volatility times this can be a money printer.
03/ works for market data too
you can open the new socket while the old one is still draining, so there's no blind window at all.
basically you always have to treat venue maintenance as a normal state of your system, not an exception.
04/ edge lies in the p99
when designing hft systems, always think about the worst case, the last quantile, that's where shit ton of money can be printed (or lost)
every api/dependency you have can go down, be ready for this
one thing every hft dev has to fight: transitions
01/ every transition is a way to lose or win big
your fair value changes at every transition, and volume moves: the nyse auctions, after-hours, blue ocean's overnight book
02/ it's not that easy
- make sure your slow signals are warmed up in time
- widen your quotes preemptively
- reduce size
- fc*kin timezones and holiday calendars
- every feed handler has a hard time at transitions, watch your p99 there
- filter outliers too: liquid -> illiquid is where bad prints show up
03/ where the money is
- snipe anyone who's mispricing instead of giving free options to arbers. don't be a chicken
- funding gets mispriced when the book goes thin: be the one collecting it
exchanges deploy too, downtime exist.
use that as an edge.
01/ for example
recently lighter added a shutdown notice before closing:
{"close_in_ms":12943,"type":"shutdown"}
then closes with code 1012 "server shutting down". they say within 30s
02/ ok then what ?
all sockets got the notice within 13ms of each other. close_in_ms ranged from ~5.3s to ~13.8s, different per socket.
every close landed between 10ms before and 4ms after the deadline. data kept flowing until the close
think about it. everyone has the same constraints, if you're the first to reconnect, you're basically alone for a few seconds.
won't matter in most cases, sure, but during high volatility times this can be a money printer.
03/ works for market data too
you can open the new socket while the old one is still draining, so there's no blind window at all.
basically you always have to treat venue maintenance as a normal state of your system, not an exception.
04/ edge lies in the p99
when designing hft systems, always think about the worst case, the last quantile, that's where shit ton of money can be printed (or lost)
every api/dependency you have can go down, be ready for this
matthias 0️⃣ retweeted
Desired Orders Are Not Live Orders
In the next part of my series on building an HFT system, I talk about order tracking and some of the hidden race conditions that can bring an automated system to its knees. A must read!
open.substack.com/pub/crosst…
What does that mean for arb/hft ?
01/ bigger players -> more alfa in the flow there
02/ priority fees should be independent and not used there imo, otherwise it will just create an unjustifiable inflation (similar to multi dimensional eip1559)
03/ lots of arb opportunities especially if other countries follow the same path + deeper liquidity/closer to cme
04/ speedbump should be different there too as makers are whitelisted
Excited to work with Payward to forge a path for onchain derivatives built on Hyperliquid's infrastructure. Kraken is one of the most trusted and respected exchanges in crypto. They are also true believers in the technology and crypto ethos. We're honored that they are building on Hyperliquid to bring the next evolution of perpetual markets to the United States.
This is one of these interesting behaviors we've also witnessed on OKX, keep an eye on it!
> During US stock trading hours, Binance only lags Nasdaq by 50-60ms. Whereas normally, getting Nasdaq feeds in Tokyo is at least 75ms+.
最近在做 perp 跨所套利 (Hyperliquid, Lighter, Binance, Entropy).
下面这些冷知识都是我自己实测出来的
1. VPS 放 AWS 东京, AZ 选az4. LightSail的话选默认的A地区就行了. 因为这里离币安服务器最近.
az4 到 Binance 0.3ms, 另外两个区 1.5-1.9ms.
HL 和 Lighter 都走 CloudFront. 换 Lightsail AZ C会比A快1ms..
2. Hyperliquid 行情开 3-4 条连接, 用最先到的消息. (比单条链接快). 具体为啥我也不清楚. 币安数据就没这个问题.
3. HL 撤报价别用 cancel, 用 modify 把单子挪远, 会快一倍..
4. Lighter 免费账户就够了
5. 美股闭市期间. Binance 上的币股变动都是最先的. 领先 Lighter main 50-200ms, Lighter RH 250-350ms, trade.xyz 450-550ms, Entropy ~800ms
6. 美股盘中 Binance 只落后 Nasdaq 50-60ms. 而正常情况在东京收 Nasdaq 行情最快也要 75ms+.
很明显是一些大的做市商有专线, 连接纽约和东京. 比公网链路快很多. 这个咱们散户没办法..
![Trade[XYZ]](https://pbs.twimg.com/card_img/2115522883254689792/cEx4k7y5?format=jpg&name=800x419)
one of the worst thing in HFT dev is deadlocks, worst thing is the existing debugging tools in rust are sh*t
- not adapted for agents usage
- slow
- cannot tell you precisely who is holding the lock when
we can do better than this, and thanks god it's one prompt away
matthias 0️⃣ retweeted
if you're doing 100M+ monthly volume on hyperliquid/lighter and your strategy is not performing as you want because of the fees, I have a solution for you.
DMs open.
are there really quant devs using modify rather than place/cancel ?
or am i the only one to think it should not be a thing
exchanges deploy too, downtime exist.
use that as an edge.
01/ for example
recently lighter added a shutdown notice before closing:
{"close_in_ms":12943,"type":"shutdown"}
then closes with code 1012 "server shutting down". they say within 30s
02/ ok then what ?
all sockets got the notice within 13ms of each other. close_in_ms ranged from ~5.3s to ~13.8s, different per socket.
every close landed between 10ms before and 4ms after the deadline. data kept flowing until the close
think about it. everyone has the same constraints, if you're the first to reconnect, you're basically alone for a few seconds.
won't matter in most cases, sure, but during high volatility times this can be a money printer.
03/ works for market data too
you can open the new socket while the old one is still draining, so there's no blind window at all.
basically you always have to treat venue maintenance as a normal state of your system, not an exception.
04/ edge lies in the p99
when designing hft systems, always think about the worst case, the last quantile, that's where shit ton of money can be printed (or lost)
every api/dependency you have can go down, be ready for this
one thing every hft developer should have:
a repeatable blueprint of scenarii that you can run on any exchange API to understand its behavior.
01/ list all possible operations
think about all the possible edge cases there can be, try sending each operation 3x then 10x, then invert the order of operations.
try everything so you can draw as much conclusions as possible on how their ordering/matching engine works.
02/ pipeline it
make this easily repeatable, so you can easily run it through any new exchange API you find.
every time you find an edge case on any exchange, add it to your blueprint and test it everywhere.
many details are hidden out there waiting for you to be found.
03/ run it after every update
exchanges update their logic pretty often, don't assume things will always be the way they are.
use this as an edge, the faster you catch an internal logic change, the longer you can take advantage of it.
well the number of gossip priority slots will be increased from 2 to 3, my take: it won't change much
but it's a step in the right direction!