For developers accustomed to the lightning-fast, non-blocking I/O of modern async frameworks like asyncio or aiohttp, this limitation feels like a step backward. You want your bot to listen to order book updates in real-time, process them instantly, and send trades without the overhead of synchronous HTTP polling. But the official Hyperliquid Python SDK forces you into a synchronous, request-response paradigm.
Why does Hyperliquid make this architectural choice? Is it a technical limitation, a security feature, or a deliberate design philosophy? I'll break down the reasons behind this limitation, explore the implications for algorithmic traders, and show you how to work around it to build scalable, low-latency trading systems on Hyperliquid.
About this guide: I'm Lawrence, the writer behind supa.is. Between February and May 2026 I've published 150+ articles on supa.is across crypto and brokerage tooling — including 30+ Hyperliquid-specific guides (recent examples: Hyperliquid Python SDK Tutorial, Hyperliquid API Key Setup, Hyperliquid WebSocket Reconnect Fix). The most-repeated reader question across that Hyperliquid archive is exactly why the SDK lacks async and WebSocket support, which is why I'm publishing this standardized guide instead of answering one-off.
The Synchronous Paradigm of the Hyperliquid SDK
To understand *why* the SDK doesn't support async requests, we first need to understand *how* it works. The Hyperliquid Python SDK is built on a synchronous foundation. When you call a method like exchange.get_price() or exchange.place_order(), your Python script pauses execution, waits for the HTTP request to travel to the Hyperliquid servers, waits for the server to process the request, and then waits for the response to travel back. Only then does your script continue.
This is the classic synchronous (or "blocking") model. It's simple, predictable, and easy to debug. However, it's also incredibly inefficient for trading applications where milliseconds matter and where you need to handle multiple streams of data simultaneously.
The absence of native WebSocket support means you cannot open a persistent, bidirectional connection to receive real-time market data, order book updates, or trade notifications. Instead, you are forced to poll the API at regular intervals (e.g., every 100ms or 500ms) to check for new data. This introduces latency, wastes bandwidth, and increases the risk of hitting rate limits.
Why No Async Requests? The Architectural Reasons
The lack of async support isn't an oversight; it's a deliberate architectural decision. Here's why:
1. Simplicity and Accessibility
Hyperliquid aims to be accessible to both retail traders and professional developers. Synchronous code is vastly easier to write and understand than asynchronous code. For a beginner building their first trading bot,async/await patterns can be a steep learning curve, leading to common pitfalls like race conditions, deadlocks, and unhandled exceptions. By providing a synchronous SDK, Hyperliquid lowers the barrier to entry, allowing developers to get their bots up and running quickly without needing to master the complexities of async programming.
2. Security and Determinism
In the world of algorithmic trading, a bug in your code can cost you thousands of dollars in seconds. Synchronous code is deterministic: the order of operations is strictly linear. This makes it much easier to reason about the state of your bot at any given moment. Asynchronous code, by contrast, is non-deterministic; multiple tasks can be executing concurrently, leading to unpredictable states. By enforcing a synchronous model, Hyperliquid reduces the risk of catastrophic bugs caused by concurrent access to shared resources.3. Rate Limiting and API Load
Hyperliquid's API has strict rate limits to ensure fair access for all users and to protect the infrastructure from being overwhelmed. If every developer wrote highly concurrent async bots that fired off hundreds of requests per second, the network would quickly become congested. The synchronous model naturally throttles request volume, as each request must complete before the next one can be initiated. This helps maintain the stability and reliability of the Hyperliquid network.4. The Nature of the Hyperliquid Chain
Hyperliquid is a high-performance Layer 1 blockchain optimized for trading. Unlike traditional exchanges that rely on centralized order books and WebSockets for real-time data, Hyperliquid processes trades on-chain. The state of the blockchain is updated in blocks, and the API reflects this on-chain state. While this provides unparalleled security and transparency, it also means that true "real-time" data is inherently limited by block times. The SDK's synchronous design aligns with this block-by-block reality, ensuring that your bot always interacts with the most recently confirmed state of the chain.The WebSocket Gap: Why Real-Time Data Matters
The absence of WebSocket support is arguably the most painful limitation for algorithmic traders. WebSockets allow for persistent, bidirectional connections, enabling the server to push data to the client the moment it becomes available. Without WebSockets, you are forced to rely on HTTP polling, which introduces three major drawbacks:
Like what you're reading? Try it yourself — this link supports ChartedTrader at no cost to you.
Join Hyperliquid & Get 4% Fee Discount →* Latency: Polling introduces a delay between when an event occurs and when your bot receives the data. If you poll every 500ms, the worst-case latency is 500ms. In fast-moving markets, this can mean missing out on profitable trades or entering positions at worse prices.
* Bandwidth Waste: Polling requires sending a request even if no new data is available. This wastes network bandwidth and increases the load on the API servers. * Rate Limit Exhaustion: Frequent polling can quickly exhaust your API rate limits, leading to temporary bans or degraded performance.As highlighted in the Hyperliquid WebSocket Reconnect Fix guide, developers have had to get creative to handle real-time data, often relying on third-party services or custom-built polling mechanisms to simulate WebSocket functionality.
How to Build Scalable Bots Without Async or WebSockets
Just because the official SDK doesn't support async or WebSockets doesn't mean you can't build a high-performance trading bot. Here are several strategies to work around these limitations:
1. Use a Multi-Process or Multi-Threaded Architecture
While the SDK itself is synchronous, you can use Python'smultiprocessing or threading modules to run multiple instances of the SDK concurrently. For example, you can dedicate one process to polling market data, another to processing signals, and a third to placing orders. This allows you to achieve concurrency without needing native async support in the SDK.
2. Leverage Third-Party Data Feeds
Instead of polling the Hyperliquid API directly for market data, you can use third-party data providers that offer WebSocket connections to Hyperliquid's order books and trades. Services like Kaiko, CoinGecko, or specialized crypto data aggregators often provide real-time data feeds that can be consumed asynchronously in your bot. This offloads the polling burden from your bot and gives you access to lower-latency data.3. Build a Custom WebSocket Client
If you're comfortable with lower-level programming, you can bypass the official SDK entirely for data ingestion and build a custom WebSocket client that connects directly to Hyperliquid's public WebSocket endpoints (if available) or to a third-party WebSocket proxy. You can then use this real-time data to trigger actions via the synchronous SDK. This hybrid approach gives you the best of both worlds: real-time data via WebSockets and reliable trade execution via the official SDK.4. Optimize Your Polling Strategy
If you must rely on polling, optimize your strategy to minimize latency and rate limit usage. Use exponential backoff for error handling, implement smart polling intervals that adjust based on market volatility, and cache data locally to avoid redundant requests. The Hyperliquid Python SDK Tutorial provides a solid foundation for building robust polling mechanisms.The Future of Async and WebSockets on Hyperliquid
The demand for async and WebSocket support on Hyperliquid is undeniable. As the platform grows and attracts more sophisticated algorithmic traders, the limitations of the current SDK will become increasingly apparent. The community has been vocal about this, as evidenced by discussions on the Hyperliquid Python SDK GitHub repository.
While Hyperliquid has not officially announced plans to add native async and WebSocket support to the SDK, the trajectory of the ecosystem suggests it's only a matter of time. The rise of high-frequency trading on decentralized exchanges and the increasing complexity of trading strategies require more sophisticated tools. We can expect to see either an official async-compatible SDK or a robust set of third-party libraries that bridge this gap in the near future. Until then, the workarounds above are your best bet.
Conclusion
The lack of async requests and WebSocket support in the Hyperliquid Python SDK is a deliberate design choice that prioritizes simplicity, security, and accessibility over raw performance. While this limitation can be frustrating for advanced algorithmic traders, it's not insurmountable. By leveraging multi-process architectures, third-party data feeds, and custom WebSocket clients, you can build scalable, low-latency trading bots that take full advantage of Hyperliquid's high-performance infrastructure.
As you develop your trading strategies, remember to set up your API keys securely, as outlined in our Hyperliquid API Key Setup guide. And if you're new to Hyperliquid, consider using our affiliate link to get a 4% fee discount on your trades.
Risk Warning
Risk Warning: Crypto trading involves substantial risk of loss. Never invest more than you can afford to lose. This is not financial advice.