MooreLabsxyzTech

There won’t be just one Hyperliquid.
We’re building what comes next.

[MooreLabsxyzTech @MooreLabsTech]

A four-node Lyquor prototype tested what makes an index-price update auditable.

Across 17 scenarios, the key output was not an oracle value alone, but one receipt binding evidence, authority, rules, and the final state change.

https://t.co/EanAyuNEam

[MooreLabsxyzTech @MooreLabsTech]

5/ That is the next research boundary:

What minimum evidence and fallback policy should a certified traditional-asset price update carry before it can affect risk, funding, or settlement?

Full analysis:

https://t.co/qG6YCBslKZ

[MooreLabsxyzTech @MooreLabsTech]

24/7 traditional-asset perps are not mainly a matching problem.

When external markets close, the hard question is what evidence can safely move accepted market state.

A Lyquor design should separate local observations from validated, sequenced updates.

https://t.co/qG6YCBslKZ

[MooreLabsxyzTech @MooreLabsTech]

4/ Certification helps prove that a defined validation path authorized a specific call.

It does not prove the fair value is economically correct, that a thin book is safe, or that a fallback regime should stay active.

[MooreLabsxyzTech @MooreLabsTech]

6/ “Oracle” therefore understates the problem.

This is a continuously operated state machine spanning external data, local liquidity, risk, and market lifecycle.

What evidence should be observable before closed-market discovery is allowed to affect liquidation?

Full analysis:

https://t.co/ImK8GnNCE6

[MooreLabsxyzTech @MooreLabsTech]

On Jul 13, we studied how trade[XYZ] operates 24/7 traditional-asset perps on Hyperliquid. HyperCore provides the shared execution layer: order books, matching, margin, and liquidation. The harder, market-specific work lies elsewhere: cross-market pricing methods, a production-grade Relayer, and continuous operation of risk parameters and market lifecycles. For Lyquor, the useful lesson is not to copy HIP-3, but to ask whether these capabilities can become coordinated Lyquid applications over sequenced, shared state. Market operation is an application layer of its own.

7 月 13 日，我们研究了 trade[XYZ] 如何基于 Hyperliquid 运营 24/7 传统资产永续市场。HyperCore 提供共享执行层，包括订单簿、撮合、保证金和清算；更难复制的市场专用能力则位于另一层：跨市场定价方法、生产级 Relayer，以及风险参数和市场生命周期的持续运营。对 Lyquor 来说，真正有价值的不是复制 HIP-3，而是思考这些能力能否基于被排序的共享状态，成为相互协调的 Lyquid applications。市场运营本身就是一个应用层。

https://t.co/ImK8GnNCE6

[MooreLabsxyzTech @MooreLabsTech]

5/ A formula cannot decide whether a stale source should be rejected, when a fallback should activate, or whether a thin market should be halted.

Those decisions require monitoring, permissions, versioned parameters, and well-defined emergency procedures.

[MooreLabsxyzTech @MooreLabsTech]

On Jul 10, we looked at what HyperCall's relationship with Hyperliquid suggests for HyperCall-like markets on Lyquor. HyperCall is shaped by a hybrid stack: Backend for fast venue logic, HyperEVM for account and execution boundaries, and HyperCore for liquidity, clearing state, oracle data, and hedge markets. On Lyquor, the more natural split is different: `instance` can carry matching, RFQ/RPI-style workflows, quotes, and other high-frequency market behavior, while `network` anchors settlement, deposits, withdrawals, checkpoints, and canonical state. The core point is openness: Lyquor does not just integrate with specialized trading infrastructure; it gives builders a way to create that infrastructure themselves.

7 月 10 日，我们从 HyperCall 之于 Hyperliquid 的关系，思考 Lyquor 上的 HyperCall-like market。HyperCall 是 Backend + HyperEVM + HyperCore 的混合架构：Backend 负责快速交易场所逻辑，HyperEVM 提供账户和执行边界，HyperCore 提供流动性、清算状态、oracle 数据和 hedge 市场。在 Lyquor 上，更自然的分工是：`instance` 承载 matching、RFQ/RPI-style workflow、quote 等高频市场逻辑，`network` 锚定 settlement、deposit、withdrawal、checkpoint 和 canonical state。核心区别是开放性：Lyquor 不只是接入专业交易基础设施，而是让开发者可以自己构建这类基础设施。

https://t.co/iOl4wvbiwM

[MooreLabsxyzTech @MooreLabsTech]

HyperCall is useful to study not just as an options venue, but as a signal of the business shape forming around Hyperliquid: specialized trading logic close to liquidity, account state, oracle data, margin, settlement, and a programmable on-chain boundary. From Lyquor's perspective, the deeper question is how this class of financial application should be built. Matching, clearing, risk, margin, liquidation, and settlement do not have to be split between isolated contracts and opaque backends. On Lyquor, they can become sequenced Lyquid network applications that share state and coordinate through runtime capabilities.

HyperCall 值得分析，不只是因为它是一个期权交易场所，而是因为它展示了 Hyperliquid 周围正在形成的业务形态：专业交易逻辑贴近流动性、账户状态、oracle 数据、保证金、结算，以及可编程链上边界。从 Lyquor 的视角看，更深的问题是这类金融应用应该如何构建。撮合、清算、风控、保证金、强平和结算，不一定要被拆成孤立合约和不透明 Backend。它们可以在 Lyquor 上成为被统一排序驱动的 Lyquid network applications，共享状态，并通过 runtime capabilities 协同运行。

Original blog post:

https://t.co/b0ZieVYlcS

[MooreLabsxyzTech @MooreLabsTech]

On Jul 3, we clarified a sharper distinction between HyperCore and Lyquor: the question is not only how financial applications execute, but who gets to define the financial infrastructure. HyperCore provides specialized trading infrastructure as part of Hyperliquid's core system. Lyquor exposes the capability to build that kind of infrastructure as sequenced Lyquid network applications, where matching, clearing, risk, margin, liquidation, and settlement logic can be built, inspected, and composed by developers.

7 月 3 日，我们进一步明确了 HyperCore 和 Lyquor 的区别：关键问题不只是金融应用如何执行，而是谁来定义金融基础设施。HyperCore 把专用交易基建作为 Hyperliquid 核心系统的一部分来提供。Lyquor 则开放了构建这类基建的能力，让撮合、清算、风控、保证金、强平和结算逻辑可以作为被排序驱动的 Lyquid network applications，由开发者构建、检查和组合。

https://t.co/PgvA3KNa3M

[MooreLabsxyzTech @MooreLabsTech]

Hyperliquid is becoming more than a perp exchange. HyperCore is specialized trading infrastructure, HyperEVM adds a programmable application layer around it, and HyperCall shows how trading products can be built close to liquidity, account state, margin, and settlement. If this kind of business were implemented on Lyquor, the key difference is that developers could build the trading infrastructure itself: matching, clearing, risk, margin, liquidation, and oracle-driven settlement could become sequenced Lyquid network applications sharing state and coordinating through Lyquor runtime capabilities.

Hyperliquid 正在变成不只是 perp 交易所。HyperCore 是专用交易基建，HyperEVM 在它周围增加可编程应用层，HyperCall 则展示了交易产品如何贴近流动性、账户状态、保证金和结算来构建。假设用 Lyquor 来实现这类业务，关键差异是开发者可以构建交易基建本身：撮合、清算、风控、保证金、强平和 oracle-driven settlement 可以成为被统一排序驱动的 Lyquid network applications，共享状态，并通过 Lyquor runtime 能力协同运行。

https://t.co/hCdhlLAGM7

[MooreLabsxyzTech @MooreLabsTech]

HyperEVM should not be understood as just "EVM support for Hyperliquid." Its deeper role is to turn HyperCore's high-performance financial state into a programmable application layer that developers can access through familiar Ethereum tooling. That framing also changes how we compare it with Lyquor. The closest counterpart is not a single Lyquor VM module, but the Lyquid network application layer as a whole: on-chain sequencing, node-hosted Lyquid/WASM execution, shared network state, runtime services, and Ethereum-compatible entry points. The bigger takeaway is that both systems are trying to expose lower-level network capabilities as application layers that outside developers can understand, deploy to, and compose with.

HyperEVM 不应该只被理解成“Hyperliquid 的 EVM 支持”。它更深层的作用，是把 HyperCore 的高性能金融状态变成一个开发者可以通过熟悉的 Ethereum 工具访问的可编程应用层。这个理解也会改变我们比较它和 Lyquor 的方式。更接近的对应物不是某一个 Lyquor VM 模块，而是整个 Lyquid network application layer：链上排序、节点托管的 Lyquid/WASM 执行、共享网络状态、运行时服务，以及 Ethereum-compatible entry points。更大的结论是，两套系统都在尝试把底层网络能力暴露成外部开发者能够理解、部署和组合的应用层。

https://t.co/FSfhMsJQ72