Hyperliquid HIP-4 结果市场：机制、API 工作流与验证

HIP-4 为 HyperCore 增添了什么

HIP-4 将结果市场引入 Hyperliquid 的 HyperCore。根据 Hyperliquid 文档，结果是全额抵押的合约，在固定范围内结算，HIP-4 被描述为一种通用原语，适用于预测市场和有界期权类工具。关键架构点在于，结果带来了非线性和有到期日的合约，而没有杠杆或清算，并且它们与投资组合保证金和 HyperEVM 等其他 HyperCore 原语组合。

第一种市场类型是每日根据 HyperCore 上的 BTC 标记价格结算的循环二元结果。多结果市场在设计上被记录为支持，但不属于初始主网发布的一部分，其他功能分阶段推出。将任何特定的市场列表、结算来源或抵押品面额视为需要根据当前文档和实时 API 响应进行确认的事项，而不是从旧文章中假设。

• 全额抵押：不涉及清算引擎。
• 有到期日的合约：每个市场都有到期日和结算规则。
• 双边代币：每个结果市场有两个方向，通常为 Yes 和 No。
• 可组合：设计为与投资组合保证金和 HyperEVM 应用交互。

假设与前提条件

本指南假设你可以访问 Hyperliquid API 端点（info 和 exchange API），并且你有一个可用的 HTTP 客户端。只读检查不需要密钥。下单需要已注资的账户和签名，此处超出范围，仅指出其适用位置。如果你正在为延迟敏感的交易选择端点，具体的提供商决策属于 RPC Assistant；请参阅关于低延迟交易的最佳 Hyperliquid RPC 提供商的指南以及更广泛的HyperEVM RPC 提供商概述。

对于基础设施规划，请注意结果交易是一个类似于现货的 API 表面，但在资产 ID 上有所不同。你的集成不应假设永续风格的资产 ID。文档指引开发者到 asset-ids 页面了解确切的编码。

双重订单簿心智模型

每个结果市场由两个方向组成，每个方向都有一个代币。代币由 outcomeMeta info 端点中的 sideSpecs 标记，通常为 Yes 和 No。同一结果的 Yes 和 No 代币的订单簿合并以共享流动性。以价格 p 买入 Yes 的订单等价于以 1-p 卖出 No 的订单。

在合并订单簿下，价格-时间优先级推广为价格-方向-时间优先级：对于同一合并价格水平的订单，挂单卖单排在所有挂单买单双重订单之前。大多数操作从用户角度抽象了双重订单簿，但文档指出一些人体工程学将在未来的网络升级中改进。一个已记录的示例：如果用户发送的订单既匹配又挂在订单簿上，历史订单可以分别返回主订单和双重订单。

高级用户可以手动拆分和合并结果，以在主余额和双重余额之间转换。对于大多数集成，实用规则是在合并价格空间中推理，让 API 处理双重表示，同时注意订单历史可能显示两条腿。

结算数学与 settleFraction

结算自动将 Yes 转换为 settleFraction 报价代币，将 No 转换为 1 - settleFraction 报价代币。具体来说，二元 yes 结算时 settleFraction = 1，二元 no 结算时 settleFraction = 0。这是核心会计恒等式：在结算时，两个方向总是合计为一个单位的报价资产，这正是合约全额抵押的原因。

对于有界范围或多结果市场，同一恒等式在整个结果集上推广。在构建支付模型时，将每个头寸表示为抵押品单位的分数，并验证所有结果的总和等于一。如果你的模型产生的总和不是一，则你误读了市场定义或结算来源。

def payout(side: str, settle_fraction: float) -> float:
    """Return quote-token payout per unit of collateral for a binary outcome."""
    if side.lower() == "yes":
        return settle_fraction
    if side.lower() == "no":
        return 1.0 - settle_fraction
    raise ValueError(f"unknown side: {side}")

# Example: binary yes settlement
assert payout("yes", 1.0) == 1.0
assert payout("no", 1.0) == 0.0
# Example: binary no settlement
assert payout("yes", 0.0) == 0.0
assert payout("no", 0.0) == 1.0
print("settlement identity holds")

通过 Info API 检查实时市场

outcomeMeta info 端点是市场元数据的真相来源，包括 sideSpecs。每个集成都从获取它并记录原始响应开始。不要硬编码方向标签或市场标识符；它们是数据，不是常量。以下只读脚本仅使用标准库和一个占位端点。

针对你选择的端点运行它，并将返回的市场列表与前端显示的内容进行比较。不匹配通常意味着你指向了不同的网络或过时的缓存。

import json, urllib.request

RPC_URL = "https://YOUR_HYPERLIQUID_ENDPOINT"

def post_info(payload: dict) -> dict:
    req = urllib.request.Request(
        RPC_URL,
        data=json.dumps(payload).encode(),
        headers={"Content-Type": "application/json"},
        method="POST",
    )
    with urllib.request.urlopen(req, timeout=10) as resp:
        return json.loads(resp.read().decode())

meta = post_info({"type": "outcomeMeta"})
print(json.dumps(meta, indent=2)[:2000])

# Extract side labels for each market without assuming Yes/No
for market in meta.get("universe", meta.get("markets", [])):
    sides = market.get("sideSpecs") or market.get("sides")
    print(market.get("name"), "->", sides)

解析结果资产 ID

结果交易使用类似于现货的 API，但在资产 ID 上有关键差异，记录在 Hyperliquid asset-ids 页面上。实用工作流是：获取结果元数据，将每个市场和方向映射到其资产 ID，然后在订单和信息请求中使用该 ID。切勿将现货或永续资产 ID 重用于结果市场。

下面的 curl 示例展示了请求形状。将 RPC_URL 替换为你的端点，如果 info 类型名称已更改，请调整负载类型以匹配当前文档。

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"type":"outcomeMeta"}' \
  | python3 -m json.tool | head -n 80

可复现的验证程序

使用此程序确认你的集成正确读取 HIP-4 数据。它故意是只读的，因此可以在 CI 或笔记本电脑上无需密钥运行。

步骤 1：获取 outcomeMeta 并记录市场数量和方向标签。步骤 2：对于每个市场，获取两个方向的订单簿或 L2 订单簿，并确认合并价格水平与买 Yes 等于卖 No 的恒等式一致。步骤 3：选择一个临近到期的市场，确认结算规则文本与记录的来源匹配。步骤 4：在已知间隔后重新运行同一脚本，并对比输出以检测模式漂移。

将结果记录在如下表中。在实际运行程序之前，将值留空；不要填写估计值。

• | 检查项 | 预期 | 观察值 | 通过/失败 |
• | outcomeMeta 返回市场 | 非空列表 | | |
• | 方向标签存在 | 每个市场两个方向 | | |
• | 合并订单簿恒等式 | 买 Yes p ~ 卖 No 1-p | | |
• | 结算规则文本 | 与文档匹配 | | |
• | 跨运行模式稳定 | 无意外字段 | | |

排查常见集成故障

大多数 HIP-4 集成问题属于几个类别。如果 outcomeMeta 返回空或意外的形状，首先确认端点和网络；测试网端点不会显示主网市场。如果资产 ID 被拒绝，你可能在需要结果 ID 的地方使用了现货或永续 ID。如果订单历史显示一个订单有两个条目，那是当订单既匹配又挂单时记录的主/双重拆分。

如果你的支付模型总和不是一，请重新阅读市场定义和结算来源。如果问题是延迟，请测量而不是猜测：从你的生产区域计时信息请求并比较端点。Hyperliquid 性能比较和专用节点选项是评估基础设施权衡的正确场所。

限制与权衡

HIP-4 被记录为分阶段推出。多结果市场不属于初始主网发布的一部分，一些双重订单簿的人体工程学计划在未来的网络升级中改进。构建你的集成以容忍模式添加和新市场类型，而不是假设固定形状。

全额抵押的结果消除了清算风险，但也消除了杠杆；资本效率与永续合约不同。发现是另一个权衡：Hyperliquid 的前端是为活跃交易者构建的，因此如果你的用户期望浏览式预测市场体验，你可能需要在 API 之上自行构建该层。最后，结算取决于定义的来源；客观、规范的来源减少歧义，但你仍应验证你交易的每个市场的规则。

构建者的后续步骤

一旦只读验证通过，下一步是在测试环境中进行签名订单流，然后是一个监控层，对模式漂移和结算事件发出警报。对于端点选择，使用 RPC Assistant 而不是在代码中嵌入提供商选择；请参阅最佳 Hyperliquid RPC 提供商条目和RPC 定价概述进行容量规划。如果你运营自己的基础设施，在确定拓扑之前，请查看区块链节点托管和网络目录。

保留你所依赖的 info 类型的变更日志，并在任何记录的网络升级后重新运行验证程序。这种纪律是保持结果市场集成在 HIP-4 演进过程中正确的关键。