Hire a Hyperliquid Bot Developer: What to Vet For

Most trading-bot hires go sideways in the first week for the same reason: the candidate can call an exchange REST endpoint, but they've never reasoned about what happens when their order sits in the book and the mark price moves against a position they can't unwind fast enough. Hyperliquid makes that failure mode worse than most venues, because it isn't a normal exchange with a normal matching engine you poke over HTTPS. It's an L1 with an on-chain order book, a specific signing scheme, and latency characteristics that punish anyone treating it like Binance.

So when you set out to hire a Hyperliquid developer, the vetting has to go deeper than "do you know Python." Here's what actually separates someone who has shipped size on HL from a generalist who read the docs last night.

Start with the signing and SDK questions

The fastest tell is how a candidate talks about order placement. On Hyperliquid, orders are actions signed with an EIP-712 typed-data structure and posted to the exchange endpoint. There are two account models — the master wallet and an API/agent wallet you approve on-chain — and mixing them up is the single most common integration bug. Ask directly:

• Do you use an agent wallet, and why? (Correct answer: to keep the master key cold and to scope/rotate a hot signing key. If they've never heard of agent wallets, they haven't run this in production.)
• What's the difference between the info and exchange endpoints, and which one is rate-limited how?
• How do you handle nonce/expiry on signed actions when you're firing hundreds of orders a minute?

A strong candidate will mention that the official Python SDK (hyperliquid-python-sdk) is fine for research and slower strategies but that they moved the hot path to Rust or a hand-rolled signer once they needed throughput. That tradeoff — Python for iteration, Rust for the latency-sensitive loop — is exactly the ground covered in our Python vs Rust guide for building on the HL API, and a real engineer will independently arrive at the same split. If they claim the Python SDK is production-grade for a sub-second market maker, push back.

A concrete signing gotcha to probe

Ask what breaks when the system clock drifts. On HL, signed actions carry a timestamp and the exchange rejects anything outside a tolerance window. A candidate who has been burned will tell you about NTP sync, monotonic-clock vs wall-clock confusion, and the joy of debugging intermittent L1 error: invalid nonce rejections at 3am. If they've never seen that error, they've never run size.

Latency: measure the right thing

Generalists quote "low latency" as if it's one number. HL has several that matter, and they're different:

• WebSocket feed lag for l2Book and trades updates.
• The round trip from signing an action to seeing it acknowledged.
• Block time and how quickly a resting order actually becomes active on-chain.

A market maker that reprices on every top-of-book tick but posts orders that take a block to land will get picked off constantly. The right answer involves colocating near the API, batching cancel/replace, and — critically — designing quoting logic that assumes your order will be stale by the time it rests. Ask a candidate how they'd quote a two-sided book knowing there's meaningful placement latency. If they don't mention widening spreads under latency uncertainty or using post-only and ALO (add-liquidity-only) flags to avoid crossing, they haven't thought about it as a Hyperliquid market maker has to.

Here's the kind of check I want to see in a candidate's own code — not a perfect implementation, just evidence they think about staleness:

def should_requote(current_quote, book, max_age_ms, drift_ticks):
    age_ms = now_ms() - current_quote.placed_at
    mid = (book.best_bid + book.best_ask) / 2
    drift = abs(mid - current_quote.ref_mid) / book.tick_size
    # requote if the quote is old OR the market moved past our tolerance,
    # but rate-limit so we don't hammer the exchange endpoint
    return (age_ms > max_age_ms or drift > drift_ticks) \
        and (now_ms() - current_quote.last_requote_ms) > MIN_REQUOTE_INTERVAL_MS

The detail that matters is the MIN_REQUOTE_INTERVAL_MS guard. Someone who has hit HL rate limits knows that naive requoting gets you throttled, and throttling mid-repricing is how you end up holding a one-sided quote in a fast market.

The risk engine is where money actually leaks

Anyone can place orders. Almost nobody handles the position lifecycle correctly, and this is where I spend most of an interview. Hyperliquid uses cross- and isolated-margin modes, its own maintenance-margin formula, and a liquidation mechanism backed by the HLP vault. A developer building a perps bot on Hyperliquid needs to answer:

• How do you track effective leverage in real time, not just at order-submit time?
• Where's your kill switch, and what triggers it — position notional, drawdown, feed staleness, or all three?
• What happens to open orders when the WebSocket drops for 20 seconds?

That last one is the killer. The correct design keeps a local mirror of open orders and positions, reconciles it against the exchange on every reconnect, and treats any divergence as a stop-trading event until resolved. A generalist assumes the exchange state and their local state agree. They never do.

Liquidation mechanics deserve their own probe, because they cut both ways. If you're the one getting liquidated, you need margin monitoring that fires well before maintenance margin. If you're running a liquidation bot on Hyperliquid to catch other people's forced exits, you need to model the HLP backstop and how it absorbs flow — the same vault dynamics we break down in the HLP vault strategy explainer. Ask which side they've built for and what surprised them.

Funding is the other silent P&L driver. HL pays funding hourly, not every eight hours like most CEXes, and the rate can swing hard around events. A candidate building funding-rate arbitrage on Hyperliquid should immediately bring up the hourly cadence and the basis risk of holding the offsetting CEX leg — the exact structure covered in our piece on funding arbitrage between HL and centralized venues. If they think funding is a monthly footnote, they've never held a position through it.

Audit, observability, and the "show me" test

The last filter is whether the person builds systems you can actually operate. Working code that you can't see into is a liability. I ask:

• Do you log every signed action with its response, and can you replay a day from those logs?
• How do you reconcile realized P&L against the exchange's own fills, and what's your tolerance for mismatch?
• Where does an operator see live position, margin headroom, and open-order state at a glance?

That last question is why a serious build almost always includes a live trading dashboard. A bot without one is a black box, and black boxes lose money quietly until they lose it loudly.

The single best interview move is to ignore the résumé and say: walk me through your reconnect logic. The generalist describes reconnecting the socket. The engineer describes reconnecting the socket, re-fetching open orders and positions, diffing against local state, canceling anything orphaned, and only then resuming quoting. That gap is the whole hire.

If you'd rather skip the vetting and start with a team that already lives inside HL's order-book and margin quirks, that's what our Hyperliquid perps bot builds are for.