Deep Research Report on Major DEX Design

Differences and Their Implications for Holding and Trading Cryptoassets

Executive summary

The most important divide among decentralized exchanges is not “DEX versus CEX,” but which market structure the DEX uses.

Broadly, the major designs in scope break into four groups:

➢ fully onchain central limit order books on appchains or custom L1s such as Hyperliquid;

➢ appchain/orderbook derivatives venues with mixed in-memory and onchain persistence such as dYdX Chain;

➢ contract-based AMMs such as Uniswap v3, SushiSwap, Curve, PancakeSwap, and Raydium;

➢ and aggregators / intent systems such as 0x/Matcha that route to other venues rather than owning the underlying liquidity. 

GMX is best treated as a separate derivatives design again: it is not a classical AMM or a classical orderbook, but an oracle-priced pooled-liquidity system with offchain keepers and onchain settlement.

Those choices determine who bears slippage, how assets are custodied, what can be recovered if a front end disappears, and where regulation or admin power can bite. 

---

For long-term holders, the highest-level question is whether using a venue requires you to bridge or pre-fund assets into a separate environment.

Uniswap, Curve, PancakeSwap, SushiSwap, Raydium, and Matcha mostly let you keep assets in your wallet until the moment you sign a transaction; by contrast, Hyperliquid and dYdX require assets to be moved into their trading environments, which adds bridge, chain-liveness, and operational risk even if the system remains non-custodial in the broader DeFi sense. GMX also requires capital to sit inside protocol contracts or market tokens. That matters because “holding on a DEX” can mean anything from “just keeping assets in my wallet and occasionally swapping” to “parking collateral inside an appchain or protocol pool.” 

For active traders, the decisive distinctions are execution quality, predictable price formation, and MEV/path dependence. Orderbook venues such as Hyperliquid and dYdX can feel more familiar to CEX traders because they support maker–taker pricing and price-time priority, while concentrated-liquidity AMMs can be extremely efficient for some pairs but expose traders to pool-depth cliffs and sandwich risk on public-orderflow chains. Aggregators such as Matcha reduce route-finding burden and can source both AMM and RFQ liquidity, which often improves execution for spot traders, while GMX suppresses classical AMM slippage by using oracle-based execution but replaces it with price-impact, funding, borrow-fee, and pool-solvency considerations. 

For liquidity providers, the biggest divide is whether LP returns come from swap fees on deterministic curves, maker rebates / orderbook quoting, or warehouse-style inventory risk against leveraged traders. In Uniswap v3, PancakeSwap v3, Sushi v3, and Raydium CLMM, LPs gain capital efficiency by narrowing price ranges, but inactive ranges stop earning fees. In Curve, LPs usually take less directional risk on correlated assets but become highly sensitive to peg breaks and parameter choices. In GMX, LPs are not classical curve LPs at all; they are effectively underwriting trader PnL and earning a share of trading, borrowing, swap, and liquidation fees. Hyperliquid’s HLP/vault model also differs sharply from standard AMMs because fee flows and inventory risks are tied to the protocol’s orderbook/perps ecosystem rather than to a simple pool invariant. 

Two bottom-line conclusions follow.

First, the safest venue for a passive holder is usually not the same venue that maximizes execution quality for a derivatives trader.

Second, “non-custodial” is not enough of a risk label: you also need to ask where settlement happens, who can upgrade contracts or market parameters, how listings occur, whether official interfaces geoblock your jurisdiction, and whether you can still recover or route assets if a front end, relayer, or bridge fails. Those differences are material, not cosmetic. 

Scope, assumptions, and platform selection

This report focuses on the user-specified protocols — Hyperliquid, dYdX, Uniswap v3, SushiSwap, Curve, PancakeSwap, and 0x/Matcha — and adds GMX and Raydium as representative top-usage venues covering additional major design patterns: oracle-priced pooled perps and Solana-native AMM/CLMM routing. That selection overlaps materially with CoinGecko’s DEX market-share research and its live DEX rankings, which place venues such as Uniswap, PancakeSwap, Hyperliquid, Raydium, and Curve among major decentralized trading venues, while GMX remains a major reference design for onchain perpetuals even when spot-volume rankings are measured separately. Because market-share tables change rapidly, all ranking claims here should be read as representative as of 2026, not permanent. 

Unspecified assumptions remain unspecified. In particular, the user’s jurisdiction, tax posture, legal entity status, custody preferences, and risk tolerance were not provided. That matters because derivatives interfaces in particular may geo-restrict users or impose local-law eligibility representations, while pure smart-contract access may remain technically possible outside an official front end. It also matters because a conservative treasury holder, a discretionary retail trader, and a market maker will rationally prefer different venues even if they trade the same token. 

Methodologically, I prioritized official documentation, whitepapers, security and audit pages, official support/legal pages, and official developer docs, then used CoinGecko, CoinMarketCap, Dune, The Graph, and DefiLlama only to anchor scope or current ecosystem context. Where official documentation did not clearly specify an item — especially upgradeability or exact fee distribution for some multi-product protocols — I mark it as not clearly specified in the reviewed official materials, rather than inferring from tradition or community lore. 

How DEX design choices change user risk

The architecture choice changes the entire risk stack. An onchain orderbook tries to reproduce exchange-style price formation by matching discrete bids and asks; it tends to produce lower visible slippage for liquid pairs and supports maker–taker economics, but it also depends on specialized sequencing, market-data infrastructure, and often a custom chain or exchange-specific execution design. Hyperliquid explicitly describes a fully onchain order book on its own L1 with price-time priority, while dYdX Chain uses an orderbook where short-term orders live in validator memory and stateful orders are written onchain; that improves throughput, but it means not all order states are equally persistent. 

An AMM removes the need for matching counterparties and instead lets price emerge from pool math and liquidity distribution. That simplicity is why AMMs dominate permissionless spot trading, but the experience for users depends heavily on which AMM variant they are using. Uniswap v3, PancakeSwap v3, Sushi v3, and Raydium CLMM use concentrated liquidity, which can be very capital efficient but causes LP ranges to go inactive outside chosen bands. Curve uses StableSwap and CryptoSwap-family invariants optimized for pegged or correlated assets and therefore usually offers different slippage behavior from a generic x·y=k venue. These are not cosmetic implementation details; they directly determine who absorbs price movement and how deep the market feels at different trade sizes. 

An aggregator such as 0x/Matcha does not usually own the ultimate liquidity source. Instead, it discovers and packages liquidity across many venues, sometimes including private RFQ market makers, then returns executable calldata or a gasless order flow. This can lower user slippage because the aggregator can split orders and compare venues, but it also introduces dependency on quote infrastructure, API availability, and any compliance filters applied by the routing layer or interface. Put differently: the trader may keep self-custody, but execution quality now depends on the aggregator’s offchain intelligence as well as the onchain venues it targets. 

A fourth family, represented here by GMX, uses oracle-priced pooled liquidity. This suppresses the classic “I moved the curve against myself” AMM problem, because execution is driven by oracle pricing and pool-balance logic rather than a visible x·y=k path; but it replaces that with a different risk model involving open-interest imbalances, adaptive funding, borrow fees, reserve factors, PnL caps, and auto-deleveraging. That can be very attractive to active perpetual traders who hate sandwiching and curve slippage, but it means LPs are underwriting trader outcomes much more directly than on a vanilla AMM. 

The MEV and frontrunning surface also follows architecture and chain design. Ethereum-style public-mempool AMMs are the clearest sandwich target, which is why Uniswap docs spend so much time explaining price impact and slippage, and why UniswapX and Matcha’s RFQ/gasless paths exist. Solana changes the mechanics — Raydium’s docs are explicit that Solana MEV is leader-ordering and bundle-centric rather than Ethereum-mempool-centric — but it does not eliminate MEV. Orderbook venues reduce classical AMM sandwiching, yet they still create latency, sequencing, mark-price, and liquidation races. GMX tries to mitigate classic frontrunning with two-phase keeper execution and oracle pricing, but that is a different mitigation model, not the absence of execution risk. 

Comparative platform matrix

Architecture, custody, settlement, routing, and trading behavior

Platform	Core architecture	Custody model	Settlement layer	Cross-chain / bridge posture	Liquidity provision & incentives	Fee / slippage / MEV profile
Hyperliquid	Fully onchain CLOB on its own L1; HyperCore + HyperEVM share HyperBFT security.	User-signed, non-custodial in protocol terms, but trading capital is deposited into HyperCore accounts; API wallets and native multisig exist.	Custom L1 for exchange logic; bridge to/from Arbitrum for USDC and native interactions between HyperCore and HyperEVM.	Spot deployment is permissionless via HIP-1 and spot-pair deploy auctions; HIP-3 enables permissionless builder-deployed perps; bridging and asset-linking introduce extra operational complexity.	Native orderbook liquidity plus protocol/vault structures; spot and HIP-3 perp deployers may keep up to 50% of fees on their assets.	Good for tight execution when books are deep; fees are volume-tiered and community-directed; classic AMM slippage is absent, but users inherit orderbook depth, oracle, and chain-liveness risk.
dYdX Chain	Appchain CLOB; short-term orders live in validator memory, long-term/conditional orders are stateful onchain.	Non-custodial chain accounts derived from user signatures, but collateral must be bridged in and placed into dYdX chain accounts/subaccounts.	Cosmos appchain; matching/order state mediated by validators, with chain settlement for stateful orders and balances.	Deposits and withdrawals route through Noble/IBC and Skip Go; direct IBC supported from Cosmos chains.	No classic AMM LP role on v4; fee schedule is maker/taker and governance-configurable; maker rebates exist, and trading rewards parameters are governance-controlled.	Execution resembles a derivatives exchange; lower visible slippage than AMMs in liquid books, but persistence differs for short-term versus stateful orders and traders inherit bridge/appchain risk.
Uniswap v3	Concentrated-liquidity AMM with multiple fee tiers per pair; non-upgradeable core contracts.	Wallet-first self-custody until swap or LP deposit; LP positions are NFTs.	Deployed across multiple EVM networks; direct onchain settlement in pool contracts.	The interface supports bridging across supported networks; protocol deployments exist on multiple chains.	LPs choose ranges and fee tiers; fees accrue outside the position and must be collected.	Typical common tier is 0.30%, with 0.01%, 0.05%, 0.30%, and 1% available; price impact depends on pool depth and public-orderflow swaps can be sandwiched unless routed through UniswapX/private fillers.
SushiSwap	Multi-product AMM: legacy V2-style cpAMM plus V3 concentrated liquidity; also has an offchain route optimizer with onchain RouteProcessor execution.	Wallet self-custody until smart-contract use.	Onchain settlement on supported EVM chains via AMM and router contracts.	Sushi has supported cross-chain experiences via Squid/Axelar integrations, but those add separate bridge/router trust and execution assumptions.	V2 uses pool fees; V3 adds range LPing and custom fee tiers; aggregator pathfinding is offchain, execution onchain.	Legacy docs describe 0.30% trading fees for swappers; V3 supports 0.01%, 0.05%, 0.30%, and 1.00% tiers. Slippage follows AMM depth, though routing can improve execution.
Curve	Specialized AMMs: StableSwap for pegged assets and CryptoSwap/TriCrypto for volatile mixes; permissionless pool factories.	Wallet self-custody until pool deposit or swap.	Onchain contracts on Ethereum and supported sidechains/L2s.	Factories exist across mainnet and sidechains/L2s; some chain-specific bridging and fee-forwarding infrastructure exists, but user risk still depends on the chain used.	LPs earn swap fees; DAO/admin fees are collected and distributed to veCRV holders through the fee system. Dynamic fees apply in some NG pools.	Usually best execution for stable/correlated assets; lower slippage than generic AMMs in the right pairs, but higher peg-break and parameter risk if assets de-correlate.
PancakeSwap	AMM suite with V2-style pools and V3 concentrated liquidity; multichain product stack.	Wallet self-custody until pool or swap interaction.	Onchain settlement on BNB Chain and other supported networks.	Multichain products and cross-chain farming exist, but chain/bridge risk depends on the specific product path.	V3 positions are NFTs; CAKE tokenomics route portions of ecosystem fees into buyback-and-burn.	V3 pool fees range from 0.01% to 1%, with 0.25% the common mid-tier; slippage depends on pool depth and chain congestion like other AMMs.
0x / Matcha	Aggregator + RFQ / smart-order routing rather than native liquidity ownership; onchain settlement from calldata or gasless order flow.	User remains self-custodial; approves/permits spender contracts or signs gasless orders.	Onchain settlement across many chains; quote discovery and routing are offchain/API-driven.	Matcha supports cross-chain swaps and 16 chains in current materials; 0x Cross-Chain API spans many bridges/providers.	No LP role at the Matcha layer; it routes into AMMs and RFQ market makers.	Matcha Standard and Auto commonly charge 0.25% on non-stable pairs, with lower stablecoin fees and higher cross-chain fees; routing and RFQ/private market makers can reduce slippage and MEV compared with direct public-AMM swaps.
GMX	Oracle-priced pooled-liquidity perpetuals and swaps; not a classical AMM or orderbook.	Self-custodial onchain, but collateral and LP capital sit inside protocol contracts / GM or GLV market tokens.	Onchain on Arbitrum, Avalanche, Botanix, and MegaETH per current docs.	Docs describe multichain account/deposit flows and direct operation on deployed chains; bridge and routing risk depends on how capital is moved in.	LPs hold GM/GLV market tokens and earn directly through pool appreciation as fees flow into pools; LPs also underwrite trader PnL.	Classic AMM slippage is reduced because execution is oracle-based; but users face price-impact, borrow-fee, funding, reserve-factor, and ADL mechanics. Two-phase keeper execution is intended to reduce frontrunning and sandwich attacks.
Raydium	Solana-native CPMM, CLMM, legacy AMM v4, and routing programs.	Wallet self-custody until smart-contract use; pool state and LP claims are onchain accounts.	Onchain on Solana; multi-hop swaps can be executed atomically through routing programs.	Solana-native rather than multichain-first; routing is within Solana liquidity topology rather than bridge-heavy cross-chain design.	CLMM and CPMM pools split trading fees between LPs, RAY buybacks, and treasury; common fee tiers center on 0.25% but also include 0.01%, 0.05%, and 1%.	Slippage can be improved by split routing; MEV exists via leader ordering and Jito bundles, though CLMM structure can reduce sandwichability for some shallow moves.

Governance, listings, upgradeability, security, transparency, UX, and compliance

Platform	Listing / delisting governance	Upgradeability / admin keys	Security history & audits	Onchain transparency & recoverability	UX / wallet / KYC / compliance posture
Hyperliquid	HIP-1 spot deployments are permissionless; HIP-3 moves perp listings toward permissionless builder deployment, with deployers controlling oracle definitions, leverage limits, and market operation.	Official docs reviewed do not present a traditional EVM-style contract immutability story for the exchange itself; users should treat the L1, bridge, and market-deployer powers as real governance/admin surfaces.	Official audit page prominently discloses Zellic audits for the bridge contracts; docs also run a native bug bounty and explicitly enumerate smart-contract, oracle, liquidity, and L1 risks. In the reviewed docs, public audit disclosure is much clearer for the bridge than for the entire exchange stack.	Exchange APIs expose exchange and user state; spot/perps are native to the chain, but recoverability depends on chain and bridge liveness.	Wallet-based access; official interface terms exclude “Restricted Persons,” including U.S. persons, and contract specs say there are few contract-specific restrictions at market level. No KYC is described for trading itself in reviewed docs.
dYdX Chain	Governance can change fee tiers, stats parameters, and insurance-fund actions; market and protocol functionality are governance-exposed through Cosmos-style modules.	Chain behavior changes through protocol/governance upgrades rather than fixed immutable core contracts; governance periods and deposits are documented.	Official docs cite Informal Systems audits for the protocol and note additional audits are planned; release resources also show multiple security advisories patched in 2025–2026.	Orderbook and account data can be queried through Node/Indexer/OEGS infrastructure; however, short-term orders are not durable through validator restarts, unlike stateful orders.	Wallet-based onboarding derives chain keys from a signed message; no KYC is described for protocol trading, but official software terms restrict U.S., Canada, and other Restricted Persons from using dYdX software.
Uniswap v3	Pool creation is permissionless; interface-level token warnings and unsupported-token policies are separate from protocol deployment.	v3 core is non-upgradeable by design; governance controls some parameters, such as additional fee tiers and protocol-fee settings.	Launch materials describe major bugs found and fixed pre-launch, plus a public bug bounty; v2/v3 materials reference audits and formal verification.	Very high transparency: pools, fees, and positions are onchain and queryable through subgraphs; if the interface goes down, contracts remain usable directly.	Standard swapping is wallet-based and generally no-KYC, but fiat on-ramp providers in Uniswap products may require KYC; Uniswap Labs screens sanctioned/illicit addresses on its interface and imposes terms-based eligibility rules.
SushiSwap	Pool creation and AMM usage are broadly permissionless in the standard DeFi sense; exact current listing gatekeeping was not clearly specified in the reviewed docs.	Current official security docs confirm audits and bug bounty coverage, but the reviewed docs did not clearly specify a single concise current admin/timelock overview comparable to Raydium’s.	Security page states Sushi regularly engages auditors and maintains an Immunefi bounty.	Onchain contracts settle trades; recoverability is strong at the contract layer, while aggregator/routing convenience depends on offchain tooling.	Wallet-based DeFi UX; no general protocol KYC requirement was identified in reviewed docs; interface-specific legal restrictions were not clearly specified in the reviewed official materials.
Curve	Permissionless pool factories mean listing is open, and Curve’s own risk disclosures emphasize that pools may contain unvetted tokens.	Factory/admin roles exist; some implementations allow admin-fee control and DAO-controlled admin assignment. Views contracts can be factory-admin-upgradeable.	Curve docs cite audits by Trail of Bits, MixBytes, QuantStamp, and ChainSecurity and maintain security disclosures/bug bounty processes.	High transparency: factories, pools, and fee-distribution machinery are documented onchain; recoverability is generally strong if users can interact directly with contracts.	Wallet-based DeFi UX; no protocol-wide KYC noted in docs reviewed. Curve’s own risk disclosures explicitly mention regulatory uncertainty and unvetted-token risk.
PancakeSwap	Broadly permissionless AMM usage; product-specific campaigns and perps surfaces can apply jurisdictional restrictions.	PancakeSwap states contracts are protected by multisig and timelocks; exact powers vary by product.	Extensive official audit list spanning core exchange, farms, pools, stable swap, cross-chain farming, and Aptos products.	Core contracts are open and publicly verifiable; strong recoverability at contract layer if the UI disappears.	Wallet-based AMM UX; no general KYC for swapping identified in reviewed materials, but the perpetuals interface/campaign materials exclude U.S., China, and other restricted jurisdictions.
0x / Matcha	0x supports all tokens by default except those blocked for compliance reasons; Matcha can also block tokens violating its terms.	Reviewed docs did not provide a simple “immutable vs proxy” summary across all current 0x v2 settlement surfaces; contract-level due diligence should be deployment-specific.	0x states that v2 contracts are fully audited by multiple firms and covered by an Immunefi bounty.	Good transparency for executed transactions, but route discovery depends heavily on offchain API infrastructure. If the API/front end fails, self-custody remains, but execution convenience falls sharply.	Matcha is available in most countries per its help docs; swaps are wallet-based, while the service still applies terms/compliance controls and collects ordinary web-service metadata.
GMX	Market parameters, referral rules, and broader protocol evolution are governance-driven; GMX also uses a DAO/governance forum and onchain delegation process.	The reviewed docs clearly describe active upgrade, audit, and bounty processes but did not surface one compact official “all admin keys” page in the material I reviewed.	GMX security docs list Guardian, ABDK, Certora, Dedaub, and Sherlock audit engagements plus Immunefi coverage.	Strong onchain transparency for positions, pools, and market tokens; however, recoverability of optimal UX depends on keepers, APIs, and front-end tooling as well as contracts.	Docs explicitly market GMX as non-custodial, permissionless, and no-KYC; trading still requires chain-native operational literacy and collateral management.
Raydium	Pool and fee-tier creation is partly permissioned at the AmmConfig/admin level, but trading and much pool usage are permissionless; LaunchLab and farms have creator-scoped powers.	Programs are upgradeable; a 3/4 Squads multisig holds upgrade authority with a 24-hour timelock, and a 3/5 treasury multisig controls limited admin functions. Raydium explicitly says no program has had upgrade authority nulled.	Official docs provide program-by-program audits, bug bounty, and historical incidents including a pool-authority exploit in December 2022 and OpenBook integration freeze in January 2023.	Very high transparency: authority addresses, treasuries, and fee destinations are published; users can verify onchain who controls upgrades or fee claims.	Wallet-based Solana UX with Solana-specific concerns such as priority fees, ATAs, and bundle routing; no KYC requirement was identified in the reviewed docs.

Indicative fee comparison

The chart below is intentionally simplified. It compares common user-facing base trading/swap fees for selected paths with clear official fee disclosures. It does not include gas, bridge fees, funding, borrow fees, dynamic fees, price impact, or maker rebates, and it excludes Hyperliquid because the exact fee schedule was not fully captured in the retrieved materials. In practice, execution quality matters more than sticker fees for large or thin markets. 

Indicative common base trading or swap fees

Practical implications by user profile

Platform	Long-term token holders	Active traders	Liquidity providers
Hyperliquid	Suitable only if you are comfortable moving assets into a custom exchange L1 and accepting bridge/L1/oracle risk in exchange for venue-native functionality.	Strong fit for traders who want CEX-like orderbook behavior, onchain transparency, and broad perp access; weaker fit if you dislike appchain/bridge dependence or jurisdictional restrictions on the official UI.	More relevant as a vault/HLP-style participant than a classic AMM LP; your risk is ecosystem inventory and exchange performance, not just passive curve rebalancing.
dYdX Chain	Better viewed as a trading venue than a passive holding venue because collateral must be bridged into the chain and kept in subaccounts.	Excellent for derivatives traders who want maker–taker pricing and exchange-style orders; less ideal if you need simple wallet-in-place spot execution or if you are in a restricted jurisdiction.	There is no standard AMM LP role comparable to Uniswap or Curve; the maker side behaves more like professional quoting than passive LPing.
Uniswap v3	Strong for holders who want wallet-first self-custody and occasional swaps on supported chains, but less ideal if they want to avoid price-impact/MEV complexity on public orderflow.	Good for spot traders in deep pairs, especially with routing help, but trade quality can deteriorate quickly in thin pools or volatile tokens.	Attractive for sophisticated LPs who actively manage ranges; dangerous for passive LPs because inactive ranges stop earning and inventory can become one-sided.
SushiSwap	Reasonable as a wallet-based swap venue, though its product mix and official docs are less crisp than Uniswap’s for risk introspection.	Useful when route optimization beats a single-venue AMM quote, but trading behavior still ultimately inherits the liquidity of routed pools.	LP opportunities exist, especially on V3, but passive LPs still face the same concentrated-liquidity management burden seen on other CLAMMs.
Curve	Often one of the safer places for stablecoin or correlated-asset swaps, but only if the assets really remain correlated; permissionless listing means token-quality due diligence matters.	Best for traders moving stablecoins or correlated assets in size; less compelling for generic volatile-token speculation versus deeper generalized venues.	Attractive for LPs seeking lower directional risk than generic AMMs, but peg breaks, admin-fee parameters, and unvetted tokens can still create sharp losses.
PancakeSwap	Convenient for holders already operating on BNB Chain or its adjacent ecosystem, especially for broad retail token access.	Strong retail spot venue with many pairs and chains, though slippage/MEV behavior still looks like a normal AMM rather than an orderbook.	LPs benefit from familiar AMM and V3 range structures, but they still need to manage inactive-range and volatile-tail-token risk. CAKE tokenomics can matter more to ecosystem participants than to purely passive LPs.
0x / Matcha	Strong fit for holders who want to remain in their own wallet while minimizing manual venue selection; weaker fit if they want to avoid dependence on a routing service.	Often one of the best spot-trading UX layers because routing, RFQ, and gasless/MEV-protected modes can materially improve fills over direct pool interaction.	There is no LP role at the Matcha layer; LP economics belong to the underlying venues that Matcha routes into.
GMX	Poor fit for passive spot holding if your goal is simple wallet-first ownership; much better viewed as a trading or yield-underwriting venue.	Very strong for perpetual traders who prioritize predictable oracle-based execution and anti-sandwich design over traditional orderbook feel.	LPs can earn meaningfully, but they are underwriting trader PnL and market-imbalance mechanics, so the risk is closer to being an options desk or market warehouse than a passive AMM depositor.
Raydium	Attractive for Solana-native holders who want wallet self-custody and low-fee onchain execution, provided they are comfortable with Solana-specific tooling and priority-fee dynamics.	Very competitive for active Solana spot trading, especially when combined with route splitting and CLMM depth. MEV is lower-friction than Ethereum in some ways but still real.	LPs can choose between CPMM and CLMM styles; fee economics are explicit and admin powers are unusually well documented, which is a plus for due diligence.

Conclusions

If the use case is “I mostly hold assets and occasionally rebalance”, the cleanest designs are usually the wallet-first AMM or aggregator venues: Uniswap v3, Curve, PancakeSwap, SushiSwap, Raydium, and Matcha. They let users avoid pre-funding a separate exchange environment and usually provide the best recoverability if a front end fails, because the core state sits plainly in smart contracts. Among them, Curve is strongest for correlated assets, Uniswap v3 / Raydium CLMM for concentrated-liquidity depth in major pairs, and Matcha for minimizing the need to manually choose pools and routes. 

If the use case is “I trade perps actively and care about market structure”, the best fit depends on what kind of execution you want. Hyperliquid and dYdX Chain are better if you want an orderbook-native experience, maker–taker economics, and exchange-style order management. GMX is better if you want low classical slippage, self-custody, and strong anti-sandwich design, while accepting oracle, borrow, and pooled-inventory mechanics. Those are not interchangeable products; they represent three different philosophies of onchain derivatives. 

If the use case is “I want to earn yield by supplying liquidity”, the highest-confidence distinction is between range-managed LPing and inventory-underwriting LPing. Uniswap v3, PancakeSwap v3, Sushi v3, and Raydium CLMM reward active range management. Curve rewards correct asset selection and parameter awareness more than constant repositioning. GMX and Hyperliquid vault-style participation behave more like underwriting the exchange than passively providing curve liquidity. Stated plainly: if you do not want to actively manage a position, concentrated-liquidity venues can look deceptively simple and be economically unforgiving. 

The final practical takeaway is that the phrase “non-custodial DEX” is too coarse to be decision-useful. A robust platform comparison has to ask at least six follow-on questions: Where do assets live before and after the trade? Who can list or change markets? Who can upgrade contracts or chain behavior? How does the venue source and route liquidity? How exposed is the user to MEV or oracle/bridge failure? What restrictions exist at the official interface level? On those questions, the venues in scope differ substantially, and those differences are exactly what determine whether a DEX is suitable for holding, trading, or liquidity provision in a given strategy. 

Prioritized sources and limitations

Prioritized primary sources

The highest-priority sources used in this report were official docs, official whitepapers, official legal/support pages, and official security pages for: Hyperliquid, dYdX, Uniswap, Sushi, Curve, PancakeSwap, 0x/Matcha, GMX, and Raydium. Those sources established the architecture, custody model, supported trading primitives, upgrade/admin controls, and official compliance posture cited throughout. 

Secondary context came from CoinGecko current DEX rankings and research, DefiLlama for current protocol usage context, Dune as an onchain analytics reference, and The Graph / Uniswap subgraph docs for onchain transparency and indexability. Those were used for ecosystem framing rather than to override official protocol design disclosures. 

Open questions and limitations

Several items were not clearly specified in the reviewed official material, and I have intentionally left them marked as such instead of overstating certainty. The main gaps were:

• a single concise official admin-key / upgradeability summary for 0x/Matcha, SushiSwap, and GMX comparable to Raydium’s documentation; 
• a complete official audit disclosure for the full Hyperliquid exchange/L1 stack beyond the prominently published bridge audits; 
• a single precise, source-captured base fee schedule for Hyperliquid suitable for the fee chart, which is why it was excluded from the bar chart despite extensive discussion elsewhere; 
• full current interface/legal restrictions for some wallet-based spot venues beyond the pages explicitly retrieved. 

Those omissions do not undermine the core conclusions of the report, but they do mean that any institution deploying large capital should still perform venue-specific contract and front-end legal diligence before execution.