# Hyperliquid API文档详解：WebSocket、HTTP接口与限流规则

## 背景

Hyperliquid作为高性能去中心化交易所，提供了完善的API接口供开发者进行程序化交易和数据分析。本文将详细介绍Hyperliquid的WebSocket实时数据流、HTTP REST接口以及接口限流规则，帮助开发者快速接入Hyperliquid生态。

## API端点

### 主网与测试网

| 环境 | HTTP端点 | WebSocket端点 |
|------|----------|---------------|
| 主网 | `https://api.hyperliquid.xyz` | `wss://api.hyperliquid.xyz/ws` |
| 测试网 | `https://api.hyperliquid-testnet.xyz` | `wss://api.hyperliquid-testnet.xyz/ws` |

### SDK支持

Hyperliquid官方和社区提供了多种语言的SDK：

- **Python SDK**: [hyperliquid-python-sdk](https://github.com/hyperliquid-dex/hyperliquid-python-sdk)
- **Rust SDK**: [hypersdk](https://github.com/infinitefield/hypersdk)（社区贡献）
- **TypeScript SDK**: [nktkas/hyperliquid](https://github.com/nktkas/hyperliquid)、[nomeida/hyperliquid](https://github.com/nomeida/hyperliquid)
- **CCXT**: 多语言统一API，[文档地址](https://docs.ccxt.com/#/exchanges/hyperliquid)

---

## HTTP接口

Hyperliquid的HTTP API主要分为两大类：**Info端点**（查询信息）和**Exchange端点**（交易操作）。

### Info端点

Info端点用于获取交易所和用户相关信息，所有请求都使用POST方法发送到 `https://api.hyperliquid.xyz/info`。

#### 基础请求格式

```json
{
  "type": "<请求类型>",
  // 其他参数...
}
```

#### 常用查询接口

##### 1. 获取所有币种中间价

```json
// 请求
{
  "type": "allMids"
}

// 响应
{
  "APE": "4.33245",
  "ARB": "1.21695",
  ...
}
```

##### 2. 获取用户未成交订单

```json
// 请求
{
  "type": "openOrders",
  "user": "0x..."  // 42字符十六进制地址
}

// 响应
[
  {
    "coin": "BTC",
    "limitPx": "29792.0",
    "oid": 91490942,
    "side": "A",
    "sz": "0.0",
    "timestamp": 1681247412573
  }
]
```

##### 3. 获取用户账户状态

```json
// 请求
{
  "type": "clearinghouseState",
  "user": "0x..."
}

// 响应
{
  "assetPositions": [...],
  "marginSummary": {
    "accountValue": 1000.0,
    "totalNtlPos": 500.0,
    "totalRawUsd": 500.0,
    "totalMarginUsed": 100.0
  },
  "withdrawable": 900.0
}
```

##### 4. 获取订单簿数据

```json
// 请求
{
  "type": "l2Book",
  "coin": "BTC"
}

// 响应包含买卖盘深度数据
```

##### 5. 获取元数据

```json
// 请求
{
  "type": "meta"
}

// 响应包含所有交易对信息、资产索引等
```

#### 分页机制

返回时间范围数据的接口最多返回500个元素。要查询更大范围，使用最后返回的时间戳作为下一次请求的 `startTime`。

#### 永续合约与现货

- **永续合约**: `coin` 使用 `meta` 响应中返回的名称
- **现货**: `coin` 格式为 `PURR/USDC` 或 `@{index}`（如 `@107` 表示HYPE）

---

### Exchange端点

Exchange端点用于执行交易操作，所有请求发送到 `https://api.hyperliquid.xyz/exchange`，需要签名认证。

#### 请求结构

```json
{
  "action": {
    "type": "<操作类型>",
    // 操作参数
  },
  "nonce": 1704067200000,  // 毫秒时间戳
  "signature": {
    // EIP-712签名数据
  },
  "vaultAddress": "0x..."  // 可选，用于子账户或金库
}
```

#### 下单

```json
{
  "action": {
    "type": "order",
    "orders": [{
      "a": 0,           // 资产索引
      "b": true,        // 是否买入
      "p": "50000",     // 价格
      "s": "0.1",       // 数量
      "r": false,       // 是否reduceOnly
      "t": {
        "limit": {
          "tif": "Gtc"  // Good-Til-Cancelled
        }
      }
    }],
    "grouping": "na"
  },
  "nonce": 1704067200000,
  "signature": {...}
}
```

**订单类型 (TIF)**：
- `Gtc` (Good-Til-Cancelled): 订单持续有效直到成交或取消
- `Ioc` (Immediate-Or-Cancel): 立即成交或取消未成交部分
- `Alo` (Add-Liquidity-Only): Post-Only，只做Maker

#### 取消订单

```json
{
  "action": {
    "type": "cancel",
    "cancels": [{
      "a": 0,           // 资产索引
      "oid": 12345678   // 订单ID
    }]
  },
  "nonce": 1704067200000,
  "signature": {...}
}
```

#### 取消所有订单

```json
{
  "action": {
    "type": "cancelByCloid",
    "cancels": [{
      "asset": 0,
      "cloid": "0x1234..."  // 客户端订单ID
    }]
  },
  "nonce": 1704067200000,
  "signature": {...}
}
```

#### 修改订单

```json
{
  "action": {
    "type": "modify",
    "oid": 12345678,
    "order": {
      "a": 0,
      "b": true,
      "p": "51000",
      "s": "0.2",
      "r": false,
      "t": { "limit": { "tif": "Gtc" } }
    }
  },
  "nonce": 1704067200000,
  "signature": {...}
}
```

#### USDC转账

```json
{
  "action": {
    "type": "usdcTransfer",
    "destination": "0x...",
    "amount": "100.0"
  },
  "nonce": 1704067200000,
  "signature": {...}
}
```

#### TWAP订单

```json
{
  "action": {
    "type": "twapOrder",
    "twap": {
      "a": 0,
      "b": true,
      "s": "1.0",
      "r": false,
      "m": 10,          // 分钟数
      "t": { "limit": { "tif": "Gtc" } }
    }
  },
  "nonce": 1704067200000,
  "signature": {...}
}
```

---

## WebSocket接口

WebSocket提供实时数据流，适合需要低延迟数据更新的场景。

### 连接

```bash
wscat -c wss://api.hyperliquid.xyz/ws
```

**重要提示**: 所有自动化用户应处理服务器断开连接并优雅重连。断开可能定期发生且无通知。重连期间错过的数据将在重连时的快照确认中呈现。

### 订阅消息格式

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "<订阅类型>",
    // 其他参数
  }
}
```

### 订阅类型

#### 1. 所有中间价 (allMids)

```json
{
  "method": "subscribe",
  "subscription": { "type": "allMids" }
}
```

#### 2. 交易数据 (trades)

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "trades",
    "coin": "BTC"
  }
}
```

#### 3. 订单簿 (l2Book)

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "l2Book",
    "coin": "BTC"
  }
}
```

#### 4. K线数据 (candle)

支持的间隔: `1m`, `3m`, `5m`, `15m`, `30m`, `1h`, `2h`, `4h`, `8h`, `12h`, `1d`, `3d`, `1w`, `1M`

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "candle",
    "coin": "BTC",
    "interval": "1h"
  }
}
```

#### 5. 用户订单更新 (orderUpdates)

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "orderUpdates",
    "user": "0x..."
  }
}
```

#### 6. 用户成交记录 (userFills)

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "userFills",
    "user": "0x..."
  }
}
```

#### 7. 用户资金费率 (userFundings)

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "userFundings",
    "user": "0x..."
  }
}
```

#### 8. 用户通知 (notification)

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "notification",
    "user": "0x..."
  }
}
```

#### 9. 清算所状态 (clearinghouseState)

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "clearinghouseState",
    "user": "0x..."
  }
}
```

#### 10. 未成交订单 (openOrders)

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "openOrders",
    "user": "0x..."
  }
}
```

#### 11. 资产上下文 (activeAssetCtx)

```json
{
  "method": "subscribe",
  "subscription": {
    "type": "activeAssetCtx",
    "coin": "BTC"
  }
}
```

### 取消订阅

```json
{
  "method": "unsubscribe",
  "subscription": { ... }  // 与订阅时相同的对象
}
```

### WebSocket POST请求

WebSocket也可用于发送交易请求，与HTTP Exchange端点功能相同：

```json
{
  "method": "post",
  "id": "unique-request-id",
  "request": {
    "action": { ... },
    "nonce": 1704067200000,
    "signature": { ... }
  }
}
```

---

## 限流规则

### IP级别限流

#### REST请求

- **总权重限制**: 每分钟1200权重

**权重计算**：

| 请求类型 | 权重 |
|---------|------|
| Exchange API请求 | `1 + floor(batch_length / 40)` |
| 单个操作 | 1 |
| 79个批量订单 | 2 |
| l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus | 2 |
| userRole | 60 |
| 其他Info请求 | 20 |
| Explorer API请求 | 40 |

**额外权重**（按返回项目数）：
- `recentTrades`, `historicalOrders`, `userFills`, `userFillsByTime`, `fundingHistory`, `userFunding`, `nonUserFundingUpdates`, `twapHistory`, `userTwapSliceFills`, `userTwapSliceFillsByTime`, `delegatorHistory`, `delegatorRewards`, `validatorStats`: 每20个项目增加权重
- `candleSnapshot`: 每60个项目增加权重

#### WebSocket限制

| 限制项 | 数值 |
|--------|------|
| 最大WebSocket连接数 | 10 |
| 每分钟新WebSocket连接数 | 30 |
| 最大WebSocket订阅数 | 1000 |
| 用户特定订阅的唯一用户数 | 10 |
| 每分钟WebSocket消息数 | 2000 |
| 同时进行中的POST消息数 | 100 |

#### EVM JSON-RPC

- `rpc.hyperliquid.xyz/evm`: 每分钟100个请求

### 地址级别限流

地址级别限制按用户计算，子账户视为独立用户。

#### 请求限制

- **基础逻辑**: 自地址创建以来每交易1 USDC允许1个请求
- **初始缓冲**: 10000个请求
- **限流后**: 每10秒允许1个请求
- **取消订单限制**: `min(limit + 100000, limit * 2)`

此限制仅适用于操作（actions），不适用于信息查询（info requests）。

#### 未成交订单限制

- **默认限制**: 1000个未成交订单
- **额外配额**: 每5M USDC交易量增加1个订单
- **上限**: 5000个未成交订单
- **限制触发时**: reduce-only订单和触发订单将被拒绝

#### 高拥堵时期

在高拥堵期间，地址被限制使用其做市商份额百分比2倍的区块空间。

### 批量请求

- **IP限流**: n个订单的批量请求视为1个请求
- **地址限流**: n个订单的批量请求视为n个请求

---

## 最佳实践

### 1. 使用WebSocket获取实时数据

WebSocket延迟最低，适合实时数据更新：

```python
import asyncio
import websockets
import json

async def subscribe_trades():
    uri = "wss://api.hyperliquid.xyz/ws"
    async with websockets.connect(uri) as ws:
        # 订阅BTC交易数据
        subscribe_msg = {
            "method": "subscribe",
            "subscription": {"type": "trades", "coin": "BTC"}
        }
        await ws.send(json.dumps(subscribe_msg))
        
        async for msg in ws:
            data = json.loads(msg)
            print(data)
```

### 2. 处理重连

```python
import asyncio
import websockets
import json

async def connect_with_reconnect():
    while True:
        try:
            async with websockets.connect("wss://api.hyperliquid.xyz/ws") as ws:
                # 处理消息
                async for msg in ws:
                    process_message(msg)
        except Exception as e:
            print(f"Disconnected: {e}, reconnecting...")
            await asyncio.sleep(5)
```

### 3. 签名请求

使用Python SDK进行签名：

```python
from hyperliquid.exchange import Exchange
from hyperliquid.utils import constants

# 初始化
exchange = Exchange(
    "0x你的私钥",
    constants.MAINNET_API_URL
)

# 下单
order_result = exchange.order("BTC", True, 0.1, 50000, {"limit": {"tif": "Gtc"}})
```

### 4. 限流管理

```python
import time
from collections import deque

class RateLimiter:
    def __init__(self, max_weight=1200, window=60):
        self.max_weight = max_weight
        self.window = window
        self.requests = deque()
    
    def can_request(self, weight=1):
        now = time.time()
        # 清理过期请求
        while self.requests and self.requests[0][0] < now - self.window:
            self.requests.popleft()
        
        # 检查权重
        current_weight = sum(w for _, w in self.requests)
        if current_weight + weight <= self.max_weight:
            self.requests.append((now, weight))
            return True
        return False
    
    def wait_time(self, weight=1):
        if not self.requests:
            return 0
        # 计算需要等待的时间
        current_weight = sum(w for _, w in self.requests)
        if current_weight + weight <= self.max_weight:
            return 0
        return self.requests[0][0] + self.window - time.time()
```

### 5. 资产索引处理

```python
def get_asset_index(coin, meta, spot_meta):
    """获取资产索引"""
    # 永续合约
    for i, asset in enumerate(meta['universe']):
        if asset['name'] == coin:
            return i
    
    # 现货
    for i, asset in enumerate(spot_meta['universe']):
        if asset['name'] == coin:
            return 10000 + i
    
    return None
```

---

## 参考资料

- [Hyperliquid官方API文档](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api)
- [Hyperliquid Python SDK](https://github.com/hyperliquid-dex/hyperliquid-python-sdk)
- [Hyperliquid WebSocket订阅文档](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/websocket/subscriptions)
- [Hyperliquid限流规则](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/rate-limits-and-user-limits)

---

## 总结

Hyperliquid提供了完整的WebSocket和HTTP API接口，支持程序化交易和数据分析。关键要点：

1. **双端点架构**: Info端点用于查询，Exchange端点用于交易
2. **WebSocket实时数据**: 支持交易、订单簿、K线等多种订阅
3. **严格的限流规则**: IP级别和地址级别双重限制
4. **签名认证**: Exchange操作需要EIP-712签名
5. **批量操作支持**: 提高效率但需注意限流计算

开发者应根据实际需求选择合适的数据获取方式，并严格遵守限流规则，确保稳定可靠的API接入。


Hyperliquid API文档详解：WebSocket、HTTP接口与限流规则

# Hyperliquid改进提案（HIPs）：代币标准与协议治理机制

## 背景

在区块链世界中，协议升级通常面临三种选择：治理投票、链下提案、或硬分叉。每种方式都有其局限性——治理投票可能导致大户垄断，链下提案缺乏透明度，硬分叉则可能分裂社区。

Hyperliquid采用了不同的路径：Hyperliquid改进提案（HIPs）。这是一种将升级逻辑直接嵌入HyperCore的方法，使协议变更模块化、可审查、即时生效。每个HIP都引入了对核心基础设施、智能合约逻辑或开发工具的聚焦变更。

## HIPs概述

Hyperliquid改进提案（HIPs）由构建者撰写，由社区审查，并通过HyperCore直接实现到Hyperliquid技术栈中。目前已有三个主要HIP：

- **HIP-1**：原生代币标准
- **HIP-2**：超流动性（Hyperliquidity）
- **HIP-3**：构建者部署永续合约

这些提案定义了Hyperliquid区块链如何在不停止链或进行链下升级的情况下成长。

## HIP-1：原生代币标准

HIP-1于2023年11月引入，为Hyperliquid区块链建立了正式的代币标准，从其原生HYPE代币开始，延伸到PURR等其他资产，使它们完全兼容HyperCore。

### 核心要素

**唯一资产ID：**
- 确保每个代币在链上独特
- 防止代币混淆或伪造

**可替代性标志：**
- 标识代币是否可互换或独特
- 支持同质化和非同质化资产

**丰富元数据：**
- 名称（如"HYPE"或"PURR"）
- 符号
- 小数精度

### 实际案例：PURR代币

当PURR于2024年4月作为首个HIP-1代币推出时，它立即激活了现货市场，无需任何自定义设置即可支持订单簿。这一平滑发布展示了HIP-1如何赋能代币直接在HyperCore上工作，从第一天起就支持现货交易、质押和工具集成。

### 与ERC-20的对比

| 特性 | HIP-1 | ERC-20 |
|------|-------|--------|
| **执行环境** | HyperCore原生 | EVM智能合约 |
| **Gas费用** | 交易和转账免费（初始状态更新后） | 每次操作都需Gas |
| **订单簿集成** | 原生支持 | 需要额外集成 |
| **性能** | 高性能原生操作 | 受限于EVM |

### Gas优化机制

HIP-1代币的一个创新设计是Gas优化：

- 初始状态更新（首次交易或转账）需要小额USDC Gas费
- 后续交易和转账在标准Hyperliquid填充率条件下免费
- 这消除了传统代币转账的Gas摩擦

## HIP-2：超流动性

HIP-2于2024年3月引入，是最具突破性的提案之一。它创建了超流动性（Hyperliquidity）——一种内置于HyperCore的链上流动性机制。

### 什么是超流动性

超流动性是一种内置于HyperCore的链上策略，自动为新代币放置买卖订单，为现货订单簿贡献持续流动性，支持稳定的价格执行，无需人工干预。

### 核心特性

**完全无许可：**
- 链上实现
- 验证者保护

**无需AMM或第三方机器人：**
- 直接嵌入区块逻辑
- 原生性能

**自动做市逻辑：**
- 自动在代币当前价格周围放置买卖订单
- 提供持续深度
- 支持价格发现

### 工作原理

```
价格中心点
    │
    ├── 卖单（自动放置）
    │   ├── 价格+0.1%
    │   ├── 价格+0.2%
    │   └── ...
    │
    ├── 买单（自动放置）
    │   ├── 价格-0.1%
    │   ├── 价格-0.2%
    │   └── ...
    │
```

### 实际案例：PURR/USDC市场

当PURR/USDC现货市场推出时，超流动性立即为其注入了初始深度，允许在人类流动性到达之前进行真实交易。这解决了新代币常见的"冷启动"问题——缺乏初始流动性导致交易困难。

### 与Uniswap AMM的对比

| 维度 | HIP-2超流动性 | Uniswap AMM |
|------|---------------|-------------|
| **流动性来源** | 协议内置 | LP提供 |
| **价格滑点** | 低（订单簿模式） | 高（x*y=k曲线） |
| **资本效率** | 高 | 低 |
| **价格发现** | 订单簿驱动 | 算法定价 |
| **无常损失** | 无 | 存在 |

## HIP-3：构建者部署永续合约

HIP-3于2025年10月在主网激活，使任何人都能在HyperCore上直接推出链上永续合约市场，使用HYPE支付部署Gas。

### 核心机制

**市场定义：**
- 部署者定义市场参数（资产、预言机、费用）
- 创建者可获得高达50%的费用分成

**荷兰拍卖机制：**
- Gas通过31小时荷兰拍卖以HYPE支付
- 荷兰拍卖从高价开始，随时间递减直到有人接受
- 帮助发现公平市场价值，避免竞价狂热

**质押要求：**
- 主网需要质押50万HYPE
- 防止垃圾市场
- 对齐市场部署者激励

**安全机制：**
- 验证者可在7天解质押期间惩罚恶意行为者
- 确保市场质量

### 永续合约上市流程

```
步骤1: 部署者定义市场参数
        │
        ▼
步骤2: 发起荷兰拍卖（31小时）
        │
        ├── 拍卖价格递减
        │
        ▼
步骤3: 拍卖成交，支付HYPE
        │
        ▼
步骤4: 市场激活，开始交易
        │
        ▼
步骤5: 创建者获得费用分成
```

### 为什么需要质押要求

50万HYPE的质押要求起到多重作用：

1. **防垃圾**：提高创建市场的门槛，防止低质量市场泛滥
2. **激励对齐**：创建者有动力维护市场质量
3. **风险担保**：质押可作为恶意行为的惩罚基础

## HIPs的意义

每个区块链都需要成长的方式，但大多数依赖治理开销、链下提案或完整协议分叉。HIPs采用不同方式，将升级逻辑直接嵌入HyperCore，使变更模块化、可审查、即时。

### 开发者视角

对于开发者，HIPs意味着：

- **更快迭代**：无需等待漫长的治理流程
- **清晰规范**：每个HIP都是明确的技术文档
- **直接集成**：变更直接实现到链上逻辑

### 协议视角

对于链本身，HIPs意味着：

- **升级不破坏**：模块化设计确保兼容性
- **持续演进**：功能叠加而非替换
- **透明治理**：基于技术就绪度和实现质量评估

## 非DAO投票治理

HIPs不遵循代币加权的DAO投票流程。相反，提案在集成到Hyperliquid链上逻辑之前，基于以下标准评估：

- **技术就绪度**：实现是否完整可靠
- **实现质量**：代码质量是否符合标准
- **协议影响**：对整体生态的影响是否积极

这种治理模式避免了代币加权投票可能导致的大户垄断问题，更注重技术贡献而非资本实力。

## 未来展望

随着Hyperliquid区块链发展，后续提案可能聚焦于：

- **风险引擎**：更复杂的风险管理机制
- **预言机**：去中心化价格数据源
- **验证者工具**：提升网络运营效率

目标是推动更多逻辑上链，消除整个技术栈的摩擦。

## 技术实现细节

### HIP-1代币部署

```python
# 伪代码示例
class HIP1Token:
    def __init__(self, name, symbol, decimals, fungible=True):
        self.asset_id = generate_unique_id()
        self.name = name
        self.symbol = symbol
        self.decimals = decimals
        self.fungible = fungible
        self.balances = {}
    
    def transfer(self, from_addr, to_addr, amount):
        # 首次交互需支付USDC Gas
        if (to_addr, self.asset_id) not in initialized_ledgers:
            pay_gas_fee(from_addr, "USDC", INITIAL_GAS)
            initialized_ledgers.add((to_addr, self.asset_id))
        
        # 后续转账免费
        self.balances[from_addr] -= amount
        self.balances[to_addr] += amount
```

### HIP-2流动性算法

```python
# 简化的超流动性逻辑
class Hyperliquidity:
    def __init__(self, token, spread_bps=10):
        self.token = token
        self.spread_bps = spread_bps  # 基点价差
    
    def place_orders(self, current_price):
        # 在当前价格周围放置买卖单
        mid_price = current_price
        
        # 卖单
        for i in range(1, DEPTH_LEVELS + 1):
            sell_price = mid_price * (1 + self.spread_bps * i / 10000)
            place_order(side="sell", price=sell_price, size=calculate_size(i))
        
        # 买单
        for i in range(1, DEPTH_LEVELS + 1):
            buy_price = mid_price * (1 - self.spread_bps * i / 10000)
            place_order(side="buy", price=buy_price, size=calculate_size(i))
```

## 参考资料

- [Hyperliquid Improvement Proposals (HIPs) 官方文档](https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips)
- [HIP-1: Native Token Standard](https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-1-native-token-standard)
- [HIP-2: Hyperliquidity](https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-2-hyperliquidity)
- [What are Hyperliquid Improvement Proposals (HIPs)?](https://hyperpc.app/blog/hyperliquid-improvement-proposals)

## 总结

Hyperliquid改进提案（HIPs）展示了协议决策如何通过构建者意图而非官僚流程来实现。三个主要提案分别引入了结构（HIP-1代币标准）、流动性（HIP-2超流动性）和无许可市场创建（HIP-3构建者部署永续合约）。

这种治理模式的核心优势在于：

- **模块化升级**：每个提案聚焦特定功能
- **技术导向**：基于实现质量而非代币数量评估
- **即时生效**：无需等待漫长的投票周期
- **透明可审查**：所有变更都在链上可见

对于开发者和项目方，HIPs提供了清晰的协议演进路径。无论是发行新代币、获取初始流动性，还是创建新的永续合约市场，都可以通过标准化的提案流程实现。这种设计为Hyperliquid生态的持续扩展奠定了坚实基础，也为其他区块链项目的治理机制提供了有价值的参考。

Hyperliquid改进提案（HIPs）：代币标准与协议治理机制

# Hyperliquid技术架构深度解析：从共识机制到链上撮合

## 背景

在去中心化金融（DeFi）领域，去中心化交易所（DEX）一直面临一个核心矛盾：如何在保持去中心化的同时，提供接近中心化交易所（CEX）的交易体验？传统DEX如Uniswap采用AMM模式，虽然实现了去中心化，但存在滑点大、资本效率低等问题；而订单簿模式的DEX又面临链上撮合效率低的瓶颈。

Hyperliquid从第一性原理出发，构建了一条专为高性能交易优化的Layer-1区块链，将去中心化交易与区块链基础设施深度融合，实现了在保有资产自托管的前提下，提供近乎CEX级别的交易体验。

## Hyperliquid L1区块链

Hyperliquid不是运行在以太坊或其他链上的应用，而是一条自建的Layer-1区块链。这条链从底层开始重新设计，专为"金融交易/衍生品+订单簿+高频"场景优化。

### HyperBFT共识算法

Hyperliquid采用自主研发的HyperBFT共识算法，这是其高性能的核心基础。HyperBFT的设计灵感来自著名的HotStuff共识协议及其衍生版本，但进行了稳定性的优化和改进。

**共识流程：**

1. **领导者轮换**：共识通过多轮领导者轮换进行，领导者提议区块，验证者通过多轮通信达成一致
2. **权益加权投票**：投票权重与质押量成正比，包括委托存款，采用DPoS（委托权益证明）模型
3. **拜占庭容错**：HyperBFT提供拜占庭容错（BFT），即使高达1/3的验证者恶意行为，区块链仍能正常运行

**性能指标：**

- 订单最终确认时间：约0.2秒（亚秒级）
- 吞吐量：每秒20万订单
- 理论上限：共识算法和网络栈可扩展到每秒数百万订单

### 并行处理架构

传统区块链采用串行处理模式，交易一个接一个执行。Hyperliquid引入"流水线+并发"模式，使多个交易可以同时处理，大幅提升执行效率。

## 双层架构：HyperCore与HyperEVM

Hyperliquid区块链状态分为两个部分：HyperCore和HyperEVM。这种分离创建了两个不同的执行环境，同时保持它们同步。两个环境的安全性都由同一个HyperBFT共识保障。

### 架构层次（自底向上）

```
┌─────────────────────────────────────────────────────────┐
│  前端层 - 应用界面                                        │
├─────────────────────────────────────────────────────────┤
│  应用逻辑层 - 交易和操作的内部逻辑                        │
├─────────────────────────────────────────────────────────┤
│  执行环境层 - HyperCore + HyperEVM                       │
├─────────────────────────────────────────────────────────┤
│  共识层 - HyperBFT确保状态一致性                         │
└─────────────────────────────────────────────────────────┘
```

## HyperCore：链上交易引擎

HyperCore是Hyperliquid协议最核心的部分，既是DEX本身，也是Hyperliquid L1区块链。它是一个直接在区块链层面实现的高性能交易引擎，旨在提供与中心化交易所相当的交易体验，同时保持所有核心机制的链上透明。

### 完全链上中央限价订单簿（CLOB）

HyperCore是一个完全链上的中央限价订单簿（CLOB），维护所有交易对每个订单的完整状态，完全负责：

- 订单创建
- 订单取消
- 订单撮合
- 交易执行

**关键特点：**

- 没有隐藏的订单簿
- 没有链下撮合层
- 每个订单和每笔交易都直接反映在区块链状态中
- 每个动作（下单、取消、执行交易）都是区块链交易

### 订单撮合逻辑

订单撮合逻辑直接嵌入到共识过程中，严格按照价格-时间优先级进行：

1. **价格优先**：价格更优的订单先执行
2. **时间优先**：相同价格的订单，先到的先执行

这种确定性撮合规则在区块链环境中至关重要。所有验证者必须独立得出完全相同的结果。通过强制执行单一规范的撮合结果，HyperCore保证网络状态一致性。

### 为什么HyperCore不是EVM DEX

HyperCore不依赖EVM执行其核心交易逻辑。在EVM内撮合订单会引入不必要的开销并限制性能。相反，HyperCore定义了自己的执行环境，专门为交易定制。这使得Hyperliquid能够结合：

- 确定性链上执行
- CEX级别的性能特征

### 性能实现

HyperCore使用基于Rust的虚拟机实现，专为交易逻辑优化。结合自定义HyperBFT共识，系统实现：

- 亚秒级订单最终确认（测试中平均约0.2秒）
- 每秒高达20万订单吞吐量
- 进一步优化空间

这些性能特征之所以可能，是因为订单撮合和相关操作是HyperCore的原生操作，而非昂贵的EVM调用。

## HyperEVM：智能合约层

HyperEVM不是独立的区块链，而是Hyperliquid L1区块链的扩展，由同一个HyperBFT共识保护。

### EVM兼容性

HyperEVM使用Cancun硬分叉，确保与现有以太坊工具和开发实践完全兼容：

- EIP-1559启用
- 基础费用按标准方式销毁，减少总供应量
- 优先费用也销毁（与其他大多数EVM链不同），发送到零地址

### 双块结构

HyperEVM有独特的区块架构，分为小块和大块：

**小块：**
- 最多200万gas
- 每秒处理
- 适合快速交易和快速订单确认

**大块：**
- 最多3000万gas
- 约每分钟处理
- 适合复杂合约执行，不会阻塞网络

这种结构允许用户和开发者选择操作的优先级：交易者可以依赖小块进行近乎即时的订单执行，而开发者可以高效部署大型合约。

### 与HyperCore的数据交互

HyperEVM最显著的功能之一是与HyperCore的交互方式。通过HyperEVM，开发者可以访问HyperCore的关键链上数据：

**读取数据：**
- 资产价格
- 未成交订单和交易历史
- 用户余额和验证者存款
- 区块链元数据（如区块号）

**写入数据：**
- 直接管理订单
- 链上执行交易
- 实时与交易引擎交互

这意味着智能合约可以作为活跃的市场参与者，执行结构化和可预测的操作，同时保留HyperCore的安全保证。

## 永续合约市场

Hyperliquid支持现货交易和永续合约交易。永续合约需要不同的结算和抵押模型。

### 统一抵押模型

所有永续合约头寸以USDC抵押：

- 跨市场一致保证金计算
- 清晰的清算阈值
- 跨市场标准化风险参数

这一设计选择降低了执行层的复杂性，使状态转换更容易。

### 清算所机制

清算所是Hyperliquid风险管理的核心组件：

- 监控所有头寸的抵押率
- 在抵押不足时触发清算
- 确保系统整体偿付能力

### 资金费率

永续合约使用资金费率机制使合约价格锚定现货价格：

- 每8小时结算一次
- 根据市场多空平衡调整
- 作为系统修正工具

## 团队背景

Hyperliquid Labs是支持Hyperliquid发展的核心贡献者，由Jeff Yan和其哈佛大学同学Iliensinc领导。团队成员来自加州理工学院（Caltech）和麻省理工学院（MIT）等知名机构，曾在Airtable、Citadel、Hudson River Trading和Nuro等公司工作过。团队的高频交易背景为项目带来了深厚的交易系统设计经验。

## 市场表现

截至2025年：

- TVL超50亿美元
- 占据DeFi永续市场75%份额
- 支持40倍杠杆
- 支持跨链交易

## 技术优势总结

| 维度 | Hyperliquid | 传统DEX | CEX |
|------|-------------|---------|-----|
| **去中心化** | 完全链上 | 链上 | 中心化 |
| **撮合效率** | 20万订单/秒 | 受限于链 | 高效 |
| **透明度** | 完全透明 | 透明 | 不透明 |
| **资产托管** | 自托管 | 自托管 | 托管 |
| **滑点** | 低 | AMM高滑点 | 低 |
| **资本效率** | 高 | AMM低效率 | 高 |

## 参考资料

- [Hyperliquid官方文档](https://hyperliquid.gitbook.io/hyperliquid-docs)
- [How Hyperliquid Works: Architecture, Order Book, HyperEVM](https://rocknblock.io/blog/how-does-hyperliquid-work-a-technical-deep-dive)
- [Hyperliquid Wiki - HyperBFT](https://hyperliquid-co.gitbook.io/wiki/architecture/hyperbft)

## 总结

Hyperliquid代表了去中心化交易的一次重要突破。通过从底层构建专用L1区块链，采用创新的HyperBFT共识和双层架构设计，它成功地将CEX级别的性能与DEX的透明和自托管结合起来。

HyperCore作为链上订单簿引擎，实现了亚秒级确认和每秒20万订单的吞吐量；HyperEVM则提供了熟悉的智能合约环境，并能直接访问HyperCore的交易数据。这种架构为开发者打开了广阔的可能性，使他们能够构建直接利用链上流动性和订单簿数据的去中心化应用。

随着DeFi生态的持续发展，Hyperliquid的技术架构为高性能去中心化交易树立了新的标杆，也为后续的区块链性能优化提供了宝贵的设计思路。

Hyperliquid技术架构深度解析：从共识机制到链上撮合

## 背景

随着大语言模型能力的不断提升，我们已经能够构建通用的AI Agent，它们可以与完整的计算环境交互。Claude Code就是典型例子，它能够通过本地代码执行和文件系统完成跨领域的复杂任务。

然而，当这些Agent变得更强大时，我们需要一种更可组合、可扩展、可移植的方式，来为它们提供特定领域的专业知识。这促使Anthropic创造了Agent Skills——一种组织化的指令、脚本和资源文件夹，Agent可以动态发现和加载它们，以在特定任务上表现更好。

## 什么是Claude Skills

Skills是包含SKILL.md文本文件（带有YAML前置元数据）以及任何相关脚本、文档或资源的文件夹。每个Skill"打包"一个特定的工作流程或组织指南。

简单来说，Skills就是：

```
my-skill/
├── SKILL.md          # 核心指令文件
├── reference.md      # 可选：参考文档
├── scripts/          # 可选：可执行脚本
│   └── analyze.py
└── templates/        # 可选：模板文件
    └── output.tmpl
```

与一次性提示不同，Skill明确告诉Claude如何处理一类任务，这样用户就不必每次都重新解释。

## 技术原理：渐进式披露

Skills的核心设计原则是**渐进式披露（Progressive Disclosure）**。这是使Agent Skills灵活且可扩展的关键。

### 三级上下文加载

1. **第一级：元数据预加载**
   - 在会话启动时，Agent仅预加载每个已安装Skill的name和description
   - 这只消耗每个Skill几十个token
   - Claude可以识别哪些Skill可能与用户请求相关，而不会用所有细节淹没提示

2. **第二级：完整SKILL.md加载**
   - 当Claude检测到某个Skill相关时（基于其description或嵌入的示例）
   - 它会将完整的指令和任何链接的文件加载到上下文中

3. **第三级及以上：链接文件按需加载**
   - 对于复杂的Skill，可以将内容拆分到多个文件
   - Claude只在需要时才读取这些额外文件

### 上下文窗口变化示例

```
┌─────────────────────────────────────────────────────────┐
│  初始状态                                                │
│  ┌─────────────────────────────────────────────────┐    │
│  │ 系统提示 + 所有Skill元数据 + 用户消息           │    │
│  └─────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  触发PDF Skill                                          │
│  ┌─────────────────────────────────────────────────┐    │
│  │ 系统提示 + Skill元数据 + pdf/SKILL.md内容       │    │
│  └─────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  按需加载forms.md                                       │
│  ┌─────────────────────────────────────────────────┐    │
│  │ 系统提示 + Skill元数据 + SKILL.md + forms.md    │    │
│  └─────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────┘
```

这种设计意味着Skill可以捆绑的上下文量实际上是**无界的**。

## Skills与代码执行

Skills不仅仅是静态文本，它们还可以包含可执行脚本。这解锁了强大的用例：

### 为什么需要代码执行

1. **效率考虑**：通过token生成来排序列表比简单运行排序算法要昂贵得多
2. **确定性可靠性**：许多应用需要只有代码才能提供的确定性保证
3. **本地数据处理**：保持数据在本地执行环境中

### 示例：PDF表单提取

```python
# extract_form_fields.py
import fitz  # PyMuPDF

def extract_form_fields(pdf_path: str) -> dict:
    """提取PDF中的所有表单字段"""
    doc = fitz.open(pdf_path)
    fields = {}
    for page in doc:
        for widget in page.widgets():
            fields[widget.field_name] = {
                'type': widget.field_type_string,
                'value': widget.field_value,
                'rect': widget.rect
            }
    return fields
```

Claude可以直接运行这个脚本，而无需将脚本或PDF加载到上下文中。

## Skills与MCP：技术对比

| 维度 | Claude Skills | Model Context Protocol |
|------|---------------|------------------------|
| **核心目的** | 嵌入专业知识，精简提示 | 连接外部工具和数据源 |
| **架构** | 文件夹 + SKILL.md | 客户端-服务器协议 |
| **触发方式** | 基于description自动匹配 | 通过tool调用显式触发 |
| **上下文管理** | 渐进式披露，按需加载 | 每次调用返回完整结果 |
| **可移植性** | 跨Claude平台（Claude.ai、Claude Code、API） | 跨AI平台（Claude、ChatGPT等） |
| **创建复杂度** | 简单，只需Markdown | 需要实现JSON-RPC服务器 |
| **适用场景** | 内部工作流、文档处理、品牌规范 | 外部API集成、数据库访问 |

### 互补使用

在实际应用中，两者可以互补：

- **MCP**：从GitHub、数据库、CI系统获取外部数据
- **Skills**：解释数据、应用合规逻辑、生成标准化输出

```
用户请求 → MCP获取数据 → Skill处理数据 → 输出结果
```

## 官方Skills仓库

Anthropic在GitHub上维护了官方Skills仓库：[https://github.com/anthropics/skills](https://github.com/anthropics/skills)

### 仓库结构

```
skills/
├── skills/              # 示例Skills
│   ├── creative/        # 创意与设计
│   ├── development/     # 开发与技术
│   ├── enterprise/      # 企业与通信
│   └── document-skills/ # 文档处理
├── spec/                # Agent Skills规范
└── template/            # Skill模板
```

### 核心文档Skills

仓库中包含了Claude文档能力的底层实现：

- **docx**：Word文档创建与编辑
- **pdf**：PDF处理与表单填写
- **pptx**：PowerPoint演示文稿生成
- **xlsx**：Excel电子表格处理

这些是生产级参考实现，展示了复杂Skill的设计模式。

### 安装方式

#### Claude Code

```bash
# 注册为插件市场
/plugin marketplace add anthropics/skills

# 直接安装特定Skill
/plugin install document-skills@anthropic-agent-skills
/plugin install example-skills@anthropic-agent-skills
```

#### Claude.ai

付费计划的用户可以直接使用仓库中的示例Skills，也可以上传自定义Skills。

#### Claude API

通过`/v1/skills`端点上传和管理Skills，每个请求最多支持8个Skills。

## 创建自定义Skill

### 基本结构

```markdown
---
name: my-skill-name
description: 清晰描述这个Skill做什么以及何时使用
---

# My Skill Name

[添加Claude在此Skill激活时将遵循的指令]

## 示例

- 示例用法1
- 示例用法2

## 指南

- 指南1
- 指南2
```

### 前置元数据要求

只需要两个字段：

- **name**：Skill的唯一标识符（小写，用连字符代替空格）
- **description**：完整描述Skill做什么以及何时使用

### 安全限制

- 不能使用`<>`符号（防止注入攻击）
- 名字不能包含"claude"或"anthropic"（保留词）

### 最佳实践

1. **从评估开始**
   - 在代表性任务上运行Agent，观察它们在哪里挣扎
   - 然后增量构建Skills来解决这些不足

2. **为规模而结构化**
   - 当SKILL.md变得难以管理时，将内容拆分到单独文件
   - 如果某些上下文互斥或很少一起使用，保持路径分离

3. **从Claude的视角思考**
   - 监控Claude在实际场景中如何使用你的Skill
   - 特别注意name和description，Claude用它们决定是否触发Skill

4. **与Claude迭代**
   - 完成任务后，让Claude捕获成功方法和常见错误到Skill中
   - 如果偏离轨道，让Claude自我反思哪里出了问题

## 官方推荐的五种Skill类型

根据大量案例，Anthropic总结了最常见的Skill类型：

### 1. 文档处理型

处理特定格式的文档，如PDF表单填写、Word文档格式化。

### 2. 数据分析型

按照组织特定工作流程分析数据。

### 3. 品牌规范型

确保输出符合公司品牌指南。

### 4. 工作流自动化型

自动化重复性业务流程。

### 5. 代码助手型

提供特定技术栈或框架的专业指导。

## 实际效果

官方数据显示，使用Skills后：

- 工具调用次数减少 **50%**
- Token消耗降低 **一半**
- API错误率归零

## 团队协作

Skills支持团队共享：

1. 将Skills存储在项目的`.claude/skills/`目录中
2. 提交到git仓库
3. 克隆仓库的团队成员自动获得访问权限

```
project/
├── .claude/
│   └── skills/
│       ├── brand-guidelines/
│       └── code-review-standards/
└── src/
```

## 参考资料

- [Anthropic Skills GitHub仓库](https://github.com/anthropics/skills)
- [What are skills?](https://support.claude.com/en/articles/12512176-what-are-skills)
- [Using skills in Claude](https://support.claude.com/en/articles/12512180-using-skills-in-claude)
- [Creating custom skills](https://support.claude.com/en/articles/12512198-creating-custom-skills)
- [Equipping agents for the real world with Agent Skills](https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills)
- [Agent Skills Specification](https://agentskills.io/)

## 总结

Claude Skills代表了AI Agent专业化的一条重要路径。通过将领域知识工程化为可组合的资源，我们可以：

- **降低成本**：通过渐进式披露减少token消耗
- **提高可靠性**：通过确定性代码执行保证一致结果
- **促进协作**：通过文件系统实现团队知识共享
- **保持灵活**：通过模块化设计支持快速迭代

随着Agent Skills成为开放标准，我们有望建立一个丰富的Skill生态系统，让每个组织都能轻松为其AI Agent配备专业技能。