Quick Verdict

This is an architecture comparison, not yet the final DN empirical ranking.

The Problem With Existing Perpetual DEX Rankings

Most perpetual DEX reviews rank platforms using:

• fees
• leverage
• markets
• volume
• user interface
• token incentives

Those metrics matter.

But for a leveraged trader, one of the most important questions is barely examined:

When the market goes against me, does my stop actually get me out?

A platform could offer:

0% fees

and:

100x leverage

but still provide poor risk protection if the stop mechanism is vulnerable to:

• trigger delays
• stale price feeds
• thin liquidity
• excessive slippage
• keeper failure
• chain congestion
• liquidation racing ahead of the stop

That deserves its own benchmark.

The Three Stages of a Stop Loss

A stop-loss should not be treated as one event.

It is at least three.

Stage 1: Trigger

The protocol decides that the stop condition has been reached.

Example:

BTC stop = $75,000

But which BTC price?

It might be:

• mark
• index
• oracle
• bid
• ask
• last trade

That choice can materially alter when the stop activates.

Stage 2: Execution

Triggering does not necessarily close the position.

A stop can transform into:

Market Order

Prioritizes exit probability.

But price is not guaranteed.

or:

Limit Order

Prioritizes price protection.

But fill is not guaranteed.

This is perhaps the most important stop-loss trade-off.

Stage 3: Settlement Before Liquidation

A highly leveraged trader may have:

Stop

$75,000

Liquidation

$74,700

A violent move can cross both levels almost simultaneously.

Now the relevant question becomes:

Which operation wins?

The stop?

Or liquidation?

This is where perp DEX architecture becomes particularly important.

DN Stop-Loss Reliability Score

The live benchmark scores each observation from:

0 to 100.

1. Fill Completion: 20 Points

Did the intended position actually close?

100% closed

Full score.

70% closed

Partial credit.

0%

Zero.

A stop that triggered but left most of the position open is not reliable protection.

2. Liquidation Protection: 20 Points

Did the stop close the position before liquidation?

This is the benchmark’s defining metric.

Stop fully closes before liquidation

Maximum score.

Stop partially closes first

Partial score.

Liquidation occurs first

Zero.

3. Trigger Fidelity: 15 Points

Measure:

Observed Trigger Reference − Configured Trigger

in basis points.

A platform triggering within a few basis points of the intended reference receives a high score.

Large deviations reduce the score.

4. Trigger-to-Fill Latency: 15 Points

Measure:

Trigger Timestamp → Final Fill Timestamp

Possible causes of latency include:

• keeper response
• validator consensus
• matching-engine processing
• blockchain confirmation
• oracle update timing
• congestion

A stop that begins execution immediately but takes five seconds to close a leveraged position can behave very differently from one settling in hundreds of milliseconds.

5. Execution Slippage: 15 Points

For a long position stop:

Slippage = Trigger Price − Average Exit Price

For a short:

Slippage = Average Exit Price − Trigger Price

Convert to:

basis points.

Stop-market orders will normally tolerate more slippage than stop-limit orders.

The benchmark measures the result rather than automatically rewarding either design.

6. Oracle / Mark Delay: 10 Points

Record the time between:

external reference-market movement

and:

venue trigger reference update.

This is especially valuable during sudden moves.

7. Execution Reliability: 5 Points

Was the conditional order:

• executed
• rejected
• expired
• canceled
• missed
• reverted

Repeated observations then create an empirical failure rate.

DN Score Formula

Stop-Loss Reliability Score =

20% Fill Completion

20% Liquidation Protection

15% Trigger Fidelity

15% Trigger-to-Fill Latency

15% Slippage

10% Oracle Responsiveness

5% Execution Success

What DN Should Test

A robust test should not use one stop.

Use several scenarios.

Test 1: Normal-Market Stop

Example:

BTC

Position:

$10,000

Leverage:

5x

Stop:

approximately 2% away

Purpose:

Measure normal execution.

Test 2: Tight Stop

Position:

$10,000

Leverage:

10x

Stop:

approximately 0.5% to 1% away

Purpose:

Test sensitivity to short-lived volatility.

Test 3: Large Position

Position:

$100,000

Purpose:

Expose:

• order-book depth
• slippage
• partial fills
• AMM liquidity constraints

Test 4: Liquidation-Race Test

Create an appropriately controlled research position with a stop materially closer to liquidation than normal.

The objective is not to recommend this trading behaviour.

It is to measure:

Can the stop complete before the liquidation mechanism becomes dominant?

This should preferably be performed using conservative test capital or simulation infrastructure.

Test 5: Congestion / Volatility Test

Run during:

• CPI
• FOMC
• major crypto news
• rapid BTC moves
• blockchain congestion

This is where stop architecture matters most.

Trigger Price vs Mark Price vs Index Price

These concepts should not be confused.

Last Price

The price of the most recent trade.

One aggressive trade can move it.

Index Price

Usually attempts to represent the underlying asset’s external fair value.

Mark Price

A derived fair-value reference generally used to reduce manipulation and unnecessary liquidations.

Oracle Price

External or decentralized price data supplied to the protocol.

A platform may use several of these simultaneously.

1. gTrade: The Most Interesting Stop-Guarantee Claim

gTrade deserves particular attention because its documented stop architecture makes an unusually strong statement.

Current documentation says stop losses for:

BTC

and:

ETH

are guaranteed at the user’s set price under the stated crypto execution model.

The documentation also warns that during high network congestion the stop may not trigger immediately and says manually closing the trade while waiting can void the guaranteed-stop behavior.

That is an unusually important claim.

Most perp venues explicitly say:

execution price may differ from stop price.

gTrade is saying something materially stronger for qualifying markets.

gTrade Mark vs Index

gTrade now separates:

Mark Price

Used for:

• TP
• SL
• limit orders
• stop orders
• PnL

Index Price

Used for:

liquidations.

That means stop execution and liquidation can reference different pricing layers.

This makes the liquidation-race test particularly interesting.

Oracle Architecture

gTrade uses a custom Chainlink oracle network for trade pricing and attempts to filter isolated exchange wicks.

Its contracts expose specific:

• TP
• SL
• liquidation
• limit
• stop

trigger flows.

Trigger bots identify eligible orders and oracle responses complete the execution process.

One Important 2026 Development

Current contract changes added:

• closing spread and price-impact treatment
• max closing slippage
• new liquidation logic
• explicit prioritization of SL triggers over liquidation when possible

but the changelog also makes clear that execution can still be affected by closing-price economics and trigger processing.

That makes gTrade the ideal platform to test scientifically.

DN question

Does the documented BTC/ETH stop-price protection continue to deliver:

exact-price protection

under:

• congestion
• rapid oracle movement
• liquidation proximity
• larger sizes?

If yes, that would be a significant differentiator.

gTrade Weakness

Guaranteed-stop language does not extend universally across every asset class.

For:

• stocks
• indices
• commodities
• forex

gaps during closed-market periods can make stop losses non-guaranteed.

Therefore:

gTrade’s crypto stop result must not be generalized to every gTrade market.

2. GMX: Best Stop-Trigger Transparency

GMX offers one of the most precisely documented stop architectures in DeFi.

It does not use its displayed mark price to trigger stop-loss orders.

Instead it uses Chainlink Data Stream:

minPrice

and:

maxPrice.

For stop losses:

Long

Triggers when:

minPrice ≤ Stop Price

Short

Triggers when:

maxPrice ≥ Stop Price

The same oracle component becomes the base execution price.

Why This Matters

Imagine the GMX screen displays:

ETH Mark: $2,400

Your long stop:

$2,395

The displayed mark can touch $2,395 without necessarily producing exactly the trigger behavior a trader expects because GMX’s stop logic uses the relevant edge of the oracle spread rather than the midpoint mark.

This is not necessarily bad.

It is simply different.

And DN should measure it correctly.

Oracle Gaps

GMX explicitly documents another important failure mode.

Suppose the oracle updates:

$4,010

↓

$3,990

while your stop is:

$4,000.

The order can execute on the next available oracle price rather than exactly at $4,000.

Therefore:

trigger reached

does not imply:

fill at trigger.

Keeper Design

GMX conditional orders are executed by keepers.

Oracle keepers obtain price reports, while order keepers process eligible transactions.

This creates a measurable variable:

keeper response time.

GMX Stop vs Liquidation

This is one of the most important documented behaviors in the benchmark.

When a position becomes liquidatable, GMX attempts eligible stop-loss orders before liquidation.

But GMX explicitly says this is:

not guaranteed.

Separate keeper processes operate concurrently, and a fast market move can cross both:

stop threshold

and:

liquidation threshold

in the same oracle update.

That is exactly the scenario the DN benchmark should recreate.

Partial Stops

GMX supports partial-size TP/SL instructions as well as full-position protective exits.

DN Verdict on GMX

Best documented oracle/keeper stop architecture in the group.

Not necessarily the most reliable in practice.

But one of the easiest to test scientifically because the trigger rules are explicit.

3. Lighter: Mark-Triggered Order-Book Stops

Lighter uses:

mark price

to trigger stop orders.

For a stop-loss sell:

Mark Price ≤ Trigger

For a stop-loss buy:

Mark Price ≥ Trigger.

The platform supports:

• standard stop loss
• stop-loss limit
• take profit
• take-profit limit
• reduce-only execution

Lighter Mark Price

Lighter’s mark price is unusually sophisticated.

It incorporates:

• order-book impact prices
• index price
• an eight-minute EMA component
• external CEX mark prices

and takes a median across those components.

Its index itself uses oracle infrastructure including:

• Chainlink
• Stork
• Pyth.

This creates substantial manipulation resistance.

But it also means:

Lighter mark price is not simply the last traded price.

Stop-Market Risk

Once triggered, an order still needs liquidity.

Lighter documents that market orders can be:

partially filled

where insufficient liquidity exists or where further fills would violate the user’s execution-price protection.

That is highly relevant to a stop-loss benchmark.

A stop can trigger perfectly and still fail to close:

100% of the position.

Stop-Limit Risk

Lighter also supports stop-loss limit orders.

These provide better price control.

But they introduce the classic risk:

triggered but unfilled.

Liquidation Interaction

Lighter uses its mark price when determining liquidation conditions.

When partial liquidation begins, the liquidation engine first:

cancels the user’s open orders

before attempting IOC liquidation orders.

That creates a crucial research question:

How much buffer must exist between a resting stop and liquidation for the stop to execute before liquidation logic cancels remaining orders?

DN should test this directly.

DN Verdict on Lighter

One of the strongest candidates for mark-triggered order-book execution.

Its main benchmark variables are:

• mark responsiveness
• book depth
• partial fills
• liquidation timing

4. Hyperliquid: Flexible Stop-Market vs Stop-Limit Execution

Hyperliquid supports both:

Stop Market

and:

Stop Limit

orders.

Its TP/SL triggers use:

mark price.

Hyperliquid Stop Market

A stop-market order prioritizes exit.

Current documentation specifies a default:

10% slippage tolerance

for TP/SL market orders.

This is an important number.

It makes the order far more likely to execute through a rapid move.

But it can also permit substantial execution deviation in:

• thin markets
• very large positions
• violent volatility

Hyperliquid itself warns that low liquidity and rapid movement can result in significantly worse fills.

Hyperliquid Stop Limit

A stop-limit allows traders to control execution price.

Example:

Trigger

$10

Limit

$9.80

When mark reaches the trigger, the limit order becomes active.

The trade-off:

If price jumps straight to:

$9.50

the position may remain open.

This is not a bug.

It is the fundamental compromise between:

price certainty

and:

execution certainty.

DN Verdict on Hyperliquid

Excellent stop-order flexibility and a strong candidate for the large-position liquidity test.

The primary metric should be:

slippage distribution by order size.

5. Paradex: Mark-Price Trigger + Order-Book Execution

Paradex supports:

• stop-market
• stop-limit
• TP/SL
• reduce-only orders

and explicitly triggers stop orders using:

Mark Price.

Paradex Mark Price

Paradex calculates its perpetual mark using:

Spot Oracle Price × (1 + Fair Basis).

Its spot oracle incorporates:

• Pyth
• Stork

while the fair-basis calculation also includes information from:

• Paradex’s own market
• external venues including Binance, Bybit, OKX, Hyperliquid and Lighter.

That makes it a particularly interesting cross-venue fair-value system.

Stop Market

Once mark crosses the trigger:

a market order is released.

The final execution can differ significantly from the stop during a fast market.

Paradex market orders consume successive order-book levels until the requested amount is filled.

This means order size directly affects stop-loss slippage.

Stop Limit

Paradex explicitly warns that a stop-limit can trigger and remain unexecuted where price gaps through the limit.

Liquidation

Paradex uses partial liquidation when an account breaches its margin requirements rather than necessarily closing everything immediately.

That can potentially give risk-management actions more room than an instant full liquidation, but this requires empirical testing.

DN Verdict on Paradex

Strong, transparent mark-triggered order-book architecture.

Large-position stop-market slippage should be one of the key tests.

6. dYdX: Oracle-Driven Trigger Logic

dYdX uses oracle prices as a fundamental part of its risk architecture.

Current dYdX Chain documentation says oracle price is used for:

• collateralization
• liquidation
• triggerable orders

including stop orders.

Validators participate in producing and validating those oracle values through consensus.

dYdX Stop Orders

The current software supports:

• Stop Market
• Stop Limit

and documents a:

10% maximum slippage

for stop-market execution.

Trigger Protection

dYdX also uses protected logic around last traded price.

Last trade can participate in stop-limit triggering, but the value is clamped relative to the oracle price to reduce the chance that an isolated venue print improperly activates conditional orders.

Stop vs Liquidation

Oracle pricing is also central to liquidations.

This creates a comparatively coherent reference framework:

same underlying oracle system

drives both:

• risk
• conditional execution

However, when price moves rapidly, execution still depends on actual order-book conditions.

DN Verdict on dYdX

Strong oracle-trigger transparency with a mature order-book architecture.

Key test:

oracle trigger → book fill latency.

7. Aster: Mark Price or Last Price

Aster gives traders something unusual:

choice.

TP/SL orders can use:

Mark Price

or:

Last Price.

Why This Is Useful

Mark price can reduce false triggers caused by an isolated wick.

Last price reacts more directly to actual trading activity.

That means different traders may rationally prefer different trigger sources.

Why This Creates Risk

If liquidation uses:

Mark Price

but the user’s stop is configured using:

Last Price

the two risk systems can move differently.

Aster confirms that mark price is the primary liquidation reference.

Therefore DN should run two separate Aster tests:

Test A

Stop Trigger = Mark

Test B

Stop Trigger = Last

Then compare:

• false triggers
• latency
• proximity to liquidation
• execution quality

Stop Market vs Stop Limit

Aster supports both.

Its own documentation makes the trade-off explicit:

Stop Market

Prioritizes execution but price can differ from the stop.

Stop Limit

Controls price but can remain unfilled in a fast move.

Liquidation Interaction

Aster liquidation begins by canceling open orders before using IOC execution to reduce the position.

This means a stop must be given adequate distance from liquidation.

DN Verdict on Aster

Best trigger-reference flexibility.

It deserves a dedicated:

Mark vs Last Stop Trigger Test.

8. MYX: Keeper-Based Oracle Execution

Trade on MYX

Invitation code: PHSTTHK

MYX uses a very different architecture from an order-book DEX.

Its Matching Pool Mechanism uses liquidity pools as counterparties while trade pricing is based on oracle data.

MYX documentation says trades use:

Pyth oracle pricing

rather than conventional order-book price impact.

Stop Architecture

MYX supports:

• TP
• SL
• partial advanced TP/SL
• multiple decrease orders

through its trading contracts.

Orders are stored and monitored by:

keepers.

When the relevant conditions are met, keepers execute them.

Keeper Network

MYX’s documented keeper architecture uses multiple active nodes with staking and slashing incentives.

Keepers are responsible for:

• monitoring orders
• uploading index prices
• triggering trades
• recording execution.

That makes keeper uptime directly relevant to stop reliability.

Dual Oracle Protection

MYX also uses a dual-check framework involving:

• Pyth
• keeper-submitted index prices

The contract verifies that the two price sources remain within an acceptable range.

If they do not:

orders do not execute.

This is valuable manipulation protection.

But during unusual oracle divergence it can also deliberately prevent execution.

That is a trade-off DN should measure.

Network Congestion

MYX itself explicitly acknowledges:

• two-stage order processing
• block-confirmation delay
• network congestion
• price movement between submission and execution

as possible sources of execution-price differences.

MYX also lists inactive/malicious keepers and network instability as explicit protocol risks.

Public Documentation Gap

The reviewed MYX documentation clearly exposes:

• SL order types
• keeper execution
• Pyth pricing
• dual-oracle checks

but is less explicit than GMX, Lighter or Paradex about the precise comparison rule used to determine every stop trigger.

That should be reflected in DN’s:

Execution Transparency

notes.

DN Verdict on MYX

Technically interesting keeper/oracle architecture with excellent research potential.

The benchmark should focus on:

• keeper response
• dual-oracle disagreement
• chain congestion
• liquidation races

9. EVEDEX: Hybrid Trigger and Market Execution

EVEDEX remains operational and its 2026 documentation lists a growing perpetual market catalogue with leverage up to 100x on selected instruments.

EVEDEX TP/SL

EVEDEX describes TP/SL execution as:

off-chain triggers monitoring market prices

followed by:

automatic market-order submission

when the configured stop is reached.

That is an important architectural distinction.

The trigger itself occurs off-chain.

Settlement still has to execute against the trading infrastructure.

EVEDEX Explicitly Acknowledges Missed Fills

Its documentation warns that sudden price spikes can cause:

• partial fills
• missed fills.

The wider help center also identifies:

• network congestion
• low liquidity
• platform issues

as potential causes of failed trades.

Stop Limit

EVEDEX additionally supports stop-limit orders.

After the trigger:

a limit order becomes active.

That provides execution-price control but reduces fill certainty.

Liquidity

EVEDEX itself notes that large orders in less liquid markets may partially fill and experience greater slippage.

DN Verdict on EVEDEX

An important hybrid architecture to test because the platform itself acknowledges partial and missed stop outcomes during volatile conditions.

That makes the empirical benchmark especially valuable.

10. Vest Markets: A Documentation-Transparency Test

Trade on Vest Markets

Vest Markets is currently operational with a production API and active perpetual markets. Its current API exposes:

STOP_LOSS

as a native order type and also supports TP/SL values attached to parent orders.

Vest Pricing Architecture

Vest uses a risk-based mark price.

Its model incorporates:

• index price
• system exposure
• volatility
• position imbalance
• solvency premia

rather than simply using a raw external price.

Its index price uses a depth-weighted median derived from major venues.

Stop-Loss Documentation Gap

The current public trading documentation confirms:

Stop Loss

as an available order option.

But the public API documentation itself currently states that detailed:

Order Lifecycle

and:

Order Type

documentation is still forthcoming.

That means DN should not infer:

• exact trigger source
• exact stop-market transformation
• partial-fill behavior
• exact liquidation priority

without testing or additional platform confirmation.

This is precisely why documentation transparency should be part of professional exchange research.

Vest Liquidation

Vest uses partial liquidation designed to close only enough exposure to restore account health.

That creates another useful research variable:

Does partial liquidation interact with a pending stop differently from full liquidation systems?

DN Verdict on Vest

Live and eligible, but currently one of the most important platforms for DN to test empirically because the public stop-order lifecycle is less fully documented than several competitors.

That is not evidence of weak execution.

It is evidence of:

insufficient public evidence.

Those are not the same thing.

Architecture Comparison

Stop Market vs Stop Limit: Which Is Safer?

There is no universal answer.

Stop Market

Optimizes for:

getting out.

Risk:

slippage.

Stop Limit

Optimizes for:

execution price.

Risk:

remaining in the position.

For a highly leveraged position near liquidation, the second risk can be more dangerous.

A stop-limit that protects the price but never fills provides:

zero liquidation protection.

The Liquidation Buffer

DN should introduce another metric:

Stop-to-Liquidation Buffer

Formula:

Distance Between Stop Trigger and Liquidation Price ÷ Stop Trigger

Example:

Stop:

$75,000

Liquidation:

$74,250

Buffer:

1%.

A larger buffer gives:

• oracle updates
• keepers
• validators
• matching engines

more opportunity to complete the protective exit.

There Is No Universal Safe Buffer

A:

0.5%

buffer might be comfortable in one market.

During a violent BTC move it may disappear in seconds.

For a thin altcoin:

2%

might disappear in one trade.

DN should therefore never publish:

Always keep stops X% away from liquidation.

Instead measure:

failure probability by buffer size.

DN Buffer Survival Curve

Eventually DN should publish:

Repeated across each DEX.

This could become one of the most useful proprietary risk datasets in the perp market.

Oracle Delay Test

During a sharp movement:

External Reference Price

Record from a high-quality composite.

Venue Index

Timestamp the update.

Venue Mark

Timestamp the update.

Stop Trigger

Timestamp.

Order Fill

Timestamp.

Now DN can calculate:

External Move → Mark

Mark → Trigger

Trigger → Fill

Those three intervals reveal where the latency occurs.

Chain Congestion Test

Keeper and on-chain execution venues deserve separate stress tests.

Compare normal conditions against:

• elevated gas
• sequencer congestion
• volatile oracle updates

Metrics:

• trigger latency
• revert rate
• fill rate
• slippage
• stop/liquidation ordering

Order-Book Depth Test

For:

• Lighter
• Hyperliquid
• Paradex
• dYdX
• Aster

test several position notionals:

$1,000

$10,000

$100,000

and eventually:

$1 million.

A stop market is essentially an urgent liquidity-taking order.

Its reliability is therefore partly:

order-book depth reliability.

Keeper Reliability Test

For:

• GMX
• MYX
• other keeper-triggered systems

record:

Eligible trigger time

versus:

Keeper execution transaction

Then calculate:

Keeper Reaction Time.

Repeated observations can produce:

• median
• P95
• worst observed
• failure rate

P95 Matters More Than Average

Suppose:

Platform A

Median:

0.4 seconds

P95:

8 seconds

Platform B

Median:

0.8 seconds

P95:

1.6 seconds

Which is more reliable?

For protective execution:

probably Platform B.

Tail latency matters more than headline average latency.

DN Should Publish P50, P95 and Worst Case

For each platform:

• P50 trigger latency
• P95 trigger latency
• worst trigger latency
• median slippage
• P95 slippage
• full-fill rate
• liquidation-first rate

This produces a far more sophisticated benchmark than a 1-to-10 subjective score.

Proposed Live Results Table

Until DN runs the tests, the correct result is:

TEST PENDING.

That is more credible than inventing numbers.

What Would Make a Platform Score 95+?

A genuinely elite stop architecture would need to show:

• near-perfect trigger detection
• near-100% full-position exit rate
• low P95 latency
• controlled slippage
• resilient oracle performance
• very low failure rate
• stop execution consistently beating liquidation where an appropriate buffer exists

That is a very high standard.

It should be.

A stop loss is one of the trader’s final defenses.

Stop Losses Are Not a Substitute for Position Sizing

Even the best stop architecture cannot remove:

• market gaps
• smart-contract risk
• oracle risk
• liquidity risk
• network outages
• extreme volatility

Risk begins with:

• position size
• leverage
• collateral
• liquidation distance

A stop is an additional protection layer.

It is not a guarantee that losses cannot exceed expectations.

Frequently Asked Questions

Which perpetual DEX has the most reliable stop loss in 2027?

There is not yet enough standardized independent execution data to declare a universal winner.

gTrade has one of the strongest documented stop-price claims for qualifying BTC and ETH trades, while GMX provides exceptional transparency around oracle triggering. Lighter, Hyperliquid and Paradex have strong mark-triggered order-book systems.

The DN live benchmark is designed to determine the actual winner.

Which perp DEX guarantees stop-loss execution price?

gTrade currently documents guaranteed stop-loss pricing for BTC and ETH under its qualifying crypto stop framework.

This should still be independently stress-tested.

Does GMX use mark price for stop losses?

No.

GMX displays mark price but uses the relevant Chainlink Data Stream min/max price for stop triggering and base execution.

Does Hyperliquid use mark price for stops?

Yes.

Hyperliquid TP/SL orders are triggered using mark price.

Can a Hyperliquid stop loss slip?

Yes.

Stop-market TP/SL orders can experience substantial slippage during volatility or in thin markets.

Does Lighter use mark price?

Yes.

Lighter stop-loss trigger conditions reference mark price.

Does Paradex use mark price?

Yes.

Both stop-market and stop-limit triggers use Paradex’s mark price.

Does Aster use mark or last price?

Aster allows users to choose between mark price and last price for TP/SL triggers.

Does dYdX use oracle price for stop orders?

Yes.

Oracle pricing is used for conditional triggers, with additional protections around last-trade prices in applicable order logic.

Does MYX support stop losses?

Yes.

MYX supports TP/SL and advanced partial exit configurations using its keeper and oracle infrastructure.

Does EVEDEX support stop losses?

Yes.

EVEDEX uses off-chain price monitoring to trigger automated market execution and explicitly notes that volatile conditions can cause partial or missed fills.

Does Vest Markets support stop losses?

Yes.

Its current production API includes STOP_LOSS as an order type.

However, public documentation currently provides less detail about the complete stop-order lifecycle than several competing platforms.

Can a stop loss execute after liquidation?

It can effectively become irrelevant if liquidation closes or alters the position first.

The precise interaction differs by venue.

How far should my stop be from liquidation?

There is no universal safe percentage.

It depends on:

• leverage
• asset volatility
• liquidity
• stop architecture
• oracle timing
• market conditions

Is a stop market safer than a stop limit?

For exit certainty, usually.

A stop-limit provides price protection but can remain unfilled.

A stop-market prioritizes execution but can suffer slippage.

Can network congestion make a stop fail?

Yes.

Keeper-based and blockchain-dependent execution can be delayed by network conditions.

Even centralized matching layers can face other latency and liquidity constraints.

Final Verdict

A stop-loss button is not evidence of reliable risk management.

The relevant sequence is:

Price Moves

↓

Reference Price Updates

↓

Trigger Detected

↓

Order Released

↓

Liquidity Found

↓

Position Closed

↓

Settlement Confirmed

And throughout that process:

liquidation is still approaching.

Different perpetual DEXs solve this problem in fundamentally different ways.

gTrade makes perhaps the strongest documented stop-price claim for qualifying BTC and ETH positions.

GMX offers unusually transparent oracle and keeper mechanics.

Lighter combines robust fair-price marking with order-book execution.

Hyperliquid gives traders considerable flexibility between stop-market and stop-limit behavior.

Paradex combines mark-price triggering with a sophisticated order-book architecture.

dYdX places oracle pricing at the centre of both conditional orders and risk management.

Aster allows users to choose between mark and last-price triggers.

MYX combines Pyth pricing, dual-oracle protection and a keeper network.

EVEDEX uses hybrid off-chain triggering and explicitly acknowledges missed or partial fills under difficult conditions.

Vest Markets supports native stop-loss orders but provides a particularly valuable opportunity for independent DN testing because several execution details remain less explicit in public documentation.

But the final ranking should not come from documentation.

It should come from:

real triggers

real fills

real latency

real slippage

and:

real liquidation races.

That is what the:

DN Stop-Loss Reliability Score

is designed to measure.

If DN builds this dataset continuously, it can answer a question that most perpetual DEX ranking pages currently cannot:

When the market moves violently against you, which platform actually gets you out?

Affiliate Disclosure

Some links in this article are affiliate or referral links, including selected links to MYX and Vest Markets. Decentralised News may receive compensation when eligible users access partner platforms through these links.

Affiliate relationships do not influence:

• Operational Status Gate decisions
• Stop-Loss Reliability Scores
• execution testing
• platform inclusion
• risk analysis
• editorial conclusions

Only platforms verified as LIVE are eligible for current recommendations.

Disclaimer

This article is for educational and informational purposes only and is intended for readers aged 18 and over. Leveraged perpetual futures are extremely high-risk products. Stop-loss orders are not guaranteed to prevent liquidation or limit losses to a specific amount unless a platform explicitly provides such protection under applicable conditions. Slippage, price gaps, oracle movement, network congestion, liquidity shortages and smart-contract failures can cause losses materially greater than expected. Verify current platform mechanics and product availability before trading.