我们的分析提出一个更具体的 Lyquor 方向：重点不是重建 HyperCore，也不是把 Relayer 当作单体系统原样复制，而是明确分开两类信息：各节点对外部市场可能存在差异的观测结果，以及经过认证和排序后写入共享状态的市场更新。
外部观测 -> 应用级验证 -> certified call
-> 排序 -> 最终生效的共享市场状态
trade[XYZ] 架构文档将 XYZ 描述为一个 HIP-3 DEX：它定义可交易市场、预言机数据源、杠杆上限和其他市场参数；Hyperliquid 负责交易执行与结算；trade[XYZ] 界面只是访问 XYZ 市场的一种方式。
这层分工很重要。正如我们在上一篇 trade[XYZ] 分析中指出的，HyperCore 提供专用交易基础设施，XYZ 运营方则必须让这套基础设施在外部市场闭市后仍能处理这些传统资产。
官方预言机价格规范说明了难点：外部市场开盘时，Relayer 使用外部市场推导的价格；外部输入不可用时，预言机从最后一个外部价格出发，通过受约束的订单簿机制继续更新。运营方还要处理各类资产的数据源、交易时段、节假日休市和期货换月。
这套机制能够运行，是因为外部市场在开盘时为预言机提供锚点，受约束的内部机制则让闭市期间的价格发现得以继续。问题在于，本地订单簿会参与推动一个同时影响资金费率和标记价格计算的预言机。备用定价期间，预言机更新依赖该订单簿的冲击价格。我们的判断是，当流动性较薄时，评估这些输入的质量和抗操纵性就成为风险管理的一部分，而不再只是切换数据源。
真正需要划清的并不是简单的“链下与链上”边界，而是：
| 外部观测 | 应用级决策 | 最终生效的共享状态 |
|---|---|---|
| 数据源响应与时间戳 | 数据源白名单、时效性与异常值规则 | 预言机价格与观测时间 |
| 交易场所与交易时段状态 | 外部、内部或备用定价策略 | 当前生效的定价模式 |
| 候选公允价值计算结果 | 节点门限、聚合与价格边界 | 带版本号的参考价格 |
| 数据源健康状况或生命周期证据 | 权限与生命周期策略 | 停牌、换月或结算操作 |
外部信息可能不完整、延迟、受到许可限制，甚至彼此冲突；共享市场状态仍须按照一套获得授权的规则，以可复现的顺序更新。
Lyquor 当前的 LDK 状态模型提供了划分这条边界所需的基础机制。Instance state 是节点本地状态，可以支持外部 I/O 或非确定性计算；network state 是由共识驱动的共享状态，network function 会在托管同一 Lyquid 的节点上确定性地更新该状态。
类似 trade[XYZ] 的市场运营方可以探索下面这套候选工作流：
传统交易场所、交易日历与参考数据
|
v
Instance functions：获取、标准化、计算、检查新鲜度
|
v
Instance state：本地观测 + 数据源健康证据
|
v
预言机策略：提议、聚合、验证目标调用
|
v
证书 + sequencing backend
|
v
Network function：更新最终生效的价格或生命周期状态
|
v
风险模块、市场服务、钱包与监控系统
Lyquor 预言机框架支持两种模式：直接验证一个目标调用，或先聚合多个节点的本地观测，再验证聚合结果。文档示例会等待足够的节点输入、取中位数、形成 certified call，并提交到 sequencing backend。Runtime 负责协议元数据、签名、证书聚合与目标绑定；应用级验证策略仍由开发者负责。
这是一种候选映射，不表示 Lyquor 当前已经提供生产级传统资产预言机。真实实现仍要定义允许使用的数据源、时间戳规则、异常值处理、节点门限、回退机制、更新者权限，以及证书究竟授权哪一种状态转换。
这套工作流也不会提供交易执行场所或流动性。生产市场仍然需要撮合、抵押品与清算基础设施、做市商，以及一套明确接口，把最终生效的运营状态交给实际使用它的交易系统。
这套工作流还依赖另一项设计区分：业务模块属于 Lyquid 应用；执行与协调则是 Runtime 提供的能力。
| 业务职责 | 可能的 Lyquid 应用逻辑 | 使用的 Lyquor 能力 |
|---|---|---|
| 市场数据 | 数据源适配器、标准化、交易时段逻辑 | Instance function、本地状态、HTTP 访问 |
| 预言机策略 | 节点门限、聚合与验证规则 | 预言机认证与排序 |
| 风险策略 | 敞口上限与参数更新 | 确定性 network function 和 network state |
| 生命周期 | 节假日、换月、停牌与结算条件 | Instance function、certified call、有序的网络状态更新 |
| 外部访问 | 状态、监控、钱包或机器人接口 | HTTP 或 Ethereum ABI 导出接口 |
这张表不表示每项职责都要拆成一个独立 Lyquid。一个 Lyquid 可以同时包含多个 instance function 和 network function。如果数据接入、风险策略和生命周期逻辑由同一团队负责，且共享状态不变量、发布周期和故障响应流程，把它们放在一个应用中可能更合理。
当某条边界需要独立权限、升级、故障隔离、扩缩容或复用时，拆分可能更合理。服务多个市场的定价服务可能适合成为独立应用；特定市场的停牌策略则可能更适合与其他生命周期规则放在一起。拆分的代价，是应用之间必须显式协调，而不能直接访问同一 Lyquid 内多个函数所共享的状态。
如果为了复用而独立拆分，候选定价 Lyquid 就不再只是内部辅助模块：它可以把经确认的价格和数据源健康状况证据作为服务，提供给多个市场应用。复用也会把依赖关系传递给下游应用，调用方仍需面对接口版本、显式权限，以及定价应用不可用或降级时的行为定义。
这套候选架构可以提高关键边界的可见性，却不会自动让每项输入和政策变得可信。
| 层次 | 可以建立的证据 | 仍未解决的问题 |
|---|---|---|
| 外部采集 | 哪个数据源在何时返回了什么数值 | 数据使用权、交易场所质量、隐性故障 |
| 应用级验证 | 哪套节点门限与领域规则接受了提议 | 定价方法在经济上是否合理 |
| 认证与排序 | 谁授权了调用，它被放入排序序列的哪个位置 | 被授权的策略本身是否正确 |
| 网络执行 | 哪个确定性状态转换得到执行 | 流动性、市场操纵和参数质量 |
| 运营 | 监控、版本与事件记录 | 恢复目标与应急权限归属 |
右栏列出的正是距生产可用仍有的缺口。认证可以证明一条既定验证路径授权了某个具体调用；确定性执行可以让节点一致应用这个调用。但二者都无法证明闭市期间的公允价值一定正确、薄订单簿一定适合参与定价，或备用定价策略应该继续生效。
因此，我们探索的是一个更有限、也更容易验证的判断：Lyquor 可能让开发者把市场运营表达为状态和权限边界清晰、可检查的应用。它是否比专用 Relayer 更安全，仍取决于应用层的策略、证据、运营模型和恢复流程。
我们对 trade[XYZ] 的分析表明，连接外部交易场所和共享交易基础设施的市场运营层，可能是最难构建的能力之一。Lyquor 可能提供一条路径，让这层能力可编程，同时不把 Runtime 提供的基础机制当作金融判断的替代品。
核心结论可以压缩为：
Instance 层可以观测外部现实；
只有经过验证并按明确顺序执行的状态转换，才应写入共享市场状态。
下一步需要回答一个具体问题：一条传统资产价格更新至少应携带哪些证据，并遵循怎样的备用策略，才能通过 certified call 影响风险或结算？ 这应该是下一轮原型验证的边界。
从 Lyquor 的视角看，trade[XYZ] 值得研究，因为它让一层常被忽略的金融基础设施变得可见：运营一个市场，远不只是开发交易前端或接入撮合引擎。
核心结论很简单：
HyperCore 提供共享交易引擎。
trade[XYZ] 提供特定于市场的运营层。
这套运营层负责定义传统资产合约，把分散的外部数据转化为可用价格，运行 Relayer，管理风险参数，并处理市场生命周期。
因此，trade[XYZ] 的核心竞争力不是界面，也不是 HyperCore 的撮合能力，而是让整个市场控制平面在不同资产、交易时段和异常事件中持续可靠运行。
这里的“24/7 市场”指 perpetual market 追求连续交易，并不表示 underlying stock、index、commodity 或 FX venue 本身全天候交易。
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 在多个工作日内从一个期货合约逐步迁移到下一个合约，而不是在某个时间点突然切换。
这项能力不只依赖数学公式，还包括：
例如，S&P Dow Jones Indices 曾公告授权 TradeXYZ 将 S&P 500 用于相关 perpetual contract。公开公式可以复制，获得授权的数据、生产质量的输入和持续维护的跨资产方法库则更难复制。
TradeXYZ Perp Mechanics Overview 描述了一组 distributed Relayer instances，它们大约每三秒更新一次市场，并通过 HIP-3 setOracle action 发布 oracle prices、mark-price inputs 和 external prices。
Relayer 远不只是转发 feed，它必须：
核心价格机制可以压缩为四个概念：
| 机制 | 作用 |
|---|---|
| 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 提供以下控制能力：
这些参数相互耦合。更高 leverage 提高资本效率，也增加清算敏感度；更高 OI cap 扩大容量，也要求更深流动性；更快的闭市价格发现能够更早反映信息，也可能放大薄订单簿；cross margin 提高资金利用率，也会连接更多仓位之间的风险。
传统资产还会带来 crypto-native 市场较少面对的运营事件：holiday、early close、futures roll、trading halt、delisting，以及公司或上市状态转换。持续一致地处理这些情况，是长期工程和市场运营能力，而不是一次性部署任务。
更难复制的部分是：
相对不构成核心竞争力的是：
因此，把 trade[XYZ] 描述成“一个 Hyperliquid 前端”会低估其产品；把它描述成“一套独立交易所技术栈”又会高估它自行构建的范围。
这些让 trade[XYZ] 形成差异化的能力，也把重要的运营责任集中到同一套系统中。采用这种模式的市场需要清楚回答：谁维护价格输入，异常数据如何处理，以及哪些风险仍由 HyperCore 承担。
Oracle updater 会直接影响关键价格输入，而外部报价聚合和异常值处理无法仅凭公开资料完整复算。当外部 venue 闭市且订单簿深度较低时，internal pricing 也会更依赖它正在测量的本地市场。与此同时，撮合、margin、账户状态和 liquidation 仍然继承 Hyperliquid 的系统风险。
管理这些依赖本身就是产品的一部分。协议 clamp 和 HyperCore 的本地 mark component 可以限制部分故障的影响；长期可靠性仍取决于清晰的权限划分、可观测的 Relayer 表现、带版本的参数以及明确的应急流程。
对 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 最值得研究的核心业务形态。
HyperCall 之所以值得参考，不只是因为它是一个期权产品，而是因为它展示了一个专业市场应用如何接入更大的交易系统。
在 Hyperliquid 上，HyperCall 并没有试图把每一笔期权订单、报价、成交、风控检查和生命周期事件都变成直接的链上合约动作。它更现实的形态是混合式的：HyperCall Backend 负责快速交易场所逻辑，HyperEVM 提供账户和执行边界，HyperCore 提供流动性、清算状态、oracle 数据和 hedge 市场这些金融底座。
对 Lyquor 来说，启发不是照搬这套架构。一个 HyperCall-like market 如果构建在 Lyquor 上，更可能采用另一种分工：
Lyquor network -> settlement、deposit、withdrawal、账户边界、checkpoint
Lyquid instance -> matching、RFQ/RPI-style workflow、quote、order book、快速市场状态
这个差异很重要。HyperCall 的快速期权交易场所在很大程度上依赖 operator-run Backend。Lyquor 则可以把高频业务侧变成更开放的应用能力：任何构建 Lyquid 的团队，都可以利用 instance 能力实现撮合和其他快速市场流程，同时用 network 层锚定需要共享状态、排序和 settlement 的部分。
HyperCall 和 Hyperliquid 的关系，才是最重要的模式。
HyperCall 不只是一个 options UI，也不只是一组合约。它是一个构建在 Hyperliquid 现有金融基础设施旁边的市场系统。
从高层看：
HyperCall Backend -> 低延迟交易场所逻辑
HyperEVM -> 可编程账户和 settlement 边界
HyperCore -> 流动性、清算状态、oracle 数据和 hedge execution
这个分工是合理的，因为 options market 本身很重。它需要 order book、做市商报价、RFQ、retail price improvement、保证金检查、到期处理、settlement、清算，以及 hedge 流动性。有些部分需要速度，有些部分需要可验证的资产边界，还有一些部分依赖底层 perp 和 spot market。
所以更大的启发不是“把 options 放到链上”，而是：
专业市场需要一个靠近共享金融底座的快速执行面。
在 Lyquor 上，同类业务应该从 network / instance 分工开始设计。
network 层更适合承载慢速、最终、共享状态相关的动作：
instance 层更适合承载高频市场行为：
这并不是说 instance 层只是另一个中心化 Backend。关键在于，instance 是 Lyquid 的应用能力。开发者可以用它定义一个市场的快速路径，同时仍然依赖 network 层处理需要共享排序和 settlement 的部分。
这会让 Lyquor 在链下速度和链上 finality 之间有更丝滑的衔接。快速路径不需要等待每一次 network-level state transition，而 settlement 路径也不需要承载每一次 quote、cancel 和 match。
HyperCall 围绕的是对 Hyperliquid 的特定接入：
Backend + HyperEVM + HyperCore
Lyquor 的方向会更接近：
Lyquid instance + Lyquor network
这个概念分工更小，但开放性更强。
在 HyperCall 中，快速交易场所主要由 HyperCall Backend 运行。开发者和做市商可以接入它，但他们接入的是一个特定 venue system。
在 Lyquor 上，目标可以更进一步。高频层本身可以成为开发者构建的东西。一个 Lyquid 可以在 instance 层定义自己的 matching logic、RFQ flow、quote rule、market-maker interface 和 risk policy。network 层则负责锚定资产和 settlement 边界。
这是最关键的架构差异：
Hyperliquid 提供专业交易基础设施。
Lyquor 提供构建专业交易基础设施的能力。
对于 HyperCall-like market 来说，这会让 Lyquor 在系统里最关键的部分，也就是快速市场层上更加开放。不同团队可以构建不同的 venue、matching model、liquidity program 或 derivative product，而不必等待基础网络原生支持每一种市场结构。
难点不在于简单判断某个东西是“链上”还是“链下”。真正重要的是，每一层到底承诺什么。
对 Lyquor market 来说，更有用的边界是：
快速市场状态 -> 由 instance-level market logic 产生
Canonical settlement state -> 由 network 层锚定
order、quote、cancel、RFQ 和 matching 应该属于快速侧。deposit、withdrawal、settlement、最终 accounting 和共享 checkpoint 应该属于 network 侧。
这样系统会更诚实。instance 层可以跑得快，因为它没有假装每一个市场事件都是最终 settlement。network 层可以作为 settlement anchor，因为它没有被每一次高频交互压满。
在 Lyquor 上实现 HyperCall-like business，不应该被理解成“重建 HyperCall”。更好的理解方式，是学习它背后的模式。
HyperCall 展示的是：现代金融应用需要一个靠近流动性、账户和 settlement 的快速市场层。Lyquor 可以用不同方式表达同一个模式：用 instance 承载 matching 和其他高频流程，用 network 承载 settlement、deposit、withdrawal 和 canonical state。
这才是核心 thesis。Lyquor 不需要复制 Hyperliquid 的具体架构。它可以为开发者提供一种更开放的方式，让他们自己构建专业市场基础设施。
]]>从 Lyquor 的视角看，HyperCall 的价值不只是“一个期权产品”，而是它展示了当一条链已经具备专业交易基础设施、共享账户状态、oracle 数据和可编程应用层之后，会自然长出什么样的金融业务形态。
这篇文章把 HyperCall 当作一个参考案例：先理解 Hyperliquid 周围正在出现的业务形态，再反过来思考，如果同一类交易应用构建在 Lyquor 上，撮合、清算、风控、保证金、清算和结算是否可以成为有序执行、共享状态的 Lyquid network applications。
如果把 HyperCall 理解成一个纯链上期权协议，很容易误判它的真实结构。它当前更像一个务实的混合系统：链下专业期权交易系统、HyperEVM 上的账户和可验证执行边界，以及作为底层金融状态的 HyperCore，包括 spot/perp 流动性、清算状态、oracle 数据和未来保证金整合基础。
一句话概括：
HyperCall Backend 负责速度和期权市场结构。
HyperEVM 合约负责所有权、资金边界、结算和链上动作。
HyperCore 提供金融底座：perp、spot、清算、oracle 数据和 hedge 流动性。
这个分工是理解 HyperCall 的关键。HyperCall 并没有把每一笔期权订单、每一次风控检查、每个报价和每次成交都直接塞进 HyperEVM 合约。它把高频、复杂、市场结构相关的部分放在链下，同时用 HyperEVM 和 HyperCore 锚定所有权、结算、资产流转，以及和 Hyperliquid 金融状态的连接。
下面从心智模型、三层架构和主要流程三个角度，拆解 HyperCall 如何连接 Hyperliquid 的金融底座。
理解 HyperCall 最简单的方式，是把它拆成三个连接在一起的层：
Trader / Market Maker / Integrator
|
| REST / WebSocket / EIP-712 signed messages
v
HyperCall Backend
- options order book
- RPI and RFQ workflows
- pre-trade risk checks
- positions, fills, portfolio views
- market data and volatility inputs
- liquidation and settlement orchestration
|
| signed commands / state sync / user actions
v
HyperEVM Contracts
- Exchange
- Account
- Processor
- Registry
- option tokens
- RSM command execution
|
| ActionCaster / CoreWriter-style dispatch
v
HyperCore
- spot and perp order books
- clearinghouse state
- balances and positions
- oracle, mark, and index prices
每一层承担的职责不同。
HyperCall Backend 是期权交易场所实际运行的地方。它接收订单、执行撮合逻辑、管理 RPI 和 RFQ 流程、在订单进入市场前检查保证金、跟踪仓位、推送 WebSocket 更新，并协调风险事件。
HyperEVM 是合约和账户边界。HyperCall 可以在这里表达所有权、充值、提现、账户权限、option token 注册、结算相关动作、清算拍卖，以及带签名的风险指令。
HyperCore 是 Hyperliquid 的底层金融状态。Spot 和 perp 订单簿、清算状态、余额、仓位，以及 oracle-driven prices 都在这里。HyperCall 使用这个底座来做 hedge、取数据、确定结算参考，并为未来更深的保证金整合铺路。
期权交易场所不只是 token wrapper。一个严肃的期权交易场所需要订单簿、做市商报价、面向多腿组合的 RFQ、retail price improvement、保证金检查、波动率曲面、结算规则、清算处理，以及和 hedge 市场的可靠连接。
这意味着大量状态和大量事件流。有些部分需要速度和运营灵活性。有些部分需要清晰的资金和结算边界。有些部分依赖外部金融状态，尤其是做市商用来对冲 delta 的 perp 市场。
HyperCall 的架构正是在反映这种分工：
低延迟交易场所逻辑 -> HyperCall Backend
可验证账户和执行边界 -> HyperEVM 合约
Hedge 场所和金融状态 -> HyperCore
所以不应该把 HyperCall 描述成“完全在 HyperEVM 上实现的期权”。HyperEVM 很重要，但它不是整个交易场所。它是围绕更大交易系统建立的可编程链上边界。
它也不只是 HyperCore 的一个前端。HyperCore 并不原生提供 HyperCall 需要的期权交易场所逻辑。HyperCall 是在 Hyperliquid 已有交易基础设施旁边增加了期权专用层。
Backend 负责系统中最像专业交易所引擎的部分：
这不意味着 Backend 只是一个方便层。它是当前信任模型和执行模型的核心部分。在 Mainnet Alpha 中，期权逐笔撮合并不会逐笔记录到链上。Backend 是实时期权交易场所运行的地方。
这种设计让 HyperCall 可以支持一些很难用简单 Solidity 合约表达的市场结构：RFQ、RPI、多腿组合、做市商保护、volatility-driven risk logic，以及实时 portfolio view。
HyperCall 的链上组件部署在 HyperEVM 上。理解它们时不需要记住每个地址，关键是分清角色：
Exchange 是账户、资金、拍卖、RSM 指令和面向 HyperCore 动作的主入口。Account 代表用户的链上账户边界。Processor 负责验签和动作编码。Registry 和 option token 合约管理受支持的期权资产。核心点是，HyperEVM 给 HyperCall 提供了一个贴近 HyperCore 的可编程所有权和执行边界。用户可以使用 EVM-style 账户、签名、合约调用、token 流转和可验证状态迁移，同时不需要把整个交易场所从 Hyperliquid 旁边搬走。
HyperCore 不属于 HyperCall。它是 Hyperliquid 的核心交易和金融状态层。对 HyperCall 来说，它有几层意义。
第一，它是 hedge 场所。HyperCall 的期权流动性 thesis 依赖做市商能够围绕 Hyperliquid 深度 perp 流动性对冲 delta。
第二，它是数据源。Hyperliquid 的 oracle、mark、index、balance、clearinghouse 和 position 数据，都是定价、结算、风险视图和未来 portfolio margin 的重要输入。
第三，它是执行目标。HyperCall 可以接收某些签名后的 perp 或资产动作，并通过 HyperEVM 合约路径把它们送入 HyperCore。
第四，它是长期整合目标。路线图指向更深的 cross-margin，以及未来让 options 更直接地被 HyperCore margin system 识别。这不是当前 Mainnet Alpha 的状态，但它解释了方向。
HyperCall 把账户所有权和交易权限分开。
Manager 通常是用户主钱包，控制账户。Manager 可以执行提现、转账、agent 管理等高权限动作。Agent 或 API wallet 可以签交易相关消息，但不应该拥有和 manager 一样的权限。
这很重要，因为期权交易场所里不同动作的风险完全不同。下单和撤单需要足够方便。移动资金或改变账户控制权则必须受到更强保护。
大致流程是：
Manager wallet
-> 通过 Exchange 创建或控制 Account
-> 授权 trading agents
-> 签署高权限账户动作
Agent / API wallet
-> 签署交易消息
-> 通过被允许的接口下单或撤单
期权交易路径从用户签名意图开始，但撮合本身由 HyperCall Backend 处理。
用户或做市商签署订单
-> HyperCall Backend 验签并检查风险
-> 订单进入 order book、RPI 或 RFQ 流程
-> 成交更新 Backend 中的仓位和 portfolio state
-> 用户通过 REST 和 WebSocket 观察状态
-> 选定状态或指令同步到链上边界
关键点是，期权 order book、RFQ 和 RPI 都属于 HyperCall 的交易场所层。它们不是 HyperCore 原生 perp 和 spot 订单簿的一部分。
这是一个务实设计。期权市场结构比简单单品种下单复杂得多。多腿组合、做市商报价响应、portfolio view 和 volatility-driven checks，更适合在专门的交易场所 Backend 中运行。
Perp 和资产动作走另一条路径。HyperCall 可以接收签名后的指令，并通过 HyperEVM 合约系统把它们送向 HyperCore。
概念上可以这样理解：
用户或 agent 签名动作
-> Exchange 验证权限和 nonce
-> Processor 编码动作
-> ActionCaster / CoreWriter-style dispatch
-> HyperCore 执行 perp order、cancel 或 asset action
这条流程是 HyperEVM 和 HyperCore 直接相遇的地方。HyperEVM 提供合约验签和编码边界。HyperCore 仍然是底层 perp 或资产动作真正执行的地方。
从架构层面看，更有用的心智模型是：ActionCaster 是 HyperCall 把经过验证的 HyperCall-side intent 转成 HyperCore-compatible actions 的抽象。
期权需要生命周期规则。它们会到期、结算，有时还会触发清算。
HyperCall options 是 European-style、cash-settled。到期时，新订单被拒绝，open orders 被取消，结算价由 Hyperliquid oracle 数据确定，仓位按照 intrinsic value 关闭。
清算更复杂。Backend 风险系统监控账户健康状态，链上合约系统则为清算拍卖和 RSM 指令执行提供边界。RSM 是 Risk and Settlement Manager，可以理解成把风险或结算决策转成可通过合约层执行的指令机制。
简单说：
风险系统发现需要执行的动作
-> 生成并签署 RSM command
-> HyperEVM 合约验证并执行受支持动作
-> 清算、结算、repay 或 rebalance 结果在链上可见
这也是当前系统最重要的信任边界之一。
HyperCall Mainnet Alpha 有真实链上组件，也涉及真实资金，但不应该被理解成完全 trustless 的期权交易所。
链上可验证的一侧包括：
仍然需要信任 operator 的一侧包括：
这不是一个小细节，而是当前架构的核心。HyperCall 用合约定义资金和执行边界，但实时期权交易场所仍然依赖 operator-run Backend 来完成撮合、风控、数据和编排。
路线图指向通过 RSM decentralization、更广的保证金支持、writer access、physical settlement 和更深的 HyperCore margin integration 来降低这种信任。但当前架构和未来路线图不应该被混在一起理解。
HyperCall 有价值，是因为它展示了 Hyperliquid 周围一种具体的应用形态：
专业金融应用
+ 可编程链上边界
+ 高性能金融核心
这种形态不同于部署在通用链上的普通 DeFi 应用。HyperCall 构建在 hedge 流动性、oracle 数据、清算状态和用户资产已经存在的交易环境旁边。
它也不同于完全中心化交易所。HyperEVM 账户、合约调用、结算路径和 HyperCore 动作，提供了传统交易所后端通常不会自然暴露的可验证边界。
结果是一种混合交易所设计：
在延迟和市场结构要求高的地方中心化。
在所有权、结算和执行边界重要的地方链上化。
在流动性、hedge 和金融状态重要的地方 HyperCore-native。
这是今天理解 HyperCall 更合适的方式。
HyperCall 可以概括为：
HyperCall Backend:
期权交易场所逻辑、撮合、RPI、RFQ、保证金检查、仓位、行情数据和编排
HyperEVM Contracts:
账户、权限、充值、提现、option tokens、结算、清算和经过验证的动作路径
HyperCore:
spot/perp 流动性、clearinghouse state、oracle 数据、余额、仓位和 hedge execution
最重要的架构启发不是“期权交易的每个部分都已经上链”。更准确地说，HyperCall 把一个专业期权交易场所放在 Hyperliquid 金融核心旁边，再用 HyperEVM 围绕账户、资产、结算和部分执行流程画出可编程、可验证的边界。
这让 HyperCall 成为观察 Hyperliquid 应用层金融产品如何发展的一个有用案例：它不是孤立智能合约，也不是普通中心化服务，而是围绕专业链上金融栈构建的混合系统。
对 Lyquor 来说，重点不是复制 HyperCall 现在的 Backend、合约和 HyperCore 分工。更重要的启发是，现代金融应用需要的不只是孤立合约，还需要有序执行、共享状态、具备风控能力的业务模块、结算逻辑和外部集成界面。Lyquor 的 thesis 是，这些部分可以被表达成有序执行的 Lyquid network applications，而不是被迫二选一地放进中心化 Backend 或孤立的 EVM 合约里。
HyperCore 和 Lyquor 最清楚的区别，不只是性能、EVM 兼容性，或者应用是否可以部署在交易系统周围。更深层的区别是：金融基础设施到底由谁定义。
HyperCore 把专用金融基础设施作为 Hyperliquid 系统的一部分来提供。订单簿、撮合、清算、保证金、强平和核心账户状态，都属于链级交易环境的一部分。Lyquor 走的是另一条路：它把构建专用金融基础设施的能力开放给开发者和用户，让这些能力可以作为带有排序、共享状态和 runtime 能力的 Lyquid network applications 来实现。
一句话概括：
HyperCore provides specialized financial infrastructure.
Lyquor provides the capability to build specialized financial infrastructure.
HyperCore 的强大之处在于，它给 Hyperliquid 提供了一个专门构建的交易核心。核心金融服务已经在那里：订单簿、撮合、清算、保证金、强平、oracle-driven state、vaults、assets 和账户状态。围绕 Hyperliquid 构建的应用，可以依赖这个已有的金融引擎，而不是从零开始搭建。
这种设计形成了很强的产品形态。流动性、账户状态和结算彼此接近。交易应用可以集成到一个共享的金融环境中。HyperEVM 再在这个环境周围增加一个可编程应用层，让开发者可以使用 Ethereum-compatible 的 contracts、wallets、ABIs、JSON-RPC workflows 和生态集成方式。
这也是为什么 Hyperliquid 正在变成不只是 perp 交易所。HyperCore 给它提供专用交易基建，HyperEVM 则让这套基建更可编程。
但边界也很重要。核心金融基础设施仍然是由 Hyperliquid 提供的。外部应用可以访问它、围绕它组合、在它附近构建产品，但它们并不是主要在自己定义底层的撮合、清算、风控、保证金或结算系统。
Lyquor 从另一个前提出发。它不是把交易核心看成固定的链级服务，而是把金融基础设施看成开发者可以构建的 network applications。
在 Lyquor 的模型里，撮合、清算、风控、保证金、强平、oracle settlement 和账户管理等模块，都可以表达成 Lyquid applications。这些应用由 sequencing 排序，由节点执行，并通过共享网络状态和 runtime 能力进行协同。
这改变了平台的产品含义。Lyquor 不只是一个让开发者围绕既有交易核心部署 contracts 的环境。它是一个让开发者可以构建交易核心本身的环境。
一个简化的 Lyquor 交易系统可以是：
Match Lyquid:
Order submission, cancellation, matching, fills, and strategy execution
Clear Lyquid:
Accounts, balances, positions, collateral, margin, and settlement
Risk Lyquid:
Portfolio margin, stress scenarios, liquidation thresholds, and market-maker protections
Oracle / Settlement Lyquid:
Price updates, settlement rules, expiry workflows, and market definitions
这些不是协议外部漂浮的 backend services。它们可以成为被统一排序驱动的 Lyquid network applications。关键在于，金融基础设施变成了可以在应用层被构建、检查、升级和组合的东西。
对简单应用来说，这个区别听起来可能有些抽象。但对复杂金融系统来说，它非常关键。
金融应用不只是余额之上的用户界面。它们经常需要自己的基础设施逻辑：订单优先级、撮合规则、保证金模型、强平机制、结算价格、market-maker protections、跨产品风险和带权限的运营流程。
如果基础设施内置在链里，应用继承的是一个强大的共享底座。这是 HyperCore 的模式。它给开发者一个高性能金融系统，让开发者在附近构建，但最底层的金融规则仍然属于一个专用核心。
如果基础设施可以作为应用来构建，开发者就可以定义金融系统本身。这是 Lyquor 的模式。它给开发者的是创造市场结构的工具，而不只是集成一个现有市场结构的接口。
更清晰的对比如下：
| Dimension | HyperCore | Lyquor |
|---|---|---|
| Core role | Built-in specialized trading infrastructure | Capability to build specialized trading infrastructure |
| Financial logic | Provided by the Hyperliquid core system | Defined by Lyquid application developers |
| Application layer | HyperEVM contracts around HyperCore | Sequenced Lyquid network applications |
| State model | Core financial state exposed through controlled interfaces | Shared network state coordinated by runtime capabilities |
| Main strength | Unified high-performance trading environment | Open construction of custom financial infrastructure |
这也解释了透明性上的区别。
Lyquor 是透明的，因为金融逻辑可以被定义为 application logic。撮合规则、清算规则、保证金模型、强平逻辑、oracle settlement 和风险参数，都可以表达成可部署模块。开发者和用户可以检查一个金融系统如何运行，因为这个系统是由可见的应用组件构建出来的。
HyperCore 从外部看相对不透明，因为最重要的金融机制属于专用核心。用户和开发者可以观察行为、使用 API、围绕它构建应用，但核心金融引擎并不是每个开发者都可以定义和重组的 application。
这不应该被写成简单的缺点。HyperCore 的一体化设计也正是它能够提供统一、高效交易环境的原因。它的 tradeoff 是：用户获得一套强大的金融基础设施；而 Lyquor 给用户的是构建这套基础设施的路径。
所以 Lyquor 的产品论点不是：
Lyquor is another chain for financial applications.
更准确的说法是：
Lyquor is a platform for building financial infrastructure as sequenced network applications.
这个 framing 很重要，因为现代交易应用需要的不只是 contracts 和 APIs。它们需要 ordered execution、shared state、自定义风险逻辑、oracle workflows、margin systems、liquidation processes，以及面向 market makers、users、wallets 和 external protocols 的 integration surfaces。
Hyperliquid 当前的业务形态证明了专用交易基础设施是有价值的。HyperCore 直接提供这套基础设施。HyperEVM 把它变成一个可编程应用环境。
Lyquor 的不同赌注在于：这类基础设施应该作为 construction surface 向开发者开放。撮合、清算、风控、保证金、强平和结算，不应该只是链提供的服务。它们也可以成为开发者构建、运行、验证和组合的应用。
HyperCore 和 Lyquor 代表了链上金融系统的两条不同路径。
HyperCore 把金融基础设施集中在一个专用的链级交易核心中。这为交易产品和应用层集成提供了一个强大、高效、统一的底座。
Lyquor 则开放了把这类金融基础设施构建成 sequenced Lyquid network applications 的能力。这让基础设施更明确、更可检查，也更开放给开发者定义不同的市场结构。
最简洁的总结是：
HyperCore gives users a specialized financial system.
Lyquor gives users the capability to build specialized financial systems.
这就是关键差异：HyperCore 提供基础设施；Lyquor 暴露构建基础设施的能力。
]]>HyperCall 不只是一个期权交易场所案例，它更适合作为观察 Hyperliquid 业务形态的窗口。Hyperliquid 已经不只是一个高性能 perp 交易所。随着 HyperCore、HyperEVM，以及 HyperCall 这类应用层产品出现，它正在变成一个金融应用平台：HyperCore 是专用交易基建，HyperEVM 在它周围开放可编程应用入口，专业交易产品可以贴近这套金融状态来构建。
对 Lyquor 来说，关键问题是：如果这类业务放到 Lyquor 上，会有什么不同？哪些能力会更自然？哪些地方会形成自己的优势？核心差异是：HyperCore 是一套已经做好的专用交易基建；Lyquor 开放的是让开发者把专用交易基建构建成 Lyquid network applications 的能力。
简短概括：
Hyperliquid 的模式:
专用交易基建 + 可编程应用层 + 专业交易应用。
Lyquor 的机会:
开放构建交易基建的能力，并把它表达成被排序驱动的 Lyquid applications。
Hyperliquid 的核心产品能力是市场结构。HyperCore 提供的是一套专用交易基建：订单簿、spot/perp 流动性、清算、资产、vault、staking，以及 oracle-driven state。这给活跃金融应用提供了很强的底层。
HyperEVM 在这个基础上增加了可编程层。它的作用不只是“支持 EVM”。它是在 HyperCore 旁边给开发者一个熟悉的合约界面，让应用既能使用 Ethereum-style 工具链，又能贴近 Hyperliquid 的流动性和账户状态。
HyperCall 说明了为什么这件事重要。期权交易所不能只是一个前端，也不能只是一个 public API integration。它需要：
所以 HyperCall 的战略价值不只是“SpaceX options” 或 “SP500 options”。它展示的是：专业衍生品应用如何贴着 Hyperliquid 的金融核心构建。
HyperCall 采用混合架构。链下系统处理撮合、做市商交互、RFQ/RPI、行情接入和部分风控。链上组件处理账户、存取款、结算、清算拍卖和关键状态迁移。
HyperEVM 的价值，是让可编程结算层靠近 HyperCore。如果 HyperCall 把结算放在外部链，而自然的对冲场所仍然是 Hyperliquid，系统会被拆开：
把结算放在 HyperEVM，可以减少这种割裂。HyperCall 可以保持 Hyperliquid-native，同时继续暴露 EVM-compatible contracts、addresses、ABIs、wallet signatures 和 JSON-RPC workflows。
这套架构可以概括为：
HyperCore:
高性能订单簿、spot/perp 流动性、清算、资产和核心金融状态
HyperEVM:
可编程账户、抵押品状态、结算逻辑、清算流程、权限控制和可验证状态迁移
HyperCall backend:
撮合、RFQ/RPI 流程、风控计算、行情接入和做市商交互
这是一个务实分工。HyperEVM 不替代撮合引擎，也不替代 HyperCore。它给混合交易所提供可编程结算边界。
Lyquor 的对比不应该从 EVM compatibility 开始，而应该从业务需求开始：这类产品需要有序执行、共享状态、可靠结算、复杂风控逻辑和外部集成能力。
更尖锐的区别是：
HyperCore = Hyperliquid 已经做好的专用交易基建
Lyquor = 开放给开发者构建专用交易基建的能力
所以 Lyquor 版本不应该被描述成 “EVM contracts next to HyperCore”。它更像是把交易基础设施模块实现成被排序驱动的 Lyquid network applications，并由共享网络状态和 runtime capabilities 协调起来。
HyperCall on HyperEVM:
用 EVM 合约作为账户、保证金、结算和清算层，贴近 HyperCore 流动性。
HyperCall-like business on Lyquor:
把账户、保证金、结算、风控和交易所服务基建构建成 Lyquid network applications，
通过 sequencing 保证订单和状态迁移顺序。
这很重要，因为很多交易系统功能更像交易所服务，而不是简单智能合约。Portfolio margin、多腿期权策略执行、清算流程、oracle-driven settlement 和做市商保护，都是复杂、持续演进、强状态的系统。把这些逻辑全部塞进 Solidity 合约，会让系统变贵、变硬，也更难升级。
Lyquor 可以把这些功能表达成节点托管的 Lyquid applications，同时用 sequencing 保证状态迁移有序、可复现。
如果用 Lyquor 构建一个类似 HyperCall 的交易场所，更自然的拆分方式是：
Option Match Lyquid:
订单、RFQ、RPI、撮合和多腿策略执行
Option Clear Lyquid:
账户、余额、期权仓位、抵押品、保证金、清算和结算
Oracle / Settlement Lyquid:
标的价格、TWAP、到期结算价和市场定义规则
Risk Lyquid:
Portfolio margin、压力场景、做市商保护和风控参数
关键点是，这些不是漂在系统外面的独立后端服务，而是被共享 sequencing model 驱动的 Lyquid applications。下单、撤单、成交、保证金更新、oracle 更新、清算触发和到期结算，都进入一个有序流。节点按照这个顺序执行应用逻辑，并更新 network state。
这会让 Lyquor 具备不同的产品特点：
第一个潜在优势是更丰富的执行模型。成熟期权交易场所需要很多在 EVM 约束下很别扭的计算：Greeks、压力场景、组合抵消、跨产品保证金、清算阈值和做市商库存控制。Lyquor 的 runtime model 可以让这些更像交易所核心逻辑，而不是 gas-optimized contract code。
第二个优势是更清楚的排序模型。交易系统需要确定性顺序。Lyquor 显式拆开 sequencing 和 execution：链或排序入口决定顺序，节点执行应用逻辑。这和下单、撤单、成交、保证金更新、清算、oracle 更新、结算等交易所事件非常匹配。
第三个优势是服务拆分。HyperEVM 里最熟悉的单位是 contract。Lyquor 更自然的单位是 Lyquid application。这让复杂交易场所更容易拆成 match、clear、risk、oracle 等组件，同时仍然处在同一个 network execution model 下。
第四个优势是内部灵活性。外部用户仍然可以通过 Ethereum-compatible address、ABI-like interface、JSON-RPC、wallet signature 或 sequencing contract 交互。内部产品则可以使用 Lyquid/WASM 和 runtime capabilities，而不是受 Solidity 和 EVM execution 限制。
第五个优势是更接近交易所运行基础设施。HyperEVM 给 Hyperliquid 应用提供合约结算层。Lyquor 有机会承载更多交易所栈本身：撮合协调、清算、保证金、风控、强平、oracle settlement 和账户状态，都可以成为 sequenced network applications。
代价是熟悉度。HyperEVM 对现有 EVM 开发者和 DeFi 集成方更容易理解。Contract address、wallet、ABI、explorer 和 Solidity code 都是熟悉的。
Lyquor 需要更多解释。它的价值不是“另一条 EVM 链”，而是把应用逻辑作为被排序驱动的 network services 来运行。这对复杂金融系统更强，但也要求更好的产品教育、开发者工具和集成示例。
另一个权衡是成熟度。Hyperliquid 已经有真实流动性和可见的交易用户基础。Lyquor 版本需要证明自己的流动性路径、做市商接入、运行可靠性和外部集成能力。
Hyperliquid 当前方向展示了一个有参考价值的产品模式：
专用交易基建 -> 可编程结算/应用层 -> 专业金融应用
HyperCall 是这个模式的一个例子。它使用 HyperEVM，是因为期权需要贴近 HyperCore 的流动性、对冲、保证金、结算和账户状态。
对 Lyquor 来说，机会不同，而且可能更宽：
Sequencing layer -> Lyquid network applications -> 开发者构建的交易基建
如果说 HyperEVM 让 Hyperliquid 的专用交易基建可以通过 contracts 被编程，那么 Lyquor 开放的是直接把这类交易基建构建成 sequenced network applications 的能力。也就是说，一个 HyperCall-like 产品放在 Lyquor 上，不只是拥有一个结算层。它的撮合、清算、风控、保证金、强平和 oracle-driven settlement 模块，都可以成为协同的 Lyquid applications。
这才是主要产品启发：HyperCore 是专用交易基建；Lyquor 是构建专用交易基建的开放环境。
HyperEVM 的意义不只是“Hyperliquid 支持 EVM 了”。更准确地说，HyperEVM 是 Hyperliquid 在高性能交易核心之外建立的通用应用层：HyperCore 负责订单簿、清算、资产和核心金融状态，HyperEVM 负责让开发者用熟悉的以太坊工具链部署合约、组合应用，并访问 HyperCore 的部分能力。
比较 HyperEVM 与 Lyquor 时，重点不应该是“Lyquor 哪个 VM 等于 HyperEVM”。更合适的比较对象是 Lyquor 的 Lyquid network 层：它同样承担对外应用入口的角色，只是内部不是原生 EVM 合约，而是由 Lyquid/WASM、链上排序入口、节点托管执行和以太坊兼容接口共同完成。
一句话：
HyperEVM: 用 EVM 合约承载 Hyperliquid 的应用层。
Lyquor: 用 Lyquid network 应用承载应用层，再通过以太坊兼容入口对外连接。
Hyperliquid 的核心优势在 HyperCore。它更像一个高性能金融内核，负责交易、清算、预言机、vault、staking 等关键状态。这个内核非常适合做交易系统，但如果所有外部创新都必须直接围绕 HyperCore API 展开，生态扩展会受到限制。
HyperEVM 的必要性就在这里。它给 Hyperliquid 增加了一个开发者熟悉的编程平面：
所以 HyperEVM 不是替代 HyperCore，而是补全 HyperCore。它让 Hyperliquid 从一个强交易系统，进一步变成可以被开发者组合和扩展的金融应用平台。
API 适合做工具接入，但合约层适合做生态。
如果只有 API，外部开发者可以查询数据、执行操作、构建前端或交易工具。但他们很难把自己的应用变成链上可组合的一部分。EVM 合约层带来的不是单个接口，而是一整套开发者习惯：合约地址、链上状态、钱包签名、前端调用、协议组合和第三方集成。
这就是 HyperEVM 的关键价值。它把 HyperCore 的交易流动性和金融状态，放进以太坊开发者可以理解和复用的应用模型里。
Hyperliquid 的文档也体现了这种分工：HyperEVM 有自己的 RPC、chain ID 和 EVM 交互方式；同时，它又可以通过预编译读取 HyperCore 信息，并通过系统合约向 HyperCore 发送动作。这说明 HyperEVM 不是孤立的“另一条 EVM 链”，而是 Hyperliquid 应用层和核心金融状态之间的连接层。
要理解 Lyquor 与 HyperEVM 的关系，关键不是寻找单独某个 VM 模块，而是看 Lyquid network 层整体。
原因很简单：HyperEVM 对外呈现的是“开发者部署合约，用户调用合约，合约状态随交易变化”。而 Lyquor 对外呈现的更像是“开发者部署 Lyquid 应用，链上排序入口给出调用顺序，节点托管执行应用逻辑，network state 形成全网一致状态”。
它们要解决的问题相近：都希望让应用可以被外部用户访问、被链上顺序驱动、被开发者组合，并尽量兼容以太坊生态的入口。
但实现方式不同：
| 维度 | HyperEVM | Lyquor Lyquid network |
|---|---|---|
| 开发者模型 | 部署 EVM 合约 | 部署被节点托管的 Lyquid 应用 |
| 应用执行 | 原生 EVM 合约执行 | Lyquid/WASM 运行时执行 |
| 外部入口 | JSON-RPC、钱包、合约地址 | 以太坊兼容 RPC、合约入口、Lyquor 原生服务入口 |
| 状态模型 | 合约状态 | network state 加节点本地 state |
| 排序方式 | EVM block 给出执行节奏 | 链上排序事件驱动 Lyquid network 执行 |
| 核心能力访问 | 预编译和系统合约 | runtime、跨 Lyquid 调用、认证调用和 host 能力 |
因此，更准确的说法是：
HyperEVM 合约层
~= Lyquid network 方法
+ 链上排序入口
+ 节点托管运行时
+ network state
+ 以太坊兼容 RPC/ABI 接口
这不是一比一复制，而是产品角色相近。
HyperEVM 的以太坊兼容更直接。它就是 Hyperliquid 内部的 EVM 环境，开发者和用户可以把它当成一条 EVM 链来理解：有 RPC，有 chain ID，有 gas token，有合约部署和调用。
Lyquor 的以太坊兼容更像“入口兼容”。外部可以通过类似以太坊的合约地址、ABI、RPC 或 sequencer contract 触达应用，但应用内部执行的不是 Solidity/EVM bytecode，而是 Lyquid/WASM。换句话说，Lyquor 不是把自己变成一条普通 EVM 链，而是把以太坊工具链作为外部入口之一。
这会带来不同的取舍：
如果你关注 Hyperliquid，HyperEVM 的重点不是“又一个 EVM 兼容链”，而是 HyperCore 的开放方式。它让 Hyperliquid 的交易系统可以被合约生态、钱包、前端和 DeFi 应用组合起来。
如果你关注 Lyquor，比较 HyperEVM 时不要急着找一个“等价模块”。Lyquor 更像是把合约入口、排序、托管、运行时和状态模型拆开，再组合成一个应用网络。它对应的不是 HyperEVM 的某个底层部件，而是 HyperEVM 对开发者和用户呈现出来的整个合约应用层。
HyperEVM 存在的必要性，可以概括为：
HyperCore = 高性能交易与金融状态核心
HyperEVM = 面向开发者的通用合约层
两者互通 = 把 Hyperliquid 的交易流动性变成可组合生态资产
Lyquor 的对应方向，则可以概括为：
Lyquid network = 面向应用的链上排序执行层
以太坊兼容入口 = 面向外部用户和工具的连接层
节点托管运行时 = 面向应用执行和服务能力的基础设施
所以，HyperEVM 和 Lyquor 的共同点不是“都在做 EVM”。更准确的共同点是：它们都在寻找一种方式，把底层网络能力转化为外部开发者可以理解、部署和组合的应用层。
clear-lyquid 和 match-lyquid，现在它们都通过一个 Lyquor 实例作为入口来调用。所有状态都已经转换为实例级状态。整体思路是，多个实例先为一笔交易发起某种本地共识，然后再把结果提交到链上。
在这个阶段，我们遇到了一个问题：每次状态访问都涉及读写锁，这说明系统里存在竞争条件，也暗示这里可能需要一个多线程设计。
所以问题变成了：在这个上下文中，我们应该如何利用 Lyquor 提供的多线程能力？
工程侧的讨论集中在 Lyquid 的实例化执行、同步和多线程上。一个反复出现的主题，是从以 network 为中心的实现模型，转向以 instance 为中心的模型，并更认真地处理同步、锁和多线程在生产级路径中应该如何工作。更大的目标不只是让当前代码编译和运行，而是理解实例化设计如何支撑更高效的共识，也就是参与实例之间的共识，以及后续验证流水线。
我们也回顾了测试进展。大部分测试用例已经完成翻译，并围绕当前调用链整理好，只剩较小一部分还在处理中。这让团队更清楚地看到，代码库哪些地方已经稳定到可以做对比测试，哪些地方在更大范围验证前还需要继续打磨。
]]>讨论的一部分集中在比较 Hyperliquid、OKX 和 Binance 的 feed 结构。一个有用的结论是，这种比较并不像一开始看起来那么直接。Hyperliquid 并不是简单地暴露“更少数据”。相反，很多字段被拆分到不同 subscription 中，使整体模型更像事件流，而不是一个打包好的单一推送格式。
这种差异很重要，因为它会改变下游系统对重建、完整性和时序的理解方式。一个分散在多个 subscription 中的 feed，和一个把更多状态聚合到单一 channel 中的 feed，即使总信息量相近，系统行为也会不同。
与此同时，我们继续讨论 Lyquid 向实例化执行迁移的问题。这里的实际问题已经不只是代码迁移本身，还包括如何组织同步、如何降低锁竞争，以及如何在不退回到过粗锁粒度的情况下，让多线程执行变得可行。
我们也重新讨论了共识和下游状态分发应该如何建模。关键问题之一不只是结果如何达成一致，而是执行完成后应该传播多少信息。尤其是只发送很小的 delta 式更新，不一定总是足够。在某些路径里，更完整的状态传递可能比最小 payload 更稳健。
综合来看，这些讨论指向同一个更大的主题：系统设计同时取决于外部数据模型和内部执行模型。更准确地理解交易所 feed，有助于反过来塑造 Lyquid 内部的执行、共识和下游状态处理方式。
我仍然有一个印象：Hyperliquid 推送的数据可能更少，但这一点还需要继续验证。
]]>这次大家聊到的内容比较多，包括合约字段设计、ADL 业务用 Rust 重写、系统往 Lyquor 上的集成联调，以及链下共识方案。表面上看，这些话题分散，但放在一起看，其实都在围绕同一个问题：系统怎么才能做得更清楚、更稳定，也更适合继续往前走。
先说合约字段。讨论里一个让我印象比较深的点是，不同平台对交易单位的表达方式差异其实很大。像 OKX、BitMEX 这类更早期的平台，很多时候更强调“张”的概念，这种表达方式和传统金融衍生品市场比较接近。而币安、Bybit 在很多场景下，则更倾向于直接让用户面对“标的物数量”这样的概念，把 lot size、face value 这些约束更多放在系统内部处理。
从用户角度看，这样会更容易理解。普通用户不需要先理解“几张合约”，而是可以直接从数量去认识下单和持仓。某种程度上，这也确实降低了衍生品交易的入门门槛。
但从系统实现的角度看，事情反而会更复杂一些。因为越是把复杂度隐藏在内部，越要求系统把 quantity、lot size、face value、multiplier 之间的关系处理清楚。这些字段看起来只是定义问题，实际上会影响下单限制、仓位计算、价值换算，甚至后面的风控逻辑。所以大家才会越来越意识到，字段统一这件事并不只是“对接口”，更像是在统一内部的业务语义。
另一个重点，是 ADL 相关业务正在推进用 Rust 重写。聊下来会发现，这件事不只是技术迁移，更像是在重新梳理系统理解。因为重写的过程中，大家需要不断确认哪些业务语义必须保留，哪些结构可以借这个机会重新整理。很多旧系统的问题并不是不能运行，而是调用链、命名方式和接口边界在长期迭代中慢慢变得复杂。到了重写阶段，真正重要的也许不是把代码搬过去，而是借这个过程把核心逻辑重新理清楚。
还有一个很有代表性的点，是这次在把系统往 Lyquor 上集成时暴露出来的联调问题。当前的方式，是先把 Clear 和 Match 分别做成两个 Lyquid，再去验证它们之间的调用链路。从目前的结果看，下单之后，Clear 调用 Match 这一步已经能走通，但调用完成之后，并没有拿到预期中的正确返回。这也说明，链路虽然已经接上了，但整个调用闭环还没有真正建立起来。
这类问题在工程里其实很常见。单个模块自己测试时可能都没问题，但一旦进入完整链路，上下游一接起来，很多真实问题才会浮出来，比如日志异常、回调丢失、参数处理不一致，或者模块之间对返回结果的理解并不完全一致。尤其像这种拆成两个 Lyquid 来做集成的方式，本身就更容易把跨模块调用中的边界问题暴露出来。
也正因为这样，联调往往不是简单的收尾阶段，而更像是系统第一次在真实路径上被完整检验。很多问题不是代码“不能跑”，而是只有真正接进系统、走完整条链路之后，才会知道返回是否正确、状态是否闭环、上下游是否真的对齐。
最后一个让我觉得很值得继续观察的点，是关于链下共识方案的讨论。大致思路是，把同一个订单发到多个节点执行，在多数结果一致之后，再继续推进后续流程。这个方向的目标很明确，就是希望在兼顾一致性的同时，把效率尽量做得更好一些。但越往下讨论，越会发现这里面有很多细节值得反复推敲，比如订单顺序怎么保证一致、前端什么时候看到结果、数据是先推送还是先上链。这些问题未必马上有答案，但讨论本身很有价值，因为它会帮助大家逐渐看清系统在性能、一致性和风险控制之间准备怎么平衡。
回头看这次讨论，我自己的感受是，系统往前推进的过程中，除了继续做功能，像这样围绕模型、链路和方案边界的讨论，其实同样重要。它们看起来没那么“热闹”，但可能正是系统慢慢变得更稳、更清晰的过程。
]]>先从技术侧说起。一个比较实际的进展，是这周已经尝试用 Lyquid 中的 ERC20 合约连接 MetaMask 做充值测试，整体流程基本已经走通。虽然未来演示时不一定会完全照着这条路径来做，但这至少说明，围绕资产接入和用户侧交互的基础路径，已经开始从概念走向可验证的实现。
这也自然带出了另一个更大的问题：如果系统未来不仅仅停留在单链上，那么底层的执行和共识结构是否可以支撑更灵活的多链接入。会上提到的一个思路，是把不同链上的余额变化统一纳入主系统的共识视角中，再通过后端切换或者兼容 EVM 的方式去扩展。这个方向本身还需要继续细化，但它反映出团队已经不只是把 Lyquor 看成一个单点系统，而是在把它往更通用的执行底座上思考。
另一个重要进展，是交易核心流程的重写和整理继续往前推进。下单、撤单、改单、成交和强平相关的处理已经基本完成，单元自测也做过，并合并到了当前的 clear 侧实现中。真正还在持续消化的部分，不是“功能有没有”，而是如何把原来比较复杂的模型，映射到一个更简洁、也更适合当前系统的表达方式上。
这个讨论和上一篇关于字段建模的思路其实是连在一起的。系统越想靠近更直接、更易理解的外部接口，内部越需要认真处理参数映射、模型压缩和语义统一。简化用户理解，并不意味着简化系统本身，很多时候恰恰相反。
会上另一个非常值得注意的点，是推送服务设计的调整。之前的思路是监听区块事件再向用户推送，但如果底层链路本身是一秒一块，那么用户看到结果就天然会有延迟。这对于交易场景来说，很容易让“链上确认”变成影响体验的瓶颈。因此这次讨论开始明显转向一种更偏链下的处理方式：先把后端结果推送给用户，再完成后续上链动作。
这种调整并不是简单地“追求更快”，而是开始正面面对一个交易系统里很现实的取舍：用户需要更快的反馈，但系统也必须防止错误推送、错误状态传播，以及 WebSocket 服务被劫持后带来的风险。所以问题已经不只是推不推，而是如何在速度、可信度和系统边界之间找到一个合适的平衡点。
这也和会议里对 Hyperliquid 的研究连了起来。大家讨论到，它宣称很高的 TPS，但链上实际看到的 event 数量却并不多，这意味着它在数据表达和状态记录上，大概率做了相当激进的压缩。这里最有意思的地方，不只是“它做到了什么”，而是这会反过来影响我们怎么理解链上记录、链下执行，以及结果回放之间的关系。
在架构层面，这些观察最终又落回到几个很实际的问题上：下单和推送是否都应该是链下服务，clear 和 match 是否要进一步合并，分片能不能作为后续横向扩展的一条路径。这些问题现在未必都有定论，但已经能看出来，团队在思考的不是单个模块怎么补齐，而是整个交易路径的形态应该怎么重新组织。
除了技术部分，这次会议还有一条同样重要的主线，就是项目的产品定位和创业方式。一个比较鲜明的观点是，项目更适合被理解为一个 DeFi 产品，而不是沿用传统中心化交易平台的叙事方式。这里面既有合规层面的考虑，也有增长方式上的考虑。
会议里提到的想法是，如果项目要继续往前推进，与其把大量精力放在一个过早封装的 MVP 上，不如优先把关键业务、架构方向和公开表达打磨清楚。通过直播周会、持续发周报、公开展示进展这些方式，让外部用户和潜在支持者真正看到项目在往哪里走。这种方式和很多传统产品“先闭门做完再拿出来”的路径不太一样，但和当前项目的节奏反而是相匹配的。
最后还有一个讨论点也很值得记下来，就是 ADL 和保证金逻辑的再理解。这里并不是简单复现某个平台的规则，而是想把触发条件、权益变化、可转资金限制这些东西重新想清楚。因为这些规则表面上像是风险控制细节，实际上会直接影响用户体验，也会影响系统是否稳定。
回头看这次周会，我自己的感受是，它没有给出一个单点结论，而是把几条关键主线慢慢拉到了一起。技术侧在继续往更稳定、更可展示的交易路径收敛，产品侧则在思考更公开、更持续的推进方式。对一个还在快速形成中的项目来说，这种同时整理工程问题和外部叙事的过程，本身就很重要。
]]>这张图对应的是 2 月 27 日讨论过的架构概念。可以参考之前的文章：02-27 合约测试与架构取舍。
这次的核心架构结论是，一个 Lyquid 应该能够同时支持指数价格相关功能和撮合功能。团队不希望过早把这些职责拆到不同系统里，而是更倾向于一种共享结构：多个节点或角色在同一套结构里运行，共用内存中的订单簿状态，同时根据节点身份或执行角色承担不同任务。从方向上看，这让设计更接近实例共享模型，而不是一组彼此隔离的服务。
这张更新后的图反映了 3 月 9 日的方向：走向单 Lyquid 架构，并把撮合与指数价格相关逻辑组合到同一个节点内部。
这个决定立刻凸显了确定性执行的重要性。一些在独立服务里可以接受的实现细节，一旦进入复制执行的网络环境，就会变成问题。UUID 生成是最清楚的例子。如果不同节点在重放同一条执行路径时生成不同 UUID，即使周围业务逻辑完全一致，系统也可能发生分叉。结论很直接：基于 UUID 的行为必须被移除，或者替换成所有节点都能复现的确定性方案。
同样的约束也适用于时间和随机数。在网络层中，直接读取当前时间或依赖随机数生成，会引入不可复现的行为，破坏重放和共识假设。这些细节看起来很小，但一旦执行结果需要在多个节点之间保持一致，它们就会变成架构问题。
与此同时，价格接入和价格计算正在从次要数据源变成核心设计问题。当前方向是让 proposer 节点通过网络路径推送指数价格和标记价格相关更新，使最终结果能够反映到合约状态中。早期可以先采用简单的数据接入路径，但讨论也明确指出，最终价格模型不能只是透传几个外部值。
原因之一是，所需数据本身并不容易重建。会议中提到的一个问题是，系统无法直接按定价逻辑需要的形式取回过去 150 分钟的 bid、ask 和 last trade 数据。这意味着价格逻辑可能需要更紧密地和撮合耦合，或者更直接地存储在同一套合约级结构中，而不能只被当作纯外部参考流。
这也是 Hyperliquid 研究变得特别相关的地方。讨论中提到，Hyperliquid 的定价模型并不是一个简单公式。标记价格依赖多个值的中位数，并且看起来还结合了移动平均和加权中位数逻辑。也就是说，价格逻辑不只是预言机接入问题，也是建模问题。要正确复现这种行为，需要理解哪些数据被存储、如何聚合，以及计算应该发生在哪里。
在这些架构问题之外，功能开发也继续推进。下单和撤单已经可以工作，改单、成交执行和更丰富的查询路径仍在推进。短期预期是完成改单和查询支持，重新生成 Swagger 文档，然后开始实验如何把订单簿和基于指数的计算结合起来。
背景中还有一个实际的基础设施经验。一些编译和部署困难看起来并不是业务逻辑本身导致的，而是环境不匹配造成的，尤其是 macOS 和 Ubuntu 工作流之间的差异。更实际的应对方式是，把更多工作流迁移到 Docker 或类 Ubuntu 环境里，因为部署已经在这些环境中被证明可行；然后再在更接近目标运行时的环境中解决 UUID 移除等确定性执行问题。
综合来看，3 月 9 日的讨论让项目的一条关键工程原则更清楚了：架构不只是决定功能放在哪里，也是在决定哪些假设可以存在于复制执行模型中。因此，走向单 Lyquid 架构不只是简化了图，它也迫使团队把确定性、价格逻辑和执行边界当成同一个设计问题来处理。
]]>会议的一部分重点放在合约执行和测试上。此前 devnet 出现过一个问题：hub 节点运行时间过长，或部署合约过多后，行为会变得异常。通过重置 rocksdb 目录、重启 devnet、重新部署合约，基础 swap 测试恢复正常。这有助于把环境不稳定和真实合约逻辑问题区分开来。早期验证中，这两类问题很容易混在一起。
我们也进一步明确了 swap 流程背后的合约交互模型。流程是先部署两个 ERC20 合约，再用这两个 token 地址部署基础 swap 合约。当用户用 token A 兑换 token B 时，token A 会进入 swap 合约，合约计算输出数量，再把 token B 转给指定接收方；这个接收方不一定要和调用地址相同。这个模型让团队更容易理解，在验证 swap 行为时到底测试的是什么。
与此同时，订单流转语义仍然有一些开放问题。两个用于下单和查询订单状态的合约已经成功测试过，但 new 状态的含义还没有完全定下来。团队特别讨论了 new 到底表示撮合前、撮合后，还是仅仅表示合约已经接受订单。这个不确定性很重要，因为状态流转不只是 UI 细节，它决定了上下游服务如何解释执行结果。
另一个有用的澄清是原子性。讨论再次确认，一笔合约交易要么整体成功，要么整体失败；失败交易不应该让第一个合约停留在部分更新的状态。这个假设听起来基础，但当合约执行要映射回更广泛的撮合和清算流程时，它是非常关键的前提。
会议也迫使团队更诚实地看待项目时间。一个原本估计一周多完成的任务，实际已经接近三周。这说明早期估算过于乐观，没有留出足够缓冲。结论并不是简单要求“更快完成”，而是要用更实际、可辩护的方式估算，把真实复杂度纳入时间计划，而不是只按理想执行情况估算。
这种现实感也延伸到了任务规划上。与其同时分散精力做太多测试和旁支探索，团队更倾向于把注意力集中在当前关键路径上，尤其是改单逻辑、DTO 边界和代码模型一致性。大致思路是，在核心数据模型和执行路径足够稳定之前，不要把太多精力消耗在外围验证上。
AI 辅助代码分析也被作为一种战术工具讨论，而不是工程判断的完整替代品。团队并不打算把所有代码整体翻译一遍，而是更有选择地使用 AI：比较逻辑、标出不合理之处，并帮助把具体行为迁移到当前代码库中，避免为无差别的全量代码翻译付出成本。这是一种更克制的 AI 使用方式，也符合当前保留功能连续性、减少无效投入的整体思路。
在架构侧，一个比较有意思的话题是，相比一些更碎片化的方案，集成在高核心数机器上的模型是否更现实。讨论中的观点是，把清算和撮合放在一台强大的多核系统上，即使单合约性能仍然有限，也可能支撑较大规模使用。这个想法和另一种被认为容易出现内部拥堵和运行不稳定的模型形成了对比。
更近一步的实现计划则更加具体。团队准备把 clear 服务和 match 服务做成两个独立的 Lyquid 组件，每个组件都有自己的 network entry，近期目标是完成让这个结构可运行所需的 Lyquor 集成工作。这样一来，架构讨论就有了实际下一步：不再只是在抽象层面讨论，而是通过真实的服务级集成路径继续推进系统。
会议中还有一个更深层的分歧：应该如何理解节点级执行。一种观点认为，不同节点可以各自运行合约执行，再通过共识收敛到最终结果，从而支持横向扩展。另一种观点强调全网一致性，也就是所有交易必须先被收集、排序并达成一致，然后才能产块。这个区别非常基础，因为它会改变团队对执行并行度、部署边界以及共识在最终架构中角色的理解。
]]>在这个基础上，迁移路径被定义成一个阶段性过程，而不是完整推倒重来。计划是先部署更新后的 Java 实现，观察最新产品逻辑和性能改动带来的效果，然后把实现迁移到 Rust，最后再逐步演进到 Lyquid。也就是说，Lyquid 不是一个孤立的替换项目，而是要分阶段接入当前系统，让性能变化可以在迁移过程中持续被观察和比较。
这种分阶段思路也影响了服务层面的迁移计划。当前的判断是，先从 clear（账户清算服务）和 order（API 下单服务）这类单节点服务开始，把它们作为 Lyquid 迁移对象；之后再处理 match（撮合服务）这类要求更高的组件。在这个阶段，基于 Kafka 的通信仍然应该保留。这样做的意图是，在能降低迁移风险的地方继续使用熟悉的 Web 2.0 式架构，而不是一开始就强迫所有组件进入新的模型。
我们也进一步明确了代码适配 Lyquid 需要做什么。迁移工作被概括为三个核心步骤：定义状态、实现合适的入口函数，以及确保幂等性。如果 f_750 分支能够在保留幂等行为的同时完全移除 Kafka transaction，那么一部分适配成本会直接消失，剩下的工作会更集中在状态定义和执行入口上。与之相关的一个开放问题是 Lyquid 的共识机制，这仍然需要和 Lyquor 团队进一步对齐，才能最终确定实现路径。
除了工程机制本身，这次会议也明确了协作预期。要提前整理好给 Lyquor 团队的问题，假期结束后恢复定期对齐会议，并且每次周会后输出简洁的文字总结，让外部相关方不用参加每一次技术讨论，也能持续了解进展。
4 月初的产品目标被有意定义为能力展示，而不是精修版本。目标是展示一个基础交易功能能够以去中心化方式运行的版本。高质量前端和极限性能不是当前优先级。更重要的是先证明架构可以通过一个基础界面端到端跑通。
最后一个主题是实现策略。团队对同时推进 AI 辅助迁移和人工开发迁移保持开放态度，并计划在比较性能差距后再决定长期方向。会议中也有人建议把早期 C++ 撮合版本重新接入 Kafka 并尝试上链，同时先翻译 Rust 版本以保留功能完整性，再做后续优化。这些想法背后的共同信息很一致：正确性和迁移连续性应该先于激进调优。
]]>