Hyperliquid vs Backpack Exchange: Perps, Spot and Fees

Hyperliquid and Backpack both pitch themselves as the exchange serious traders actually want to build on, but they're solving different problems. Hyperliquid rebuilt the order book as blockchain state; Backpack rebuilt a conventional matching engine and wrapped it in on-chain settlement rails and a regulated wrapper. If you're deciding where to point a bot, that architectural fork matters more than either platform's marketing copy suggests.

The order book lives in different places

Hyperliquid runs its own L1 with a consensus engine called HyperBFT, a HotStuff derivative tuned for sub-second finality. The order book, matching logic, funding calculations and liquidation engine are all on-chain state produced by validators, not an API server somewhere. That on-chain order book is called HyperCore. Sitting next to it is HyperEVM, a general-purpose EVM environment that can read HyperCore state through precompiles, meaning a smart contract can see live positions, mark prices and order book depth without an oracle round trip. We've written before about how HyperCore and HyperEVM split responsibilities, and that split is the single biggest reason teams choose Hyperliquid over an AMM-perp design like GMX's, which we cover in our order book vs. GLP liquidity comparison.

Backpack takes the opposite bet. Its matching engine is centralized and fast, comparable in latency to Binance or Bybit's engines, not to an L1 block time. What's on-chain is the settlement layer: deposits and withdrawals move across Solana, Ethereum, Bitcoin and a handful of L2s, and balances are provably backed rather than custodied in a black box. Backpack holds a VASP license in Dubai, ties into the Backpack wallet for seedless onboarding, and generally reads like a CEX that took custody and proof-of-reserves seriously rather than a chain that happens to run an exchange. Neither approach is wrong; they just produce different failure modes and different automation surfaces, which is the part that actually affects a trading desk.

Spot and perps, one account, with a catch

Both venues market unified accounts, and both mostly deliver. On Hyperliquid, your USDC balance backs perp margin and your spot holdings sit in the same wallet, but perp collateral itself is USDC-only. You can hold ETH or PURR in spot, but it isn't accepted as perp margin without converting first. Backpack goes a step further on this specific point: its cross-collateral model accepts SOL, BTC and a short list of majors directly as perp margin alongside USDC, with an internal haircut applied per asset. If your strategy runs a spot inventory you don't want to keep converting, that's a real edge for Backpack. If you want your margin math to be dead simple and USDC-denominated end to end, Hyperliquid is the cleaner mental model, and it's the one we build against most often when clients ask for a Hyperliquid perps bot that needs predictable margin behavior under load.

Fee tiers, side by side

Dimension	Hyperliquid	Backpack Exchange
Order book	Fully on-chain (HyperCore)	Off-chain matching engine
Settlement	Native L1, sub-second finality	Multi-chain deposits/withdrawals
Perp margin assets	USDC only	USDC, SOL, BTC + majors
Base taker fee	~0.045%	~0.05%
Base maker fee	~0.015% (rebates at scale)	~0.02%
Top-tier maker	Negative, rebate around -0.003%	Reduced, stays non-negative
Fee discounts	Referral code + HYPE staking tiers	Points/volume tiers, BACKPACK holdings
Smart contract access	Yes, via HyperEVM precompiles	No public contract layer
Regulatory posture	Permissionless, geo-blocked list	Dubai VARA license

The headline numbers look close, and at low volume they basically are. The gap opens once you're pushing real size. Hyperliquid's maker rebate flips negative at its top tiers, meaning a market maker running enough 14-day volume gets paid to add liquidity. That's the entire economic premise behind our Hyperliquid market maker engagements, and it doesn't exist in the same form on Backpack, where maker fees compress but stay non-negative. On the other side, Backpack's points program and BACKPACK token discounts can meaningfully undercut posted fees for active accounts, so the effective fee you actually pay often diverges from the fee schedule you'd quote from memory. Pull both venues' current tier tables before sizing a strategy around fee assumptions; they get revised more often than either team announces.

What the architecture means for a bot

The practical difference shows up in how you get data and how you fail. Against Hyperliquid, you can build the strategy as a smart contract on HyperEVM that reads HyperCore's precompiles directly:

// simplified: read a user's perp position size from a HyperCore precompile
address constant POSITION_PRECOMPILE = 0x0000000000000000000000000000000000000800;

function getPositionSize(address user, uint32 asset) external view returns (int64) {
    (bool ok, bytes memory data) = POSITION_PRECOMPILE.staticcall(
        abi.encode(user, asset)
    );
    require(ok, "precompile read failed");
    return abi.decode(data, (int64));
}

That contract's view of your position is exactly the chain's view. No websocket to babysit, no reconciliation between what your bot thinks happened and what actually settled. Against Backpack, you're back to a conventional REST and WebSocket integration: authenticate, subscribe to fills, track order state client-side, and build your own reconciliation against the exchange's account snapshot, the same pattern you'd use on any centralized venue. It's a mature, well-understood pattern, nothing wrong with it, but it means your bot's source of truth lives on Backpack's servers, not on a ledger you can independently verify. For latency-sensitive designs like funding-rate arbitrage, where a missed settlement window costs real money, that distinction is why most of our funding arb builds and liquidation bots target Hyperliquid specifically, with a trading dashboard layered on top for monitoring both venues from one screen when a client runs positions on each.

If you want the deeper architectural context on why an on-chain order book behaves differently from a request-response API under load, our comparison of Hyperliquid against dYdX v4 covers a lot of the same ground from the app-chain angle rather than the CEX angle.

Which to pick when

Pick Hyperliquid if you're building anything that benefits from composability: a liquidation bot, a funding-rate arbitrage strategy, a market-making desk chasing rebate tiers, or any system where you want the settlement layer and the strategy logic to share one source of truth. The maker rebates alone make it the better home for pure market-making flow once you clear the mid volume tiers.

Pick Backpack if your strategy runs a real spot inventory and you want that inventory usable as margin without converting to USDC first, or if your compliance team needs a regulated counterparty with a VASP license rather than a permissionless protocol. It's also the simpler onboarding for teams already used to a standard CEX API who don't need contract-level access to the book.

Running both isn't unusual; plenty of desks arb the funding differential between them. If Hyperliquid is where that strategy needs to live, we build perps bots for exactly that setup.