永续合约 06 - Hyperliquid 深度解析

Hyperliquid 没有基于以太坊或 Cosmos, 而是从共识层 (HyperBFT) 到撮合引擎全部用 Rust 自研了一条 L1, 200ms 出块, 在链上跑订单簿. 本文介绍其 L1 架构, 链上订单簿机制, HLP Vault 做市模式, 保证金清算流程, 以及 JELLY 事件暴露出的一些问题.

一、术语表

1.1 架构

术语	英文	含义
应用链	Appchain	专为单一应用构建的区块链, 不与其他 dApp 共享资源
共识	Consensus	验证者节点对交易排序/确认达成一致的协议
HyperBFT	HyperBFT	Hyperliquid 自研 BFT 共识, 基于 HotStuff 优化
验证者	Validator	运行共识 + 撮合引擎的节点
区块时间	Block Time	出块间隔, Hyperliquid ~200ms

1.2 交易

术语	英文	含义
链上订单簿	On-chain Order Book	每个订单作为交易提交到链上, 撮合在共识层完成
撮合引擎	Matching Engine	按 price-time priority 配对买卖订单
做市	Market Making	在买卖两侧同时挂单, 赚取 bid-ask spread
HLP	Hyperliquid LP Vault	协议原生做市 vault, 用户存 USDC 参与做市
ADL	Auto-Deleveraging	保险基金不足时, 强制让盈利方减仓

1.3 代币

术语	英文	含义
HYPE	HYPE Token	Hyperliquid 原生代币, 用于 staking + 手续费折扣
HIP-1	Hyperliquid Improvement Proposal 1	代币标准 + Spot 上币规则: 定义如何在 L1 上发行代币, 通过荷兰拍卖竞拍 ticker 上线交易对
HIP-2	Hyperliquid Improvement Proposal 2	协议自动做市: 新 token 上线后协议自动在订单簿两侧挂单, 解决冷启动流动性问题, 不依赖外部做市商

二、Hyperliquid 概述

2.1 为什么需要 Hyperliquid?

现有链上永续协议的问题:

协议	问题
GMX (Oracle 型)	零滑点但 OI 受限, LP 被动承担对手方风险
dYdX v3 (StarkEx)	订单簿在 StarkEx 链下, 依赖中心化 sequencer
dYdX v4 (Cosmos)	订单簿在内存中 (off-chain), 只有撮合结果上链
vAMM (Perp Protocol)	虚拟流动性, 滑点大, 易被操纵

Hyperliquid 的目标: 把完整的订单簿和撮合引擎搬到链上, 同时保持 CEX 级别的性能.

2.2 当前规模 (量级参考)

指标	数值 (约)
日均交易量	$1B ~ $10B
总 OI (Open Interest)	$1B ~ $5B
上线交易对	100+
最大杠杆	50x

注: 具体数据随市场波动, 以上为 2025 年 Q1 的量级参考. 请以 Hyperliquid Stats 为准.

三、架构: 自研 L1

Q: Hyperliquid L1 到底是什么? 跟 Ethereum L2, Cosmos 链, EVM 链是什么关系?

Hyperliquid L1 是完全自建的独立 L1, 不是 Ethereum L2, 不是 Cosmos 链, 也不是 EVM 链. 用 Rust 从零写的, 不基于任何现有框架 (不用 OP Stack, 不用 Cosmos SDK, 不用 Substrate). 共识协议是 HyperBFT, 基于学术界的 HotStuff 改进而来.

维度	GMX (Arbitrum L2)	dYdX v4 (Cosmos appchain)	Hyperliquid (自建 L1)
基础框架	Ethereum L2 (OP Stack)	Cosmos SDK (Go)	自研 (Rust)
安全性继承	Ethereum	自身验证者	自身验证者
定制性	低	高	极高
EVM 兼容	完全	不兼容	后期加了 HyperEVM

3.1 HyperBFT 共识

HyperBFT 基于学术界的 HotStuff 协议优化:

HotStuff (学术论文, Facebook/Meta Libra 使用)
    ↓ 优化
HyperBFT (Hyperliquid 自研)
    - 降低通信轮次
    - 针对订单簿场景优化
    - ~200ms 区块时间
    - 100k+ orders/sec 吞吐

关键特性:

特性	说明
区块时间	~200ms (vs Ethereum ~12s, vs Cosmos ~6s)
吞吐量	100k+ orders/sec
确认	单次共识即最终确认 (no reorg)
容错	BFT: 容忍 < 1/3 恶意节点

3.2 vs dYdX v4: 同为 Appchain, 路径不同

维度	dYdX v4	Hyperliquid
基础框架	Cosmos SDK	自研
共识	CometBFT	HyperBFT (HotStuff)
订单簿位置	内存 (off-chain)	链上 (on-chain)
上链内容	撮合结果	每个订单
透明性	中 (撮合过程不可验证)	高 (全链路可验证)
语言	Go (开源)	Rust (未开源)
IBC 互操作	支持	不支持

核心区别: dYdX 的订单簿在验证者内存中, 用户无法验证撮合过程是否公平.
Hyperliquid 每个订单都上链, 撮合过程完全可审计, 但代价是对共识层性能要求极高.

四、链上订单簿

4.1 工作原理

Hyperliquid 的每个操作都是一笔链上交易:

4.2 订单类型

订单类型	说明
Limit Order	指定价格, 到价成交
Market Order	按当前最优价格立即成交
Stop Loss	价格跌到触发价 → 自动卖出
Take Profit	价格涨到触发价 → 自动卖出
TWAP	时间加权均价, 大单拆分为小单分时段执行

4.3 撮合规则: Price-Time Priority

4.4 vs dYdX: 订单簿的关键区别

维度	dYdX v4	Hyperliquid
订单存储	验证者内存	链上状态
挂单	gossip 到验证者内存	作为交易上链
撮合	内存中完成, 结果打包上链	共识层执行, 结果写入链上状态
可审计性	只能验证最终结果	每笔订单可追溯
取消订单	从内存删除 (免费)	需要上链 (消耗资源)

类比: dYdX 像一个公证处: 你看不到内部审批过程, 但可以看到公证结果.
Hyperliquid 像法庭公开审理: 每个环节都公开记录.

五、HLP Vault

HLP (Hyperliquid LP) 是 Hyperliquid 最独特的设计之一: 一个协议原生的做市 vault.

5.1 工作原理

5.2 HLP vs GMX GLP: 本质区别

维度	GMX GLP	Hyperliquid HLP
角色	被动对手方	主动做市
策略	无策略, 交易者赚 = GLP 亏	协议运行做市策略, 赚 spread
风险来源	交易者的盈亏 (零和)	做市策略的库存风险
收益模式	手续费 + 交易者亏损	手续费 + spread + 清算利润
资产	多种 (ETH, BTC, USDC…)	仅 USDC
赎回	随时 (有冷却期)	随时 (有冷却期)

GLP: “你存钱进来, 交易者赢了你就亏, 交易者亏了你就赢.”
HLP: “你存钱进来, 协议帮你做市赚差价, 但行情剧烈时可能亏.”

5.3 HLP 的子策略

HLP vault 内部运行多个策略组件:

策略	说明
Hyperliquidity	在多个交易对提供流动性 (挂 bid/ask)
Liquidator	接管被清算的仓位
Clearinghouse	处理 ADL 和风险管理

用户存入 USDC 后, 资金按比例分配到各策略, 收益也按比例分配.

六、保证金与清算

详细的保证金/清算机制见保证金管理与清算引擎. 这里只记录 Hyperliquid 的特殊实现.

6.1 保证金模式

模式	说明
Cross Margin (默认)	所有头寸共享保证金, 一个赚的可以 cover 另一个亏的
Isolated Margin	每个头寸独立保证金, 亏完就清算, 不影响其他头寸

6.2 Mark Price

1	`mark_price (标记价格) = median (中位数)(binance_price, okx_price, bybit_price, ...)`

Hyperliquid 的 mark price 由验证者节点从多个 CEX 拉取价格, 取 中位数 (median).

为什么用中位数而不是加权平均?

中位数天然抗单个数据源异常 (一个 CEX 宕机或被操纵, 中位数不受影响)
加权平均会被极端值拉偏

6.3 清算流程

Hyperliquid vs 其他协议的清算区别:

协议	清算执行者	清算激励
GMX	Keeper 网络 (外部)	清算奖励
dYdX v4	任意链上交易 (外部)	清算利润
Hyperliquid	协议自动 (内部)	无需外部激励

Hyperliquid 的清算由验证者节点自动执行, 不需要外部 keeper.
这降低了清算延迟, 但也意味着清算逻辑完全由协议控制 (不像 GMX/dYdX 由竞争性 keeper 执行).

七、Funding Rate

7.1 结算频率

协议	Funding 频率	说明
Binance / OKX	8h 离散结算	每 8 小时结算一次
dYdX v3	8h 离散结算	每 8 小时结算一次
dYdX v4	连续累积, 费率/8h	每个区块连续累积
Hyperliquid	连续累积, 费率/1h	每个区块连续累积
GMX	连续累积, 费率/1h	每个区块连续累积

Hyperliquid 每个区块连续累积 funding, 费率以 1h 为单位标注. 连续累积意味着:

价格偏离被更快纠正
不存在 “结算前抢跑” 的套利窗口
套利者有更多机会参与

7.2 计算逻辑

premium (溢价) = (mark_price (标记价格) - oracle_price (预言机价格)) / oracle_price

funding_rate (资金费率) = clamp(premium, -0.05%, +0.05%)
               // 每小时上限 ±0.05% (年化 ±438%)

funding_payment (资金支付) = position_size (头寸规模) × funding_rate

// 正 funding_rate: 多头付给空头
// 负 funding_rate: 空头付给多头

7.3 为什么连续累积比离散结算好?

八、Spot 交易

Hyperliquid 不只做永续, 它也在链上运行了完整的 Spot 订单簿.

8.1 HIP-1: 链上 Spot Order Book

HIP-1 定义了 Hyperliquid L1 上的代币标准和 spot 交易规则:

代币在 Hyperliquid L1 上原生发行
交易通过链上订单簿完成 (与 perp 相同的撮合引擎)
通过 bridge 与 Arbitrum 互通 (USDC 桥接)

8.2 HIP-2: Hyperliquidity (协议自有做市)

HIP-2 是 Hyperliquid 的创新: 协议自动为 spot 市场做市, 不依赖外部做市商.

传统 spot DEX:
  新 token 上线 → 需要找做市商 → 没人做市 → 流动性差 → 没人交易
  (冷启动问题)

Hyperliquid HIP-2:
  新 token 上线 → 协议自动做市 (protocol-owned liquidity)
  → 立即有流动性 → 用户可以交易

维度	Uniswap (AMM)	Hyperliquid HIP-2
模型	x * y = k	订单簿 + 协议做市
流动性来源	LP 提供	协议自有
冷启动	需要 LP 注入	自动启动
价格发现	AMM 曲线	订单簿 (更高效)

8.3 Bridge

Hyperliquid 通过 bridge 连接 Arbitrum:

用户将 USDC 从 Arbitrum 桥接到 Hyperliquid L1
提款时从 Hyperliquid L1 桥回 Arbitrum
bridge 由验证者集合维护 (多签)

Q: Hyperliquid 上的 USDC 是 Circle 原生发行的吗?

不是. Hyperliquid 上的 USDC 是从 Arbitrum 桥接过来的, 不是 Circle 在 Hyperliquid 上原生发行的. bridge 安全性由 Hyperliquid 验证者集合保障 (多签), 不是 trustless 的. dYdX 也是类似情况, USDC 通过 Noble chain 经 IBC 转入, 也不是 Circle 直接发行.

Circle 是否在某条链上原生发行 USDC, 本质上是对该链的信任背书. 目前 Circle 原生支持的链包括 Ethereum, Arbitrum, Base, Solana, Avalanche 等, 但不包括 Hyperliquid 和 dYdX chain.

8.4 代币的三种上线方式

Q: Hyperliquid 上的代币有几种来源?

Hyperliquid 上的代币有三种来源:

跨链桥接 (Bridge): 从 Arbitrum 桥接 USDC 到 Hyperliquid, 目前只支持 USDC 一种资产
原生层 HIP-1 代币: 通过荷兰拍卖 (Dutch Auction) 机制上币, 无需审批, 任何人出价竞拍 ticker 即可上线 spot 交易对
HyperEVM ERC20: 任何人都可以在 HyperEVM 上部署 Solidity 合约, 发行标准 ERC20 代币

这三种方式对应 Hyperliquid 的双层架构:

Native 层性能极高 (200ms 区块, 100k+ orders/sec), 但只能运行 Hyperliquid 预定义的逻辑. HyperEVM 层更灵活 (任意 Solidity), 但性能受限于 EVM 执行开销. 两层之间可以互操作.

九、HYPE Token

9.1 用途

用途	说明
Staking	质押 HYPE 参与网络验证, 获得 staking 收益
手续费折扣	持有/质押 HYPE 降低交易手续费
治理	未来可能用于协议治理 (目前治理权集中)

9.2 空投

2024 年 11 月, Hyperliquid 进行了大规模空投:

基于历史交易量和协议使用情况
总供应量 31% 分配给社区
无 VC 轮次, 无 lockup (社区空投部分)
被认为是 2024 年最大规模的空投之一

十、费率结构

10.1 Maker/Taker 分层费率

层级	30d 交易量	Maker	Taker
基础	< $5M	0.01%	0.035%
VIP 1	$5M ~ $25M	0.008%	0.03%
VIP 2	$25M ~ $100M	0.006%	0.025%
VIP 3	$100M ~ $500M	0.004%	0.02%
VIP 4	> $500M	0.002%	0.015%

注: 费率随协议更新可能调整, 以上为参考值.

特点:

Maker 费率极低 (鼓励挂单提供流动性)
与 CEX 相比, 整体费率有竞争力 (Binance maker 0.02%, taker 0.04%)
HYPE staking 可获得额外折扣

10.2 Referral System

推荐人获得被推荐人手续费的一定比例 (通常 ~10%)
被推荐人获得手续费折扣 (~5%)
referral code 绑定在地址上

十一、Go: 与 Hyperliquid API 交互

Hyperliquid 提供 REST + WebSocket API. 以下用 Go 演示常见操作.

11.1 基础设置

package main

import (
	"bytes"
	"context"
	"encoding/json"
	"fmt"
	"io"
	"log"
	"net/http"
	"time"
)

const (
	baseURL = "https://api.hyperliquid.xyz"
	infoURL = baseURL + "/info"
)

// Client wraps HTTP client for Hyperliquid API.
type Client struct {
	http *http.Client
}

func NewClient() *Client {
	return &Client{
		http: &http.Client{Timeout: 10 * time.Second},
	}
}

// post sends a POST request with JSON body to the info endpoint.
func (c *Client) post(ctx context.Context, payload any) ([]byte, error) {
	body, err := json.Marshal(payload)
	if err != nil {
		return nil, fmt.Errorf("marshal payload: %w", err)
	}

	req, err := http.NewRequestWithContext(ctx, http.MethodPost, infoURL, bytes.NewReader(body))
	if err != nil {
		return nil, fmt.Errorf("create request: %w", err)
	}
	req.Header.Set("Content-Type", "application/json")

	resp, err := c.http.Do(req)
	if err != nil {
		return nil, fmt.Errorf("do request: %w", err)
	}
	defer func() { _ = resp.Body.Close() }()

	data, err := io.ReadAll(resp.Body)
	if err != nil {
		return nil, fmt.Errorf("read response: %w", err)
	}
	if resp.StatusCode != http.StatusOK {
		return nil, fmt.Errorf("unexpected status %d: %s", resp.StatusCode, string(data))
	}
	return data, nil
}

11.2 读取 Order Book (L2)

L2 = Level 2 (二档行情), 不是 Layer 2 (二层网络). 这是交易所 API 的通用术语:

L1 (Level 1): 只返回最优买卖价 (best bid/ask)

L2 (Level 2): 返回多档聚合报价 (同一价格的订单合并, 显示总量和档数)

L3 (Level 3): 返回每笔订单明细 (不聚合)

CEX (Binance, OKX) 的 API 也用同样的 L1/L2/L3 命名.

// L2Book represents the order book snapshot.
type L2Book struct {
	Levels [][]PriceLevel `json:"levels"` // [0]=bids, [1]=asks
}

type PriceLevel struct {
	Px string `json:"px"` // price
	Sz string `json:"sz"` // size
	N  int    `json:"n"`  // number of orders
}

// GetL2Book fetches L2 order book for a given coin.
func (c *Client) GetL2Book(ctx context.Context, coin string) (*L2Book, error) {
	payload := map[string]any{
		"type": "l2Book",
		"coin": coin,
	}
	data, err := c.post(ctx, payload)
	if err != nil {
		return nil, fmt.Errorf("get l2 book: %w", err)
	}

	var book L2Book
	if err := json.Unmarshal(data, &book); err != nil {
		return nil, fmt.Errorf("unmarshal l2 book: %w", err)
	}
	return &book, nil
}

11.3 读取 Open Interest 和 Funding Rate

// Meta contains perpetual market metadata.
type Meta struct {
	Universe []AssetMeta `json:"universe"`
}

type AssetMeta struct {
	Name          string `json:"name"`
	SzDecimals    int    `json:"szDecimals"`
	MaxLeverage   int    `json:"maxLeverage"`
	OnlyIsolated  bool   `json:"onlyIsolated"`
}

// AssetCtx contains real-time context for an asset.
type AssetCtx struct {
	Funding    string `json:"funding"`    // current funding rate
	OpenInterest string `json:"openInterest"` // total OI in contracts
	PrevDayPx  string `json:"prevDayPx"`
	DayNtlVlm  string `json:"dayNtlVlm"` // 24h notional volume
	MarkPx     string `json:"markPx"`
	MidPx      string `json:"midPx"`
	OraclePx   string `json:"oraclePx"`
}

// MetaAndAssetCtx is the response from metaAndAssetCtxs.
type MetaAndAssetCtx struct {
	Meta      Meta       `json:"-"`
	AssetCtxs []AssetCtx `json:"-"`
}

// GetMetaAndAssetCtxs fetches market metadata + real-time context.
func (c *Client) GetMetaAndAssetCtxs(ctx context.Context) (*MetaAndAssetCtx, error) {
	payload := map[string]any{
		"type": "metaAndAssetCtxs",
	}
	data, err := c.post(ctx, payload)
	if err != nil {
		return nil, fmt.Errorf("get meta: %w", err)
	}

	// Response is a JSON array: [meta, [assetCtx, ...]]
	var raw []json.RawMessage
	if err := json.Unmarshal(data, &raw); err != nil {
		return nil, fmt.Errorf("unmarshal outer: %w", err)
	}
	if len(raw) != 2 {
		return nil, fmt.Errorf("expected 2 elements, got %d", len(raw))
	}

	result := &MetaAndAssetCtx{}
	if err := json.Unmarshal(raw[0], &result.Meta); err != nil {
		return nil, fmt.Errorf("unmarshal meta: %w", err)
	}
	if err := json.Unmarshal(raw[1], &result.AssetCtxs); err != nil {
		return nil, fmt.Errorf("unmarshal asset ctxs: %w", err)
	}
	return result, nil
}

11.4 查询用户持仓

// UserState contains a user's account and positions.
type UserState struct {
	AssetPositions []AssetPosition `json:"assetPositions"`
	CrossMarginSummary MarginSummary `json:"crossMarginSummary"`
}

type AssetPosition struct {
	Position Position `json:"position"`
	Type     string   `json:"type"`
}

type Position struct {
	Coin           string `json:"coin"`
	Szi            string `json:"szi"`            // signed size (negative = short)
	EntryPx        string `json:"entryPx"`
	PositionValue  string `json:"positionValue"`
	UnrealizedPnl  string `json:"unrealizedPnl"`
	Leverage       Leverage `json:"leverage"`
}

type Leverage struct {
	Type  string `json:"type"`  // "cross" or "isolated"
	Value int    `json:"value"` // leverage multiplier
}

type MarginSummary struct {
	AccountValue    string `json:"accountValue"`
	TotalMarginUsed string `json:"totalMarginUsed"`
	TotalNtlPos     string `json:"totalNtlPos"`
}

// GetUserState fetches positions and margin info for an address.
func (c *Client) GetUserState(ctx context.Context, address string) (*UserState, error) {
	payload := map[string]any{
		"type": "clearinghouseState",
		"user": address,
	}
	data, err := c.post(ctx, payload)
	if err != nil {
		return nil, fmt.Errorf("get user state: %w", err)
	}

	var state UserState
	if err := json.Unmarshal(data, &state); err != nil {
		return nil, fmt.Errorf("unmarshal user state: %w", err)
	}
	return &state, nil
}

11.5 使用示例

func main() {
	client := NewClient()
	ctx := context.Background()

	// 1. 读取 ETH order book
	book, err := client.GetL2Book(ctx, "ETH")
	if err != nil {
		log.Fatalf("get order book: %v", err)
	}
	if len(book.Levels) == 2 && len(book.Levels[0]) > 0 {
		fmt.Printf("ETH best bid: %s, best ask: %s\n",
			book.Levels[0][0].Px, book.Levels[1][0].Px)
	}

	// 2. 读取所有市场的 funding rate 和 OI
	meta, err := client.GetMetaAndAssetCtxs(ctx)
	if err != nil {
		log.Fatalf("get meta: %v", err)
	}
	for i, asset := range meta.Meta.Universe {
		if i >= len(meta.AssetCtxs) {
			break
		}
		actx := meta.AssetCtxs[i]
		fmt.Printf("%-8s  funding: %s  OI: %s  mark: %s\n",
			asset.Name, actx.Funding, actx.OpenInterest, actx.MarkPx)
	}

	// 3. 查询用户持仓
	state, err := client.GetUserState(ctx, "0x...")
	if err != nil {
		log.Fatalf("get user state: %v", err)
	}
	fmt.Printf("Account value: %s\n", state.CrossMarginSummary.AccountValue)
	for _, ap := range state.AssetPositions {
		p := ap.Position
		fmt.Printf("  %s: size=%s entry=%s pnl=%s\n",
			p.Coin, p.Szi, p.EntryPx, p.UnrealizedPnl)
	}
}

11.6 WebSocket 订阅

// WebSocket endpoint
const wsURL = "wss://api.hyperliquid.xyz/ws"

// Subscribe message format:
// {"method": "subscribe", "subscription": {"type": "l2Book", "coin": "ETH"}}
// {"method": "subscribe", "subscription": {"type": "trades", "coin": "ETH"}}
// {"method": "subscribe", "subscription": {"type": "userEvents", "user": "0x..."}}

// Example subscription payload:
type WSSubscription struct {
	Method       string            `json:"method"`
	Subscription map[string]string `json:"subscription"`
}

// 实际使用时, 推荐用 gorilla/websocket 或 nhooyr.io/websocket 库连接.
// 伪代码:
//
//   conn, _, err := websocket.Dial(ctx, wsURL, nil)
//   sub := WSSubscription{
//       Method: "subscribe",
//       Subscription: map[string]string{
//           "type": "l2Book",
//           "coin": "ETH",
//       },
//   }
//   _ = wsjson.Write(ctx, conn, sub)
//   for {
//       var msg json.RawMessage
//       _ = wsjson.Read(ctx, conn, &msg)
//       // process msg...
//   }

十二、风险与争议

12.1 中心化程度

维度	现状
验证者数量	有限 (远少于 Ethereum 的数千节点)
代码	未开源 (Rust 实现, 不可审计)
治理	团队主导, 无链上治理
Bridge	验证者多签, 非 trustless

虽然 Hyperliquid 声称 “链上透明”, 但核心代码未开源, 用户无法验证撮合引擎是否真的公平.
这是一个 信任假设: 你信任验证者集合不会作恶.

12.2 JELLY 事件 (2025 年 3 月)

2025 年 3 月发生的 JELLY 事件是 Hyperliquid 迄今最大的争议, 也是典型的 “市场操纵 + 强制清算转嫁” 攻击.

攻击对象: JELLY (JellyJelly), 一个极小市值的 meme token, 流动性极差, 价格容易被操纵.

攻击步骤:

第 1 步: 建立巨额空头
  在 Hyperliquid 上做空 JELLY, 仓位远超正常水平
  例: $5M 保证金, 10x 杠杆, 做空 $50M 的 JELLY

第 2 步: 拉盘
  自己在现货市场 (链上 DEX) 大量买入 JELLY
  JELLY 市值本来就小, 几百万美元就能把价格拉起来
  → 攻击者在现货端赚了

第 3 步: 等空头被清算
  价格被拉高 → 攻击者自己的空头仓位爆仓
  但攻击者根本不在乎, 他故意让自己被清算

  关键: 清算后这个巨额空头仓位去哪了?
  → HLP (协议做市 vault) 自动接盘! 被迫持有这个巨额空头

结果:
  JELLY 价格还在高位 → HLP 持有的空头巨亏
  攻击者: 现货端赚的钱 > 空头保证金的损失 → 净赚
  HLP 用户 (存 USDC 的普通人) → 承担亏损

攻击成功的三个条件 (缺一不可):

条件	说明
小市值 token 上了永续合约	现货流动性差, 容易操纵价格
OI 上限 (Open Interest Cap) 设置过高	允许建立与市值不匹配的巨额仓位 (如市值 $10M 却允许 $50M 空头)
HLP 自动接管清算仓位	攻击者利用此机制把 “毒仓位” 转移给 HLP

团队应对 (争议核心):

团队做了什么:
  1. 紧急下架 JELLY 永续合约
  2. 以 "团队认为合理的价格" 强制结算所有 JELLY 仓位
  3. HLP 的亏损被部分挽回

为什么有争议:
  - "合理价格" 由团队单方面决定, 非市场价格
  - 链上交易的不可篡改性被绕过: 直接改了结算价格
  - 本质上与 CEX "拔网线" 无异

问题:

问题	说明
市场操纵	攻击者利用小市值 token 的低流动性, 联动现货和永续两个市场
HLP 风险暴露	HLP 作为清算接收方, 被迫持有高风险头寸, 成为定向攻击目标
中心化干预	团队单方面下架 token 并以自定价格强制结算, 违背去中心化原则
信任危机	“链上透明” 的叙事被动摇: 关键时刻团队可以直接干预

教训:

链上订单簿不等于去中心化: 如果运营方能单方面干预, 本质上与 CEX 无异
HLP 的风险不只是做市亏损: 作为清算接收方, 面临被定向攻击的风险
小市值 token 的 OI 上限需要严格控制, 应与现货市值挂钩

vs GMX: GMX 的 Oracle 模型 (Chainlink 多源聚合) 不容易被单个 DEX 的价格操纵影响; Hyperliquid 的链上订单簿直接反映市场价格, 被操纵了就是被操纵了

12.3 审计状况

核心代码未开源, 难以进行完整审计
团队声称内部有安全审计流程, 但缺乏第三方独立审计报告
智能合约 (bridge 等) 部分有审计

十三、小结

13.1 Hyperliquid 的定位

优势	劣势
CEX 级别性能 (~200ms)	验证者数量有限, 偏中心化
完全链上订单簿, 可审计	代码未开源
HLP vault 创新做市模式	HLP 面临被定向攻击风险 (JELLY)
连续累积 funding (费率/1h), 价格锚定更紧	Bridge 依赖验证者多签
大规模社区空投	关键时刻团队可单方面干预

13.2 核心问题

Hyperliquid 本质上是一个 “由少数验证者运行的高性能订单簿”.
它比传统 DeFi 更快, 比 CEX 更透明, 但它真的去中心化吗?
JELLY 事件表明, 当危机发生时, 它的行为与中心化交易所并无二致.

下一步: → 永续合约中的 MEV - 清算 MEV, Oracle 抢跑, 跨市场套利.

Web3

#Web3 #永续合约 #Hyperliquid

永续合约 06 - Hyperliquid 深度解析

https://mritd.com/2025/09/20/perp-hyperliquid/

作者

Kovacs

发布于

2025年9月20日

许可协议

永续合约 07 - 永续合约中的 MEV 上一篇

永续合约 05 - vAMM 永续合约演进史下一篇