# Oracles and Pricing

MoveX has three "prices" that matter, all sourced from on-chain price feeds:

| Price                | What it is                     | Updated when           | Used for                              |
| -------------------- | ------------------------------ | ---------------------- | ------------------------------------- |
| **Reference price**  | Underlying price at epoch open | Once per epoch         | Anchoring the MOVE settlement formula |
| **Mark price**       | Current \`                     | underlying − reference | \`                                    |
| **Settlement price** | Final \`                       | underlying − reference | \` at epoch close                     |

#### HyperCore precompiles (primary)

**The single biggest reason MoveX is built on HyperEVM is the HyperCore precompiles.** HyperEVM exposes a set of system contracts that let smart contracts read state directly from **HyperCore,** the matching engine that powers the Hyperliquid L1. Through these precompiles, an EVM contract can pull live spot mid prices and perpetual mark prices straight from Hyperliquid's matching engine, in the same transaction it's executing, with no off-chain relay and no signed attestation in between.

This solves the hardest problem in on-chain derivatives: **getting a trustworthy, low-latency price feed**.

Traditional setups depend on an off-chain oracle network to observe centralized venues and republish their prices on-chain. That introduces relay latency, an extra trust assumption, gas costs on every update, and a manipulation surface (oracle reorgs, stale data, signer compromise). The HyperCore precompiles erase all of that. The price MoveX settles against is the same price Hyperliquid's order book is producing, by definition. No middleman.

For every market whose underlying trades on Hyperliquid, and that's most of the assets anyone wants to trade, HyperCore is our **primary** price source. We didn't build on HyperEVM and *then* discover the precompiles; we picked HyperEVM *because* they exist.

#### Pyth Network (safety layer)

Although the HyperCore feed is primary, MoveX still integrates **Pyth Network** as a safety mechanism on top.

Pyth aggregates first-party price data from over a hundred institutional contributors — exchanges, market makers, and trading firms<sub>;</sub> into a single signed price update per asset. It's pull-based: signed updates are published off-chain through a feed called Hermes, and the protocol pulls fresh updates on-chain only when it needs them. This keeps the gas cost of always-fresh data manageable.

In MoveX, Pyth is layered on top of HyperCore as a **cross-source sanity check**. For every price the protocol acts on, a recent Pyth price for the same asset is pulled in parallel. If the two sources diverge beyond a configured tolerance, the protocol triggers a circuit breaker: it pauses sensitive operations (new fills, liquidations) on that market until the discrepancy resolves. This catches the rare failure mode where one source is briefly compromised or stale, neither feed is asked to be perfect on its own; together they cover each other.

#### Why this matters

Oracle updates trigger an automatic **liquidation sweep** after each tick. If the new mark price would make any position liquidatable, the sweep catches it in the same block. Because HyperCore is read synchronously from the EVM (no relay) and Pyth is pulled at the moment we need it (no stale push), the lag between "real market price" and "MoveX mark price" is measured in milliseconds. That tightness is what lets us run liquidations safely with conservative maintenance margin requirements.

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.movex.market/architecture/oracles-and-pricing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.