Hyperliquid vs Binance vs Bybit: API Comparison for Algo Traders

Every exchange comparison written for traders stops at fees and liquidity. This one is for the person who has to make three APIs behave like one — where the differences are authentication, session lifecycle, rate-limit accounting, and the error semantics you only discover when something has already gone wrong in production.

• Three different auth models: HMAC over a query string, HMAC over a header payload, and an EIP-712 typed-data signature.
• Three different private-stream session models: listenKey, an auth message, and a direct subscription — each fails differently.
• Rate limits are accounted differently on each venue, so one shared limiter across all three is either too slow or gets you banned.
• Minimum notional rules silently break multi-leg exit ladders, and each venue enforces them differently.
• Reconnection is the hard part. A dropped private stream that reconnects without replaying state loses fills, and lost fills mean wrong position state.

Authentication: the fork in the road

This is where the three genuinely diverge, and it shapes everything downstream.

Binance Futures — HMAC over a query string

Classic REST. You hold an API key and a secret. Every signed request appends a timestamp, you HMAC-SHA256 the query string with the secret, and send the digest as a signature parameter with the key in an X-MBX-APIKEY header. Widely documented, every language has a client, and the failure mode most people hit is clock drift — a system clock a few seconds off produces rejections that read like auth errors.

Bybit V5 — HMAC over a header payload

Same primitive, different construction. The signed string is assembled from timestamp, API key, receive window and the raw body, and the result travels in headers rather than the query string. The unified V5 API is cleaner than what preceded it, and the receive-window parameter gives you an explicit knob for tolerating latency that Binance handles more implicitly.

Hyperliquid — EIP-712 typed-data signature

Structurally different. There is no API secret. You authorise an agent wallet against your account, and that agent signs each action as EIP-712 typed data — the same signing scheme used for wallet-based authentication across Ethereum tooling.

Three consequences for an integrator:

• You need a signing library, not just an HMAC. The payload must be constructed exactly, and a mismatch produces a valid-looking signature the venue rejects.
• Nonces are sequenced. Actions carry a nonce and the ordering matters. Parallel submission from multiple processes against one agent needs coordination.
• The credential cannot withdraw. Not a permission you set — the protocol does not expose withdrawal to an agent. This is the strongest security property of the three by a wide margin.

If your account is a sub-account or a vault, signed actions must also carry the master account address. Omit it and everything is rejected with an authorisation error that looks exactly like a bad key, which is why this is the most common first-integration failure on Hyperliquid.

REST surface and rate limits

The practical trap: Binance's weighted model means requests are not equal — a deep order-book snapshot can cost many times a simple query. A limiter that counts requests rather than weight will either throttle you far below your actual allowance or blow through it. Bybit groups limits by endpoint family. Hyperliquid accounts per source IP in aggregate, which matters most for read-heavy workloads such as pulling candles across a large universe: the ceiling is shared across everything from that address, so a busy market-data loop can starve order placement from the same host.

The consequence is that a single shared rate limiter across all three venues is wrong in both directions. Each needs its own accounting model.

WebSocket: three session models, three failure modes

Public market-data streams are broadly similar everywhere — subscribe to a channel, receive updates. Private streams carrying your fills, order updates and position changes are where the venues diverge, and where an integration is most likely to be silently wrong.

Binance — listenKey

Obtain a listenKey over REST, connect to a user-data stream at that key, then keep it alive with a periodic REST call. Forget the keepalive and the key expires; the socket closes without ceremony and your fills stop arriving. This is the single most common source of "my bot lost track of a position" on Binance, because a stream that stops delivering looks identical to a market with no activity.

Bybit — auth message on the socket

Connect to the private endpoint and send a signed auth frame. No separate key to obtain, no keepalive REST call — one less moving part and one less thing to get wrong. Re-auth on reconnect.

Hyperliquid — subscribe with the account address

Subscribe to user-scoped channels directly. Simplest of the three conceptually.

Reconnection is the actual problem

Every one of these disconnects eventually. What matters is what your client does next, and the naive answer is wrong on all three venues:

• Reconnect with backoff, not a tight loop that gets you rate-limited on top of being disconnected.
• Re-fetch state after reconnect. Events during the gap are gone. If you resume streaming without reconciling positions and open orders over REST, your internal state is now a fiction that gets more wrong over time.
• Detect a silently dead socket. TCP connections can stop delivering without closing. Track time since last message and treat an unexplained quiet period as a disconnect — do not wait for a close event that may never arrive.
• Sequence-check where offered. Order book diff streams carry update ids; a gap means your local book is corrupt and must be rebuilt from a fresh snapshot rather than patched.

Order types and precision

Market, limit, stop and reduce-only exist everywhere, but the details that break integrations do not line up:

The stop-trigger row deserves emphasis. Whether a stop fires on mark price or last price changes which candle wicks can take you out, and the venues differ on both the default and whether it is configurable. A strategy backtested against last-price candles and executed against mark-price triggers is not the strategy you tested.

Error semantics, and why they are worse than they look

Every venue returns errors in its own vocabulary, and the categories that matter to a bot are not the ones the docs organise by. What you actually need to distinguish:

• Retryable — transient network failure, rate limit, temporary unavailability. Retry with backoff.
• Fatal for this order — invalid precision, notional below minimum, insufficient margin. Retrying is pointless; fix or abandon.
• Fatal for the session — invalid or revoked credential. Stop and alert; retrying looks like an attack.
• Ambiguous — a timeout on submission. This is the dangerous one. You do not know whether the order was placed. Retrying blindly can double your position.

The ambiguous case is the one that costs real money and the one most integrations handle worst. The correct pattern is a deterministic client-supplied order id on every submission, so a retry with the same id is idempotent at the venue and a duplicate is rejected rather than filled. All three venues support a client order id; use it on every order, not just the ones that seem important.

What abstraction actually requires

A usable multi-venue layer needs, at minimum: per-venue authentication; per-venue rate limiting with the correct accounting model; a normalised order model that survives translation both ways; per-symbol precision and minimum-notional rules fetched and cached; a WebSocket manager per venue with backoff, liveness detection and post-reconnect reconciliation; and an error taxonomy that maps each venue's vocabulary onto the four categories above.

That is a meaningful amount of engineering, and it is the same engineering three times. TradeFloor implements it once: strategy logic is written against a normalised model, venue differences are handled underneath, and API credentials are encrypted at rest with signing isolated in a separate component so the application never holds a raw key. For the trader-level view of the same three venues, see Binance vs Bybit vs Hyperliquid.

// questions or corrections · [email protected] · more essays · /blog