Hyperliquid

Hyperliquid is a decentralized perpetual futures and spot exchange built on the Hyperliquid L1, a purpose-built blockchain optimized for trading. HyperCore provides a fully on-chain order book and matching engine. This integration supports live market data ingest and order execution on Hyperliquid.

Overview

This adapter is implemented in Rust with Python bindings. It provides direct integration with Hyperliquid's REST and WebSocket APIs without requiring external client libraries.

The Hyperliquid adapter includes multiple components:

• HyperliquidHttpClient: Low-level HTTP API connectivity.
• HyperliquidWebSocketClient: Low-level WebSocket API connectivity.
• HyperliquidInstrumentProvider: Instrument parsing and loading functionality.
• HyperliquidDataClient: Market data feed manager.
• HyperliquidExecutionClient: Account management and trade execution gateway.
• HyperliquidLiveDataClientFactory: Factory for Hyperliquid data clients (used by the trading node builder).
• HyperliquidLiveExecClientFactory: Factory for Hyperliquid execution clients (used by the trading node builder).

Examples

You can find live example scripts here.

Builder address

Mainnet orders submitted through the adapter include a NautilusTrader builder address with a zero fee rate, so it adds no trading cost to your orders. This helps us gauge real usage of the integration and prioritize ongoing maintenance and improvements.

The builder address is omitted from orders in two cases:

• Testnet. Hyperliquid testnet rejects orders that include a builder address the wallet has not explicitly approved (faucet-funded testnet wallets typically have no approval), so testnet orders never include the builder.
• Vault trading (vault_address configured). Hyperliquid does not allow vaults to approve builder fees, so including the builder address would cause the exchange to reject the order.

Testnet setup

Hyperliquid provides a testnet environment for testing strategies with mock funds.

Getting testnet funds

To receive testnet USDC, you must first have deposited on mainnet using the same wallet address:

1. Visit the Hyperliquid mainnet portal and make a deposit with your wallet.
2. Visit the testnet faucet using the same wallet.
3. Claim 1,000 mock USDC from the faucet.

Creating a testnet account

1. Visit the Hyperliquid testnet portal.
2. Connect your wallet (MetaMask, WalletConnect, or email).
3. The testnet automatically creates an account for your wallet address.

Exporting your private key

To use your testnet account with NautilusTrader, you need to export your wallet's private key:

MetaMask:

1. Click the three dots menu next to your account.
2. Select "Account details".
3. Click "Show private key".
4. Enter your password and copy the private key.

Setting environment variables

Set your testnet credentials as environment variables:

export HYPERLIQUID_TESTNET_PK="your_private_key_here"
# Optional: for vault trading
export HYPERLIQUID_TESTNET_VAULT="vault_address_here"

The adapter automatically loads these when environment=HyperliquidEnvironment.TESTNET in the configuration.

Product support

Hyperliquid offers linear perpetual futures, HIP-3 builder-deployed perpetuals, native spot markets, and HIP-4 binary outcome markets.

Symbology

Hyperliquid uses a specific symbol format for instruments:

Spot markets

Format: {Base}-{Quote}-SPOT

Examples:

• PURR-USDC-SPOT - PURR/USDC spot pair
• HYPE-USDC-SPOT - HYPE/USDC spot pair

To subscribe in your strategy:

InstrumentId.from_str("PURR-USDC-SPOT.HYPERLIQUID")

Perpetual futures

Format: {Base}-USD-PERP

Examples:

• BTC-USD-PERP - Bitcoin perpetual futures
• ETH-USD-PERP - Ethereum perpetual futures
• SOL-USD-PERP - Solana perpetual futures

To subscribe in your strategy:

InstrumentId.from_str("BTC-USD-PERP.HYPERLIQUID")
InstrumentId.from_str("ETH-USD-PERP.HYPERLIQUID")

HIP-3 perpetuals

Format: {dex}:{Asset}-USD-PERP

HIP-3 markets use a dex prefix separated by a colon. The dex name identifies which builder-deployed perp dex the market belongs to.

Examples:

• xyz:TSLA-USD-PERP - Tesla perp on trade.xyz
• xyz:GOLD-USD-PERP - Gold perp on trade.xyz
• flx:NVDA-USD-PERP - Nvidia perp on Felix
• vntl:SPACEX-USD-PERP - SpaceX perp on Ventuals

To subscribe in your strategy:

InstrumentId.from_str("xyz:TSLA-USD-PERP.HYPERLIQUID")

HIP-4 outcome side tokens

Format: {outcome_index}-{YES|NO}-OUTCOME.HYPERLIQUID, where outcome_index is the outcome field from outcomeMeta and the middle segment names the binary side. The -OUTCOME suffix is symmetric with -PERP / -SPOT.

HIP-4 side tokens are binary contracts that settle in USDH at 0 (loser) or 1 (winner). The Nautilus symbol uses the human-readable form above; the wire raw_symbol uses the venue coin form #{encoding} (where encoding = 10 * outcome_index + side, side is 0 for Yes / 1 for No), which is what l2Book and allMids accept.

Examples (outcome 25):

• 25-YES-OUTCOME.HYPERLIQUID: Yes side. Encoding 250, wire coin #250, token name +250, action asset id 100_000_250.
• 25-NO-OUTCOME.HYPERLIQUID: No side. Encoding 251, wire coin #251, token name +251, action asset id 100_000_251.

To subscribe in your strategy:

InstrumentId.from_str("25-YES-OUTCOME.HYPERLIQUID")

See HIP-4 outcome markets for the trading flow, settlement, and current limitations.

HIP-3 builder-deployed perpetuals

HIP-3 allows qualified deployers to launch permissionless perp dexes on Hyperliquid. These markets include equities (TSLA, NVDA, AAPL), commodities (gold, crude oil), indices (S&P 500), and pre-IPO tokens (SpaceX, OpenAI).

HIP-3 instruments are excluded by default. To load them, include HyperliquidProductType.PERP_HIP3 in the requested product types.

For direct instrument provider usage:

from nautilus_trader.adapters.hyperliquid.enums import HyperliquidProductType
from nautilus_trader.adapters.hyperliquid.providers import HyperliquidInstrumentProvider

provider = HyperliquidInstrumentProvider(
    client=client,
    product_types=[
        HyperliquidProductType.PERP,
        HyperliquidProductType.SPOT,
        HyperliquidProductType.PERP_HIP3,
    ],
)

For live TradingNode usage, pass the same product_types through the Hyperliquid client config:

from nautilus_trader.adapters.hyperliquid import HyperliquidDataClientConfig
from nautilus_trader.adapters.hyperliquid import HyperliquidExecClientConfig
from nautilus_trader.adapters.hyperliquid import HyperliquidEnvironment
from nautilus_trader.adapters.hyperliquid import HyperliquidProductType

HyperliquidDataClientConfig(
    product_types=(
        HyperliquidProductType.PERP,
        HyperliquidProductType.PERP_HIP3,
    ),
)

HyperliquidExecClientConfig(
    product_types=(
        HyperliquidProductType.PERP,
        HyperliquidProductType.PERP_HIP3,
    ),
)

Once HIP-3 instruments are loaded, you can filter them with InstrumentProviderConfig:

instrument_provider=InstrumentProviderConfig(
    load_all=True,
    filters={"market_types": ["perp_hip3"]},
)

Differences from standard perpetuals

HIP-3 markets trade on the same HyperCore matching engine and use the same order API. The key differences are:

• Higher fees: 2x standard perp fees by default. The deployer receives half.
• Isolated margin: HIP-3 markets default to isolated-only margin.
• Deployer-managed oracles: The deployer operates the oracle feed, not validators.
• Growth mode: Some dexes enable growth mode, which reduces protocol fees by 90%.

For full protocol details, see the Hyperliquid docs:

• HIP-3 proposal
• HIP-3 deployer actions
• Asset IDs
• Fees

Wildcard character sanitization

Some HIP-3 dexes deploy assets whose venue names contain * or ? bytes (for example dex:STREAMABCD****-USD-PERP). Those bytes collide with the Nautilus message bus pattern syntax (* = zero-or-more, ? = one-char) and would corrupt subscription routing if embedded in topic strings unchanged.

The Hyperliquid adapter substitutes both bytes with x when constructing the InstrumentId.symbol, so a HIP-3 asset named dex:STREAMABCD**** is exposed to strategies as:

InstrumentId.from_str("dex:STREAMABCDxxxx-USD-PERP.HYPERLIQUID")

The substitution applies only to the Nautilus-internal symbol used in topics, caches, logs, and config. The venue-official name is preserved on the instrument's raw_symbol field for HTTP and WebSocket wire calls, and order submissions reference the numeric asset index, so the round-trip with Hyperliquid is unaffected.

When subscribing to a HIP-3 instrument with wildcard bytes in its venue name, use the sanitized form. Symbols without * or ? are passed through unchanged.

The substitution is lossy: two distinct venue names such as dex:FOO* and dex:FOO? would normalize onto the same Nautilus symbol. The instrument loader detects collisions, keeps the first definition, and logs a warning with the dropped venue name; the dropped instrument will not be tradeable through Nautilus until the venue rename resolves the collision.

HIP-4 outcome markets

HIP-4 markets are fully-collateralized binary contracts. Each market has two side tokens (Yes / No) that settle to 1 USDH (winner) or 0 USDH (loser) on the resolution date. Hyperliquid's current API docs expose outcome metadata through outcomeMeta and mark that endpoint as testnet-only. The adapter treats outcome metadata as best-effort and skips HIP-4 instruments when the venue does not return that payload.

Loading outcome instruments

Include HyperliquidProductType.OUTCOME in product_types on both the data and exec client configs. This opts into outcome discovery where the venue exposes outcomeMeta; current Hyperliquid docs mark that metadata endpoint as testnet-only.

from nautilus_trader.adapters.hyperliquid import HyperliquidDataClientConfig
from nautilus_trader.adapters.hyperliquid import HyperliquidProductType

HyperliquidDataClientConfig(
    product_types=(
        HyperliquidProductType.SPOT,
        HyperliquidProductType.PERP,
        HyperliquidProductType.OUTCOME,
    ),
)

The provider emits two BinaryOption instruments per outcome (one per side), denominated in USDH. Symbols use the form {outcome_index}-{YES|NO}-OUTCOME.HYPERLIQUID. expiration_ns is parsed from the venue description (expiry:YYYYMMDD-HHMM, UTC). Standalone binaries carry their own expiry; named and fallback outcomes inherit from their parent question. Defaults: 0.0001 per tick, 0.01 per lot.

Each instrument's BinaryOption.info carries the parsed venue metadata as a key/value map (consumed via info["key"] in Python or Params.get_str(...) in Rust). Derived identifiers are always populated; description-derived fields appear when the venue includes them.

Description keys are lowered from venue camelCase to snake_case (targetPrice -> target_price, priceThresholds -> price_thresholds). Values are kept as strings to preserve wire fidelity; numeric identifiers (outcome_index, outcome_side, encoding, asset_id, question, named_index) are stored as JSON numbers.

Settlement currency

Outcomes settle in USDH (token index 360, traded on the USDH/USDC spot pair @230). The adapter registers USDH at 8-decimal precision on first outcome instrument creation, so BinaryOption.currency, quote_currency, and the commission currency on zero-fee outcome fills all resolve to USDH.

USDH spot balances merge with the perp clearinghouse view, so AccountState carries USDH alongside USDC and any other non-zero spot holdings.

Trading flow

Outcome side tokens ({outcome_index}-{YES|NO}-OUTCOME.HYPERLIQUID) trade through the standard order path. Submit SubmitOrder as you would for any perp or spot instrument; the execution client routes it through the same Order action against the venue's #{encoding} orderbook (where encoding = 10 * outcome_index + outcome_side). No HIP-4-specific call is needed.

Settlement is venue-driven; see Settlement dispatch.

Advanced workflows

The full userOutcome action set is reachable directly on HyperliquidHttpClient (Rust and PyO3) for strategies that need to manage side-token inventory off-book:

from decimal import Decimal
from nautilus_trader.core.nautilus_pyo3 import HyperliquidEnvironment
from nautilus_trader.core.nautilus_pyo3 import HyperliquidHttpClient

client = HyperliquidHttpClient.from_env(HyperliquidEnvironment.MAINNET)

# Mint matched Yes + No side tokens from USDH (e.g. dual-side market making)
await client.submit_split_outcome(50, Decimal("1.0"))

# Burn a matched Yes + No pair back to USDH (amount=None merges the max)
await client.submit_merge_outcome(50, None)

# Multi-outcome priceBucket helpers
await client.submit_merge_question(9, None)
await client.submit_negate_outcome(9, 52, Decimal("1.0"))

For directional bets the ordinary SubmitOrder path is sufficient; the methods above are only needed when you want to create or destroy side-token inventory off-book.

Order constraints

Outcome side tokens behave like spot tokens (no margin, no funding, no liquidation). The execution client rejects features that don't apply:

• reduce_only orders.
• Trigger order types (StopMarket, StopLimit, MarketIfTouched, LimitIfTouched, trailing stops).

Limit and Market orders with GTC, IOC, or ALO time-in-force are supported. The venue minimum is 10 USDH notional; size order_qty so that order_qty * limit_price >= 10.

Settlement dispatch

At expiry the venue closes held side-token balances and emits a Settlement fill per side. The adapter consumes these through the standard user-fills stream (HTTP poll and WebSocket); no synthetic dispatch runs.

Each settlement fill:

• order_side = SELL, zero commission.
• Price 1 USDH for the winning side, 0 for the loser.
• Surfaces as a FillReport.
• Also emits OrderFilled when WebSocket dispatch links the position to a tracked order.

Covers standalone priceBinary outcomes and multi-outcome priceBucket questions uniformly.

Position reconciliation

HIP-4 side tokens arrive on spotClearinghouseState with coin set to the +E token form and no token field. The adapter:

• Treats SpotBalance.token as optional during deserialization.
• Resolves +E / #E coins to their BinaryOption instrument when generating PositionStatusReports.
• Skips the perp clearinghouse fetch when the position-status filter is an outcome instrument (outcomes never appear in assetPositions).

Multi-outcome (priceBucket) markets

The venue exposes multi-outcome markets via the top-level questions array in outcomeMeta. Each question references a fallback outcome plus a sequence of named outcomes whose individual descriptions point back at the question via index:N. Each side token is modeled as an independent BinaryOption instrument; the submit_merge_question and submit_negate_outcome actions on HyperliquidHttpClient operate at the question level for basket close and cross-outcome rotation.

Instrument provider

The instrument provider supports filtering when loading instruments via InstrumentProviderConfig(filters=...):

Example loading only perpetual instruments:

instrument_provider=InstrumentProviderConfig(
    load_all=True,
    filters={"market_types": ["perp"]},
)

Data subscriptions

The adapter supports the following data subscriptions. All perpetual data types (mark prices, index prices, funding rates) apply to both standard and HIP-3 perps.

Order book precision controls

The l2Book subscription accepts optional nSigFigs and mantissa parameters that thin the venue-side book aggregation. The adapter forwards them when passed through subscribe_params on book deltas and depth subscriptions.

Hyperliquid accepts nSigFigs values 2, 3, 4, 5, or omitted for full precision. mantissa is only valid when nSigFigs=5 and accepts 1, 2, or 5.

from nautilus_trader.model.data import BookType

self.subscribe_order_book_deltas(
    instrument_id=instrument_id,
    book_type=BookType.L2_MBP,
    params={"n_sig_figs": 5, "mantissa": 2},
)

Omitting both params subscribes to the full-depth book.

Hyperliquid specific data

The adapter emits two Hyperliquid-specific custom data types:

• HyperliquidAllMids from the WebSocket allMids feed. Each update carries all currently reported mid prices in one payload.
• HyperliquidOpenInterest from the shared activeAssetCtx feed used by mark prices, index prices, and funding rates.

Subscribe from an actor or strategy with DataType(HyperliquidAllMids). For HIP-3 dex-specific streams, pass the venue dex in metadata["dex"]:

from nautilus_trader.adapters.hyperliquid.constants import HYPERLIQUID_CLIENT_ID
from nautilus_trader.adapters.hyperliquid.data import HyperliquidAllMids
from nautilus_trader.model.data import DataType

self.subscribe_data(
    data_type=DataType(HyperliquidAllMids, metadata={"dex": "hyperliquid"}),
    client_id=HYPERLIQUID_CLIENT_ID,
)

HyperliquidOpenInterest carries the latest open interest for one perpetual instrument. Subscribe with the canonical Nautilus instrument_id in metadata["instrument_id"]:

from nautilus_trader.adapters.hyperliquid import HYPERLIQUID_CLIENT_ID
from nautilus_trader.adapters.hyperliquid import HyperliquidOpenInterest
from nautilus_trader.model.data import DataType

self.subscribe_data(
    data_type=DataType(
        HyperliquidOpenInterest,
        metadata={"instrument_id": str(self.instrument_id)},
    ),
    client_id=HYPERLIQUID_CLIENT_ID,
)

HyperliquidOpenInterest reuses the same single underlying activeAssetCtx venue subscription that already backs mark prices, index prices, and funding rates for the same coin. Adding OI does not open a second parallel activeAssetCtx subscription.

In a Python strategy running inside a TradingNode, the payload arrives via CustomData.data and can be downcast by isinstance:

from decimal import Decimal

from nautilus_trader.model.data import CustomData

def on_data(self, data: CustomData) -> None:
    if isinstance(data.data, HyperliquidOpenInterest):
        if data.data.open_interest > Decimal("1000"):
            self.log.info(f"OI {data.data.instrument_id} -> {data.data.open_interest}")

Supported bar intervals

Orders capability

Hyperliquid supports a full set of order types and execution options.

Order types

from decimal import Decimal, ROUND_DOWN

def round_to_sig_figs(price: Decimal, sig_figs: int = 5) -> Decimal:
    if price == 0:
        return Decimal(0)
    shift = sig_figs - int(price.adjusted()) - 1
    if shift <= 0:
        factor = Decimal(10) ** (-shift)
        return (price / factor).to_integral_value() * factor
    return round(price, shift)

Time in force

Execution instructions

Order operations

Modify as cancel-replace

Hyperliquid implements order modification as a cancel-replace. The modify action on the exchange endpoint cancels the original order (old oid) and opens a replacement with a new oid. Both legs share the same client order ID (cloid).

The modify HTTP response only confirms success. The orderUpdates WebSocket subscription then delivers an ACCEPTED(new_oid) status report, followed by a CANCELED(old_oid) for the original leg.

The Rust-native HyperliquidExecutionClient (used through HyperliquidExecutionClientFactory) runs detection, deduplication, and event promotion on the Rust side via the WsDispatchState owned by the execution client. On submission the client registers an OrderIdentity (strategy, instrument, side, type, quantity, last-known price) keyed by client_order_id. Each inbound status report or fill is routed through the dispatch: tracked orders emit typed OrderEventAny::* events via ExecutionEventEmitter::send_order_event; external orders fall back to the raw OrderStatusReport / FillReport so the engine can reconcile. The dispatch compares the report's venue_order_id against the last cached value for the cloid; when they differ it promotes the ACCEPTED to OrderUpdated and suppresses the paired stale cancel:

If Hyperliquid delivers CANCELED(old_oid) before ACCEPTED(new_oid) for an in-flight modify, the pending-modify marker lets the dispatch drop the old leg's cancel and still route the subsequent ACCEPTED through the OrderUpdated path. The marker is only set after a confirmed HTTP success, so a failed modify never leaves stale race state. Because detection otherwise relies on the cached venue_order_id, the adapter also recovers a modify that times out on the HTTP call but still reaches the venue: the eventual WS ACCEPTED(new_oid) sees the old cached oid and translates to OrderUpdated. See GH-3827.

A FillReport for the replacement leg can also race ahead of ACCEPTED(new_oid). The dispatch buffers such fills (when the pending-modify marker is set and the report's oid does not match the cached value) and drains them on the matching ACCEPTED, so OrderFilled always follows the promoting OrderUpdated against up-to-date state. See GH-3972.

Order books

Order books are maintained via L2 WebSocket subscription. Each message delivers a full-depth snapshot (clear + rebuild), not incremental deltas.

Account and position management

AccountState merges perp margin and spot balances. Perp margin and cross-margin usage come from clearinghouseState; non-zero spot tokens (USDC, USDH, HYPE, vault tokens, HIP-4 outcome side tokens, etc.) come from spotClearinghouseState. USDC is deduplicated when the perp summary is present.

Standard perps default to cross margin; HIP-3 perps default to isolated. On connect, the execution client reconciles orders, fills, and positions against Hyperliquid's clearinghouse state. Spot positions are reconstructed from held balances (long-only); HIP-4 side tokens reconcile against their matching BinaryOption instruments.

Liquidation and ADL handling

Hyperliquid signals venue-initiated closures through two WebSocket surfaces on the userEvents subscription:

• liquidation event: emitted when an account is liquidated. Carries a liquidation ID, liquidator address, liquidated user, liquidated notional position, and liquidated account value. The adapter logs these at warning level for operator visibility.
• Fill-level liquidation metadata: each entry in the fills array can carry an optional liquidation object with method, markPx, and liquidatedUser. The method value is either market (liquidated into the book) or backstop (closed against the backstop vault, the equivalent of an ADL close when the insurance mechanism steps in).

The adapter emits the standard FillReport for each liquidation fill. The liquidation metadata is logged alongside the fill so you can correlate closures to venue-side events. No strategy-side changes are required; existing risk and reconciliation logic runs over these fills as for any other TAKER fill.

Upstream references:

• WebSocket userEvents (liquidation and FillLiquidation)
• Liquidation mechanics

Connection management

The adapter automatically reconnects on WebSocket disconnection using exponential backoff (starting at 250ms, up to 5s). On reconnect, all active subscriptions are resubscribed automatically, and order book snapshots are rebuilt. No manual intervention is required.

A heartbeat ping is sent every 30 seconds to keep the connection alive (Hyperliquid closes idle connections after 60 seconds).

API credentials

There are two options for supplying your credentials to the Hyperliquid clients. Either pass the corresponding values to the configuration objects, or set the following environment variables:

For Hyperliquid mainnet clients, you can set:

• HYPERLIQUID_PK
• HYPERLIQUID_VAULT (optional, for vault trading)

For Hyperliquid testnet clients, you can set:

• HYPERLIQUID_TESTNET_PK
• HYPERLIQUID_TESTNET_VAULT (optional, for vault trading)

For agent (API) wallet trading on either environment, you can also set:

• HYPERLIQUID_ACCOUNT_ADDRESS (master account address; shared between mainnet and testnet)

Agent wallets

Hyperliquid lets a master account approve an agent wallet (also called an API wallet or sub-key) that signs orders on the master's behalf. Orders signed by the agent belong to the master account, not to the agent's address.

If your HYPERLIQUID_PK (or HYPERLIQUID_TESTNET_PK) is an agent wallet, you must also set account_address (or the HYPERLIQUID_ACCOUNT_ADDRESS environment variable) to the master account address. Otherwise the adapter queries the agent's address for balances, orders, and WebSocket events, which owns nothing, and submitted orders will never reconcile (no OrderStatusReport, no fills surfaced).

The execution factory resolves one account address and passes that same value to REST account queries and WebSocket user subscriptions. Signing still uses the configured private key, and vault trading still sends vaultAddress in the signed exchange payload when vault_address is set.

Explicit config values take precedence over environment variables. Environment variables fill only omitted config values.

Resolution order for the execution account address used by info queries and WebSocket subscriptions:

1. account_address (master account when using an agent wallet).
2. vault_address (vault sub-account).
3. HYPERLIQUID_ACCOUNT_ADDRESS.
4. HYPERLIQUID_VAULT or HYPERLIQUID_TESTNET_VAULT.
5. The address derived from the private key (the wallet itself).

Vault trading

Hyperliquid supports vault trading, where a wallet operates on behalf of a vault (sub-account). Orders are signed with the wallet's private key but include the vault address in the signature payload.

To trade via a vault, set the vault_address in your execution client config (or set the HYPERLIQUID_VAULT / HYPERLIQUID_TESTNET_VAULT environment variable).

Funding rates

Hyperliquid perpetual futures use a fixed 1-hour funding interval. The adapter sets interval to 60 (minutes) on all FundingRateUpdate objects.

Rate limiting

The adapter implements a token bucket rate limiter for Hyperliquid's REST API with a capacity of 1200 weight per minute. HTTP info requests are automatically retried with exponential backoff (full jitter) on rate limit (429) and server error (5xx) responses. For WebSocket post trading requests, the adapter caps simultaneous inflight messages at 100 to match the venue limit.

Configuration

Data client configuration options

Execution client configuration options

Configuration example

from nautilus_trader.adapters.hyperliquid import HYPERLIQUID
from nautilus_trader.adapters.hyperliquid import HyperliquidDataClientConfig
from nautilus_trader.adapters.hyperliquid import HyperliquidExecClientConfig
from nautilus_trader.adapters.hyperliquid import HyperliquidProductType
from nautilus_trader.config import InstrumentProviderConfig
from nautilus_trader.config import TradingNodeConfig

config = TradingNodeConfig(
    data_clients={
        HYPERLIQUID: HyperliquidDataClientConfig(
            instrument_provider=InstrumentProviderConfig(load_all=True),
            product_types=(
                HyperliquidProductType.PERP,
                HyperliquidProductType.PERP_HIP3,
            ),
            environment=HyperliquidEnvironment.TESTNET,
        ),
    },
    exec_clients={
        HYPERLIQUID: HyperliquidExecClientConfig(
            private_key=None,  # Loads from HYPERLIQUID_TESTNET_PK env var
            vault_address=None,  # Optional: loads from HYPERLIQUID_TESTNET_VAULT
            instrument_provider=InstrumentProviderConfig(load_all=True),
            product_types=(
                HyperliquidProductType.PERP,
                HyperliquidProductType.PERP_HIP3,
            ),
            environment=HyperliquidEnvironment.TESTNET,
            normalize_prices=True,  # Rounds prices to 5 significant figures
        ),
    },
)

Then, create a TradingNode and add the client factories:

from nautilus_trader.adapters.hyperliquid import HYPERLIQUID
from nautilus_trader.adapters.hyperliquid import HyperliquidLiveDataClientFactory
from nautilus_trader.adapters.hyperliquid import HyperliquidLiveExecClientFactory
from nautilus_trader.live.node import TradingNode

# Instantiate the live trading node with a configuration
node = TradingNode(config=config)

# Register the client factories with the node
node.add_data_client_factory(HYPERLIQUID, HyperliquidLiveDataClientFactory)
node.add_exec_client_factory(HYPERLIQUID, HyperliquidLiveExecClientFactory)

# Finally build the node
node.build()

Contributing