Deposits & Withdrawals

Funding configuration

GET /config

The single source of truth for deposit destinations and withdrawal thresholds. Live response:

1
{
2
  "data": {
3
    "deposit": {
4
      "hypercore": { "address": "0xa386bd71eaf18efc401bf86a559e1052cf43a60e", "min_amount": "1" },
5
      "arbitrum": { "min_amount": "5" }
6
    },
7
    "withdrawal": { "min_amount": "10", "new_wallet_fee": "1" },
8
    "trader_share": 0.5
9
  },
10
  "success": true,
11
  "timestamp": 1787067314951
12
}

• deposit.hypercore.address — the trading address every user deposits to via a Hyperliquid spot transfer; the sender’s wallet determines which account is credited. Always read this address from /config at runtime — never hardcode it.
• trader_share — the fee-savings split (0.5 = 50% of the venue-fee saving is rebated to the trader).

Track deposits

GET /account/{account}/deposit-history

{account} is the 32-byte account id (a 20-byte wallet address is rejected). Params: limit, offset, from, to. Returns data: { account, deposits: [] } — detected deposits, newest first: tx_hash, amount, source (send | spotTransfer | internalTransfer), status ∈ DETECTED → CONFIRMED (or BELOW_MIN), with detected_at / credited_at timestamps. Poll this to track a just-sent deposit to credit.

Request a withdrawal

POST /account/withdraw

Withdrawals are signed by your main wallet (never the trading key) as Withdraw(address user,address destination,uint256 amount,string hyperflowEnvironment,uint256 nonce):

• destination — your own wallet for the default HyperCore rail, or the EVM recipient for the Arbitrum rail.
• amount — USDC base units (6 decimals): 25 USDC signs as 25000000.

Body (signature split into {r, s, v} components):

1
{
2
  "account_id": "0x<wallet 40 hex>000000000000000000000000",
3
  "amount": "25",
4
  "signature": { "r": "0x…32 bytes…", "s": "0x…32 bytes…", "v": 27 },
5
  "nonce": "1787067314957",
6
  "signature_chain_id": 999
7
}

• Body amount is a decimal string (max 6 dp); the signed amount is the same value in base units.
• On the default HyperCore rail, don’t send a destination field — sign your own wallet address as destination; the server verifies against it.
• Arbitrum (EVM) rail: add destination_chain_id (42161 mainnet / 421614 testnet) and destination_recipient (the signed destination). The EVM rail is offered only to email/embedded-wallet accounts; a normal EOA withdraws to its own HyperCore wallet.

Response and lifecycle

A valid request returns status: "REQUESTED" with a withdrawal_id; an inline validation failure returns status: "REJECTED" with reason ∈ BELOW_MIN, ABOVE_MAX, RATE_LIMITED, DAILY_LIMIT_EXCEEDED, BELOW_MIN_AFTER_FEE.

Poll the lifecycle:

GET /withdrawal-history/{withdrawalId}
GET /account/{account}/withdrawal-history?limit=&offset=&from=&to=

{account} is the 32-byte account id. The list returns data: { account, withdrawals: [] } with items withdrawal_id, amount, l1_send_amount, destination, status, failure_reason, l1_tx_hash, created_at, completed_at.

REQUESTED → ACCEPTED → PROCESSING → COMPLETED
          → REJECTED  (insufficient balance verdict is async — seen here, not inline)
          → REFUNDED  (debited then returned to your balance)
          → FAILED

Completed withdrawals carry l1_send_amount (net of any new-wallet fee) and l1_tx_hash. Every withdrawal passes the platform’s 2-of-4 multisig review between ACCEPTED and COMPLETED.