> ## Documentation index > Fetch the complete documentation index at: https://docs.predictefy.com/llms.txt > Use it to discover every available page before exploring further. # Hyperliquid > The build request schema, signing scheme, and bounds for Hyperliquid. ## Step zero — from nothing to your first trade 1. **Create the account.** Go to [hyperliquid.xyz](https://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: ```json { "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: ```ts 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: ```json { "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.