Skip to content
Zunder Guard docs

How integrations work

Guard listens on your machine and speaks Hyperliquid’s own HTTP API. So most tools need two changes and no new code:

  1. The API URL points at Guard instead of https://api.hyperliquid.xyz.
  2. The private key is the client key Guard gave you, not your API wallet key.
http://127.0.0.1:8547

The account address stays your real Hyperliquid account address.

What Guard does with each request

Section titled “What Guard does with each request”
RequestWhat Guard does
POST /info (prices, account, orders)passes it to Hyperliquid unchanged
POST /exchange, order that opens or grows a positionchecks the client signature and nonce, applies the nine rules, re-signs with the API wallet, sends
POST /exchange, order that reduces or closeschecks the client signature and nonce, re-signs, sends. Exits are never blocked
POST /exchange, stop moved closerpasses; moved further away: ignored (Stops only tighten)
POST /exchange, cancelpasses, unless it removes the last stop of an open position
POST /exchange, updateLeveragechecked against your leverage rules
Any action that moves funds or approves a key (withdraw3, usdSend, approveAgent, approveBuilderFee, …)refused. An API wallet cannot sign these anyway
WebSocket market datapassed through

A refusal comes back in Hyperliquid’s own error format, with a readable reason and a veto code. Tools that already handle Hyperliquid errors handle Guard’s.

Send the stop with the entry

Section titled “Send the stop with the entry”

Guard sizes from the stop, so it needs the stop when it judges the entry. Two ways count:

  • In the same request. Hyperliquid’s order action can carry an entry and its stop-loss together (grouping normalTpsl). Guard sizes the entry from that stop and resizes the stop with it.
  • Already resting. A stop that already protects the whole position in that coin (for example a position TP/SL) counts for an entry that grows the position.

An entry with neither is refused under the default rules (no_protective_stop). Placing the stop a moment after the entry, as many bots do, does not work behind Guard: the entry is judged before the stop exists.

One thing every tool does differently: the network in the signature

Section titled “One thing every tool does differently: the network in the signature”

Hyperliquid signatures carry the network: source "a" for mainnet, "b" for testnet. Tools decide which one to use in different ways:

ToolHow it picks the networkPointed at Guard, it signs as
Hyperliquid Python SDKbase_url == MAINNET_API_URL (hyperliquid/exchange.py)testnet ("b"), always
ccxtits sandbox modemainnet unless sandbox mode is on
@nktkas/hyperliquidthe transport’s isTestnetmainnet unless isTestnet: true

This does not matter for safety, because the client key is only valid at your Guard and Guard signs the real order itself, for the network Guard is set to. So Guard is planned to accept a client signature with either source. The network your orders reach is decided by Guard’s config, never by the bot.

Guides

Section titled “Guides”