Step zero — from nothing to your first trade

1. Create the account. Go to hyperliquid.xyz and connect a Hyperliquid EVM master wallet. The wallet is the account identity; the repository sources do not document a separate KYC step.
2. Set up signing. If this is your first on-chain venue, create an EVM wallet first and secure its seed phrase offline. Use the master key directly or approve an agent key. Predictefy never sees either private key; signing stays in your process.
3. Fund it. Deposit USDC into Hypercore spot, Hyperliquid’s own L1 clearinghouse. Fund at least the price × size of your first order; the historical Bridge2 fallback rejects deposits below 5 USDC. Use GET /v1/bridge/quote to price cross-chain funding, then create a bridge session for the assisted deposit. HIP-4 orders spend spot USDC directly.
4. Allow time. Budget about 1–2 hours for a first wallet and bridge; an already-funded wallet can be ready much sooner. Confirm venue eligibility for your location before depositing.

What you need first

• Production status: Armed for build, submit, cancel, single-order modify, and approveAgent as verified on 2026-08-15.
• Wallet and chain: A Hyperliquid EVM master wallet, or an EVM agent approved by that master, signs the Hyperliquid L1 action in the caller’s process.
• Venue account: The master wallet is the account identity. Approve an agent first when a browser or mobile wallet will not sign each order directly.
• Credentials: No venue API credential. The master or agent private key remains client-side and never transits Predictefy.
• Funding: Spendable Hypercore spot USDC (total - hold). POST /v1/bridge/session can deliver USDC to that spot balance; first-party HIP-4 orders need no internal transfer.
• Getting funds out: Only through Hyperliquid’s own withdraw3 action, which reaches Arbitrum and nowhere else — that action is the venue’s Arbitrum bridge, so the destination chain is not a caller choice. client.funding.buildWithdrawRequest builds the EIP-712 data against the Arbitrum domain and stops there; you sign and POST it to Hyperliquid yourself. Any other chain is a second leg: withdraw to Arbitrum, then bridge onward with GET /v1/bridge/quote.

Field	Type	Required	Rejection
asset	non-negative integer	this or outcome + outcomeSide	asset must be a non-negative integer
outcome	non-negative integer	with outcomeSide	provide asset, or outcome + outcomeSide (YES|NO)
outcomeSide	"YES" or "NO"	with outcome	same message
isBuy	boolean	yes	isBuy (boolean) is required
price	number in (0, 1] dollars	yes	price must be a number in (0, 1] dollars
size	number > 0	yes	size must be a number > 0
owner	0x… EVM address	yes	owner (the wallet that will sign this action) is required
tif	Alo | Ioc | Gtc (default Gtc)	no	tif must be Alo, Ioc, or Gtc
trigger	object, mutually exclusive with tif	no	provide either tif (limit) or trigger (tp/sl), not both
trigger.triggerPx	number in (0, 1] dollars	with trigger	trigger.triggerPx must be a number in (0, 1] dollars
trigger.tpsl	"tp" or "sl"	with trigger	trigger.tpsl must be "tp" or "sl"
trigger.isMarket	boolean (default true)	no	trigger.isMarket must be a boolean when provided
nonce	safe positive integer (default: ms clock)	no	nonce must be a safe positive integer
expiresAfter	safe positive integer	no	expiresAfter must be a safe positive integer
cloid	0x + 32 hex chars (128-bit)	no	Hyperliquid cloid must be a 128-bit hex string (0x followed by 32 hex characters). — auto-derived when omitted, so every order carries one
reduceOnly	boolean (default false)	no	—

A HIP-4 outcome resolves to asset = 100000000 + 10 × outcome + (YES → 0, NO → 1). These are spot-class assets with no perp-DEX component. On a unified account, their collateral is spendable spot USDC: total - hold from spotClearinghouseState. The spend-cap and funding target are price × size; current Hyperliquid documentation says outcome fees are zero.

Every HIP-4 order build makes the collateral location explicit:

{ "collateral": { "ledger": "spot", "destinationDex": null } }

The SDK convenience path validates that descriptor before signing. Default-on autoFund is a typed no-op because the source and destination ledgers already match:

const signer = makeHyperliquidSigner({
  privateKey: process.env.HL_AGENT_PRIVATE_KEY!,
  agentFor: process.env.HL_MASTER_ADDRESS!,
});

const result = await client.exec.createOrder(
  {
    venue: 'hyperliquid',
    outcome: 1081,
    outcomeSide: 'YES',
    isBuy: true,
    price: 0.5,
    size: 25,
    owner: signer.owner,
  },
  signer,
);

result.funding;
// {
//   status: 'not_required',
//   reason: 'collateral_destination_matches_source',
//   collateral: { ledger: 'spot', destinationDex: null }
// }

It does not call the funding route, read a default-perp balance, sign sendAsset, or move funds. Pass { autoFund: false } as argument three only if you also want to omit the SDK-only funding result. autoFundMax is reserved for a future named builder DEX whose destination genuinely differs from spot; it has no effect on first-party HIP-4 orders.

REST callers can inspect readiness with POST /v1/funding/hyperliquid/steps. The route reads only spot state and always returns zero steps for first-party HIP-4. For the funded tester case — 11 USDC spot and a 28 at 0.40 order — it returns:

{
  "readiness": {
    "spotUsdcBalance": "11",
    "targetAmount": "11.2",
    "shortfall": "0.2"
  },
  "reason": "insufficient_spot_usdc",
  "steps": []
}

Without a target, reason is readiness_only; with a sufficient target it is collateral_already_in_place. Funding signing and submission refuse every sendAsset today. A future named destinationDex requires an explicit venue-verified destination, collateral token, and mainnet deployer allowlist entry. Predictefy exposes no hosted send-asset endpoint and never changes account abstraction automatically.