Hyperliquid CLI (with HIP3 Support)

**Judgement:** A powerful, feature-rich CLI for Hyperliquid that is well-suited for advanced, supervised trading agents but carries significant financial and key-management risk. Best used by experienced users with strict safeguards and preferably on testnet during development. **What it does well** - Covers the core lifecycle of trading on Hyperliquid: market discovery (`hl markets ls`), order placement (spot & perps, limit & market), leverage configuration, cancellations, and real-time monitoring of positions, orders, balances, and portfolios. - Supports HIP3 traditional assets (AAPL, NVDA, TSLA, GOOGL, GOLD, SILVER, etc.) with the same interface as crypto perps, which is valuable for multi-asset strategies. - Offers a server mode with persistent WebSockets and in-memory caching, giving a plausible path to low-latency/high-frequency trading in an agent context. - Provides agent-friendly output via `--json`, enabling robust parsing of responses and integration into automated workflows. - Documentation is relatively complete and task-oriented, with explicit examples for account management, trading, and monitoring. **Key risks / limitations** - **High financial risk:** The skill can place leveraged trades (up to 50x per documentation). Misconfigured or autonomous agents can rapidly incur large real-money losses. - **Private key handling:** Requires a Hyperliquid API wallet private key (0x…), which must never be exposed to logs, prompts, or third parties. Any mis-handling by surrounding systems is catastrophic. - **HIP3 complexity:** HIP3 markets use isolated margin and can require specific Hyperliquid settings (e.g., disabling "Disable HIP-3 Dex Abstraction"). Misconfiguration may lead to unexpected margin behavior or failed trades. - **Operational and liquidity risk:** All trading depends on Hyperliquid’s availability, liquidity, and behavior; downtime or thin markets can cause failed orders or extreme slippage. - **Agent orchestration challenges:** The low-latency server is a long-lived process. In some sandboxed or stateless OpenClaw deployments, maintaining this background process may be difficult, reducing the practical latency benefits. **Recommended scenarios** - Experienced quants or devs using OpenClaw to build trading agents that **start on testnet**, thoroughly validate behavior, and then migrate to mainnet with tight controls (position/size caps, explicit human approvals). - Monitoring/analytics agents that primarily read data (positions, prices, order books) and only place limited, carefully controlled orders. - Environments where secure secret management is in place (e.g., vault/secret manager, no logging of env vars or command outputs) and where human operators supervise critical order-flow decisions. Given the strong functionality but inherent risk profile, this skill is **not** suitable for novice users or unsupervised autonomous agents trading real funds without strict guardrails and review.