why/SKILL.md
Why build on Hyperliquid. HyperBFT consensus, native orderbook, speed, AI agent angle, honest tradeoffs. Use when someone asks "should I build on Hyperliquid?", "why not Ethereum?", or when an agent needs to understand what makes Hyperliquid unique.
npx skillsauth add cloudzombie/liquidskills why-hyperliquidInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
"Hyperliquid is just a fast Ethereum L2." No. Hyperliquid is a purpose-built L1 with HyperBFT consensus and a native orderbook. HyperEVM is ONE component — it's an EVM environment that runs alongside HyperCore (the native exchange engine). They share finality. They are NOT the same thing.
"MEV sandwich attacks happen here too." They don't. HyperCore processes orders through HyperBFT consensus — there's no public mempool, no reordering by validators. Orders arrive, match, settle. No frontrunning. No sandwich. This is structurally different from any EVM chain.
"The native token is ETH." It's HYPE. HYPE is the gas token on HyperEVM, the staking token for HyperBFT validators, and the governance token. ETH has no role on Hyperliquid.
"I'll just use standard Ethereum tooling." HyperEVM works with standard EVM tools (wagmi, viem, Foundry). But HyperCore does NOT. HyperCore has its own API (/info, /exchange), its own token standards (HIP-1, HIP-2, HIP-3), and its own signing scheme (EIP-712 typed data over the exchange).
Hyperliquid is a purpose-built L1 where HyperCore (native orderbook, perps, spot) and HyperEVM (Solidity contracts) share atomic finality via HyperBFT consensus.
HyperBFT is a BFT (Byzantine Fault Tolerant) consensus algorithm optimized for throughput and finality. Key properties:
What this means for builders:
HyperCore is the core of Hyperliquid. It's not an EVM contract. It's built into the L1 itself.
What lives in HyperCore:
You interact with HyperCore via:
POST /info — read-only queries (no auth)POST /exchange — signed actions (orders, cancels, transfers)wss://api.hyperliquid.xyz/ws — real-time streamsHyperCore is what makes Hyperliquid unique. No other chain has a native perp DEX running at L1 consensus speed with no MEV.
HyperEVM is a standard EVM environment running alongside HyperCore. It:
0x2222222222222222222222222222222222222222 — send HYPE here to bridge from HyperCore to HyperEVMHyperEVM and HyperCore share finality. A HyperEVM transaction and a HyperCore order that execute in the same block are final together — no cross-chain bridge risk between them.
/exchange API is designed for algorithmic trading. Order placement is deterministic.| What Hyperliquid Does Well | What It Doesn't | |---------------------------|-----------------| | High-speed, high-volume trading | Ecosystem as deep as Ethereum/Arbitrum | | Native orderbook with no MEV | Not EVM-only — HyperCore has its own API surface | | Built-in token launch rails | Developer tooling still maturing vs Ethereum | | Sub-second finality | Less composability surface (smaller protocol ecosystem) | | Low gas costs on HyperEVM | HyperCore API learning curve | | AI-agent-friendly trading API | Smaller DeFi liquidity than Arbitrum |
When NOT to choose Hyperliquid:
When TO choose Hyperliquid:
development
Wallets on Hyperliquid — MetaMask + chain ID 999 setup, HyperCore API wallets, agent wallet patterns, EIP-712 signing for exchange actions. Essential for any agent that needs to interact with Hyperliquid.
tools
Development tools for Hyperliquid — Foundry, Hardhat, viem, wagmi for HyperEVM; Python SDK and TypeScript SDK for HyperCore API. What works, what to use, how to set up.
testing
Smart contract testing for HyperEVM with Foundry/Hardhat — unit tests, fuzz testing, testnet fork testing. What to test, what not to test, and what LLMs get wrong on Hyperliquid.
tools
Token standards on Hyperliquid — ERC-20 on HyperEVM, HIP-1/HIP-2/HIP-3 native token standards on HyperCore. When to use each, how they work, key interfaces.