nerd https://xitter.cf/t.co/0Qa3nBSEzo ex: @makerdao

?
Joined May 2020
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.
1
1
2
35
6,759
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+. 很明显是一些大的做市商有专线, 连接纽约和东京. 比公网链路快很多. 这个咱们散户没办法..
3
38
3,457
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
2
26
1,427
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.
1
1
2
35
6,759
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
20
54
11,732
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.
4
2
4
114
17,464
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!
had a bunch of calls recently explaining why gossip fees were simply not usable for us right now, good write-up on why here, it's not *that* simple and there are other dynamics in place but things need to change!
12
1,086
had a bunch of calls recently explaining why gossip fees were simply not usable for us right now, good write-up on why here, it's not *that* simple and there are other dynamics in place but things need to change!
gossip (read) priority fees on hyperliquid are broken currently the team that is benefitting the most is wintermute (insert fist shaking red emoji guy meme) this is not publicly known but can be determined with certainty by mapping out transfers to labeled wallets from the top winner of the gossip priority fee auctions (they have won 79% of the slot 0 auctions in the past 24h) tldr; wahhh wahhhh wahhh hl gossip priority, not fair. add more slots or scrap the gossip auction my proposed solution: 1) increase gossip priority to 20 equal-priority slots 2) make it so winning an auction slot grants IP whitelisting to a foundation-run peering slot i think this basically solves it and would likely *increase* total gossip priority fees --- some context the purported intention, as stated in the docs, is to "reduce the need for market makers to hyper-optimize their infrastructure to remain competitive" if you win the gossip auction slot, you get order book / node data 50ms (!!) faster than anyone else. yes. one IP, across the *entire network*, gets the feeds 50ms faster. it's the whole ballgame so in theory you could just buy the faster data slot instead of spending 10s of thousands monthly on high octane ec2 instances and [insert hft magic] or you can do BOTH, which is what wintermute is doing so despite the stated intentions it does the exact opposite and gives 1 wallet a dominant advantage over every other participant further reducing the democratization of this mechanism is the fact that, practically speaking, you can only use a won gossip slot if you have a direct peering relationship with the foundation node. multiple providers we work with couldn’t pass gossip priority benefits through to us without slowing their other peers (all independently confirmed this behavior - strange design) and to get a foundation peering you to do 0.5% of the 14d HL maker volume (we don't quite meet this threshold so our application was rejected) as well as stake 10,000 HYPE ($780,000 here), or be like, a node service provider --- without revealing too much i can say with 100% certainty that wintermute has maxed out BOTH the infrastructure optimization + expenditure AND is monopolizing the gossip fee auction they're spending on average $26,000 *per day* ($10M/yr) to win this auction so rn they're just eating everyone else's lunch and the only way that approach is economic is if you are MM at the scale that they are, which only a handful of wallets are doing
1
1
13
3,270
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.
a few more good HFT tricks for you to try out again. not rocket science. just there to nudge you in the right direction. 01/ multiple feeds subscribe to multiple feeds, from different places, with different IPs, multiple times. and deduplicate the output. you never know why one feed or the other can be faster in different conditions. benchmarking when the market is calm has nothing to do with high vol times. even the worst median can be the best p99. yes ultimately you want a private fiber w/ @Avelacom_Corp but until then just compound the feeds you have and make the best usage of em. can already get you pretty far. 02/ always a/b test keep a low risk engine running on the side that serves as a reference for your optimizations. first, well you can still catch some liquidations but more importantly bugs early on and actually see your improvements. more volume, more activity = more messages going through your system, you need to be able to spot where is the bottleneck at all times. 03/ stale data is worse than no data you have to know your data feeds, their edge cases, especially when pricing fair value using multiple sources and layers. each layer should have its own thresholds and protections, an oracle feed you're using for a basis or a weekend mid price should not be treated equally.
1
3
2
99
10,412
happy birthday hip-3 🎉 who won, where the flow went, what comes next 01/ winner takes all? hip-3 holds $4.0B of open interest today, 26% of all hyperliquid perps. the record in january was $790M. xyz holds 97% of it. at $3.9B, its open interest is bigger than bitcoin's on hyperliquid ($3.4B). s&p 500, gold and brent are among its biggest markets. outside xyz 6 dex have disappeared. 97 markets gone. the 3 others hold $115M together. liquidity attracts liquidity. 02/ lighter today 213 perps: crypto, us100, gold, eurusd, equities. plus spot. $2.0B traded in the last 24h on $0.54B of open interest. it turns its open interest over 3.6x a day, hyperliquid 0.46x. within 2 bps of mid, its eth book is 84% as deep as hyperliquid's, btc 61%. 03/ what then moar instruments. variational launched swaps on sept 1: $2.8B traded in the first week, liquidity sourced for 100+ markets. derive did $3.8B of options notional in the last 30 days, 6x a year ago. options, swaps, spot and perps under one good margin system: that's when basis, vol and carry trades can run fully on-chain. dms open if you trade size on hl/lighter.
3
10
800
matthias 0️⃣ retweeted
Partner Mainnet in 7 days. October 26, 2026.
148
76
93
498
113,027
thanks for everyone who reached out already, we still have a few seats left for the first wave of the beta. if you care about the best fee tier and best execution, DMs open.
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.
14
2,241
wanted to share a bug we discovered on lighter and got them to fix it, shows a lot about what it means to be an HFT developer 01/ the setup lighter nonces are per api key and strictly sequential: n+1 can't execute before n. in our benches, gtc and ioc creates took 90-200ms from ack to execution. cancels and post-only took a few ms. so a cancel signed behind a gtc on the same key has to wait for it. 02/ the bug we place two orders and cancel both right after, on the same key. lighter says ok to all four, then rejects the second cancel as "invalid nonce" before the orders even reach the book, so one of them is "stale". 03/ why it hurts a market maker order y is still on the book, and your system thinks it's cancelled. the rejected nonce isn't consumed, so every tx already signed above it fails too. and the ack said 200. the reject only shows up on the authenticated account stream. 04/ the workaround we can't use wait for each tx to execute before sending the next: 3/3 clean. it also turns a 1ms create->cancel gap into 0.7-1.6s. when you requote on every tick, that's not a workaround. 05/ what we run quotes are post-only on their own key. they execute within 0.2ms of the ack, so nothing waits behind them. a 200 means "received" but the actual status comes from the account stream. it took us 3 versions: v1 counted the rejected nonce as used. v2 froze the key for 10s. v3 resumes at the refused nonce as soon as everything below it has executed 06/ s/o @Lighter_xyz we sent them the script pinned to the sdk version, its sha256, raw traces, a control run and every tx hash. reacted pretty fast and in a week it was fixed. that's the kind of support you want from a venue you quote on.
10
4
99
7,390
new claude code update is pretty bad, keeps asking for "GO" and gives time estimations for everything as if it made any sense
8
11
1,370
how not to get rekt by ADL on hyperliquid 01/ 2 things - effective leverage: notional / account value - profit factor: mark vs entry adding collateral proportionaly reduces the score, realizing the gains resets it 02/ its bad as ADL closes your position at mark price, 87% of the time that will be worse than the mid. there is time to react, 18min p50 between the start of the stress period (if we account for a 5% move in 15min) and the actual ADL. 70% of ADL'd notional comes from the top 10% of the queue. 03/ how to compute it? ADL is computed independently for each dex (hip-3 included). depends on what the backstopping vault can absorb. funny enough that's still one of the major risk vector of these hip3 markets imho, xyz only has 104k USDC in their backstop vault and most markets are still in isolated margin. 04/ it's hard doing this for yourself is hard, you don't have that much control over your margin requirements and rebalancing between venues can be hard and capital intensive. I have a solution for this. DMs open.
a few more good HFT tricks for you to try out again. not rocket science. just there to nudge you in the right direction. 01/ multiple feeds subscribe to multiple feeds, from different places, with different IPs, multiple times. and deduplicate the output. you never know why one feed or the other can be faster in different conditions. benchmarking when the market is calm has nothing to do with high vol times. even the worst median can be the best p99. yes ultimately you want a private fiber w/ @Avelacom_Corp but until then just compound the feeds you have and make the best usage of em. can already get you pretty far. 02/ always a/b test keep a low risk engine running on the side that serves as a reference for your optimizations. first, well you can still catch some liquidations but more importantly bugs early on and actually see your improvements. more volume, more activity = more messages going through your system, you need to be able to spot where is the bottleneck at all times. 03/ stale data is worse than no data you have to know your data feeds, their edge cases, especially when pricing fair value using multiple sources and layers. each layer should have its own thresholds and protections, an oracle feed you're using for a basis or a weekend mid price should not be treated equally.
4
4
39
2,432
matthias 0️⃣ retweeted
It's a question we can answer with data, sooo: First, for those who don't know the square-root law: when someone splits a big order into a run of trades (can be anyone, but usually funds, indexes etc), the price moves with the square root of the run's size. Size is measured as a percentage of the day's volume, the move as a percentage of the day's price change, so let's say a stock trades $100M a day within a 3% range. Buy $1M (so that's 1% of the volume) and the price moves 0.25% (on average obv). Buy $4M and it moves 0.5%, not 1%. Just to develop your intuition, your first buys are news, and thus the market prices the subsequent ones (remember @chameleon_jeff's tweet about how broadcasting your big trades will give you a better price, well that's the same thing we're describing here, the market expects the other buys, and thus reacts less and less to them, it's priced in). The claim made here is that HL breaks it at 0.19, with small trades moving the price WAY more than they should. So why is that? Is there an explanation? Well it's pretty simple: these xyz perps don't make their own price during US hours. NVDA's price is made on Nasdaq and HL follows. The square-root law describes how a market absorbs orders where the price is formed. A market that follows another one has little reason to obey it. And by the way, there is a kind of "sequence" that naturally weakens this number: latency arbitrage between NYC and Tokyo, by definition the arb buys when he has positive markouts, so if he buys, price will go higher in the next seconds, and vice versa, not because he made the market go up, but because he catched a move faster. But coming back to previously, that gives two clean tests where HL does make the price: • weekends, when Nasdaq is closed and the xyz oracle prices off the HL book (we showed in February that HL even leads weekend price discovery on crude) • HYPE, where HL is the main venue We pulled every HL fill with its address and built the runs the same way as the paper: same address, same side, at least 60s, price change from first to last fill, scaled by that day's volume and range. So first, the same five names, done the paper's way: exponent 0.44 [0.31, 0.54]. Not 0.19. And no floor: the smallest runs have zero or negative impact, with or without the 60s cut, on fills or on book mids. (First graph) Now the interesting part. Weekends vs US market hours on 22 xyz stocks: above a few thousand dollars the curves overlap. 0.43 vs 0.33, but reasonable fit choices move both anywhere between 0.3 and 0.5, so that gap doesn't mean much. The real difference is in small runs. During market hours they buy after a drop (or sell after a rise) and the move keeps going while they trade. On weekends small runs move nothing, which is what Tokyo would predict. So our guess was half right: the satellite effect shows up, but in who trades small, not in the slope. (Second graph) And HYPE: the perp ($514M a day) comes out at 0.42 [0.35, 0.48] with a prefactor of 0.83, vs 0.84 in Tokyo. Where HL is the main market, it looks like Tokyo. Spot trades ~7x less and its curve flattens above ~$60k, which is what you'd expect if spot is just arbitraged against the perp. (Third graph) tldr: measured the Tokyo way, HL isn't flat at all. The xyz names and the HYPE perp land between 0.3 and 0.5, and the HYPE perp sits right on Tokyo's level. The flat curve looks like a method question, not a market one.
We are looking at a very deep level into hyperliquid perps and their transaction costs. The dashed line is the sqrt impact. This has been proven a number of times to hold in tradfi equities. Early indications are that it doesn't hold on @HyperliquidX perps. Seems that there is microstruture inefficiency. We don't know precisely why yet. Any thoughts welcome. The plots follow
1
1
14
1,093
time to talk about pricing in HFT 01/ micro price or mid price? well none, you need a proper filter. mid price and micro price can easily be manipulated, especially during weekends or illiquid markets. what you want, is to filter out the noise from the signal. 1. don't overreact to price movements, wait for confirmations. 2. anchor on the deepest side of the book. 3. the tighter, the closer to the actual mid 02/ kalman filter there is a very good description of it in the book "Algorithmic Trading: Winning Strategies and Their Rationale" not for lead-lag arb or tight quoting. good if you have one fast but noisy source and one slower more reliable source. be careful to align on origin timestamps. rewind, correct, replay. 03/ future contracts rolling xitter.cf/AriPingle/status/20422… outdated alfa, but if you look around closely it's still a good example on how you can print with better pricing models. look at the oracles used by each market, there are lots of innefficiencies or MMs mispricing out there.
Yesterday, Hyperliquid oil perp was paying -300% annualized funding. Onchain infrastructure is telling us something about how commodity markets will work going forward @tradexyz perps use CME front month as the oracle. Front month ~$95, back month ~$87. Oracle rolls over 5 business days, stepping down ~$1.70 per shift The "obvious" trade is to short the perp, hedge on CME, collect the roll. We open-sourced a model to price it w/ a link at end of the 🧵
4
10
119
12,481
Aged well lol
in between technical posts $EKUBO is criminally undervalued
1
8
975