Lyquor 让状态持久化变得非常方便：网络函数可以修改共享且版本化的网络状态，实例函数可以维护节点本地的实例状态。但这种便利也带来一个设计风险。如果每一笔订单、观测结果、响应、文件和审计记录都写入状态层，两类状态层最终都会承担数据库不断膨胀带来的存储与运维成本。
我们的核心判断是：只有当未来执行、恢复或下一次状态转换的验证必须把一份数据当作“当前事实”读取时，它才应该进入状态层。 不符合这个条件但仍需持久化的数据，需要不同的去处和明确的生命周期；临时数据则可能根本不需要持久化。
即使预言机网络已经产出价格，请求也成功返回，这次指数价格更新也未必最终生效，更不代表它已经可审计。运营方还需要说明：哪套策略决定了结果、哪些证据被采纳、谁授权了决策、此前是什么状态，以及新状态为什么能够最终生效。
为了验证这条边界，我们没有停留在架构描述，而是搭建了一套可运行的本地系统：四节点 Lyquor 委员会、可编程 HTTP 数据源、确定性判定内核、故障注入测试运行器、保存共享状态的 Lyquid，以及一套使用相同规则和场景输入的传统单进程协调器。
我们通过这次原型验证得到的核心结论是：这套工作流真正有用的输出，不是预言机数值或证书本身，而是一条把证据、授权主体、策略快照和最终状态转换绑定在一起的终态回执。
让传统资产永续合约保持 24/7 交易，首要难题并不是撮合。标的资产所在市场闭市后，运营方必须判断哪些数据仍然有效、如何验证新的价格，以及价格更新何时可以影响资金费率计算、风险控制或市场生命周期状态。trade[XYZ] 揭示了这层通常隐藏在交易系统背后的市场运营能力。
我们的分析提出一个更具体的 Lyquor 方向：重点不是重建 HyperCore，也不是把 Relayer 当作单体系统原样复制，而是明确分开两类信息：各节点对外部市场可能存在差异的观测结果，以及经过认证和排序后写入共享状态的市场更新。
外部观测 -> 应用级验证 -> certified call
-> 排序 -> 最终生效的共享市场状态
从 Lyquor 的视角看，trade[XYZ] 值得研究，因为它让一层常被忽略的金融基础设施变得可见：运营一个市场，远不只是开发交易前端或接入撮合引擎。
核心结论很简单：
HyperCore 提供共享交易引擎。
trade[XYZ] 提供特定于市场的运营层。
这套运营层负责定义传统资产合约，把分散的外部数据转化为可用价格，运行 Relayer，管理风险参数，并处理市场生命周期。
因此，trade[XYZ] 的核心竞争力不是界面，也不是 HyperCore 的撮合能力，而是让整个市场控制平面在不同资产、交易时段和异常事件中持续可靠运行。
这里的“24/7 市场”指 perpetual market 追求连续交易，并不表示 underlying stock、index、commodity 或 FX venue 本身全天候交易。
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 的部分。
从 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 金融状态的连接。
HyperCore 和 Lyquor 最清楚的区别，不只是性能、EVM 兼容性，或者应用是否可以部署在交易系统周围。更深层的区别是：金融基础设施到底由谁定义。
HyperCore 把专用金融基础设施作为 Hyperliquid 系统的一部分来提供。订单簿、撮合、清算、保证金、强平和核心账户状态，都属于链级交易环境的一部分。Lyquor 走的是另一条路：它把构建专用金融基础设施的能力开放给开发者和用户，让这些能力可以作为带有排序、共享状态和 runtime 能力的 Lyquid network applications 来实现。
一句话概括：
HyperCore provides specialized financial infrastructure.
Lyquor provides the capability to build specialized financial infrastructure.
HyperCall 不只是一个期权交易场所案例，它更适合作为观察 Hyperliquid 业务形态的窗口。Hyperliquid 已经不只是一个高性能 perp 交易所。随着 HyperCore、HyperEVM，以及 HyperCall 这类应用层产品出现，它正在变成一个金融应用平台：HyperCore 是专用交易基建，HyperEVM 在它周围开放可编程应用入口，专业交易产品可以贴近这套金融状态来构建。
对 Lyquor 来说，关键问题是：如果这类业务放到 Lyquor 上，会有什么不同？哪些能力会更自然？哪些地方会形成自己的优势？核心差异是：HyperCore 是一套已经做好的专用交易基建；Lyquor 开放的是让开发者把专用交易基建构建成 Lyquid network applications 的能力。
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 应用承载应用层，再通过以太坊兼容入口对外连接。
一开始，我们重构了 clear-lyquid 和 match-lyquid，现在它们都通过一个 Lyquor 实例作为入口来调用。所有状态都已经转换为实例级状态。整体思路是，多个实例先为一笔交易发起某种本地共识，然后再把结果提交到链上。