07-13 Hyperliquid 上的 trade[XYZ]：24/7 传统资产永续合约背后的市场控制平面
摘要
从 Lyquor 的视角看，trade[XYZ] 值得研究，因为它让一层常被忽略的金融基础设施变得可见：运营一个市场，远不只是开发交易前端或接入撮合引擎。
核心结论很简单：
HyperCore 提供共享交易引擎。
trade[XYZ] 提供特定于市场的运营层。
这套运营层负责定义传统资产合约，把分散的外部数据转化为可用价格，运行 Relayer，管理风险参数，并处理市场生命周期。
因此，trade[XYZ] 的核心竞争力不是界面，也不是 HyperCore 的撮合能力，而是让整个市场控制平面在不同资产、交易时段和异常事件中持续可靠运行。
这里的“24/7 市场”指 perpetual market 追求连续交易，并不表示 underlying stock、index、commodity 或 FX venue 本身全天候交易。
trade[XYZ] 位于哪一层？
trade[XYZ] 既不只是一个 Hyperliquid 前端，也不是从零重建的一套独立交易所。
| 层次 | 主要职责 |
|---|---|
| HyperCore | 订单簿、撮合、账户状态、保证金检查、funding 结算、清算和 ADL |
| HIP-3 | Builder-deployed perpetual DEX 的原生部署和运营接口 |
| XYZ deployer | 资产定义、风险参数、费用和生命周期 action |
| TradeXYZ Relayer | 外部数据、定价方法、session 管理和高频价格更新 |
| trade[XYZ] interface | 钱包、下单、仓位、历史记录和其他用户工作流 |
HIP-3 通过 Hyperliquid L1 原生 action 将 XYZ 直接接入 HyperCore。用户通过统一的 HyperCore API 交易 xyz: 订单簿；XYZ 没有在 HyperEVM 上另行运营一套撮合引擎。
TradeXYZ 架构文档也说明，其界面不是访问 XYZ markets 的唯一方式，其他兼容客户端可以进入同一组订单簿。
XYZ 使用 HyperCore CLOB，实际可成交流动性仍由市场参与者提供。
这个边界把共享基础设施与 TradeXYZ 特有的能力区分开来：
共享执行基础设施 -> HyperCore
市场专用控制平面 -> XYZ deployer + Relayer
用户访问层 -> trade[XYZ] interface
核心能力一：把传统资产转化为可靠价格
不同传统资产的交易时段、交易场所和定价机制各不相同。股票、股指、原油和非美元计价股票，无法通过同一个通用行情适配器统一处理。
因此，TradeXYZ 需要一套特定于资产的定价方法库：
| 资产类别 | 主要定价工作 |
|---|---|
| 股指 | 现金时段使用 spot，闭市后根据 dated futures 推导 implied spot |
| 美国股票 | 拼接 pre-market、cash、post-market 和 overnight sessions |
| 商品 | 选择合适的 spot 或 futures reference，并维护合约换月 |
| FX | 使用机构 executable quotes，并识别周末闭市或 stale inputs |
| 非美元股票 | 将本地股票价格与实时 FX conversion 组合 |
以股指为例，官方方法会估算并平滑 spot 与 dated futures 的关系，在现金指数不可用时据此推导价格。对商品，Roll Schedules 会让 oracle 在多个工作日内从一个期货合约逐步迁移到下一个合约，而不是在某个时间点突然切换。
这项能力不只依赖数学公式，还包括：
- 可靠的 executable data 和指数使用权。
- Session、holiday、early close 和 daylight-saving calendar。
- Futures expiry 与 roll 配置。
- 本地资产与 FX 市场之间的数据同步。
- Stale data 和外部市场中断的处理规则。
例如，S&P Dow Jones Indices 曾公告授权 TradeXYZ 将 S&P 500 用于相关 perpetual contract。公开公式可以复制，获得授权的数据、生产质量的输入和持续维护的跨资产方法库则更难复制。
核心能力二：把 Relayer 作为生产基础设施运行
TradeXYZ Perp Mechanics Overview 描述了一组 distributed Relayer instances，它们大约每三秒更新一次市场，并通过 HIP-3 setOracle action 发布 oracle prices、mark-price inputs 和 external prices。
Relayer 远不只是转发 feed，它必须：
- 从不同市场采集并标准化数据。
- 根据资产类别和当前 session 应用正确的定价方法。
- 识别 stale 或不可用的外部输入。
- 在 external pricing 与 internal pricing 之间安全切换。
- 在满足协议时间和价格约束的前提下发布更新。
- 从数据源、进程、网络或密钥管理故障中恢复。
核心价格机制可以压缩为四个概念：
| 机制 | 作用 |
|---|---|
| External price | 保留最近一次由外部市场推导的 fair-value anchor |
| Oracle | 外部数据可用时使用外部定价，不可用时使用受约束的订单簿价格发现 |
| Mark price | 将 oracle 相关输入与 HyperCore 本地市场状态组合 |
| Discovery Bounds | 限制闭市价格范围，并在满足条件时重新锚定 |
外部市场关闭时，internal oracle 从最后一个外部值出发，根据 XYZ 订单簿的 impact prices 渐进移动。最终 mark price 还包含由 HyperCore 本地订单簿和成交状态计算的输入。Discovery Bounds 则约束闭市价格发现能够移动多远。
这套设计允许 underlying venue 闭市后继续吸收新信息，但也存在取舍：订单簿帮助塑造 oracle，oracle 又影响 funding、margin 和 liquidation。流动性不足时，价格系统会变得更加反身。
公式是公开的，真正困难的是让 Relayer 持续运行：数据源冗余、校验、监控、failover、部署纪律、incident response 和 updater key security。
核心能力三：运营风险参数与市场生命周期
可靠价格并不等于工作结束。XYZ 还必须管理决定杠杆市场能否安全运行的参数和事件。
HIP-3 deployer interface 提供以下控制能力：
- 合约语义、metadata、精度和 initial oracle。
- Leverage、margin table、margin mode 和 OI cap。
- Funding multiplier 和 interest component。
- Fee 与 Growth Mode。
- 市场 halt、resume、convert 和 settlement。
这些参数相互耦合。更高 leverage 提高资本效率，也增加清算敏感度；更高 OI cap 扩大容量，也要求更深流动性；更快的闭市价格发现能够更早反映信息，也可能放大薄订单簿；cross margin 提高资金利用率，也会连接更多仓位之间的风险。
传统资产还会带来 crypto-native 市场较少面对的运营事件：holiday、early close、futures roll、trading halt、delisting，以及公司或上市状态转换。持续一致地处理这些情况，是长期工程和市场运营能力，而不是一次性部署任务。
哪些能力真正难以复制？
更难复制的部分是：
- 数据接入和特定于资产的定价方法。
- 生产级 Relayer 可靠性。
- Leverage、margin、funding、bounds 和 OI cap 的联合运营。
- 资产上线、换月、暂停、转换和结算流程。
相对不构成核心竞争力的是：
- 基础交易前端。
- HIP-3 markets 共享的 HyperCore 撮合、margin 和 liquidation。
- 公开的 HIP-3 action schema。
- 脱离数据和运营系统的公开定价公式。
因此，把 trade[XYZ] 描述成“一个 Hyperliquid 前端”会低估其产品；把它描述成“一套独立交易所技术栈”又会高估它自行构建的范围。
核心能力背后的运营责任
这些让 trade[XYZ] 形成差异化的能力，也把重要的运营责任集中到同一套系统中。采用这种模式的市场需要清楚回答：谁维护价格输入，异常数据如何处理，以及哪些风险仍由 HyperCore 承担。
Oracle updater 会直接影响关键价格输入，而外部报价聚合和异常值处理无法仅凭公开资料完整复算。当外部 venue 闭市且订单簿深度较低时，internal pricing 也会更依赖它正在测量的本地市场。与此同时，撮合、margin、账户状态和 liquidation 仍然继承 Hyperliquid 的系统风险。
管理这些依赖本身就是产品的一部分。协议 clamp 和 HyperCore 的本地 mark component 可以限制部分故障的影响；长期可靠性仍取决于清晰的权限划分、可观测的 Relayer 表现、带版本的参数以及明确的应急流程。
这为什么与 Lyquor 有关？
对 Lyquor 真正有价值的是这种业务形态，而不是一比一复制 HIP-3。
trade[XYZ] 表明，市场运营本身就是一个应用层。它围绕共享交易引擎组合了数据集成、oracle workflow、风险策略、流动性条件和生命周期控制。
对 Lyquor 来说，机会在于思考：其中哪些能力可以成为相互协调的 Lyquid applications，哪些状态转换需要 sequencing 和共享状态，哪些外部集成必须保持明确。
重点不是让 Lyquor 重建 HyperCore，而是让 specialized financial infrastructure 成为 builders 可以使用的开放构建表面，而不是隐藏在一套固定交易所技术栈中。
结论
trade[XYZ] 最强的技术位置，不是界面，也不是独占一套撮合引擎。
它位于传统市场与 HyperCore 之间的市场控制平面：
资产定义
+ 跨市场定价方法
+ 生产级 Relayer
+ 闭市价格发现
+ 风险参数运营
+ 市场生命周期管理
HyperCore 让市场可以执行；TradeXYZ 更困难的工作，是让传统资产 perpetuals 在连续交易中保持可解释、可运营，并具备足够的安全性。
这才是 Lyquor 最值得研究的核心业务形态。