
nerd https://xitter.cf/t.co/0Qa3nBSEzo ex: @makerdao
?
Joined May 2020
- Tweets3.7K
- Following2.7K
- Followers2.2K
- Likes6K
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.
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.
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.
new claude code update is pretty bad, keeps asking for "GO" and gives time estimations for everything as if it made any sense
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.
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
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 🧵
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.
I don't understand wether @papertrade_xyz is meant as an experiment of what can be done on-chain or as something that will live in this form on the long-run (which seems unlikely to me)
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.
i see people want more HFT tricks so here we go
probably most of you doing any serious hft know these simple ones but I think it's always good to see what hft optimizations actually looks like
01/ every action is sent over 3 ws channels at once
why?
just benchmark it, you will see by yourself
its not a global rule, every exchange has its own internal system and logic. TCP networks are inherently random, by multiplying the load you get rid of the tail
not enough IPs ? you can always have more IPs, it's absolutely never a bottleneck
02/ think about shards
exchanges have to shard their backend, not everyone will use the same sharding keys tho, again you have to benchmark it (be careful not to introduce biases there)
some subaccounts could have lower latency, some markets, some api keys or a mix of everything
you have to be creative and understand how the underlying system you're interacting with is shaped, there is no magic rule, there will be nothing online
03/ watch what other traders are doing, hyperliquid is public so use this, analyse patterns, find alpha, its out there, waiting for you
04/ oh great so agents can do it
well, I wish but from personal experience they do lack that creativity, you can easily benchmark previous exchanges' tricks on new ones you're integrating and use them to reverse-engineer/understand better the underlying api/elb/matching engine
01/ When working with AI agents you should make them as you questions at the END of their work not the beginning, has drastically improved my output quality
02/ Also be careful when wanting to simplify the PR that’s usually where you introduce errors
the actor model in rust and why it's not that easy
01/ what is it
one actor parses the data from CME, one actor computes the fair value, one actor builds the layers, one actor sends to the venue.
each actor has its own local state and actors communicate together using channels and messages.
it is by far one of my favorite way to design software as it's very pleasant to reason about.
02/ locks are fine
there is a middleground between what should be an actor and what shouldn't.
we benchmarked a bunch of our internal implementations using actor model vs mutex and it's never been a clear cut.
if you know what you're doing and inside a carefully designed system, locks are very easy and powerful too.
a system with 100s of actors is not that easy to understand either.
03/ lifecycle
there are some good actor frameworks for rust out there github.com/tqwewe/kameo but imho you should not use them in hft, we hate backpressure, we only care about the latest data (except some parts of the pricing)
ask yourself: what's the lifecycle of my actor? what happens if he dies, if he's slow ? we built a small crate to wrap up our tokio tasks lifecycle you might find useful: crates.io/crates/task-superv…
im just scratching the surface of a very interesting subject in HFT development. as always you should start small and as simple as possible, use agents to break your trading system as much as possible.
Wanted to write a bit about the impact of AI on HFT development
01/ it’s not great
Well starting with the obvious, there are not many resources out there when it comes to proper HFT. No one is going to open source their oms, risk engine, pricing modules
Many times you will have to refactor completely some modules to scale properly. Your main goal as an HFT developer is to lower the probability of mistakes, mistakes cost money and they shouldn’t happen.
You are sitting in between the quant that will tweak the configuration files you put at his disposal. It’s your’role to make sure things are doing what they seem to be doing.
Circuit breakers should be everywhere, everything should be auditable.
Focus on the hotpath and load test it: from the moment your program receives data from your provider to the moment your sending quotes to exchanges. Every single line and function should be simple and easily understandable.
This is where AI development will fail you if you don’t do it properly. Minimize the lines of code not the opposite. But write as much slop to try to break it!
Do not over abstract, exchanges are completely different from each others. We all tried to create the right abstractions to make it fit but well no just don’t.
02/ won’t get much better
This is inherently how the LLMs are working and they have been unlucky that there is not much good code out there.
Sure a good actor model design (more on this in another post) can help, sure some good skills can help too, but you’re the one loosing money at the end, you’re the one that forgot that circuit breaker or realized AI added some magic number there.
03/ seat in the drivers place
Having said all that, I still think one cannot dev without it today so how ?
It will be very frustrating, you will have to code with the agents as if the code you write could actually kill people.
Use the agent as a rubber duck, above all keep things simple and well organized.
You could get probably get better results than before AI because well you can do mu ch more stuff. But it’s not going to be an easy road there.
I do not see a future where GPT 10 changes all these principles unfortunately but happy to be proven wrong!











