Hyperliquid & HIP-3 Agent Trading in 2026: API Wallets, Namespace Routing, and Zero-Custody Execution

Hyperliquid and HIP-3 agent trading in 2026: API wallets, namespace routing, funding risk, Spot/perps, and FarmDash zero-custody execution.

TLDR: Hyperliquid is unusually well suited to programmatic trading, but an agent still has to keep four identities straight: the master or sub-account whose state it reads, the API wallet that signs venue actions, the exact market namespace it is targeting, and the FarmDash authority mode that permits the action. FarmDash separates research, commercial access, simulation, authority, signing, submission, and reconciliation. USER_SIGNED is the default for one-off futures actions; BOUNDED_AUTONOMOUS is separately opt-in, owner-authorized, policy-bounded, revocable, and still locally signed by the customer's API wallet. FarmDash never receives the raw private key. Check /api/v1/agent/status before assuming any route is executable.

Hyperliquid has evolved from a single perpetual-futures venue into a broader HyperCore market system with native perpetuals, Spot markets, builder-deployed HIP-3 perpetual DEXs, and a distinct HIP-4 outcome-market design. That breadth is useful for AI agents, but it also creates more ways to route an order to the wrong venue, query the wrong account, misread funding, or confuse API access with execution authority.

This guide focuses on those failure boundaries and on how FarmDash composes Hyperliquid research and execution without taking custody.

How Do Autonomous AI Agents Trade on Hyperliquid Without Custody Risk?

An autonomous agent can trade Hyperliquid without handing custody to FarmDash by separating the account that owns capital from the local signer authorized to act on that account.

Hyperliquid's API-wallet model allows a delegated agent wallet to sign supported trading actions on behalf of a master or sub-account. The important operational distinction is that account-state queries still use the actual master or sub-account address. Hyperliquid's own API documentation warns that querying user state with the agent-wallet address is a common cause of empty results.

FarmDash adds a second boundary on top of the venue model:

FarmDash does not receive the customer's raw private key.
Commercial access is not transaction authority. An API key, subscription, session, Scout allowance, or x402 payment can change API capacity; none of them creates a Hyperliquid signature or delegation.
USER_SIGNED is the default futures mode. The customer or customer-controlled agent runtime signs each Hyperliquid action locally; FarmDash verifies the signed action and applies the runtime risk and research gates before forwarding.
BOUNDED_AUTONOMOUS is opt-in. The owner authorizes a revocable futures policy with explicit scopes and quantitative limits. The customer's API wallet still signs every action locally; FarmDash never receives that key.
Research is not authority. A funding scan, strategy analysis, workflow plan, or static guide can recommend an action without granting permission to perform it.

The live source of truth is /api/v1/agent/status. The current machine contract exposes both futures authority modes as operational, subject to venue ownership, local signatures, policy scope, builder approval where applicable, durable nonce/budget controls, and the required risk/research gates.

What Is the Difference Between Native Perps, Spot, HIP-3, and HIP-4?

Treat these as separate market families rather than a flat ticker list.

Market family	Typical identity	What an agent must verify	Key schema difference
Native validator-listed perpetuals	`BTC`, `ETH`, `SOL`, `HYPE`	Native perp metadata, leverage, funding, OI caps, margin mode	Perpetual context includes funding, oracle/mark prices, open interest
HIP-3 builder perpetuals	Namespaced, for example `xyz:XYZ100`	Builder DEX name, exact coin namespace, collateral, oracle, leverage and margin rules	Same HyperCore trading system, but market identity is builder-scoped
Spot	Pair/index identity from `spotMeta`	Spot pair/token indices and any UI remapping	No perpetual funding or liquidation schema
HIP-4 outcome markets	Outcome-market identity	Current deployment/readiness and outcome-specific settlement rules	Do not reuse perpetual funding or liquidation assumptions

For market-wide reads, Hyperliquid's public POST /info endpoint is the main discovery surface. Useful request types include:

Purpose	Request shape	Why it matters
Mid prices	`{"type":"allMids","dex":""}`	Fast price snapshot; `dex` selects a perp DEX
Perp metadata	`{"type":"meta","dex":""}`	Resolve a perp DEX universe, precision and margin tables; the empty DEX name is the canonical/default perp DEX
Default perp metadata + context	`{"type":"metaAndAssetCtxs"}`	Mark/oracle price, funding, OI, premium and volume for the default perp universe
Builder DEX discovery	`{"type":"perpDexs"}`	Discover HIP-3 perp DEX identities before resolving a builder market
Spot metadata	`{"type":"spotMeta"}`	Resolve Spot universe and token indices
L2 order book	`{"type":"l2Book","coin":"BTC"}`	Inspect book depth for an exact market identity; HIP-3 coin names remain namespaced
Funding history	`{"type":"fundingHistory", ...}`	Historical hourly funding observations for the exact coin identity

Do not hard-code a market count into an autonomous strategy. Hyperliquid's live universe changes. Discover it at runtime, preserve the returned identifiers, and bind the selected DEX and coin through quote, simulation, signing, and reconciliation.

What does HIP-3 change?

HIP-3 lets qualifying builders deploy perpetual DEXs on HyperCore. The deployer is responsible for market definition and operation, including oracle configuration and market parameters, while the resulting markets use HyperCore's order-book and margining infrastructure.

The current mainnet staking requirement documented for HIP-3 is 500,000 HYPE, with the protocol retaining slashing mechanisms around deployer operation. Those requirements can change, so an agent should never use a static blog post as the operational source of truth for a deployer decision.

For traders, the more important consequence is namespace and venue identity: a builder market is not interchangeable with a same-looking native ticker.

What about HIP-4?

HIP-4 defines outcome markets as a distinct product family. FarmDash treats them separately from perpetuals because an outcome contract should not inherit perpetual-specific assumptions such as hourly funding, perpetual liquidation mechanics, or a perp strategy's position-management loop. Check current Hyperliquid deployment documentation before assuming a particular HIP-4 market is available in the environment you are targeting.

Why Do Trading Bots Route Orders to the Wrong HIP-3 Asset?

The most common mistake is destroying namespace information too early.

Hyperliquid's current API documentation shows HIP-3 fills with a namespaced coin such as xyz:XYZ100. A bot that converts that into XYZ100, matches by substring, or searches only the native perp universe can silently resolve the wrong market.

A safer resolver keeps a compound identity:

market_family
perp_dex
canonical_coin
collateral
margin_mode

Then it carries that identity through every stage.

For example:

HIP-3
→ dex = "xyz"
→ coin = "xyz:XYZ100"
→ metadata resolved for dex "xyz"
→ risk parameters captured
→ exact action simulated
→ exact locally signed action submitted
→ fill reconciled against the same dex + coin identity

Do not reconstruct the namespace from a display ticker after the fact.

Spot has a different identity problem. Hyperliquid's API documentation notes that Spot may use @{index} identifiers and that some assets are remapped in frontends. The API identity, not the UI label, should drive machine execution.

Why Do API Wallets Return Empty Account State or Nonce Errors?

Two implementation mistakes account for many apparently mysterious failures.

1. Reading state from the signer address

For user-specific /info calls, query the master or sub-account address whose state you want. Hyperliquid explicitly documents that using an agent-wallet address for account data can return an empty result.

That means your runtime should keep these concepts separate:

account_read_address = master or sub-account
action_signer = authorized API wallet

Do not infer one from the other.

2. Treating nonces as disposable timestamps

Hyperliquid uses signer-scoped nonce rules for signed actions. A production agent should centralize nonce generation, avoid parallel workers racing the same signer, and reconcile the result of every state-changing request before blindly retrying.

A safe local signer should also maintain:

one owner/account relationship per configured signer;
an explicit venue/environment boundary;
durable request/idempotency state above the venue where FarmDash provides it;
no log line containing the raw private key;
revocation procedures for unused or suspected API wallets.

If a signer is compromised, treat that as a trading-risk incident even when the venue's authority model separates trading from master-account withdrawal actions. A malicious signer can still place harmful orders, consume margin, or create liquidation risk. Revoke it and rotate credentials rather than relying on the absence of an arbitrary withdrawal path.

How Does FarmDash Orchestrate a Zero-Custody Hyperliquid Workflow?

FarmDash can compose the Hyperliquid workflow as Sense → Decide → Guard → Authorize → Verify.

1. Sense

Use read-only intelligence before requesting authority:

Trail Intelligence 3.1.3 for protocol and opportunity context;
Wagon Steward 0.7.2 for position health, portfolio summary, idle capital and capital efficiency;
Futures Strategist 3.4.0 for funding scans, market conditions, account context, strategy analysis and position sizing.

The live MCP surface contains 94 tools, but tool discovery alone never proves an operation is currently executable.

2. Decide

Trail Marshal 1.1.2 can select or plan a multi-skill workflow. A workflow plan is orchestration state, not wallet authority. Each state-changing step still belongs to its owning tool and runtime gate.

A delta-neutral design, for example, may combine:

spot quote
→ spot simulation
→ spot local signature / preparation
+
perp funding + market analysis
→ perp position sizing
→ perp local EIP-712 signature

The two legs must be treated independently until both are reconciled. A plan is not a guarantee that either leg will fill.

3. Guard

Camp Guard 1.1.2 provides preflight risk checks. Futures Strategist separately applies the Hyperliquid-specific research, risk, signature and order-control gates.

For a new-risk futures order, current FarmDash runtime truth requires a recent authoritative research record. Reduce-only and cancellation paths have different safety semantics; do not force a new-risk workflow onto an emergency risk-reduction action.

4. Authorize

There are two explicit futures modes.

USER_SIGNED

default for one-off use;
customer signs each exact Hyperliquid action locally;
FarmDash receives the signed action, not the private key;
FarmDash verifies the action and runtime gates before forwarding.

BOUNDED_AUTONOMOUS

opt-in and separately authorized;
owner signs a bounded futures policy;
scopes can cover actions such as open, reduce, close, cancel, and protective orders;
policy limits remain revocable and quantitative;
the customer's API wallet signs each Hyperliquid action locally;
FarmDash still holds no private key.

Do not describe a subscription, API token, x402 payment, or workflow session as a substitute for either authority path.

5. Verify

Submission acknowledgement is not final settlement.

After a futures action, reconcile the order/venue result and then update higher-level state. Wagon Steward can re-read position health; Ledger Keeper 1.1.2 can record FarmDash-observed activity according to its data contract.

For cross-leg strategies, never mark the strategy complete simply because one leg returned an acknowledgement. Reconcile both legs, funding exposure, realized fees, and remaining directional risk.

Which Hard-Coded Safety Guards Should a Hyperliquid Agent Enforce?

Risk limits belong in deterministic code, not only in an LLM prompt.

The values below are illustrative starting points for a conservative strategy template, not FarmDash runtime defaults and not individualized trading advice. A production operator should set them from its own mandate, capital, liquidity, venue constraints, and risk tolerance.

Guard	Illustrative starting point	Enforcement idea
Maximum single-position allocation	10% of portfolio	Reject new risk above the configured per-market cap
Total perp exposure	50% of portfolio	Sum open notional/margin exposure before each new-risk action
Free-collateral reserve	20%	Halt new exposure when available collateral falls below the configured floor
Strategy leverage cap	10x; often 2x–3x for carry	Use the lower of venue maximum and policy maximum
Stop-loss requirement	5% adverse move	Require an explicit protective plan for strategies that mandate one
Per-position loss breaker	-20% unrealized	Trigger the operator's risk-reduction workflow
Daily drawdown breaker	-10% account equity	Freeze new-risk actions for the configured cooling period

The important property is not the exact percentage. It is that an LLM cannot negotiate the limit away at runtime.

A robust agent should also enforce:

maximum order size;
maximum slippage;
maximum cumulative daily notional;
maximum funding cost;
allowed DEX/coin namespaces;
allowed collateral assets;
reduce-only semantics for emergency actions;
stale-research rejection;
signer/account binding;
cancellation and reconciliation timeouts.

How Should Agents Evaluate HIP-3 Rebates, Points, and HyperEVM Opportunities?

Separate realized economics from speculative reward expectations.

For any builder venue or ecosystem campaign, ask:

What is verifiably live today?
Which exact market or venue qualifies?
What fee/rebate applies to this user's actual order?
What are the funding, spread, slippage, and liquidation costs?
Is any future token or points conversion actually documented?
Is the user eligible in their jurisdiction?
Can the strategy remain profitable if the speculative reward is worth zero?

A simple accounting frame is:

net farming cost
=
maker/taker fees
+ spread
+ slippage
+ net funding paid
+ realized trading loss
- realized fee rebates

Keep unpriced points or future token expectations outside realized PnL.

Entropy and other HIP-3 builders

Entropy is relevant because it illustrates builder-specific economics: a fee/rebate program can be real even when a future token thesis is speculative. Verify the current first-party rebate rules and make sure the instrument you trade is actually part of the qualifying builder venue.

Likewise, FarmDash directory coverage of a HyperEVM or Hyperliquid ecosystem project is research coverage, not proof of a live reward season, execution adapter, or positive expected return. Use current first-party rules and the live FarmDash status contract before acting.

Why Does Hourly Funding Matter So Much for Hyperliquid Agents?

Hyperliquid computes an 8-hour funding rate but settles funding every hour at one eighth of that computed rate. Hyperliquid's documentation also states that funding is capped at 4% per hour.

That cadence matters to automated strategies because a seemingly attractive carry can reverse quickly. An agent should therefore measure:

current funding;
recent funding history;
predicted funding where available;
basis/premium;
holding horizon;
expected fees and slippage;
liquidation distance;
the effect of funding on account equity.

Do not annualize a single hourly observation and treat it as guaranteed yield.

For delta-neutral strategies, funding should be part of the decision at every rebalance, not a static assumption made when the position opens.

Frequently Asked Questions

Does Futures Strategist analysis mean FarmDash can automatically execute my Hyperliquid trade?

No. Analysis does not grant authority.

Current FarmDash runtime truth exposes two operational futures modes: USER_SIGNED, where the customer signs each action locally, and opt-in BOUNDED_AUTONOMOUS, where an owner-signed futures policy constrains a customer-controlled API wallet that still signs each action locally. Both remain subject to live venue, research, risk, nonce, policy and reconciliation gates.

Check /api/v1/agent/status immediately before relying on execution readiness.

Can a leaked Hyperliquid API wallet key harm my account?

Yes.

Even when the venue separates an API wallet's trading authority from master-account withdrawal actions, a compromised trading signer can place bad orders, use margin, create losses, or push positions toward liquidation. Revoke suspected API wallets, rotate the signer, and reconcile account state immediately.

Why does querying my API wallet address return no positions?

Because user-state reads belong to the master or sub-account whose positions you are querying. Hyperliquid's API documentation explicitly identifies use of the agent-wallet address as a common cause of empty account results.

How should an agent identify an HIP-3 market?

Discover the builder DEX and preserve the exact namespaced coin returned by the API, such as xyz:XYZ100. Bind the DEX plus coin through metadata lookup, strategy analysis, signing, submission and reconciliation. Never strip the prefix and later reconstruct the venue from a display ticker.

Is HIP-3 the same thing as HyperEVM?

No. HIP-3 is a HyperCore mechanism for builder-deployed perpetual DEXs. HyperEVM is Hyperliquid's EVM environment. A strategy can involve both ecosystems, but their execution, state, contracts and risk boundaries are not interchangeable.

Does paying FarmDash through x402 grant trading authority?

No. x402 is commercial access. It can unlock API capacity for an eligible call, but it cannot create a Hyperliquid signature, owner policy, delegation, account relationship, research record, builder approval, or risk clearance.

Primary Sources and Runtime Contracts

For current Hyperliquid mechanics, prefer the protocol's own documentation:

For current FarmDash capability truth:

FarmDash currently exposes 94 MCP tools, 54 operations in the primary OpenAPI contract, 75 operations across 4 OpenAPI documents, and 10 OpenClaw skills. These are build-derived documentation facts, not execution authority.