7 posts tagged with "Lyquor"

Lyquor makes persistent state unusually convenient: network functions can update shared, versioned state, while instance functions can maintain node-local state. That convenience creates a design risk. If every order, observation, response, file, and audit record becomes state, both layers eventually inherit the cost of an unbounded database.

Our central judgment is: data belongs in state only when future execution, recovery, or validation of a future transition must read it as a current fact. Persistent data that fails this test needs a different home and a defined lifecycle; ephemeral data may not need persistence at all.

Even if an oracle network produces a price and the request returns successfully, an index-price update may still be neither final nor auditable. An operator must still show which policy governed the decision, which evidence counted, who authorized it, what state preceded it, and why the new state became final.

To test that boundary, we built a runnable local system rather than only describing an architecture: a four-node Lyquor committee, programmable HTTP data sources, a deterministic decision core, a fault-injection runner, a shared-state Lyquid, and a conventional single-process coordinator using the same rules and scenario inputs.

Our core conclusion from this prototype was that the useful output of this workflow is not an oracle value or certificate alone, but one terminal receipt that binds the evidence, authority, policy snapshot, and resulting state transition.

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​

From the Lyquor perspective, trade[XYZ] is worth studying because it makes a hidden part of financial infrastructure visible: operating a market requires much more than building a frontend or connecting to a matching engine.

The central conclusion is simple:

HyperCore provides the shared trading engine.
trade[XYZ] provides the market-specific operating layer.

That operating layer defines traditional-asset contracts, turns fragmented external data into usable prices, runs the Relayer, manages risk parameters, and handles the market lifecycle.

trade[XYZ]'s core capability is therefore not the interface or HyperCore matching. It is the ability to keep this entire market control plane reliable across assets, sessions, and exceptional events.

Here, “24/7 market” describes the perpetual market's continuous trading objective. It does not mean the underlying stock, index, commodity, or FX venue trades continuously.

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​

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.