2026-06-17 · Hyperliquid · 8 条相关讨论
Hi everyone! I'm building a latency-sensitive app on HyperEVM and I've run into an issue: eth_sendRawTransaction usually takes 300–500ms, sometimes even 700–800ms. Why is that, and how can I reduce the latency?
Hi everyone! I'm building a latency-sensitive app on HyperEVM and I've run into an issue: eth_sendRawTransaction usually takes 300–500ms, sometimes even 700–800ms. Why is that, and how can I reduce the latency?
latency sensitive 🤨 is that suitable for even any EVM chain
latency sensitive 🤨 is that suitable for even any EVM chain
Well, I mean I just need my tx to be included in the next block, but when eth_sendRawTransaction takes 800ms in some cases, it's hard to achieve..
Well, I mean I just need my tx to be included in the next block, but when eth_sendRawTransaction takes 800ms in some cases, it's hard to achieve..
That 300-800ms is the submission RTT (the node accepting your tx into the mempool), not block finalization. Those are two separate clocks The spikes are almost certainly cold connections If you're opening a fresh TCP/TLS handshake per call, that alone can be 200-400ms. To fix use persistent connections (keep-alive/HTTP2) or a websocket, and pre-sign your txs ahead of time so you're not doing that work in the hot path Geography also matters more than people realize, all 24 HL validators are in AWS Tokyo (ap-northeast-1) If you're in EU/US, you're already 200ms+ behind someone colocated there, and a shared public endpoint adds more on top. A dedicated endpoint closer to Tokyo helps P.S. Also double-check you're on small blocks (default, ~1–2s) and set a real priority fee cause both affect inclusion speed independently of the broadcast latency
That 300-800ms is the submission RTT (the node accepting your tx into the mempool), not block finalization. Those are two separate clocks The spikes are almost certainly cold connections If you're opening a fresh TCP/TLS handshake per call, that alone can be 200-400ms. To fix use persistent connections (keep-alive/HTTP2) or a websocket, and pre-sign your txs ahead of time so you're not doing that work in the hot path Geography also matters more than people realize, all 24 HL validators are in AWS Tokyo (ap-northeast-1) If you're in EU/US, you're already 200ms+ behind someone colocated there, and a shared public endpoint adds more on top. A dedicated endpoint closer to Tokyo helps P.S. Also double-check you're on small blocks (default, ~1–2s) and set a real priority fee cause both affect inclusion speed independently of the broadcast latency
it would make more i would guess, evm has too much lag (but at cost of mroe complexity to set up/run)
it would make more i would guess, evm has too much lag (but at cost of mroe complexity to set up/run)
Will you ever fix hevm, the chain is so slow + expensive while there is like 3tx per second 💀 + the 3m gas limit is so annoying
Will you ever fix hevm, the chain is so slow + expensive while there is like 3tx per second 💀 + the 3m gas limit is so annoying
Is hyperevm still in alpha?
Is hyperevm still in alpha?
i like that we have small blocks/big blocks options maybe speed is something we can improve on
i like that we have small blocks/big blocks options maybe speed is something we can improve on