Choosing a decentralised exchange is a risk assessment, not a feature comparison. The interface tells you almost nothing about whether your trade will execute at the price shown or whether your funds sit behind a key someone else controls.
These eight checks take about twenty minutes and are worth running before the first meaningful trade on any venue you have not used.
1. Quote a real trade size, not the minimum
Enter the amount you actually intend to trade and read the price impact. Every exchange looks good on a token-sized swap. The difference between venues appears at the size you care about, and it appears immediately.
Do this on the specific pair you need. Depth is per pool, not per exchange, and a venue with excellent majors can be unusable on the asset you came for.
2. Check whether the route passes through a bridge
Cross-chain interfaces often present a bridged swap as a single transaction. It is not. Each bridge in the route is a separate contract with its own failure modes, and the aggregate risk is the sum of them.
Expand the route before confirming. A quote that looks better than everyone else’s usually looks that way because it routes through something the others avoid.
3. Find out who can change the contracts
Look for admin keys, upgrade proxies and pause functions on the router and factory. Their existence is not automatically bad, since many venues keep an emergency pause deliberately, but who holds them and under what process is the actual risk profile.
A single externally owned account with upgrade rights over the router means one key can redirect every trade on the exchange. A timelocked multisig means a change is visible before it takes effect. These are different products.
4. Read what the audit actually covered
An audit badge means a firm reviewed specified contracts at a specified commit. It does not mean the deployed code matches, that peripheral contracts were included, or that findings were fixed.
Open the report and check three things: the date, the contracts in scope, and whether the high-severity findings were resolved or acknowledged. Acknowledged means still present. This takes two minutes and separates real diligence from decoration.
5. Look at volume over time, not the headline number
A single day’s volume figure is the easiest number on a decentralised exchange to manufacture. What is harder to fake is a consistent chart across weeks with the shape you would expect: weekday peaks, weekend troughs, spikes that line up with events in the market.
Flat volume at a suspiciously round level, or volume concentrated in a handful of pairs nobody trades elsewhere, is wash activity. It tells you the depth you see may not be depth that serves you.
6. Understand the fee structure before you need to
Swap fee, protocol cut, gas and any withdrawal or bridge fee are four separate numbers, and interfaces routinely show one of them. Compare the amount received, not the advertised rate.
On some venues the fee varies by pool tier, which means the same pair can cost several times more depending on which pool the router picks. If the interface does not disclose which tier it used, that is worth knowing before a large trade rather than after.
7. Check the front end is not the only way in
A decentralised exchange whose contracts can only be reached through one website is centralised in the way that matters. Domains get seized, hijacked and mistyped, and front-end compromises are one of the more common ways users lose funds on otherwise sound protocols.
Confirm the contracts are documented, that an aggregator or alternative interface can reach them, and that the project publishes the official domain somewhere a newcomer would find it.
8. Test the exit before the entry
Trade in, then trade straight back out with a small amount. The round trip reveals what the quote screen does not: whether the reverse pair has depth, whether the router finds a sane path back, and what the whole thing actually costs.
Venues where entry is smooth and exit is not are common, and it is always cheaper to discover that with a test amount. For a project deciding where to place its own liquidity, the same round trip is the fastest read on whether the venue can serve real traders, and our token listing sequence covers what to do once you have chosen.
Use a separate wallet for testing
Run the first trade on any new venue from a wallet that holds only what the test needs. An unknown router then has spending rights over a balance you can afford to lose, and the wallet where assets actually sit never touches an interface you have not used before. Move funds across once the round trip has completed cleanly and the costs on both legs look like what the quote screen promised.
A hardware device does not change this. It protects the key, not the approval you sign with it, so an allowance granted to a contract that turns out to be malicious drains the balance the same way whether you confirmed it on a small screen or in a browser extension. Separating balances is the control that holds here, not the storage medium.
Label the test address somewhere you will find it again. Anyone assessing several venues in the same week ends up with a row of addresses and no record of which one approved what, and untangling that months later costs more time than writing it down at the moment of the first trade.
Check the approval you are signing
Most decentralised exchanges need a token approval before the swap, and the amount in that approval is a separate decision from the amount in the trade. Interfaces default to an unlimited allowance because it saves a transaction on every later swap. It also leaves the router holding permanent spending rights over that token, long after you have stopped using the venue and forgotten it existed.
Approve the trade size where the interface allows it, and revoke allowances once the position is closed. The cost is one extra transaction per trade. The benefit shows up on the day a router you approved months ago turns out to sit behind the upgrade proxy you decided not to worry about, and someone with the key decides to use it.
Before confirming, check that the spender address matches the router the documentation names. A front end requesting approval for a contract the project does not publish anywhere is the clearest evidence available that something in the path has been replaced, and the wallet prompt shows it plainly to anyone who reads the prompt instead of clicking through it.
Read the transaction before confirming it
The wallet prompt shows the contract being called, the value being sent, the token being spent and the network the transaction belongs to. A few seconds spent on those four fields catches a native amount you did not intend to send, a call to a contract that is not the published router, a chain you did not think you were on, and a signature request that is not a transaction at all.
Signature requests deserve the most attention, because they cost no gas and leave no on-chain trace until somebody uses them. A permit signature can hand over approval rights without any visible approval transaction, which is why a site asking you to sign something described only as verification is worth closing rather than reading twice. Nothing on a working exchange requires a signature you cannot identify.
Set slippage deliberately rather than accepting whatever the interface offers by default. A wide tolerance on a thin pool is an invitation to be sandwiched, and the loss arrives as a worse fill rather than as an error message, so nothing tells you it happened unless you compare the quote you accepted with the amount that actually landed in the wallet.
How to choose a reliable DEX quickly
There is a short version for the trade that cannot wait. Quote the real size on the exact pair, expand the route to see whether it crosses a bridge, take the contract address from the project documentation rather than from a message, and send a small amount through and straight back out before the rest of the position follows it.
That compressed sequence is how to choose a reliable DEX under time pressure, and it catches the two failures that cost the most: a route that crosses a bridge without saying so, and an exit that has no depth behind it. Both are invisible on the quote screen and both are obvious within one small round trip.
What it does not catch is anything in the contract permissions or the audit scope, so treat it as permission to trade once rather than a decision to use the venue. The full sequence above belongs in the hour before size goes on, not in the minute before a fill that somebody is waiting for.
What to do when a swap fails
A reverted swap that still charged gas usually means the slippage tolerance was too tight or the pool moved between the quote and the block that included your transaction. Raising tolerance blindly is the wrong response, because on a thin pool it converts a failed trade into a bad one. Re-quote first, and look at whether the price impact has changed since the attempt.
A transaction stuck as pending is a nonce problem rather than an exchange problem. Replace it with a transaction of the same nonce at a higher fee, sending nothing to your own address, instead of submitting a second swap that may land after the first one clears and trade the size twice at prices nobody chose.
Tokens that take a fee on transfer break routers that assume the amount sent equals the amount received, and the swap fails repeatedly with no useful error attached. A venue either supports that behaviour explicitly or it does not, and further attempts only spend gas proving the point. The same applies to tokens with transfer restrictions written into the contract.
Mistakes that cost more than fees
Copying a contract address from a chat message is the most expensive habit on this list. Take it from the project documentation or from a site you reached without clicking anyone’s link, then compare the opening and closing characters against a second source before the first trade. Addresses that differ only at the end are generated for exactly this moment.
Treating total value locked as depth is the next one. A venue can hold a large amount spread across pools that have nothing to do with the pair you came for, and the figure on the front page has no bearing at all on what your order fills at. Depth is per pool, and the only proof is a quote at your size.
The last is assuming an aggregator removes the question. Routing through an aggregator still ends in somebody’s pool behind somebody’s router, and the permissions, audit scope and exit depth of whatever it selected are the same risks arriving under a different interface. An aggregator changes who chooses the venue, not whether the venue deserves the trade.
Look at how the venue handles trouble
Every exchange that has run for a while has had an incident. What you want to find is how it was handled: whether users were told while it was happening, whether the postmortem names the cause, and whether the fix was deployed or promised. A venue with no visible history has either been lucky or has not been running long enough to tell you anything.
Check that the documentation matches what is deployed. Projects iterate through router versions and leave the old addresses in the docs, and a deprecated router often still works while quietly holding less liquidity behind it. If the addresses in the documentation and the addresses the front end calls disagree, stop and find out which one is current.
Find out where problems get announced and whether anyone answers there. A support channel that exists but has had no reply in weeks is worse than none, because it tells users to wait somewhere nobody is reading. During an incident, the venue that posts quickly is the one where a stuck position can still be acted on.
Keep a short note on each venue
Write down the router address you verified, the approval policy you settled on, the fee tier the router used at your size and the date you checked. Four lines per venue takes a minute and removes the entire question the next time somebody asks whether this exchange was assessed and what came out of it.
Re-check the note when something changes. A new router version, a governance vote on fees or an announcement about the front end all invalidate parts of it, and the checks that matter are the ones about contract permissions rather than the ones about depth, which move on their own every day anyway.
Keep the failed venues in the same file with the reason. Teams reassess the same exchange twice a year and repeat the work because nobody recorded why it was rejected, and a rejection that took twenty minutes to establish is worth one line of storage.
If you are weighing a concentrated liquidity DEX on another chain, see our comparison of Uniswap v3 clones by TVL, volume and fee tiers.
What these checks cannot tell you
- Whether the team is honest. Contract permissions tell you what they can do, not what they will.
- Whether depth persists. Liquidity on incentive programmes leaves when the incentives end.
- Whether an audited contract is safe. Audits reduce the chance of known bug classes and eliminate nothing.
- Whether a quote holds. Price impact is calculated at quote time and other trades land before yours.
For projects choosing where to be listed rather than where to trade, the venue comparison and the marketing consequences of each are covered on our crypto traffic acquisition page.