9 posts tagged with "Architecture"

Keeping a traditional-asset perpetual open 24/7 is not primarily a matching problem. When the underlying venues close, an operator must decide which data remains usable, how to validate a new price, and when a price update may affect funding calculations, risk controls, or market lifecycle state. trade[XYZ] makes this hidden market-operations layer visible.

Our analysis suggests a specific Lyquor design opportunity: do not rebuild HyperCore or replicate the Relayer as a monolith. Separate node-local, potentially divergent observations of external markets from certified, sequenced updates to shared market state.

external observations -> application validation -> certified call
                      -> sequencing -> accepted market state

Summary​

HyperCall is useful as a reference case because it shows how a specialized market application attaches itself to a larger trading system.

On Hyperliquid, HyperCall does not try to make every options order, quote, fill, risk check, and lifecycle event a direct on-chain contract action. Its practical shape is hybrid: the HyperCall Backend handles the fast venue logic, HyperEVM provides the account and execution boundary, and HyperCore supplies the financial base of liquidity, clearing state, oracle data, and hedge markets.

The Lyquor lesson is not to copy that architecture one-to-one. A HyperCall-like market on Lyquor would likely use a different split:

Lyquor network -> settlement, deposits, withdrawals, account boundaries, checkpoints
Lyquid instance -> matching, RFQ/RPI-style workflows, quotes, order books, fast market state

That difference matters. HyperCall depends on an operator-run Backend for much of the fast options venue. Lyquor can make the high-frequency side a more open application surface: anyone building a Lyquid can use instance capabilities to implement matching and other fast market workflows, while the network layer anchors the parts that need shared state, ordering, and settlement.

Summary​

From the Lyquor perspective, HyperCall is useful not only because it is an options product, but because it shows what kind of financial application starts to appear once a chain has specialized trading infrastructure, shared account state, oracle data, and a programmable application layer.

This post uses HyperCall as a reference case: first to understand the business shape emerging around Hyperliquid, then to ask what the same class of trading application could look like if matching, clearing, risk, margin, liquidation, and settlement were built as sequenced Lyquid network applications on Lyquor.

HyperCall is easiest to misunderstand if it is treated as a pure on-chain options protocol. Its current design is more practical and more hybrid: a professional off-chain options trading system, a HyperEVM contract layer for accounts and verifiable execution boundaries, and HyperCore as the underlying source of spot/perp liquidity, clearing state, oracle data, and future margin integration.

In one sentence:

HyperCall backend handles speed and options market structure.
HyperEVM contracts handle ownership, custody boundaries, settlement, and on-chain actions.
HyperCore provides the financial base: perps, spot, clearing, oracle data, and hedge liquidity.

That split is the main point. HyperCall does not try to push every options order, risk check, quote, and fill directly into HyperEVM contracts. Instead, it keeps the high-frequency and market-structure-heavy parts off-chain, while using HyperEVM and HyperCore to anchor the parts that need ownership, settlement, asset movement, and integration with Hyperliquid's financial state.

Summary​

The clearest difference between HyperCore and Lyquor is not simply performance, EVM compatibility, or whether an application can be deployed around a trading system. The deeper difference is who gets to define the financial infrastructure.

HyperCore provides specialized financial infrastructure as part of the Hyperliquid system. Order books, matching, clearing, margin, liquidation, and core account state are built into the chain-level trading environment. Lyquor takes a different direction: it exposes the capability for developers and users to build specialized financial infrastructure themselves, as sequenced Lyquid network applications with shared state and runtime capabilities.

In short:

HyperCore provides specialized financial infrastructure.
Lyquor provides the capability to build specialized financial infrastructure.

Summary​

HyperEVM is not just “EVM support for Hyperliquid.” A better way to understand it is as Hyperliquid's general-purpose application layer. HyperCore remains the high-performance financial core for order books, clearing, assets, vaults, staking, and other critical state. HyperEVM gives developers a familiar Ethereum-compatible surface for deploying contracts, composing applications, and connecting back to HyperCore.

That framing matters when comparing HyperEVM with Lyquor. The right comparison is not “which Lyquor VM equals HyperEVM?” The closer match is Lyquor's Lyquid network layer: the application-facing layer made up of Lyquid/WASM execution, on-chain sequencing, node-hosted runtime, network state, and Ethereum-compatible interfaces.

In one sentence:

HyperEVM runs the application layer as EVM contracts.
Lyquor runs the application layer as Lyquid network applications, exposed through Ethereum-compatible entry points.

很多时候，一提到交易系统，大家首先想到的都是性能，比如撮合速度、延迟和吞吐量。这些当然很重要，但这次内部讨论让我感觉，真正值得反复琢磨的，未必只有“快”这一件事。

When people talk about trading systems, performance is usually the first thing that comes to mind: matching speed, latency, and throughput. Those things are certainly important. But this internal discussion made me feel that speed is not the only topic worth revisiting again and again.

On March 9, the discussion moved the project toward a more unified architectural direction. Instead of continuing to think in terms of multiple Lyquid instances with pre-assigned responsibilities, the team aligned on a single-Lyquid design that could host multiple roles while sharing the same underlying state. That shift matters because it changes both the technical implementation path and the way different features, especially matching and index-price-related logic, are expected to coexist.

This diagram reflects the architecture concept discussed on February 27. See the earlier post here.

On February 27, the discussion combined three layers of the project that are usually hard to keep aligned at the same time: contract execution, day-to-day delivery discipline, and the longer-term system architecture. The result was a more grounded view of what had already been validated, where execution was slipping, and which architectural questions still needed sharper answers.

The February 22 discussion narrowed the project down to a practical migration sequence: validate the current system in a realistic environment first, then move service by service toward Lyquid without breaking the existing operational model. The emphasis was not on a big architectural rewrite, but on establishing a baseline, preserving comparability, and reducing uncertainty as each layer is adapted.