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 80+ Hyperliquid-specific guides (recent examples: Hyperliquid HIP-3: user_fills dex Parameter Fix, Hyperliquid Python SDK Tutorial: Build a Bot, Hyperliquid API Rate Limits & User Limits)). The most-repeated reader question across that Hyperliquid archive is exactly how to diagnose and work around SDK bugs that surface when HIP-3 dexes enter the picture, which is why I'm publishing this standardized guide instead of answering one-off.
If your Hyperliquid bot suddenly started failing on user_state, open_orders, or all_mids after you pointed it at a HIP-3 dex, you are not imagining it. GitHub issue #286 in the official hyperliquid-python-sdk repository documents exactly this: the dex parameter is missing on those three read endpoints when HIP-3 dexes are involved. This guide breaks down what the bug is, why it exists, which endpoints are affected, and what your options are until the SDK ships the fix.
The Symptom: What Users Actually See
The issue is narrow but annoying. When a bot calls one of the three affected endpoints while operating against a HIP-3 dex, the request does not carry the dex parameter it needs. Depending on how the backend handles the omission, you get one of two outcomes:
- An error response, because the endpoint cannot determine which dex's state you want.
- Silent fallback to the default dex, which is worse in a way: your bot reads state for the wrong market and keeps trading on stale or irrelevant data without raising an exception.
user_state— your account's margin, positions, and balance summaryopen_orders— your currently resting ordersall_mids— mid prices across markets
open_orders for order management or on user_state for margin checks, a silent fallback can produce positions you never intended.
Why It Happens: HIP-3 and the dex Parameter
To understand the bug you need the one-line version of HIP-3: Hyperliquid's architecture now supports multiple DEXes, each with its own order book and market set, and the API distinguishes them with a dex parameter. Before HIP-3, there was effectively a single main dex, so most API calls didn't need to specify which one they meant. The parameter existed but was optional in practice.
HIP-3 changed that. Once a second (or third) dex is live with its own markets, every endpoint that returns dex-specific data must be told which dex to query. The Python SDK got the parameter wired into some of its calls but not all of them. Issue #286 identifies the gap: user_state, open_orders, and all_mids were never updated to forward the dex argument, so any bot targeting a HIP-3 dex through those calls hits the omission.
This is a classic "the world changed, the wrapper didn't" bug. The exchange backend moved to a multi-dex model, and the SDK's convenience layer lagged behind on a handful of endpoints. It is not a security issue and not a funds-safety issue: your keys, your orders, and your balances are unaffected. It is a data-correctness issue confined to read calls.
Affected Endpoints vs. Ones That Work
Here is the current state of play, as of 2026-09:
| Endpoint | Purpose | dex parameter forwarded? | Status |
|---|---|---|---|
user_state | Account margin, positions, balances | No | Broken for HIP-3 dexes |
open_orders | Resting orders | No | Broken for HIP-3 dexes |
all_mids | Mid prices across markets | No | Broken for HIP-3 dexes |
user_fills | Fill history | No (separate fix) | Covered in its own guide |
user_fills had the same class of bug, and it was documented and addressed in a sibling fix that I covered in Hyperliquid HIP-3: user_fills dex Parameter Fix. If your bot also reads fill history for HIP-3 dexes, check that article too — the pattern is identical, and the fix path is the same.
The practical takeaway: if your bot only trades the main dex, none of this touches you. The bug activates exclusively when you pass a HIP-3 dex identifier. Most bots in the wild still don't, which is why the issue stayed narrow rather than becoming a headline.
How to Confirm You're Hitting the Bug
Before you change anything, confirm the diagnosis. Three checks, none of them requiring a live trade:
1. Check which dex your bot targets. If your config or strategy code never references a HIP-3 dex identifier, you cannot be hitting this bug. The omission only matters when a non-default dex is in play. 2. Check your SDK version. Look at the installedhyperliquid-python-sdk version and compare it against the repository's release history. Issue #286 is the authoritative reference for which version introduced the gap and whether a fix is queued.
3. Inspect the actual request. If your bot logs outgoing API payloads (or you add a temporary log line), you can see directly whether the dex field is present on user_state / open_orders / all_mids calls. Absent field plus a HIP-3 dex target plus wrong or errored responses = confirmed.
I'd do all three before touching code. Half the "SDK is broken" reports I see turn out to be a misconfigured dex target or a stale SDK install, and the fix for those is a config edit, not a code change.
The Fix Path and Your Options
The resolution path, per the issue thread, is a SDK update: the maintainers need to thread the dex parameter through the three affected calls the same way it was done for the rest of the API. Until that ships, you have a few options, roughly in order of how I'd rank them:
Like what you're reading? Try it yourself — this link supports ChartedTrader at no cost to you.
Start on Hyperliquid →dex parameter set explicitly. This is more fragile — you're now responsible for matching the wire format yourself — so treat it as a bridge, not an architecture.
One honest caveat on Option C: I have not run this workaround in a live account, and neither has anyone I can point you to with a verified reproduction. The issue thread is the source of truth for the exact request shape; do not trust third-party blog posts that guess at it. If you go this route, test against a tiny position first.
Related SDK Pitfalls Worth Knowing About
Since you're now inside Hyperliquid SDK troubleshooting territory, three adjacent issues come up constantly in the same conversations:
- Rate limits. Read endpoints like
user_stateandopen_ordersare exactly the ones bots poll aggressively, and Hyperliquid enforces per-user rate limits that will 429 you if you're not careful. See Hyperliquid API Rate Limits & User Limits for the numbers and backoff patterns. - Missing fills and reconciliation. If your bot's local state drifts from the exchange's truth, the usual suspects are dropped fill events and reconciliation gaps. Hyperliquid Missing Fills: Reconciliation Guide covers the audit loop.
- General SDK usage. If you're building from scratch rather than debugging, Hyperliquid Python SDK Tutorial: Build a Bot walks through the full setup so the HIP-3 parameter question never surprises you mid-incident.
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. A bot reading the wrong dex's state can place orders you never intended to place — the bug in this article is a data-correctness issue, but acting on bad data with real capital is how small bugs become real losses.
FAQ
Does this bug affect my funds or my private keys?
No. Issue #286 is about read-only status calls missing a parameter. Your keys, balances, and order placement are unaffected. The risk is acting on incorrect state data.
Which endpoints are broken?
user_state, open_orders, and all_mids when targeting a HIP-3 dex. user_fills had the same class of bug and is covered separately in the user_fills fix guide.
I only trade the main dex. Do I need to do anything?
No. The omission only matters when a non-default dex identifier is in play. If your bot never references a HIP-3 dex, the bug cannot activate.
Is there a workaround if I need HIP-3 dex state right now?
Yes, but it's fragile: bypass the SDK wrappers for those three calls and send the underlying requests with dex set explicitly. Use it as a short-term bridge and verify the request shape against the issue thread before trusting it.
When will the fix ship?
That's up to the SDK maintainers. Track issue #286 for the fix commit and upgrade your SDK when it lands. Until then, the main-dex path and the pin-and-wait path are the safe options.
---
If you're building on Hyperliquid and want to start with a referral that earns you a 4% fee discount on your first $25M of volume (note: Vaults and sub-accounts are excluded from the discount), you can Start on Hyperliquid. This is an affiliate link — we may earn a commission at no extra cost to you. For more on how Hyperliquid's fee structure actually works under the hood, see Hyperliquid Maker vs Taker Fees: How Limit Orders Save You Money.
Continue with Hyperliquid
Browse the Hyperliquid guide hub for the complete user journey.
Official reference: Hyperliquid documentation.