Oracle Definition and Market Stability: Building Trustworthy Perpetual Markets on HIP-3

The evolution of how perpetual contracts launch has fundamentally shifted. Where platforms once controlled which assets could trade and under what terms, HIP-3 has redistributed that power to qualified builders operating within defined parameters. Since its mainnet deployment, over $13 billion in transaction volume has flowed through third-party-operated markets, signaling a genuine democratization of market creation. Yet this shift from gatekeeper to rule-based system creates a critical paradox: greater market flexibility demands more rigorous operational discipline. At the center of this challenge lies a deceptively simple concept with outsized consequences—oracle definition.

The Architecture Behind Decentralized Listing: Shifting From Approval to Standards

Traditional centralized exchanges control perpetual contract listing through opaque internal processes. A product team evaluates an asset, makes a business decision, and deploys it. Risk control lives within the exchange’s infrastructure. HIP-3 inverts this model. Rather than maintaining a curated catalog, Hyperliquid provides the infrastructure—HyperCore handles matching and settlement at scale, HyperEVM runs smart contracts—and invites builders to layer markets on top of it.

The mechanism is straightforward on the surface: stake 500k HYPE tokens, deploy a DEX (which holds its own margin and order book), launch three markets for free, then acquire additional market slots through Dutch auctions. But this structural simplicity masks profound complexity in execution. The builder now owns not just market creation but market operations—price feeding, parameter management, ongoing stability monitoring. What was once a platform responsibility becomes a builder’s accountability surface.

This shift exposes a central tension: decentralization requires standardization. The system must establish clear interfaces and constraints; otherwise, the risk doesn’t disappear—it fragments across dozens of independent operators with varying capabilities.

Oracle Definition: The Critical First Decision

When a builder initiates market creation, the first and most consequential decision involves oracle definition. This isn’t merely selecting a price feed; it encompasses the entire conceptual framework for how market participants will determine whether their positions are profitable, face liquidation, or trigger emergency mechanisms.

What Oracle Definition Actually Specifies:

An oracle definition in HIP-3 includes three components: the oraclePx (the raw price from an external source), the optional markPx (custom mark prices the builder supplies), and the externalPerpPx (weighted median from centralized exchange perpetual prices). These aren’t interchangeable inputs—they serve distinct functions in HIP-3’s risk calculation hierarchy.

The oraclePx anchors funding fees and serves as the reference for price bounds. The markPx gets calculated by the builder’s relayer combining on-chain and off-chain signals. The externalPerpPx provides a fallback reference. HIP-3 then composes these into an actual mark price through median calculation: first the local order book median, then combined with the builder-supplied external marks, then compared against externalPerpPx. This multi-source approach theoretically prevents any single price source from dictating liquidations.

Theoretically.

Why Oracle Definition Matters More Than Technology:

The technical composition of oracle definition is less critical than the builder’s operational capacity to maintain it. A builder selecting an oracle definition that relies on a centralized relayer server inherits that server’s availability, security, and update frequency as constraints. If the private key securing the relayer gets compromised, or if DDoS attacks prevent price updates, the oraclePx stagnates. With mark prices unable to update, the system reverts to local order book medians—exactly when liquidity is thinnest and manipulation risk peaks.

The December 14, 2025 incident on trade.xyz demonstrated this dynamic. Attackers accumulated a short position of approximately 398 XYZ100 contracts (~$10M), deliberately creating an imbalance. The price decoupled from external sources due to insufficient order book depth. Long position holders faced cascading liquidations, with roughly $13M in positions closed. The mechanism worked technically—liquidations executed—but the system transferred losses to the least-prepared participants rather than preventing the initial dislocation.

This scenario becomes far more likely when oracle definition assumes stable external price anchors during off-market hours.

The 24/7 vs Non-24/7 Asset Divide: Where Oracle Definition Becomes Critical

HIP-3’s flexibility to list any asset creates a categorical difference in oracle definition requirements.

24/7 Assets (Perpetual Cryptocurrencies):

For Bitcoin, Ethereum, and other 24-hour tradeable assets, oracle definition can rely on multiple CEX/DEX price feeds combined with specialized oracle services like Pyth. These assets trade continuously across multiple venues. A builder can aggregate multiple price sources, apply median calculations, and detect outliers. When one source drifts, others provide immediate anchoring.

Oracle definition for 24/7 assets remains challenging—selecting weighted sources, managing update frequency, handling exchange outages—but the underlying external market provides consistent signals even if any single feed fails.

Non-24/7 Assets (Equities and Commodities):

Oracle definition for stock perpetuals requires fundamentally different assumptions. During market hours, price feeds from services like Pyth provide stable external anchors. But when the New York stock exchange closes, the builder faces a choice: either halt price feeds (and restrict trading), or continue pricing based on internal market signals with external references only at “previous closing price.”

Most builders implementing non-24/7 assets currently use an internal pricing mechanism similar to trade.xyz—combining the last external oracle price with internal order book dynamics, clamped to prevent excessive drift (typically 1/max_leverage fluctuation). This is mathematically sound; it’s operationally dangerous.

During market closures, order book depth typically contracts. Market makers reduce quotes, retail participants sleep, and the market thins dramatically. An oracle definition that caps price movement to “1/10th of previous close” (for 10x leverage) sounds conservative. When liquidity vanishes, even modest order flow creates disproportionate price moves within that bounded range. When the market opens Monday morning and external data re-anchors, gaps emerge. These gaps trigger cascading liquidations or, in severe cases, ADL (automatic position reduction) events where profitable trades are forcibly closed to cover losses from insolvent positions.

Building a Defensible Oracle Definition Framework

Builders attempting to operate stable markets need oracle definition strategies that anticipate failure modes rather than assuming continuous stability.

Supplemental Price Anchors During Market Closures:

For non-24/7 assets, introducing external price signals even during market closures improves oracle definition substantially. Options include:

• Blue Ocean ATS and after-hours trading venues: These provide continuous price discovery outside regular trading hours, offering more current signals than “previous closing price.” A builder can weight Blue Ocean ATS data into the oracle definition during market closures, creating a less manipulable reference point.

• Weekend CFD quotes from providers like IG: These forecast market expectations for next-week openings. While not direct substitutes for spot prices, they serve as directional anchors for “expected opening gaps” within the oracle definition.

These sources share a crucial characteristic: they’re available during market closures but differ structurally from spot markets. Oracle definition should treat them as references and risk signals rather than unconditional equivalents.

Designing Transparent and Auditable Price Derivation:

The core vulnerability in current oracle definition implementation is centralization of the relayer. If price feeds originate exclusively from a builder’s private server, that server becomes a single point of failure and attack. Builders should construct oracle definition verification systems allowing external parties to audit price authenticity.

This requires publicly disclosing: the data sources feeding the oracle, the exact algorithm combining those sources, the sampling timestamps for each input, and the resulting mark prices. For each setOracle call, generate a cryptographic proof including raw data, computation steps, and final outputs. Serialize this into a proofHash, which the relayer signs. Periodically aggregate these hashes into Merkle trees and publish the root on-chain.

This approach transforms oracle definition from “trust the builder’s price server” to “verify the builder’s methodology.” Any user can retrieve historical price data, recompute outputs using published algorithms, and confirm whether the builder’s feeds matched declared sources.

When Oracle Definition Falters: Monitoring and Intervention

Even well-designed oracle definitions fail under extreme market stress. Builders operating on HIP-3 need monitoring frameworks detecting degradation before it cascades.

Price-Side Monitoring: Detecting Oracle Drift:

Oracle price feed failures appear first as discontinuities—the relayer stops updating. Builders should monitor on-chain observables: if two consecutive oracle updates exceed 10 seconds apart, the system flags Level 1 alert. The builder health-checks their relayer infrastructure, potentially switching to backup nodes.

More insidious is price de-anchoring: the oracle price drifts gradually from external benchmarks. A builder’s oracle definition might rely on Pyth for equity perpetuals, but Pyth’s input data (which uses aggregate exchange prices) diverges from current market conditions. The oracle definition becomes outdated without appearing broken. Monitoring thresholds should compare multiple external sources against the builder’s oracle: if two or more diverge by >X%, escalate alerts.

At Level 1 alert, lower open interest caps using setOpenInterestCaps. At Level 2 (sustained deviation), update margin tiers to gradually reduce maximum leverage by tier. At Level 3, trigger emergency stops via haltTrading.

Order Book Monitoring: Detecting Liquidity Collapse:

Oracle definition is only as useful as the market’s liquidity structure. If the order book narrows, spreads widen, and aggressive order impact spiked, even accurate prices become dangerous. Builders should track depth_band (cumulative volume within ±x% of mid price), spread (best ask - best bid), and impact_ratio (aggressive volume / depth_band). When depth shrinks while spreads and impact ratios expand simultaneously, liquidation risk rises sharply.

At Level 1, cap open interest growth. At Level 2, forcibly reduce leverage on high-risk positions.

Position Concentration Monitoring: Detecting Speculation Cascades:

Finally, monitor whether the market is shifting from genuine hedging to pure speculation. Track the ratio of open interest notional to 24-hour trading volume. When OI grows much faster than volume, the market is shifting toward accumulated one-sided exposure. Combined with extreme majority-side profit/loss, this precedes liquidation cascades. Builders should alert when ratios breach thresholds; if persistent, lower OI caps.

Governance Through Staking: Accountability for Oracle Definition Decisions

HIP-3’s mechanism for holding builders accountable centers on staking. Builders must maintain 500k HYPE staked at all times. Validators can vote to slash this stake if the builder’s actions create invalid market states, prolonged downtime, or performance degradation.

This staking mechanism makes oracle definition choices carry concrete financial consequences. A builder implementing a negligent oracle definition—accepting a single centralized price feed, failing to monitor drift, or ignoring off-hours pricing risks—creates liquidation cascades. Validators observing repeated failures or a market collapse directly traceable to oracle definition inadequacy can vote to slash the builder’s entire stake.

This transforms oracle definition from a technical decision to a governance decision. Validators implicitly ratify or penalize builders’ oracle choices through slashing votes. Over time, this creates evolutionary pressure: builders implementing robust oracle definitions survive; those cutting corners accumulate slashing votes.

The mechanism isn’t perfect—validators may lack technical sophistication to evaluate oracle definition choices fairly, or may vote in ways unrelated to true operational quality. But it establishes a minimum accountability threshold.

The Broader Implication: Decentralization as Risk Redistribution

HIP-3’s core innovation isn’t eliminating risk; it’s redistributing it. Where centralized exchanges internalize operational risk (maintaining price feeds, preventing manipulation, managing liquidations), HIP-3 externalizes these responsibilities to builders. The protocol provides infrastructure; builders provide operational excellence.

This works only when builders understand what they’ve actually assumed responsibility for. Oracle definition represents one of the most underestimated attack surfaces. It appears simple—select a price feed—but encompasses feed selection, relayer management, off-hours pricing, fallback mechanisms, verification frameworks, continuous monitoring, and governance accountability.

Markets built on careless oracle definitions will fail. Markets built on thoughtful oracle definitions, proper monitoring, and transparent verification mechanisms can sustain substantial trading activity. The $13 billion in trade volume through HIP-3 markets suggests adequate builders exist. But each failed market—each liquidation cascade traceable to oracle definition failures—transfers capital from unsuspecting traders to platform operators and sophisticated arbitrageurs.

Builders entering HIP-3 should approach oracle definition not as a technical implementation detail but as the foundational architectural decision determining whether their market will operate with integrity or fail under stress.

Navigating the Path Forward

For builders designing market access, parameter templates, alerting systems, and emergency response procedures based on HIP-3, success hinges on treating oracle definition as a first-principles design problem. This means explicitly modeling how your oracle definition behaves under scenarios: exchange outages, DDoS attacks on your relayer, gaps between internal and external pricing during off-hours, and liquidation cascades under thinly-traded conditions.

It means implementing verification frameworks allowing external auditing of your price methodology. It means establishing monitoring thresholds and escalation procedures with clear decision rules. Most importantly, it means recognizing that the complexity of maintaining trustworthy oracle definitions under stress hasn’t disappeared—it’s simply moved from the exchange to builders.

Those who take oracle definition seriously will operate stable, trusted markets. Those who don’t will become case studies in how decentralized systems fail.