Hyperliquid Python SDK: Builder Perp Slippage Price Misclassified as Spot (2026)

This article summarizes the reported root cause, the affected asset-ID ranges, the arithmetic example in the issue, and the community-suggested fix. As of 2026-11-13, the issue is open; the fix below is a community suggestion, not a confirmed SDK patch.

Symptom

The issue affects builder-deployed perp markets, not ordinary spot markets. The reporter says the failure is fail-closed: the order is rejected and no funds move. The worst case is broken market_open or market_close on some builder-perp markets.

Hyperliquid's order types documentation describes a market order as an order that executes immediately at the current market price. The SDK slippage logic is meant to calculate a usable price for such orders, but the reported bug can make the calculated price invalid for the perp market's decimal rules.

Root cause

The issue points to hyperliquid/exchange.py:119-139, specifically the classification:

is_spot = asset >= 10_000

According to the issue, spot asset IDs start at 10000, while builder-deployed HIP-3 perp asset IDs start at 110000. Because every builder perp ID is also >= 10000, the SDK treats it as spot.

The issue cites Hyperliquid documentation for the decimal allowance: MAX_DECIMALS is 6 for perps and 8 for spot. Therefore the SDK can apply the spot decimal allowance 8 - szDecimals instead of the perp allowance 6 - szDecimals.

The reporter notes that five-significant-figure rounding often keeps the number of decimals low, which is why the issue may appear only on some low-priced builder perps. The issue was reported against SDK version 0.24.0, commit 2fdb18f9517675ea03695a0962bd19eece9c83f0.

Affected asset-ID ranges

Example from the issue

The issue gives a testnet example:

• Market: felix:TEST1
• Asset ID: 140002
• szDecimals: 4
• Mid price: 38.5
• Slippage: 5%

6 - 4 = 2

For a spot market, the maximum price decimals would be:

8 - 4 = 4

The SDK's buy price at 5% slippage is:

38.5 * 1.05 = 40.425

40.425 has three decimal places, which exceeds the reported perp cap of two. A two-decimal price such as 40.42 would fit the decimal cap.

The reporter could not obtain a server-side price-specific rejection on testnet because both the invalid-price order and the valid-price control order were rejected earlier with a wallet/API-wallet error. The decimal-cap violation itself is supported by the arithmetic and the documentation cited in the issue.

Community-suggested fix

The issue suggests bounding the spot range instead of using an open-ended lower bound:

is_spot = 10_000 <= asset < 110_000

Alternatively, the issue suggests tracking asset kind from metadata instead of relying on ID ranges.

This is a reference patch suggested in the public issue. It should be treated as a workaround until the SDK maintainers confirm and release an official fix. If you are not using builder-deployed perp markets, this issue is unlikely to affect your SDK orders.

Practical notes

• Check whether the asset is a builder-deployed perp and whether its ID is at or above 110000 before using market_open or market_close.
• If you see price rejection on a builder perp, compare the SDK-generated price decimals with the perp decimal cap.
• For general slippage behavior, see Hyperliquid slippage math and order-not-filling slippage guidance.
• If you need a Hyperliquid account, Create a Hyperliquid account. This article includes a Hyperliquid referral link. If you sign up, the referred account receives a 4% fee discount on the first $25M of volume, excluding Vaults and sub-accounts.

Sources

• Hyperliquid Python SDK issue #341
• Hyperliquid order types documentation

Continue with Hyperliquid

Browse the Hyperliquid guide hub for the complete user journey.