Why You Can Get Liquidated Before Spot Hits Your Liquidation Price

Data reviewed: 10 September 2026

Methodology: DN-POBRI v1.0

Affiliate disclosure: Decentralised News may receive compensation when eligible users use certain partner links. Commercial relationships do not determine benchmark inclusion, methodology, measurements or conclusions.

The Signal

A perpetual trader can be looking at five different versions of the same asset price:

spot price → index price → oracle price → mark price → executable price

and the price that determines liquidation may not be the one displayed on an external BTC or ETH chart.

The DN Perpetual Oracle Basis Risk Index measures these divergences in basis points and asks a more useful question:

How much of a trader’s liquidation buffer can disappear because the protocol’s risk price differs from the price the trader thinks they are watching?

DN calls this Liquidation Headroom Compression.

What Matters

The biggest misconception in leveraged crypto trading is that there is one “BTC price.”

There isn’t.

At the same moment:

Binance spot might show one price.

Coinbase may show another.

The perp order book can show another.

An oracle can produce another.

A protocol’s mark-price algorithm may produce another.

And the liquidation engine may deliberately use yet another directional price.

These differences are usually small.

At high leverage, however, small is not the same as irrelevant.

A 25-basis-point divergence represents:

$25 on $10,000 notional

$250 on $100,000

$1,250 on $500,000

$2,500 on $1 million

More importantly, a 25 bp adverse divergence can consume a meaningful portion of the remaining distance to liquidation.

That is the risk this Index is designed to expose.

Key Findings

There is no universal “mark price.” Hyperliquid constructs a mark using multiple oracle, local-book and external-perpetual inputs. GMX calculates a midpoint mark but does not use that mark for liquidation. dYdX primarily uses its oracle price for collateralization and liquidation eligibility. gTrade deliberately separates mark and index prices for some markets.

A displayed spot chart is not necessarily the liquidation reference. Hyperliquid uses its mark price for margining and liquidation, while GMX uses directional oracle bounds, specifically the lower oracle price for closing/liquidating longs and the upper oracle price for shorts.

Oracle divergence is not automatically oracle failure. Different exchanges genuinely trade at slightly different prices, especially during volatility, fragmented liquidity or impaired arbitrage. Pyth explicitly publishes a confidence interval because a single universally correct market price often does not exist.

Oracle age matters alongside oracle price. A numerically accurate price can become dangerous if it stops updating. Pyth specifically advises consumers to check staleness rather than assuming the last available observation is current.

Basis risk becomes more important as liquidation approaches. A 10 bp discrepancy is relatively unimportant when a position has 2,000 bps of remaining buffer but very important when only 40 bps remain.

The benchmark therefore does not simply rank oracle providers. It evaluates the complete protocol pricing stack that ultimately affects the trader.

The Hidden Price Stack of a Perpetual Trade

Consider a trader who sees:

External BTC spot: $100,000

But the platform simultaneously reports:

Oracle: $99,970

Mark: $99,930

Perp book mid: $99,910

Those numbers are all reasonably close.

But imagine the trader’s liquidation threshold is:

$95,000

The external spot chart suggests approximately:

500 bps of headroom

The protocol risk price of $99,930 gives slightly less.

Nothing catastrophic has happened.

But part of the apparent safety buffer never existed according to the system actually managing the position.

DN calls that difference:

Liquidation Headroom Compression

The Five Prices Traders Need to Understand

1. External Spot Reference

DN’s independent approximation of the underlying asset’s contemporaneous fair value.

For the future live Index, this should not come from one exchange.

It should use a robust multi-venue composite with outlier controls.

Its role is not to declare one exchange “correct.”

Its role is to provide a consistent external reference.

2. Index Price

An aggregated reference intended to represent the underlying asset rather than the local perpetual market.

It can be built from:

• centralized exchanges
• spot markets
• external market-data providers
• validator observations
• oracle publishers

But protocols use the word index differently.

That is one reason simplistic comparison tables become misleading.

3. Oracle Price

The price transmitted into the protocol’s risk machinery.

For some platforms, the oracle and index concepts are effectively intertwined.

For others they remain distinct.

The crucial question is:

What price can actually change account health?

4. Mark Price

A protocol-generated fair-value reference typically designed to resist manipulation or noisy last trades.

It may incorporate:

• oracle price
• perp prices
• local order book
• moving averages
• spreads
• risk adjustments

But, again, it is not universal.

On Hyperliquid the mark is central to liquidation.

On GMX the displayed midpoint mark is explicitly not the order-trigger or liquidation price.

5. Executable Price

Finally there is the amount at which the position can actually be opened or closed.

Liquidation eligibility and liquidation execution are two separate questions.

A position can become liquidatable at one reference price and then be closed against:

• an order book,
• liquidity pools,
• liquidators,
• protocol liquidity,
• a calculated liquidation price band.

That difference is critical.

The DN Risk Price

To compare radically different architectures, Decentralised News introduces a normalization term:

DN Risk Price

The price input that directly determines account health or liquidation eligibility at that instant.

It is not necessarily:

• the chart price
• the mark labelled in an interface
• the last traded price
• the order-book mid

For each platform, DN first identifies the Risk Price, then compares that price with external market value.

That makes cross-platform comparisons possible without pretending their terminology is identical.

DN Spot-to-Oracle Basis

The first measurement is straightforward:

Spot-Oracle Basis =

(Oracle Price − External Spot Reference) ÷ External Spot Reference × 10,000

Suppose:

External spot:

$100,000

Oracle:

$99,950

Then:

Spot-to-Oracle Basis = −5 bps

The oracle is five basis points below the external reference.

That number alone is not inherently good or bad.

Direction matters.

For a leveraged long nearing liquidation, an oracle below spot may be adverse.

For a short, the same discrepancy may be favorable.

DN Mark-to-Oracle Basis

Next:

Mark-Oracle Basis =

(Mark Price − Oracle Price) ÷ Oracle Price × 10,000

Example:

Oracle:

$100,000

Mark:

$99,900

Mark-to-Oracle Basis:

−10 bps

This measures what the protocol’s own mark construction adds on top of the oracle.

For some architectures it may reflect:

• perp premium/discount
• local-book conditions
• smoothing
• risk adjustments

DN Risk-Price Basis

The more important number for leveraged traders is:

Risk-Price Basis

RPB = (Risk Price − Spot Reference) ÷ Spot Reference × 10,000

This asks:

How far is the price actually protecting the protocol’s margin system from the external spot reference?

Adverse Liquidation Basis

Raw basis is directional.

DN therefore defines:

For a long

ALB = max(0, Spot − Risk Price) ÷ Spot × 10,000

For a short

ALB = max(0, Risk Price − Spot) ÷ Spot × 10,000

This isolates only the divergence moving the trader toward liquidation.

Suppose:

External BTC spot:

$100,000

Risk price:

$99,800

A long experiences:

20 bps adverse basis

A short experiences:

0 bps adverse basis

Reverse the prices and the result reverses.

DN Liquidation Headroom Compression

Now we reach the central metric.

Suppose a long has:

External spot:

$100,000

Liquidation level:

$95,000

External-spot headroom is approximately:

500 bps

But the platform risk price is:

$99,750

The risk-price-based buffer is smaller.

DN defines:

Headroom Compression

Spot-Based Liquidation Headroom − Risk-Price-Based Liquidation Headroom

And:

Liquidation Basis Exposure

LBE = Headroom Compression ÷ Spot-Based Headroom × 100

This produces an intuitive answer:

What percentage of the apparent liquidation buffer has been consumed by the pricing basis itself?

Why This Is More Useful Than Saying “The Oracle Is 20 bps Off”

Imagine two traders facing the same 20 bp adverse basis.

Trader A

Remaining liquidation headroom:

2,000 bps

Basis consumes roughly:

1% of the buffer

Trader B

Remaining headroom:

40 bps

A 20 bp discrepancy represents roughly:

half of the remaining safety margin

Same oracle basis.

Completely different risk.

That is why basis must be interpreted relative to liquidation distance.

Hyperliquid: Liquidation Is Driven by Mark Price

Operational status: LIVE

Hyperliquid provides one of the clearest examples of a multi-layer pricing architecture.

Validators publish spot oracle prices approximately every three seconds.

For major external assets, validator oracle calculations incorporate weighted spot prices from exchanges including Binance, OKX, Bybit, Kraken, KuCoin, Gate.io and MEXC. Validator submissions are then combined using a stake-weighted median.

But the oracle price itself is not Hyperliquid’s liquidation price input.

Its mark price is.

How Hyperliquid Constructs the Mark

Hyperliquid documents the mark price as the median of several robust inputs, including:

1. the oracle price adjusted by an EMA of the difference between the Hyperliquid mid and oracle;
2. a local Hyperliquid price based on best bid, best ask and last trade;
3. a weighted collection of external perpetual-market mid prices.

The mark updates alongside oracle updates, approximately every three seconds.

The result is important because Hyperliquid uses this mark for:

• margining
• unrealized PnL
• liquidations
• TP/SL triggers

Why This Matters to the Trader

Imagine the spot oracle is:

$100,000

but perp markets collectively trade lower.

Hyperliquid’s mark calculation can reflect some of that derivative-market information.

The platform may therefore consider a leveraged long less healthy than somebody looking exclusively at an external spot chart expects.

This is not automatically unfair.

It is the consequence of using a robust derivative fair-value mechanism instead of one instantaneous price.

What DN wants to measure is:

How large does that difference become under ordinary and stressed conditions?

Hyperliquid Creates Three Distinct Basis Tests

DN should separately record:

Oracle vs External Spot

Does the validator oracle follow the broader spot market?

Mark vs Oracle

How much adjustment is introduced by perp and local-book information?

Book vs Mark

How far can executable local trading price diverge from the price used to margin the account?

These are economically different phenomena.

Hyperliquid itself cautions that mark and book price can differ materially during highly volatile conditions and recommends using the actual mark formula when monitoring liquidation precisely.

GMX: The Displayed Mark Is Not the Liquidation Trigger

Operational status: LIVE

GMX demonstrates exactly why a universal definition of mark price fails.

GMX currently receives Chainlink Data Streams pricing as a bid/ask spread represented by:

minPrice

and

maxPrice.

Its documented execution convention is directional:

This is not arbitrary.

The system uses the adverse side of the available price spread.

GMX’s Mark Price Serves a Different Purpose

GMX defines its displayed mark as:

(minPrice + maxPrice) ÷ 2

But the protocol explicitly says this midpoint is used for:

• interface/chart display
• funding calculations
• some price-impact calculations

and not for order triggering or execution.

That is a crucial distinction.

A user could therefore see:

Mark = $100,000

while liquidation of a long is evaluated using:

minPrice = $99,970

The 3 bp difference is not oracle failure.

It is part of the price-spread design.

DN Calls This Directional Oracle Basis

For GMX-style architectures, a midpoint comparison is inadequate.

DN therefore records:

Directional Oracle Basis

For longs:

minPrice vs external reference

For shorts:

maxPrice vs external reference

This creates an apples-to-apples comparison with other protocols’ risk prices.

GMX Liquidation Price Is Also Dynamic

GMX calculates whether a position can remain open after considering:

• unrealized losses
• accrued fees
• negative price impact
• minimum collateral requirements

For long positions, liquidation calculations use the lower index/oracle bound; for shorts they use the upper bound. Borrow and funding costs can also move the effective liquidation point over time.

So again:

The number labelled “liquidation price” is not necessarily permanently fixed at position entry.

dYdX Chain: Oracle Consensus Drives Account Health

Operational status: LIVE

dYdX takes another approach.

Current dYdX documentation says the network’s validator set participates in determining oracle prices.

Those oracle prices are used to:

• ensure accounts remain collateralized;
• determine liquidation;
• trigger conditional orders such as stops and take-profit orders.

That means the DN Risk Price for liquidation eligibility is principally:

Oracle Price

rather than a separate Hyperliquid-style mark.

But Liquidation Trigger and Liquidation Execution Still Differ

A dYdX account becomes eligible for liquidation when account value falls below maintenance requirements based on oracle pricing.

But positions are not necessarily closed at the oracle itself.

The liquidation engine creates a liquidation order with a calculated Fillable Price, then matches it against available order-book liquidity.

So DN needs two separate measurements:

Trigger Basis

Where liquidation becomes eligible.

Liquidation Execution Gap

Where the position actually closes relative to the trigger reference.

Combining these into one number would obscure the real mechanics.

dYdX Stop Orders Add Another Price Layer

dYdX conditional orders can use oracle price and a clamped last-traded-price mechanism.

Its documentation says the last traded price used for triggering is constrained relative to the oracle to reduce the risk of an isolated local price causing inappropriate order triggering.

That gives DN another potential future benchmark:

Trigger Price Integrity

Does a trader’s stop activate before, after or near the point expected from the external reference market?

That will be addressed separately in the DN Stop-Loss Reliability programme.

gTrade: Mark and Index Prices Are Deliberately Separated

Operational status: LIVE

gTrade presents perhaps the most educational example for this Index because its current pricing API explicitly separates:

Mark Price

Used for:

• trade execution
• PnL
• TP/SL
• limit orders
• stop orders

Index Price

Used for:

• liquidation calculations

For some markets the two can be identical.

For others they may not be.

Why gTrade Separates Them

gTrade categorizes markets into several types.

For certain volatile crypto markets, the mark can reflect futures pricing while the index remains spot-based.

Its documentation explicitly warns that mark and index prices for these volatile pairs may differ significantly.

That creates an unusual situation.

A trader’s:

PnL

can be responding to one price stream,

while:

liquidation eligibility

is responding to another.

That is exactly the kind of architectural distinction DN wants to make visible.

Why a Single “Oracle Quality Score” Would Be Wrong

Consider:

Hyperliquid’s risk price:

composite mark

GMX’s:

directional Chainlink oracle bound

dYdX’s:

validator oracle

gTrade’s:

spot index for liquidation

If DN merely measured:

Which oracle is closest to Coinbase?

we would be measuring the wrong thing.

The Index therefore scores the whole price-risk pipeline.

Architecture Comparison

This is an architecture classification, not a performance ranking.

Pyth Shows Why “Oracle Accuracy” Is Not One Number

Pyth’s current documentation is particularly useful here.

Each price can include:

• aggregate price
• confidence interval
• publisher count
• update timestamp

The confidence interval measures disagreement or uncertainty across publisher observations.

During stressed conditions, that interval can widen.

That gives the future DN benchmark another valuable variable:

Oracle Confidence Width

Rather than merely asking:

What is the oracle price?

DN can ask:

How certain is the oracle network that this price represents the underlying market?

Oracle Age Is a Separate Risk

Suppose two prices both show:

BTC = $100,000

Oracle A updated:

0.5 seconds ago

Oracle B updated:

45 seconds ago

They are numerically identical.

They are not informationally equivalent.

Pyth specifically tells integrators to guard against stale prices and notes that blockchain, network or data-provider problems can leave a previous value in place.

That leads to another DN measurement:

Price Age at Risk Event

For every:

• liquidation trigger
• stop trigger
• large basis deviation

record how old the relevant oracle observation was.

Oracle Latency Cannot Be Reduced to “Fastest Wins”

An oracle must balance:

latency

against:

robustness

A raw exchange WebSocket can update faster than an on-chain consensus-backed oracle.

But raw speed is not the only objective.

Pyth explicitly notes that on-chain oracle systems inherently face latency relative to off-chain sources because consensus and security add overhead. It recommends protocols design with that latency threat model rather than assuming it does not exist.

That is why DN should not rank oracle infrastructure solely by milliseconds.

DN Oracle Basis Risk Dataset

Every observation should record at least:

The First DN Test Should Focus on BTC and ETH

The cleanest first empirical benchmark would use:

BTC

and:

ETH

Why?

Because these assets have:

• deep external liquidity;
• many independent price venues;
• mature perpetual markets;
• relatively strong oracle coverage.

That makes external-reference construction substantially easier.

Once the methodology works, expand into:

SOL

HYPE

and selected liquid altcoins.

The long-tail cohort should be separate.

Long-Tail Perpetuals Are Where This Becomes More Interesting

For obscure assets:

• spot liquidity is thinner;
• fewer exchanges provide meaningful discovery;
• perp liquidity can dominate spot liquidity;
• spreads widen;
• oracle publisher coverage can weaken;
• stale or noisy feeds become more important.

A 3 bp BTC basis may be routine.

A thin token can behave very differently.

Hyperliquid explicitly uses additional restrictions including open-interest caps on less-liquid assets as part of its oracle-manipulation risk controls.

This suggests DN should eventually maintain separate:

Major Asset Oracle Index

and

Long-Tail Oracle Index

rather than pretending their risk distributions are comparable.

DN Stress Regimes

Measurements should be labelled according to the environment in which they occurred.

Normal

Low/moderate realized volatility.

Volatility Shock

Large short-window move.

Liquidity Stress

External exchange spreads widen.

Exchange Divergence

Spot venues disagree materially.

Oracle Staleness Event

Price age exceeds normal cadence.

Perp Basis Stress

Derivative market diverges materially from spot.

The Index should eventually answer:

Which architecture remains most stable when the market becomes least stable?

That is much more useful than measuring 10,000 observations during quiet conditions.

P95 Matters More Than the Average

Suppose:

Platform A

Median Risk-Price Basis:

2 bps

P95:

7 bps

P99:

18 bps

Platform B

Median:

1 bp

P95:

25 bps

P99:

90 bps

Which oracle system is better?

A simple average might favor B.

A trader using 30x leverage may care much more about the tail.

Therefore DN should publish:

Median absolute basis

P75

P95

P99

Maximum observed adverse basis

basis duration

frequency above 10 / 25 / 50 bps

A New DN Metric: Basis Shock Persistence

A one-second dislocation and a five-minute dislocation are not equivalent.

DN defines:

Basis Shock Persistence

Time for an adverse Risk-Price Basis exceeding a specified threshold to return below that threshold.

For example:

>10 bp event duration

>25 bp event duration

>50 bp event duration

This can distinguish an architecture that temporarily reacts to noise from one where divergence persists.

DN Oracle Basis Half-Life

Borrowing the temporal concept introduced in our DEX Quote Decay research:

Oracle Basis Half-Life

The time required for a basis shock to retrace half of its peak deviation.

Example:

Basis spikes:

40 bps

It later falls to:

20 bps

after:

11 seconds

Basis Half-Life:

11 seconds

This measures resilience rather than merely the peak.

The Most Important Metric for Leveraged Traders

Peak basis still needs position context.

That gives us:

DN Liquidation Basis Exposure

LBE = Adverse Basis ÷ Remaining Spot-Based Liquidation Headroom

expressed as a percentage.

Suppose:

Adverse basis:

20 bps

Remaining headroom:

200 bps

LBE:

10%

If headroom is only:

40 bps

then:

LBE:

50%

This is the metric I would expect to become particularly useful for AI citations because it translates an abstract oracle discrepancy into a question traders intuitively understand:

How much of my liquidation buffer is being consumed by the price layer?

Worked Example

Assume a BTC long.

External Spot

$100,000

Oracle

$99,950

Mark

$99,900

Platform Risk Price

$99,900

Liquidation Threshold

$98,000

Position Notional

$500,000

Spot-to-oracle basis:

−5 bps

Mark-to-oracle basis:

approximately:

−5 bps

Risk-price basis versus spot:

−10 bps

The long therefore faces approximately:

10 bps of adverse liquidation basis

On $500,000 notional, 10 bps corresponds to:

$500 of notional price sensitivity.

But the more relevant observation is the liquidation buffer.

External spot headroom:

approximately:

200 bps

The 10 bp adverse basis represents approximately:

5% of that apparent buffer.

That is the information the trader actually needs.

What Happens at High Leverage?

Consider a simplified position with 50 bps of remaining risk headroom.

A:

5 bp adverse basis

consumes approximately:

10%

of the buffer.

A:

25 bp adverse basis

consumes approximately:

50%

A:

50 bp adverse basis

can consume essentially the entire simplified remaining buffer.

That does not mean the oracle directly “caused a 50 bp loss.”

It means the platform’s risk reference moved 50 bps toward the position’s liquidation boundary relative to the chosen external reference.

Those concepts must not be confused.

DN Oracle-to-Liquidation Risk Calculator

The following proprietary tool lets readers enter:

• external spot price;
• oracle price;
• mark price;
• actual platform risk price;
• liquidation price;
• long or short;
• position notional;
• price age.

It calculates:

Spot-Oracle Basis

Mark-Oracle Basis

Risk-Spot Basis

Adverse Liquidation Basis

Spot-Based Headroom

Risk-Price Headroom

Headroom Compression

Liquidation Basis Exposure

Notional sensitivity

The calculator intentionally does not calculate a venue’s exact liquidation price because liquidation formulas differ by platform, position type, funding, fees, portfolio margin and maintenance tiers.

Enter the liquidation threshold supplied by the venue itself.