Level 02Integration
APIs, SDKs,
docs and support.
Everything a team needs to build on Hyperliquid and beyond, from people who have built and operated on it for years.
How we build
Quality, consistency, targeted abstraction.
The rules every crate, page and endpoint is held to.
01QualityProven against the reference570 tests on df-hyperliquid-core alone. Signatures match the reference SDKs, whole journeys run against a fake venue, a live suite reads mainnet.
02ConsistencyOne shape, every venueEvery crate is laid out the same way: client, markets, account, trade, transfer, live, utils. Learn one, know them all.
03Targeted abstractionHard parts once, the venue intactDecimals, signing, rate limits and transports are solved once. The venue's own concepts stay as they are. Native or wasm, the same code.
Generations
Tooling, three generations deep.
Each one replaced the last when we knew better.
Generation 1Provider APIOne REST and WebSocket API across venues: perps, spot and RWAs in one normalised shape.
api.perps.studio/v1papi.perps.studio
Generation 2HIP-4 SDKsThe first SDKs for Hyperliquid's outcome markets, in four languages.
hip4 (Rust)@hip4/sdk (TypeScript)hip4 (Python)hip4-go (Go)
Generation 3The core cratesRust SDKs for every venue we build on, one shape across all of them, native and wasm.
df-hyperliquid-coredf-lighter-coredf-elysium-coredf-papertrade-core
The core crates
Four venues, one shape.
Published on crates.io. Pick a venue above to see its module map, as the crate draws it.
$ cargo add df-hyperliquid-core
df-hyperliquid-core ├── client the Client, networks, rate limits │ ├── http /info and /exchange, the wire, the limit gate │ ├── evm HyperEVM JSON-RPC, transactions, ABI, precompiles, CoreWriter │ ├── native reqwest and tokio-tungstenite (feature native) │ └── web fetch and WebSocket (feature web) ├── markets what is listed and what it trades at │ ├── perps meta, funding, margin tables │ ├── spot meta, token details │ ├── dexes HIP-3 dexes and their limits │ └── outcomes HIP-4 meta, books, prices, templates ├── account what an address holds and who may sign for it │ ├── holdings perps, spot, outcomes, worth, what an order may use │ ├── history fills, orders, ledger, portfolio, fees │ ├── keys signers, API wallets, builder approvals │ └── settings margin mode, subaccounts, referrals, rate limits ├── trade orders on every market │ ├── orders market, limit, trigger, TP/SL, scale, TWAP, close │ ├── manage cancel, modify, dead man's switch │ ├── margin leverage, isolated margin, margin tables │ ├── builder builder fees and their caps │ └── outcomes outcome fees, split and merge ├── transfer sends, withdrawals, Arbitrum deposits, HyperCore to HyperEVM ├── earn staking, vaults, lending ├── deploy spot tokens, deploy auctions, HIP-3 dexes, HIP-4 outcome markets ├── live websocket subscriptions, frames, connection state, a kept store └── utils decimals, rounding, asset ids, units, time, hex, nonces, signing
df-hyperliquid-core0.0.10-betaHyperliquidPerps, spot, HIP-3 dexes and HIP-4 outcomes, HyperCore and HyperEVM. The feature-complete Hyperliquid SDK.df-lighter-core0.0.1-betaLighterPerps, spot, pools and binary options on Lighter, with the API key signer in Rust.df-elysium-core0.0.1-betaElysiumKinetiq's chain on HyperEVM: Nitro JSON-RPC, ArbOS precompiles, bridging and deploys.df-papertrade-core0.0.11-betaPapertradeGasless 1000x perps on HyperEVM: intents, the relayer and exact venue math.Documentation
Hyperliquid, from first principles.
The instruction manual for Hyperliquid: from a five-minute introduction to nonces, precision and deploys.
Open HyperBooksHyperBooks is a structured expression of our experience building and operating on Hyperliquid. Dozens of products shipped, from front ends for trading terminals to low-level protocols, developer tooling, and research and development, this is the codex we never had.