What is a DEX?

A decentralized exchange (DEX) is a class of trading system that lets users swap digital assets through blockchain protocols or smart contracts. A smart contract is a program deployed on a blockchain that checks and executes operations according to its code. Users usually initiate operations from their own wallet, and the trade is settled by this kind of onchain program under its rules, without first recording assets into an internal account controlled by the same trading platform.

A DEX is not one fixed software structure, and it does not amount to "every step happens onchain" or "there is no operator at all". Some DEXs quote automatically from liquidity pools, others use buy and sell orders; quoting, order propagation and trade path calculation may also happen offchain — that is, handled by services that do not write directly to the blockchain — with a blockchain contract settling at the end. A web interface, administrative permissions, external data and the underlying network can still form centralized dependencies.

A DEX consists of trading rules, available assets and an access point

What an ordinary reader sees as a DEX is often a web page, but completing a swap usually requires several components:

• the trading protocol: specifies how orders or pools are called and how assets move;
• smart contracts: programs deployed on a blockchain that check and execute operations according to their code;
• liquidity sources: pool assets available to trade, resting orders or market maker quotes;
• a wallet: holds or invokes a user's signing capability, letting them confirm approvals and transactions;
• an application interface: displays assets, quotes, fees and transaction status;
• the blockchain network: verifies transactions and writes execution results into shared state.

A protocol and a web page are not the same thing. One trading protocol can have several interfaces, and one interface can connect to several protocols. An official site being temporarily unreachable does not necessarily mean the underlying contracts have stopped; conversely, a page opening normally cannot prove that what it displays is the correct contract or a genuine quote.

A swap goes from a quote to onchain settlement

Once a user selects the asset to give up, the asset they want to receive and an amount, the interface queries pools, orders or other liquidity sources and gives an estimated result. A quote usually reflects only the state at the time of the query, and may carry an expiry.

If a contract needs to move a token out of the user's address, the user may first have to submit an approval transaction. An approval permits a designated spender address — the address allowed to move assets on the user's behalf — to move a token from the user's address within an allowance. That address is often the swap contract, but it can be another address. An approval is not the swap itself; an allowance that is too large, or an approval granted to the wrong address, leaves the risk of assets being moved out later. Some token standards and wallets support granting such an allowance by signature, and the actual effect still depends on the standard and the contract.

The interface then builds a transaction request containing conditions such as the target network, the contract address, asset amounts and the worst result permitted; the wallet displays the request content it can parse along with an estimated network fee. After the user confirms and signs, the transaction is sent to the blockchain network. While processing a candidate block, nodes verify under the protocol and execute the target contract; only after the transaction executes successfully and is included in a valid block do asset balances update according to the execution result. When something can be regarded as final still depends on the specific network's confirmation or finality mechanism.

A transaction can still fail after submission. For example, an expired quote, a change in pool balances, a permitted price deviation that is too small, or insufficient approval or balance will each cause the contract to refuse execution. An interface showing "submitted" only means the request has been sent; it does not mean the swap is complete.

An automated market maker produces a swap result from a pool

An automated market maker (AMM) is a class of mechanism in which a smart contract produces a swap result from pool balances and a calculation rule. A trader interacts with the pool and does not have to wait for some designated seller to take the other side at the same moment.

Liquidity providers place assets into a pool to make amounts available for other users' swaps, and may receive part of the fees under the rules. After a swapper takes one asset out of the pool and puts another in, the ratio in the pool changes, and subsequent quotes change with it.

The larger a trade is relative to the pool, the more noticeably the trade itself usually changes the ratio in the pool. The difference this trade causes between the estimated execution price and the pre-operation price inside the pool is commonly called price impact.

Different AMMs can use different calculation formulas, asset ranges and ways of distributing liquidity. The Uniswap v2 technical description shows one implementation managing a pool with two token reserves and a constant product rule, but this is not a uniform structure for all DEXs.

An order book matches buying and selling intentions

An order book records at what price and in what amount participants are willing to trade. The side placing an order is usually called the maker, and the side accepting an existing order the taker. Once the system finds orders with compatible conditions, settlement follows under the rules.

Orders and matching can be arranged differently. Some systems write both orders and matching to the blockchain; others have users sign an order first, propagate or match it offchain, and hand the signed order to a contract for verification and settlement when it fills. An offchain order book can reduce the overhead of writing every order placement onchain, but whether the order service is available, whether it hides some orders, and who may submit a fill still have to be checked separately.

The fields of a signed order and the way matching works are not uniform. The 0x order documentation shows one kind of limit order: the order contains conditions such as the assets to exchange, amounts, the signer and an expiry, and is finally checked and executed by an onchain contract.

An aggregator finds trade paths but does not necessarily provide liquidity

A DEX aggregator queries multiple pools, orders or quote sources, then calculates one or several trade paths for a swap. It may split a trade across different sources, or swap into an intermediate asset first and then into the target asset.

An aggregator does not necessarily hold funds itself or operate the underlying trading protocol. Its main capability may be finding quotes, estimating network costs and building a transaction request that calls other contracts. The 0x core concepts documentation shows one routing approach that aggregates AMMs, orders and market maker quotes.

Aggregation does not guarantee obtaining the best market-wide result at any given moment. The range of sources that can be queried, quote update timing, the routing algorithm, protocol fees, interface fees, network fees and whether a transaction succeeds all affect the amount actually received.

Price impact and slippage are not the same concept

Price impact comes from the trade itself changing available liquidity or consuming orders. Slippage is the difference between the expected execution result and the actual execution result, and may come from other transactions during the waiting period, price changes, orders being filled or transaction ordering.

Interfaces often let users set a slippage tolerance and convert it into an onchain condition of "minimum received" or "maximum paid". If the result at execution falls outside that range, the transaction usually reverts; if the tolerance range is too wide, a trade may still execute when the price has changed noticeably.

Quotes, price impact, slippage settings and the final execution result have to be looked at separately. Low price impact does not mean slippage will not occur during the waiting period, and setting a slippage limit cannot keep the market price unchanged.

Fees may go to different participants

A DEX swap may involve several kinds of fee at once:

• network fees: paid to the network participants that process blockchain transactions;
• swap fees: charged under the rules by a pool or trading contract, part of which may go to liquidity providers and part to a protocol treasury;
• interface or aggregation service fees: charged separately by an application entry point or a routing service;
• cross-chain related fees: can appear only when a trade path involves cross-chain messages or asset transfers.

Different fees may be included in a quote or displayed separately. Comparing only the surface swap ratio may overlook network fees, routing fees or a token's own transfer rules; the wallet request and the onchain execution result should be treated as authoritative.

Non-custodial does not mean assets never enter a contract

A DEX is often described as a non-custodial trading system. Non-custodial here usually means the platform operator cannot unilaterally move a user's assets from its own account; the user initiates a transaction from their wallet, and a contract executes under its rules.

That does not mean assets stay in the user's address throughout. When joining a pool, assets enter the pool contract; placing an order or trading may also involve contract custody, token approvals or a dedicated account. You should look at who can call those assets, whether a contract is upgradable, and whether a pause or emergency withdrawal permission exists.

Disconnecting a wallet from a web page only ends the current interaction. It does not automatically revoke token approvals already written onchain, and it does not exit a pool or cancel all signed orders.

DEXs and centralized exchanges differ in custody, matching and settlement

A centralized exchange (CEX) and a DEX can both display markets, receive trade requests and return execution results, but the key stages are carried by different systems.

These are common patterns, not uniform rules for every product. A DEX can retain administrative permissions, and a CEX can publish some onchain reserve information. When comparing, check the specific custody and execution structure rather than judging by a name alone.

A same-chain swap is not a cross-chain exchange

An ordinary DEX swap usually handles only assets on the same blockchain. Even when a token name represents an asset from another chain, what is traded may be a mapped or wrapped version on the current network — that is, a corresponding token created for use within that network — rather than the asset on the original network itself.

Moving value between different blockchains usually also requires a cross-chain bridge, a messaging protocol, a custodial issuer or another cross-chain mechanism. An aggregator wrapping cross-chain steps into a single interface action does not remove the risks of the underlying bridging, final confirmation and the target network.

So when checking an asset, confirm both the token contract address and the network it belongs to. An identical name, icon or ticker is not enough to prove that two tokens are the same onchain asset.

The degree of decentralization has to be checked layer by layer

When assessing a DEX, you can check separately:

• who can deploy, upgrade, pause or replace the trading contracts;
• who controls the official site, the domain, the default token list and the routing service;
• whether liquidity comes from independent pools, a few market makers or a single service provider;
• whether orders are propagated publicly, and whether a matching service can selectively display or delay orders;
• whether users can access it through other interfaces or by calling contracts directly;
• who takes part in transaction ordering, validation and final confirmation on the underlying blockchain;
• how governance voting connects to actual administrative permissions.

Public contracts, users signing for themselves, or a web page not holding assets each answer only part of these questions. The "DEX" label by itself cannot prove that a system is entirely trustless, cannot be paused, or will not censor transactions.

The main risks of a DEX

DEX risks can come from the trading mechanism, the code and the access point:

• a smart contract has defects, or upgrade and pause permissions go beyond what users expect;
• a token approval is too broad, so a mistaken or malicious contract can move assets out;
• a shallow pool or insufficient orders make the actual execution result deviate noticeably from the estimate;
• the price changes during the waiting period, so a transaction finally reverts or executes at a worse result within the permitted range;
• a publicly pending transaction is observed by others who exploit ordering, inserting transactions before or after the user's;
• a token contract contains special rules such as transfer restrictions, extra charges or the ability to mint at any time;
• a fake website, a wrong contract address or a counterfeit token induces a user to sign;
• an aggregator, router, cross-chain bridge or underlying protocol fails, passing risk along the whole trade path;
• congestion, reorganization or failure on the underlying blockchain delays transactions or changes state.

Public code, audit reports and a longer operating history can offer reference points, but cannot prove a contract has no unknown defects. Onchain success likewise only shows that a transaction complied with the rules in force at the time; it does not mean the execution result matched what the user originally expected.

FAQ

Does a DEX always use an AMM?

Not necessarily. A DEX can use AMM pools, an onchain order book, offchain signed orders, market maker quotes or a combination of several approaches.

Can a DEX move assets out directly once a wallet is connected?

Connecting a wallet usually only establishes an interaction channel; it does not amount to approving a transfer. Only a subsequent token approval, signed order or transaction confirmation can create asset permissions, and each request has to be reviewed separately.

Does a trade on a DEX always complete immediately?

Not necessarily. A transaction has to wait for network processing, and it may fail because of an expired quote, balances, approvals, slippage conditions or a contract error. The time an interface gives is only an estimate.

Are DEX fees always lower than CEX fees?

Not necessarily. Actual cost depends on network fees, protocol fees, interface fees, trade size, liquidity and execution price; you cannot compare a single fee-rate field alone.

Are identically named tokens bought on a DEX all the same?

Not necessarily. Anyone may deploy a token with the same name or ticker. Identifying an onchain asset requires checking the network and the contract address, not just a name or an icon.

Related concepts

Continue with DeFi, DApp, smart contract, non-custodial wallet and crypto token, or return to the Crypto Glossary.

Sources

• Uniswap v2 Core whitepaper — one implementation of automated market making pools, reserves and a constant product swap rule.
• 0x Protocol Docs: Orders — an implementation of limit orders propagated offchain, signed and settled by a contract.
• 0x Docs: Core concepts glossary — routing concepts for aggregating pools, orders and market maker quotes.
• Ethereum.org: Token swap guide — the basic flow of initiating a token swap from a wallet, confirming the transaction and onchain processing.