Hyperliquid HIP-3: builder-deployed perpetuals

In Part 1, we established the architectural thesis behind Hyperliquid. A fully onchain order book cannot behave like a centralized exchange if every order, cancel, and liquidation has to pass through a generic virtual machine.

In Part 2, we went inside HyperCore. We traced HyperBFT finality, spot and perpetual accounting, sub-accounts, and the lifecycle of a trade from signed action to L1 state transition.

In Part 3, we crossed the boundary between HyperEVM and HyperCore. Precompiles gave Solidity a native read path into exchange state. CoreWriter gave contracts a constrained write path back into the financial state machine.

Now we reach the next architectural question.

Who decides which markets that financial state machine should run?

Historically, the answer was the core protocol team. HIP-3 changes that. A builder who satisfies the deployment requirements can create a separate perpetual DEX inside HyperCore, define markets, update their oracles, choose margin parameters, cap open interest, and eventually halt or settle trading.

The matching engine is still HyperCore. The orders are still HyperCore actions. The balances and positions are still native L1 state. But the meaning and operation of a market can now come from an external deployer.

HIP-3 leaves the clearinghouse in place while introducing a new trust boundary inside it.

A Market Is More Than a Ticker

It is tempting to describe HIP-3 as permissionless listings. That description captures the direction of the design, but it hides both the protocol gates and the state being created.

A deployer still has to satisfy the current staking and deployment requirements. More importantly, deployment does not add a token symbol to a frontend menu. It creates a new perpetual market inside HyperCore.

A perpetual contract gives traders long or short price exposure without a fixed expiration date.

Unlike a dated futures contract, it does not automatically settle on a predetermined day. A position can remain open while the trader satisfies the market’s margin requirements. Funding payments help manage persistent differences between the perpetual price and its reference price. If the trader’s collateral can no longer support the position, HyperCore can liquidate it.

The underlying does not have to be a cryptocurrency.

For example, CRDO is the stock ticker associated with Credo Technology, a company that provides high-speed connectivity products for data centers and network infrastructure. The live annotation for para:CRDO (will be explained below) says that the market tracks the value of one Credo share.

A para:CRDO position does not provide equity ownership, voting rights, custody of shares, or direct access to the underlying company. It is a collateralized perpetual derivative. Its profit and loss depend on the market’s price process, position size, funding, and margin state.

This is what makes the full market name important.

The market identifier is not simply CRDO. It is para: CRDO.

The para prefix identifies the builder-deployed DEX. CRDO identifies an asset registered inside that DEX (read more here). Another deployer could register the same short symbol inside a different namespace and create a separate market with a different asset ID, oracle process, order book, margin configuration, and lifecycle.

The full {dex}:{coin} name is therefore part of the market’s identity.

That identity connects four layers of state:

• Market definition: the DEX namespace, collateral token, asset annotation, oracle updater, and size precision.
• Price formation: the oracle price, optional mark inputs, local order-book state, update timing, and mark-price constraints.
• Risk configuration: the margin table, margin mode, leverage boundaries, and open-interest caps.
• Economic lifecycle: funding inputs, fees, halting, and final settlement.

HIP-3 gives the deployer authority over important inputs in those layers. It does not give the deployer a separate matching engine or independent accounting system.

Orders still enter HyperCore. HyperCore still maintains the order book, matches trades, records positions, applies margin accounting, performs liquidations, enforces protocol constraints, and processes settlement actions.

The deployer supplies the market-specific configuration and operates the price process that gives the contract its economic meaning.

This creates two distinct trust domains.

You trust HyperCore to execute the configured rules consistently. You also trust the deployer and oracle updater to define a coherent market, submit defensible prices, select appropriate risk limits, and halt or settle the market responsibly.

That is the architectural change introduced by HIP-3. Market execution remains shared inside HyperCore, but market definition and part of the operational control plane move to the builder.

The right question is no longer only:

“Does Hyperliquid run this market?”

The better question is:

“What does this perpetual contract represent, which properties does HyperCore enforce, and which inputs does this deployer control?”

The HIP-3 Deployment Lifecycle

A HIP-3 market does not become operational through one permanent listing call. Deployment is a gated state machine. The builder must qualify to deploy, inspect the current auction, register the DEX and its first market, verify the resulting state, configure market-specific controls, and then operate the oracle for as long as the market remains live.

The lifecycle is easier to reason about as a sequence of protocol states:

satisfy the current stake requirement
→ inspect the deployment auction
→ submit registerAsset2 with the DEX schema and initial asset
→ verify the DEX namespace and market metadata
→ configure margin, funding, fees, and open-interest controls
→ maintain oracle and mark inputs
→ monitor deposits, limits, and market state
→ halt and settle the market when required

The hands-on section later in this article implements the read, construct, sign, submit, and verify boundaries separately so students can inspect every transition before it mutates testnet state.

Step 1: satisfy the current staking requirement

The current HIP-3 specification states that a mainnet deployer must maintain 500,000 staked HYPE. It currently says that the staking requirement is maintained for a minimum of 183 days after the DEX is deployed. The settlement section separately says that once all assets are settled, the deployer’s required stake is free to be unstaked. The documentation does not explicitly explain how an early settlement interacts with the 183-day minimum.

These are versioned protocol requirements, so a deployment tool should display the current requirement and link to the specification immediately before the action rather than silently hardcoding it.

Step 2: inspect the deployment auction

DEX creation is rate-limited through the perpetual deployment auction. Under the current rules, the first three assets in a deployed DEX do not require separate asset-auction participation. Later assets enter a Dutch auction shared across all builder-deployed perpetual DEXs.

The registerAsset2 documentation adds another path. A deployer currently receives seven reserve deployments. Setting maxGas to zero consumes one reserve deployment at the current auction price, even if the auction has not ended. The documentation therefore warns builders to query the auction before signing.

maxGas=0 is not a harmless default. Under the current action reference it consumes a reserve deployment at the current auction price. The testnet script later in this article refuses zero and queries the auction before signing.

The official SDK exposes that read through query_perp_deploy_auction_status(). The response includes the auction start time, duration, starting gas, current gas, and final gas once known.

Registration creates the DEX and first market together

The first deployment transition is more compact than the high-level diagram suggests. registerAsset2 can initialize a new DEX and register its initial asset in the same signed action.

The action carries two groups of state:

• schema defines the DEX, including its full name, collateral token, and oracle updater.
• assetRequest defines the market, including {dex}:{coin}, size decimals, initial oracle price, margin table, and margin mode.

If schema is omitted, the same action registers another asset in an existing DEX. The DEX name must currently contain two to four characters. The asset name follows the builder-perpetual format {dex}:{coin}, which is why the live market is para:CRDO rather than only CRDO.

A returned transaction response is not the end of the verification path. The builder should read the DEX back through perpDexs, then read the market through meta or metaAndAssetCtxs. The state transition is complete only when the expected namespace, market, margin configuration, and updater are discoverable through HyperCore information endpoints.

Registration is the beginning of operations

Once a market exists, the deployer can modify market-specific state through additional perpDeploy variants. The current deployer-action reference includes actions for:

• Funding multipliers and funding interest rates
• Margin tables and margin modes
• Open-interest caps
• Fee recipient and fee scale
• Oracle sub-delegation
• Growth mode and market annotation
• Trading halt and settlement

The oracle is the continuous part of the lifecycle. The documentation permits setOracle calls no more frequently than once every 2.5 seconds and expects an update every 3 seconds even when prices have not changed. After 10 seconds without an update, stale marks fall back to the local mark price. The docs explicitly say that builders should not rely on this fallback.

Settlement is also an explicit state transition. haltTrading cancels open orders and settles positions at the current mark price. The action can later resume trading, which allows the same asset slot to be recycled. This is why registration should not be described as permanent market availability. The deployer remains responsible for operating and eventually resolving the market.

The perpDeploy Action Envelope

Deployer operations use the exchange action interface. The outer action identifies the perpDeploy family, while the nested field selects the operation.

A market registration action follows this shape:

type PerpDeployAction =
  | { type: "perpDeploy"; registerAsset2: RegisterAsset2 }
  | { type: "perpDeploy"; setOracle: SetOracle }
  | { type: "perpDeploy"; haltTrading: HaltTrading }
  // Margin, funding, fees, limits, annotations, permissions, and other
  // operator actions are documented in the official current reference.

This abbreviated union shows only the variants used in this article. Consult the HIP-3 deployer-action reference for the current complete set.

The newer asset-registration structure is registerAsset2:

type RegisterAsset2 = {
  maxGas?: number
  assetRequest: {
    coin: string
    szDecimals: number
    oraclePx: string
    marginTableId: number
    marginMode: "strictIsolated" | "noCross" | "normal"
  }
  dex: string
  schema?: {
    fullName: string
    collateralToken: number
    oracleUpdater?: string
  }
}

collateralToken selects the asset traders use for margin and settlement. It is not a liquidity pool, and registering zqjx:DEMO does not create a spot token.

This structure already shows why a HIP-3 market is not merely a ticker.

coin defines the namespaced symbol. szDecimals controls size precision. oraclePx initializes the price domain. marginTableId selects the leverage and maintenance-margin schedule. marginMode constrains how trader collateral can be shared.

The optional schema field initializes DEX-level configuration. It carries the DEX’s full name, collateral-token index, and oracle-updater address. It does not define the economic contract behind an individual ticker.

Per-market display metadata belongs to setPerpAnnotation, which supports a category, description, display name. A serious interface should surface that annotation together with the DEX namespace and operator documentation rather than infer contract meaning from the short ticker alone.

The official Python SDK still exposes the older perp_deploy_register_asset helper, which serializes the older registerAsset variant. Because the current action reference documents registerAsset2, the lab below constructs and signs the raw current envelope explicitly. Inspect the installed SDK and the live action reference again before any production deployment.

The durable mental model is the signed action, not a particular helper method.

Hands-on HIP-3 lab on testnet

The safest way to teach HIP-3 is to separate reading, action construction, and state changes. Each example below shows the Python logic first and then the output captured from a real run.

To keep the article easy and readable, the snippets omit imports, command-line parsing, JSON formatting helpers, and repeated validation functions. The complete runnable programs will be linked in the GitHub repository at the end of the article.

Read a live HIP-3 market without a wallet

Start with a public testnet market. This code creates only an Info client. It does not load a wallet, sign an action, or submit a transaction.

TESTNET_API_URL = "https://api.hyperliquid-testnet.xyz"
dex_name = "test"
coin = "test:ABC"

info = Info(TESTNET_API_URL, skip_ws=True)

# Find the DEX and preserve its index because the index is part of the
# HIP-3 action asset ID.
dex_entries = info.perp_dexs()
dex_index, dex = next(
    (index, item)
    for index, item in enumerate(dex_entries)
    if isinstance(item, dict) and item.get("name") == dex_name
)

metadata, contexts = info.post(
    "/info",
    {"type": "metaAndAssetCtxs", "dex": dex_name},
)
universe = metadata["universe"]
market_index = next(
    index for index, item in enumerate(universe)
    if item["name"] == coin
)

limits = info.post("/info", {"type": "perpDexLimits", "dex": dex_name})
status = info.post("/info", {"type": "perpDexStatus", "dex": dex_name})
annotation = info.post("/info", {"type": "perpAnnotation", "coin": coin})
auction = info.query_perp_deploy_auction_status()

action_asset_id = 100_000 + dex_index * 10_000 + market_index

snapshot = {
    "network": "testnet",
    "auction": auction,
    "dex": dex,
    "market": {
        "actionAssetId": action_asset_id,
        "metadata": universe[market_index],
        "context": contexts[market_index],
        "annotation": annotation,
    },
    "limits": limits,
    "status": status,
}

print(json.dumps(snapshot, indent=2))

Output:

As we can see test is DEX index 1, and test:ABC is market index 0 inside that DEX:

asset = 100000 + perpDexIndex × 10000 + indexInMeta
      = 100000 + 1 × 10000 + 0
      = 110000

That 110000 value is what a normal HyperCore order action uses to route an order to this builder-deployed market.

Construct the current registerAsset2 and setOracle actions

Before a private key enters the workflow, build and inspect the exact wire actions.

dex = "demo"
coin = "demo:ASSET"
updater = "0x1111111111111111111111111111111111111111"

# HyperCore represents one HYPE as 100,000,000 native units.
max_gas_hype = Decimal("500")
max_gas_wei = int(max_gas_hype * Decimal("100000000"))

if max_gas_wei == 0:
    raise ValueError(
        "maxGas=0 consumes a reserve deployment at the current auction price"
    )

register_action = {
    "type": "perpDeploy",
    "registerAsset2": {
        "maxGas": max_gas_wei,
        "assetRequest": {
            "coin": coin,
            "szDecimals": 2,
            "oraclePx": "100.0",
            "marginTableId": 10,
            "marginMode": "strictIsolated",
        },
        "dex": dex,
        "schema": {
            "fullName": "Classroom Demo DEX",
            "collateralToken": 0,
            "oracleUpdater": updater.lower(),
        },
    },
}

oracle_action = {
    "type": "perpDeploy",
    "setOracle": {
        "dex": dex,
        "oraclePxs": sorted([(coin, "100.0")]),
        "markPxs": [sorted([(coin, "100.0")])],
        "externalPerpPxs": sorted([(coin, "100.0")]),
    },
}

print(json.dumps({
    "mode": "DRY_RUN",
    "submitted": False,
    "registerAction": register_action,
    "firstOracleAction": oracle_action,
}, indent=2))

Output:

The action reference expresses maxGas in native-token units. 1,000,000,000,000 units as 10,000 HYPE, corresponding to 100,000,000 units per HYPE. The 500 HYPE value above is a test cap, not a recommendation.

Query perpDeployAuctionStatus immediately before signing. Do not casually set maxGas to zero: the current action reference says that zero consumes a reserve deployment at the current auction price.

Make the expected read failure visible

A missing DEX should stop verification immediately. This is the core of the failure path:

missing_dex = "__missing_classroom__"
dex_entries = info.perp_dexs()

match = next(
    (
        item for item in dex_entries
        if isinstance(item, dict) and item.get("name") == missing_dex
    ),
    None,
)

if match is None:
    raise RuntimeError(
        f"DEX '{missing_dex}' was not returned by perpDexs on testnet"
    )

Output:

Preview registration against live testnet state

Only after the offline checks pass should you run the live testnet preflight.

private_key = os.environ["HIP3_TESTNET_PRIVATE_KEY"]
wallet = Account.from_key(private_key)

dex = "zqjx"
coin = f"{dex}:DEMO"
max_gas_hype = Decimal("500")
max_gas_wei = int(max_gas_hype * Decimal("100000000"))

info = Info(TESTNET_API_URL, skip_ws=True)

if any(
    isinstance(item, dict) and item.get("name") == dex
    for item in info.perp_dexs()
):
    raise RuntimeError(f"DEX '{dex}' already exists")

auction = info.query_perp_deploy_auction_status()
if Decimal(auction["currentGas"]) > max_gas_hype:
    raise RuntimeError("current auction gas exceeds the configured cap")

collateral = next(
    token for token in info.spot_meta()["tokens"]
    if token["index"] == 0
)

action = {
    "type": "perpDeploy",
    "registerAsset2": {
        "maxGas": max_gas_wei,
        "assetRequest": {
            "coin": coin,
            "szDecimals": 2,
            "oraclePx": "100.0",
            "marginTableId": 10,
            "marginMode": "strictIsolated",
        },
        "dex": dex,
        "schema": {
            "fullName": "Classroom Demo DEX",
            "collateralToken": collateral["index"],
            "oracleUpdater": wallet.address.lower(),
        },
    },
}

print(json.dumps({
    "mode": "DRY_RUN",
    "network": "testnet",
    "wallet": wallet.address,
    "auction": auction,
    "collateral": collateral,
    "action": action,
    "submitted": False,
}, indent=2))

Output:

This dry run prepares the registerAsset2 action that would create the zqjx HIP-3 DEX and register its first perpetual market, zqjx:DEMO. Before building the action, it verifies that the DEX name is available, checks that the current deployment-auction price does not exceed the 500 HYPE cap, and confirms that token index 0 is the selected collateral asset, currently USDC. It then prints the unsigned action as JSON without signing or submitting it.

A successful output confirms that the preflight checks passed and the action payload was constructed. We dont submit it here to the blockchain.

Sign and submit only after explicit confirmation

After reviewing the live auction and the complete action, sign with the testnet domain and submit the standard exchange payload:

expected = f"DEPLOY {coin}"
typed = input(f"Type '{expected}' to submit this TESTNET action: ")
if typed != expected:
    raise RuntimeError("submission cancelled")

nonce = get_timestamp_ms()
signature = sign_l1_action(
    wallet,
    action,
    None,
    nonce,
    None,
    False,  # is_mainnet=False selects the testnet signing domain
)

response = API(TESTNET_API_URL).post(
    "/exchange",
    {
        "action": action,
        "nonce": nonce,
        "signature": signature,
        "vaultAddress": None,
        "expiresAfter": None,
    },
)

print(json.dumps(response, indent=2))

Verify the state transition

A successful submission response is not sufficient. Read the namespace and market back from HyperCore:

dex = next(
    item for item in info.perp_dexs()
    if isinstance(item, dict) and item.get("name") == "zqjx"
)

metadata, contexts = info.post(
    "/info",
    {"type": "metaAndAssetCtxs", "dex": "zqjx"},
)
market_index = next(
    index for index, item in enumerate(metadata["universe"])
    if item["name"] == "zqjx:DEMO"
)

verified = {
    "dex": dex,
    "metadata": metadata["universe"][market_index],
    "context": contexts[market_index],
    "limits": info.post(
        "/info",
        {"type": "perpDexLimits", "dex": "zqjx"},
    ),
}

print(json.dumps(verified, indent=2))

Call the transition verified only when the expected namespace, market, updater, margin settings, context, and limits are returned. If no registration was submitted, do not manufacture this output.

Build and publish an oracle update

Construct the oracle action first and print it as a dry-run:

dex = "zqjx"
coin = "zqjx:DEMO"

oracle_action = {
    "type": "perpDeploy",
    "setOracle": {
        "dex": dex,
        "oraclePxs": sorted([(coin, "100.12")]),
        "markPxs": [sorted([(coin, "100.10")])],
        "externalPerpPxs": sorted([(coin, "100.11")]),
    },
}

print(json.dumps({
    "mode": "DRY_RUN",
    "network": "testnet",
    "iterations": 3,
    "intervalSeconds": 3.0,
    "action": oracle_action,
    "submitted": False,
}, indent=2))

Output:

Before publishing, verify that the DEX exists, the wallet is an authorized oracle updater, the market’s live szDecimals matches the price validation, and externalPerpPxs contains all assets.

Reading a Live Builder-Deployed DEX on Mainnet

We do not need deployer credentials to inspect HIP-3 state. The public /info endpoint exposes the read side.

First, enumerate builder-deployed DEXs:

curl -s https://api.hyperliquid.xyz/info \
  -H 'Content-Type: application/json' \
  -d '{"type":"perpDexs"}' | jq

One live response included the Paragon DEX:

{
  "name": "para",
  "fullName": "Paragon",
  "deployer": "0x8888888c43cbb7e1c4132542e46831bffd866ed3",
  "oracleUpdater": "0x8888888c43cbb7e1c4132542e46831bffd866ed3",
  "feeRecipient": "0x1770f43c71b8b2977771b73ca4c4cbe0c20412ed"
}

This object exposes the operating boundary directly. The deployer address controls deployer actions. The oracle-updater address controls the continuous price feed. The fee recipient receives the configured deployer fee share.

These roles can be separated. The HIP-3 specification recommends an oracle updater so the continuously active signing key does not need the same authority as the deployer key.

Now request market metadata and live contexts for that DEX:

curl -s https://api.hyperliquid.xyz/info \
  -H 'Content-Type: application/json' \
  -d '{"type":"metaAndAssetCtxs","dex":"para"}' | jq

The response is a two-element array. The first element contains DEX metadata and the asset universe. The second contains a context object for each asset at the same array index.

{
  "szDecimals": 2,
  "name": "para:CRDO",
  "maxLeverage": 10,
  "marginTableId": 10,
  "onlyIsolated": true,
  "marginMode": "strictIsolated",
  "growthMode": "enabled"
}

The context at the same index included:

{
  "funding": "0.0000440215",
  "openInterest": "1083.1",
  "dayNtlVlm": "367656.8567",
  "oraclePx": "230.6393",
  "markPx": "230.8112",
  "midPx": "230.835",
  "impactPxs": ["230.46", "231.21"]
}

These values are observations, not constants. The useful part is the state shape.

The metadata tells us what the market permits. The context tells us what the market is doing now. oraclePx anchors the external reference. markPx feeds the risk engine. midPx and impactPxs come from the local order book. Open interest and funding expose the current position and carry state.

Finally, inspect the DEX limits:

curl -s https://api.hyperliquid.xyz/info \
  -H 'Content-Type: application/json' \
  -d '{"type":"perpDexLimits","dex":"para"}' | jq

The same snapshot returned a total DEX open-interest cap of 50,000,000 and an explicit para:CRDO cap of 25,000,000.

This gives us an observable chain of responsibility:

Deployer configuration
→ asset metadata
→ continuous market context
→ DEX and asset limits
→ trader-visible HyperCore state

The API is not a marketing page. It is a debugger for the deployed market definition.

The Oracle Is the Operational Center

Registration is occasional. Oracle publication is continuous.

The deployer or delegated oracle updater sends setOracle actions:

type SetOracle = {
  dex: string
  oraclePxs: Array<[string, string]>
  markPxs: Array<Array<[string, string]>>
  externalPerpPxs: Array<[string, string]>
}

oraclePxs supplies the external reference price for each listed asset. markPxs supplies zero, one, or two additional mark inputs. externalPerpPxs provides a separate external perpetual-price input and must include every asset in the DEX.

The tuple arrays must be sorted by coin before signing. This is not cosmetic. Hyperliquid actions are signed over a deterministic serialization. If two implementations order the same economic data differently, they do not sign the same bytes.

A Python update using the current SDK can look like this:

oracle_pxs = {
    "demo:ASSET": "100.12",
}

mark_pxs = [{
    "demo:ASSET": "100.10",
}]

external_perp_pxs = {
    "demo:ASSET": "100.11",
}

result = exchange.perp_deploy_set_oracle(
    "demo",
    oracle_pxs,
    mark_pxs,
    external_perp_pxs,
)

The SDK converts these dictionaries into sorted tuple arrays before signing. If you construct the raw action yourself, you must perform that deterministic sorting explicitly.

Example of the SDK sorting:

The oracle price says what the underlying is worth according to the deployer’s reference process. The mark price says what value HyperCore will use for risk-sensitive calculations after applying its mark construction and constraints.

A stale or manipulated oracle can still create serious problems. It can distort funding, disconnect the market from the intended underlying, and push trading toward limits. HyperCore adds bounded behavior around the input, but it cannot prove that the deployer’s economic interpretation of an external asset is honest.

HIP-3 therefore creates two different security questions:

• Did HyperCore execute the submitted action correctly?
• Did the deployer submit a correct representation of the external market?

Consensus can answer the first question. It cannot answer the second by itself.

Funding Is Similar, but Not Identical

HIP-3 markets use the same broad purpose for funding as other perpetuals. Funding pressures the contract toward its reference price by transferring value between longs and shorts.

The funding documentation specifies a more responsive premium formula for HIP-3 markets:

premium = 0.5 × (impactBidPx + impactAskPx) / oraclePx - 1

Deployers can also configure funding multipliers and per-asset interest rates within the permitted ranges.

The premium is sampled through the hour and used in the hourly funding calculation. Funding is paid every hour. The payment uses position size multiplied by the oracle price and funding rate, not the mark price:

funding payment = position size × oracle price × funding rate

The oracle updater is not a background service that can be treated casually. Its submitted price affects more than a number in the UI. It participates in the economics that move value between open positions.

Trading Uses the Normal HyperCore Path

After deployment, traders do not send a special HIP-3 order type. They use the normal HyperCore order and cancel actions with the builder-deployed asset ID.

Builder-deployed names use the format:

{dex}:{coin}

For API actions, the asset-ID documentation defines the integer as:

asset = 100000 + perpDexIndex × 10000 + indexInMeta

For example, if a builder DEX has index 1 and the asset is the first entry in that DEX’s metadata, the action ID is:

100000 + 1 × 10000 + 0 = 110000

The namespace solves two problems.

First, two deployers can list different contracts with the same short ticker without colliding in API representation.

Second, HyperCore can route a standard order action to the correct builder-deployed order book.

The lifecycle becomes:

Trader signs a normal order action
→ asset ID selects the HIP-3 DEX and market
→ HyperCore validates margin and limits
→ the DEX order book matches the order
→ HyperCore updates positions, balances, and funding state

Summary

HIP-3 extends Hyperliquid at the market-definition layer.

A deployer can register a perpetual DEX, define assets, choose margin parameters, cap open interest, configure funding behavior, delegate oracle updates, and halt trading. Traders then interact with those markets through the same HyperCore order path used elsewhere on the L1.

The execution engine remains shared. The market’s operating inputs do not.

HyperCore determines how a valid order changes balances and positions. The deployer determines what the contract represents, which price process anchors it, how much leverage it permits, how much exposure it can accumulate, and when it must stop.

This separation defines the new trust boundary.

For builders, the opportunity is larger than permissionless listings. HyperCore becomes shared financial infrastructure for markets the core team did not define.

For traders and integrators, the review surface also becomes larger. It is no longer enough to trust the L1’s execution. You must understand the deployer whose inputs give a particular market its economic meaning.

The infrastructure side of that boundary

HIP-3 also makes one thing concrete: running a deployer is a continuous infrastructure job, not an occasional one.

The oracle updater has to publish at least every 3 seconds. Miss the 10-second stale window and marks fall back to local mark price — a fallback the docs explicitly tell builders not to rely on. Reading market state, monitoring open-interest caps, watching auction status: all of it is continuous polling against the same endpoint.

The public Hyperliquid endpoint is rate-limited to 100 requests per minute per IP. That is fine for prototyping and not close to fine for operating a live DEX.

Chainstack runs private Hyperliquid RPC endpoints that remove that ceiling. You get both HyperEVM paths (/evm for standard EVM traffic, /nanoreth when you need system transactions), plus /info and /exchange for the HIP-3 read and action flows this article walks through. Testnet nodes and a HYPE faucet are available for building deployer tooling before touching mainnet stake.

FAQ

Related reading

The Hyperliquid series

• Part 1: Architecture, clearinghouse, agent keys, cross-margin
• Part 2: HyperBFT, sub-accounts, spot and perpetual accounting
• Part 3: HyperEVM precompiles and the CoreWriter bridge

HIP context

• Hyperliquid HIPs explained: HIP-1 to HIP-4
• Hyperliquid HIP-4 vs Polymarket: outcome markets in 2026

Practical infrastructure

• Hyperliquid API guide: endpoints, SDK, and WebSocket