Mooré

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

[Mooré @MooreLabsxyz]

Hot-path matching in nanoseconds, Limit order placement: sub-microsecond.
Steady-state throughput at ~millions of orders/sec under realistic depth, without latency blowups.
Decentralized execution.
#Hyperliquid is not unbeatable.

[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

[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]

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]

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 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

[812.eth👁 @puregamma]

如果有人想要中文版的这个Hyperliquid投研指南，我用AI翻译了一版，内容我看完觉得很棒。https://t.co/aU36f4m0MG

[Mooré @MooreLabsxyz]

That's a very useful handbook. A must-read if you want to know more about the Hyperliquid ecosystem. We are building what's come next.

[GRZ @GRZ_Research]

After chatting with many teams about their development and the current state of their projects, the next @HyperliquidX House of all Finance paper is finally here.

(https://t.co/jqH8HwcyG4)

[Mooré @MooreLabsxyz]

Maybe able to have something very "Early Access" for you guys to play with at the end of this month.

[Mooré @MooreLabsxyz]

We’ve successfully brought two core exchange services—matching and clearing—online on Lyquor.

[Mooré @MooreLabsxyz]

We’ve built a system with a relatively novel concept called Fate‑Constrained Ordering (FCO). (This is an invention coined by Lyquor.) You can think of it like this:

First, an “ordering/consensus layer” arranges all actions that can affect the state into a single global timeline (like writing a script). Then different nodes only need to execute the “scenes” they’re responsible for (the services/contracts they host), while everyone still stays consistent on “what happened globally, and in what order.”

Why is this especially critical for Moore (on‑chain order book + fully on‑chain end‑to‑end workflow)?

Because for an on‑chain perp DEX, the execution pipeline is long:

place order → matching → position/margin changes → risk checks → may trigger liquidation cascades → accounting/settlement…

If every node had to execute everything “in full,” the performance pressure would be enormous.

What FCO enables:

Order & fairness (“who places an order first gets filled first,” “who cancels first gets canceled first”) are guaranteed by a network‑wide, unified ordering system.

Computation load can be split out by service: matching is one “service/contract,” liquidation is another, oracle is another… Different nodes can selectively host these services.

[Mooré @MooreLabsxyz]

Honestly, the $TROVE situation didn’t surprise me at all.

The core thesis behind backing Trove was never Trove itself — it was trust in Hyperliquid’s HIP-3 model and the Hypercore architecture.

But HIP-3 can’t escape one fundamental constraint:
You’re still running on someone else’s chain.
That means you always inherit:

someone else’s block space allocation

someone else’s ordering rules

someone else’s fee model

No matter how “product-focused” or “user-obsessed” a Hyperliquid white-label claims to be, the more HIP-3 style protocols you stack on the same chain, the harder it becomes to fairly and predictably allocate TPS among them.

If you choose this path, you’re never sovereign.
You’re a tenant.

How far you can run ultimately depends on how long the leash is.
Put differently:
Hypercore exists precisely because Arbitrum, Polygon, and Solana already have too many “HIP-3-like” tenants competing for the same underlying resources.

And that same structural problem will eventually reappear on Hypercore itself. #Hyperliquid

[Mooré @MooreLabsxyz]

6/ The real competitive takeaway

Hyperliquid showed that performance is about state-first design.
We believe the next step is:
state-first + DMA-native execution.

That’s how you push past today’s limits
without sacrificing correctness.

[Mooré @MooreLabsxyz]

Thread 🧵: Building a #Hyperliquid competitor taught us one thing:
exchange performance is a state-architecture problem
When you try to build a real Hyperliquid competitor,
you quickly realize something uncomfortable:

Matching engines are not the hard part.
State architecture is.

[Mooré @MooreLabsxyz]

5/ Why DMA matters for HFT-like workloads

DMA gives us:

Deterministic latency

Fewer cache misses

Predictable I/O paths under load

For exchanges, this matters more than raw TPS.

Throughput without latency stability is meaningless.