Question: are these order latency numbers (maker/cancel/taker) typical, and is there any way to reduce cancel latency?
We're running a non-validator node on Vultr BM in Tokyo, measuring action heads via gossip (cloid matching to block arrival):
Action Submit → in network
Place limit (non-crossing maker) ~155 ms
Amend ~157 ms
Cancel ~470 ms
IOC taker (crossing) ~487 ms
Network + signing is negligible (~2–5ms total from Tokyo). All the latency is server-side holding.
The maker vs taker gap (155 vs 487ms) makes sense as anti-MEV. But cancel at ~470ms surprised us — almost identical to a taker. Assumed it's anti-spoofing design.
Questions:
Do others see similar numbers from Tokyo, or are we above the floor?
Is cancel ~470ms a hard floor, or does priority fee also reduce cancel latency (same as it cuts taker 487→~200ms)?
Any other levers for cancel speed specifically?
The same applies to the taker.
Question: are these order latency numbers (maker/cancel/taker) typical, and is there any way to reduce cancel latency?
We're running a non-validator node on Vultr BM in Tokyo, measuring action heads via gossip (cloid matching to block arrival):
Action Submit → in network
Place limit (non-crossing maker) ~155 ms
Amend ~157 ms
Cancel ~470 ms
IOC taker (crossing) ~487 ms
Network + signing is negligible (~2–5ms total from Tokyo). All the latency is server-side holding.
The maker vs taker gap (155 vs 487ms) makes sense as anti-MEV. But cancel at ~470ms surprised us — almost identical to a taker. Assumed it's anti-spoofing design.
Questions:
Do others see similar numbers from Tokyo, or are we above the floor?
Is cancel ~470ms a hard floor, or does priority fee also reduce cancel latency (same as it cuts taker 487→~200ms)?
Any other levers for cancel speed specifically?
The same applies to the taker.
Hi, I was looking for a solution to my problem with slow Hyperliquid order placements and saw your post: "Am I correct in assuming that the actual fill of my market order can be within 200-300 ms if I'm in AP-Northeast-1? and I'm just getting the confirm later?"
Currently, my latency numbers are:
"Action" Submit → in network
Place limit (non-crossing maker) ~155 ms
Amend ~157 ms
Cancel ~470 ms
IOC taker (crossing) ~487 ms
What do you think, is this normal? What's your current latency?
Hi, I was looking for a solution to my problem with slow Hyperliquid order placements and saw your post: "Am I correct in assuming that the actual fill of my market order can be within 200-300 ms if I'm in AP-Northeast-1? and I'm just getting the confirm later?"
Currently, my latency numbers are:
"Action" Submit → in network
Place limit (non-crossing maker) ~155 ms
Amend ~157 ms
Cancel ~470 ms
IOC taker (crossing) ~487 ms
What do you think, is this normal? What's your current latency?
looking for an answer since I have the same numbers as yours
looking for an answer since I have the same numbers as yours
I think order cancellation can be done 100% faster, but as for other delays, it's just too long. Does a limit order take 150ms? And is the delay in reading data from the mempool 100ms? I could execute at least 10 orders on another exchange in that time. During that time, the price could move back and forth on the external market 10 times...
I think order cancellation can be done 100% faster, but as for other delays, it's just too long. Does a limit order take 150ms? And is the delay in reading data from the mempool 100ms? I could execute at least 10 orders on another exchange in that time. During that time, the price could move back and forth on the external market 10 times...
yeah these numbers seem about right
yeah these numbers seem about right
It's strange because there are traders using takers that are faster than my takers, and much faster, and they don't pay priority fees.
It's strange because there are traders using takers that are faster than my takers, and much faster, and they don't pay priority fees.
actually cancels in my cases are around <200ms
actually cancels in my cases are around <200ms
Yes, I think it's possible to achieve around 150ms when canceling orders. But a 450ms taker is too much... even an 8bp priority fee only gives 200ms, meaning the difference between maker and taker is 50ms, which is an eternity.
Yes, I think it's possible to achieve around 150ms when canceling orders. But a 450ms taker is too much... even an 8bp priority fee only gives 200ms, meaning the difference between maker and taker is 50ms, which is an eternity.
I mean that your latency calculation might be a bit off... Is that round trip latency?
I mean that your latency calculation might be a bit off... Is that round trip latency?
This is the delay from the time I submit my order until it is actually executed on the exchange. The clocks are synchronized.
This is the delay from the time I submit my order until it is actually executed on the exchange. The clocks are synchronized.
In my case that number is nearly the same for GTC maker orders
In my case that number is nearly the same for GTC maker orders
for IOC it's 300ms slower
for IOC it's 300ms slower
Yeah, it's the same thing. Maker 150ms, taker 450ms. I'm new to Hyperliquid and crypto in general, and these numbers don't seem like HFT to me, not even MFT, hahaha.
Yeah, it's the same thing. Maker 150ms, taker 450ms. I'm new to Hyperliquid and crypto in general, and these numbers don't seem like HFT to me, not even MFT, hahaha.
HyperCore block times are 70ms anyway.
There is a speedbump on taker (spread crossing GTC/IOC) orders that is an intentional design of Hyperliquid.
HyperCore block times are 70ms anyway.
There is a speedbump on taker (spread crossing GTC/IOC) orders that is an intentional design of Hyperliquid.
Yes, but this information does not provide any answers at all, it only asserts
Yes, but this information does not provide any answers at all, it only asserts
There is a much written about latency optimisation in this channel and others, just search “latency”. Besides that latency optimisation is outside the scope of the API.
There is a much written about latency optimisation in this channel and others, just search “latency”. Besides that latency optimisation is outside the scope of the API.