Logo
新用户订阅 RPC,首月享 6.5 折优惠查看优惠
OnFinality Learn
网络与协议指南阅读约 12 分钟

Hyperliquid 市场结构:永续合约与现货市场技术指南

深入了解 Hyperliquid 永续合约和现货市场的底层运作机制,从订单簿和资金费率到通过 RPC 进行程序化访问。

TL;DR

Hyperliquid 是一条 Layer-1 区块链,拥有链上订单簿,承载永续合约和现货市场,所有结算均由 HyperBFT 共识引擎完成。本指南解释了市场基础要素(订单簿、资金费率、保证金和统一账户),然后逐步介绍通过 RPC 以编程方式查询市场状态的可复现流程。您将学习如何验证连接、获取市场元数据,以及解读订单簿和资金费率数据,并针对常见故障模式提供故障排除步骤。目标是让您对 Hyperliquid 市场形成可用的心智模型,并获得一套可适配自身工具的可运行诊断工作流。

范围与直接答案

Hyperliquid 市场是直接托管在 Hyperliquid Layer-1 区块链上的基于订单簿的交易场所。该网络提供两种旗舰市场类型:永续期货(永续合约)和现货市场,两者均通过 HyperCore 应用层在链上撮合订单。与自动做市商(AMM)DEX 不同,Hyperliquid 使用中央限价订单簿(CLOB),其中买价和卖价按价格-时间优先原则撮合,结算由 HyperBFT 共识机制最终确定。

本文涵盖这些市场的技术结构、如何以编程方式读取其状态,以及基于它们构建时如何诊断连接或数据问题。本文假设您熟悉 JSON-RPC、基本交易概念(买价、卖价、资金费率、保证金)以及运行命令行工具。本文不推荐特定的 RPC 提供商;关于端点选择,请参阅文中链接的 RPC Assistant 指南。

  • Hyperliquid 市场是链上订单簿,而非 AMM 池。
  • 永续合约市场使用资金费率将标记价格锚定至预言机价格。
  • 现货市场结算账户之间的实际资产转移。
  • 所有市场状态均可通过 Hyperliquid JSON-RPC 接口查询。

先决条件与假设

在运行以下流程之前,请确保您具备:可用的 HTTP 客户端(curl、Python requests 或 Node.js fetch)、Hyperliquid 的 RPC 端点 URL(替换占位符 RPC_URL),以及对 JSON-RPC 2.0 请求/响应封装的基本了解。读取公开市场数据无需资金账户;写操作(下单)需要私钥,不在本文范围内。

示例使用标准 JSON-RPC POST 模式。Hyperliquid 的 API 接口包括 info 端点(只读查询)和 exchange 端点(签名操作)。本指南聚焦于 info 端点,因为这是在不冒资金风险的情况下检查市场状态的最安全方式。如果您需要托管端点,请在继续之前查看 RPC Assistant 中的 Hyperliquid RPC 提供商比较。

Hyperliquid 市场机制如何运作

Hyperliquid 的架构将执行层(HyperCore)与通用可编程性(HyperEVM)分离,但两者共享统一状态。市场层为每个资产维护一个订单簿。每个订单簿跟踪挂单买价和卖价,撮合引擎立即执行交叉订单。对于永续合约市场,资金费率机制定期在多头和空头之间转移价值,以使永续合约价格接近标的预言机价格。预言机价格源自外部现货市场,标记价格是用于保证金和清算计算的加权组合。

保证金通过统一账户模型管理。单个账户可以持有抵押品(USDC)和跨多个市场的头寸,支持全仓保证金或逐仓保证金模式。维持保证金要求决定清算价格。当账户权益低于维持保证金时,头寸将面临清算。理解此模型对于解读 API 返回的账户和头寸数据至关重要。

  • 订单簿:链上价格-时间优先撮合。
  • 资金费率:永续合约市场中多空之间的定期支付。
  • 预言机价格:用于标记价格和清算的外部参考价格。
  • 统一账户:跨市场共享抵押品,可配置保证金模式。

使用 curl 查询市场元数据

任何市场集成的第一步是发现存在哪些市场及其参数。Hyperliquid info 端点支持 meta 请求,返回永续合约市场列表、其资产索引和数量小数位数。以下 curl 命令向您的端点发送 JSON-RPC 请求。将 RPC_URL 替换为您的实际端点。

响应包含一个 universe 数组。每个元素包含 name(例如 BTC、ETH)、szDecimals(订单数量允许的小数位数)和 maxLeverage。在提交任何交易之前,使用此元数据验证订单数量和杠杆。如果请求失败,请检查您的端点是否支持 Hyperliquid JSON-RPC 方法命名空间,以及您是否发送了带有 Content-Type: application/json 的 POST 请求。

curl -X POST RPC_URL \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "info",
    "params": {"type": "meta"},
    "id": 1
  }'

使用 Python 获取订单簿和资金费率数据

一旦知道市场名称,您就可以获取实时订单簿和资金费率历史。l2Book 请求返回聚合的买价和卖价档位。fundingHistory 请求返回历史资金费率。下面的 Python 脚本演示了这两种调用并打印摘要。它仅使用标准库,并假设 RPC_URL 已设置为环境变量。

该脚本打印最优买价、最优卖价、价差和最新资金费率。这是一个可复现的测量流程:在不同时间运行它,并将输出记录在表格中以观察价差和资金费率的变异性。不要硬编码预期值;市场条件持续变化。目的是验证您的端点返回格式良好的数据,并且您能够正确解析它。

import os, json, urllib.request

RPC_URL = os.environ["RPC_URL"]

def rpc(method, params):
    payload = json.dumps({"jsonrpc":"2.0","method":method,"params":params,"id":1}).encode()
    req = urllib.request.Request(RPC_URL, data=payload, headers={"Content-Type":"application/json"})
    with urllib.request.urlopen(req, timeout=10) as resp:
        return json.loads(resp.read())

book = rpc("info", {"type": "l2Book", "coin": "BTC"})
bids = book["result"]["levels"][0]
asks = book["result"]["levels"][1]
best_bid = float(bids[0]["px"])
best_ask = float(asks[0]["px"])
print(f"Best bid: {best_bid}, Best ask: {best_ask}, Spread: {best_ask - best_bid:.2f}")

funding = rpc("info", {"type": "fundingHistory", "coin": "BTC", "startTime": 0})
latest = funding["result"][-1]
print(f"Latest funding rate: {latest['fundingRate']} at {latest['time']}")

预期验证结果

运行 curl 和 Python 示例后,您应该观察到:包含 result 对象的 JSON 响应,其中包含 universe 数组(对于 meta)、包含两个价格档位数组(买价和卖价)的 l2Book 结果,以及包含资金费率记录数组的 fundingHistory 结果。如果其中任何一项缺失或格式错误,则端点或请求配置有误。

为验证一致性,请在几秒内运行两次订单簿查询并比较最优买价和卖价。它们可能变化,但结构应保持稳定。将您的观察记录在如下表格中。不要编造数字;用您自己测量的值填写表格。

  • | 测量项 | 第 1 次运行 | 第 2 次运行 | 备注 |
  • | 最优买价 | (您的值) | (您的值) | 来自 l2Book |
  • | 最优卖价 | (您的值) | (您的值) | 来自 l2Book |
  • | 价差 | (您的值) | (您的值) | 卖价 - 买价 |
  • | 资金费率 | (您的值) | (您的值) | 来自 fundingHistory |

常见 RPC 和数据问题故障排除

如果收到 401 或 403,您的端点需要身份验证;请查阅提供商文档。429 表示速率限制;降低请求频率或使用专用端点。JSON-RPC 错误代码 -32601 表示不支持该方法;验证您使用的是正确的方法名(读取查询使用 info)。超时表明网络延迟或端点过载;先使用简单的 meta 请求进行测试。

如果订单簿返回空数组,市场可能流动性不足或币种名称不正确。币种名称区分大小写,必须与 meta 响应中的 name 字段匹配。如果资金费率历史为空,startTime 可能太近;将其设置为 0 以获取所有可用历史。始终记录原始响应以便调试。

  • 401/403:需要身份验证。
  • 429:速率受限;退避或升级。
  • -32601:方法未找到;检查方法名。
  • 订单簿为空:验证币种名称和市场活动。
  • 资金费率历史为空:将 startTime 设置为 0。

局限性与权衡

链上订单簿提供透明性和非托管结算,但也继承了区块链的约束。吞吐量很高(HyperBFT 专为低延迟设计),但公共 RPC 端点可能限速或增加延迟。对于延迟敏感的策略,建议使用专用节点或高级 RPC 提供商;有关选项,请参阅 Hyperliquid RPC 提供商比较。此外,统一账户模型意味着一个市场的清算可能影响其他市场的可用抵押品,因此风险管理必须考虑跨市场敞口。

另一个权衡是数据新鲜度:l2Book 快照是时间点数据。对于实时更新,您需要 WebSocket 订阅,这超出了本指南的范围。最后,资金费率不是预测;它反映过去和当前的市场条件,并且可能快速变化。

在 Hyperliquid 上构建的后续步骤

拥有可用的只读集成后,您可以继续构建监控仪表板、回测管道或告警系统。对于写操作,您需要使用私钥签署交易并提交到 exchange 端点;有关签名详细信息,请查阅官方 Hyperliquid 文档。为提高可靠性,考虑使用专用 Hyperliquid 节点或托管 RPC 服务。关于端点选择,请参阅 RPC Assistant 中关于最佳 Hyperliquid RPC 提供商的指南。

如果您要部署到生产环境,请针对多个端点测试您的集成,并实现带指数退避的重试逻辑。监控错误率和延迟。有关 RPC 概念的更广泛概述,请参阅 RPC 端点指南。有关网络特定详细信息,请访问 Hyperliquid 网络页面。

  • 阅读 Hyperliquid RPC 提供商比较以了解端点选项。
  • 探索专用节点托管以满足低延迟需求。
  • 如果您需要更高的速率限制,请查看 RPC 定价。
  • 查看网络目录以了解其他链。

永远不用担心基础设施

OnFinality 消除了 DevOps 的繁重工作,让您能够更聪明、更快地构建。

开始