CEX vs DEX

In brief

“CEX” and “DEX” describe market structures, not safety ratings.

| Question | Typical CEX | Typical DEX | | --- | --- | --- | | Who holds the user’s assets before a trade? | The operator or a third-party custodian | The user’s wallet until authorization; liquidity may sit in contracts | | Where is the balance recorded? | Internal off-chain ledger | Blockchain accounts, token contracts, and protocol state | | How is a trade priced or matched? | Operator-run order book or dealer system | AMM, on-chain order book, request for quote, or hybrid | | How does settlement happen? | Usually an internal ledger update; on-chain when depositing or withdrawing | Usually an on-chain transaction or program-defined settlement | | Who can stop access? | Operator, custodian, bank, or regulator | Contract/admin keys, front end, RPC, sequencer, or the chain itself | | Main added risk | Counterparty and custody | Contract, token, execution, and transaction-ordering risk |

IOSCO’s market reports describe the common pattern: centralized crypto-asset platforms often combine trading, custody, and other intermediary functions, keep customer records off-chain, and control withdrawal processing. DEX arrangements commonly use smart contracts and let users trade from self-hosted wallets, but can still contain identifiable operators, relayers, admin controls, hosted interfaces, and other centralized components.

The live Decentralized exchanges article explains AMMs, order books, liquidity providers, slippage, and MEV in depth. This page answers the comparison intent: where custody, execution, settlement, access, and failure risk differ.

Custody: who can move the assets?

On a typical custodial CEX, a user deposits to an address controlled by the platform or its custodian. The exchange credits an internal balance. Trades between customers can then be database entries rather than separate blockchain transactions. The user’s displayed balance is a claim on the service; withdrawing requires the service to authorize an on-chain transfer or release funds through another payment rail.

That structure can simplify key management, account recovery, fiat deposits, and rapid matching. It also means the user depends on:

• the platform and custodian holding enough assets;
• accurate internal records;
• segregation and safeguarding practices;
• functioning withdrawal systems;
• the user account not being frozen or compromised;
• the legal entity honoring its obligations.

IOSCO notes that crypto trading platforms may use several custody models: operator custody, third-party custody, or participant self-custody. “CEX” therefore does not prove the operator directly holds every key. The specific account agreement and withdrawal mechanism matter.

On a typical DEX trade, the user signs from a wallet and does not first transfer an unrestricted account balance to a company ledger. But “non-custodial” needs precision. Assets may be:

• in the user’s account until a swap executes;
• deposited into an AMM liquidity-pool contract;
• escrowed in an on-chain order-book program;
• approved for a router or settlement contract to spend;
• bridged or wrapped under a separate custodian or protocol.

Keeping the transaction-signing key does not eliminate other control. An ERC-20 allowance can let an approved contract transfer tokens within its authorization. A token issuer may retain pause or blacklist powers. An upgrade key may change a protocol. The live Self-custody article covers that broader authority spectrum.

Matching and pricing

Most CEX spot markets use a centrally operated limit order book or dealer-style system. The operator receives orders, applies its matching rules, records fills, and updates customer balances. The book can be fast and private, but customers generally cannot verify the complete matching history from the blockchain. Published prices, depth, and volume are representations supplied by the venue.

DEX is a broader family:

• Automated market maker: a smart contract prices trades against pooled reserves using a formula. Uniswap is a prominent example, not the definition of DEX.
• On-chain order book: orders and matching state live in a program, subject to network execution and fees.
• Off-chain orders with on-chain settlement: signed orders or quotes are discovered elsewhere, then a contract verifies and settles them.
• Aggregator: a router searches multiple pools or quote sources and submits a route. The aggregator is an additional dependency, not the underlying liquidity itself.

A hybrid can have self-custodial settlement but centralized matching, or decentralized contracts behind one dominant website. Classify the custody, matching, and settlement layers separately instead of relying on branding.

Settlement and exit

On a CEX, a trade can settle instantly in the platform’s ledger while no public-chain ownership changes. The important on-chain event comes when assets enter or leave the platform. A transaction proving that the exchange controls an address does not prove which customer owns which part of the pooled balance, nor that all liabilities are covered.

On a DEX, settlement is usually visible on-chain. That improves public verifiability, but the transaction can still:

• revert and consume a network fee;
• execute at an unfavorable price within the user’s limit;
• be reordered or sandwiched;
• interact with a counterfeit or malicious token;
• route through a vulnerable contract;
• depend on a rollup sequencer or bridge;
• succeed on the wrong network.

On-chain visibility proves what the chain executed. It does not prove the trade was economically fair, the token was genuine, or the contract was safe.

Access, identity, and compliance

A CEX commonly uses a customer account and may require identity checks, but requirements vary by venue, product, and jurisdiction. The operator can enforce geographic restrictions, account limits, withdrawal reviews, and legal orders.

A DEX contract may accept transactions from any address, while the hosted interface applies location blocks or other policies. Other arrangements use allowlists, permissioned pools, screened relayers, or regulated front ends. A wallet address is not the same thing as legal anonymity, and blockchain activity remains publicly traceable.

Regulatory treatment depends on activities, assets, control, and jurisdiction—not simply whether a product calls itself decentralized. This article does not classify any named venue or provide legal advice.

Listing and token authenticity

A CEX listing is generally an operator decision. The venue decides which ticker, deposit contract or chain, order book, and withdrawal rails it supports. That process is not a guarantee of solvency, fair pricing, or token quality.

In a permissionless AMM design, anyone may be able to create a pool for any pair of token contracts. The ticker and logo are not unique identifiers. A counterfeit token can copy a legitimate asset’s name and symbol, and a pool can exist with little or one-sided liquidity.

For either venue, verify:

• the chain and contract or mint address;
• whether the asset is native, wrapped, or bridged;
• who can mint, freeze, pause, or upgrade it;
• available liquidity and realistic exit size;
• the exact withdrawal asset and network.

Failure modes are different, not absent

Typical CEX failure paths include insolvency, commingling or misuse of customer assets, custodian compromise, cyberattack, operational outage, account takeover, bank disruption, and withdrawal suspension. Regulatory safeguards can reduce particular risks where they apply; they do not make operational failure impossible.

Typical DEX failure paths include contract bugs, malicious upgrades, unsafe token behavior, oracle manipulation where an oracle is used, thin liquidity, slippage, MEV, compromised interfaces, bad signatures or approvals, bridge failure, sequencer censorship, and chain congestion.

A DEX’s core contracts may be immutable while its router or website changes. A CEX may use verifiable on-chain custody while customer claims remain off-chain. Neither one-word label captures the full system.

Questions to ask before using either

1. Who can move the asset before, during, and after the trade?
2. Is my balance a ledger claim, a wallet balance, a contract position, or a wrapped claim?
3. Who chooses order matching, routing, and transaction ordering?
4. What keys can pause, upgrade, freeze, or withdraw?
5. Can I exit if the main website or operator is unavailable?
6. Which chain, token contract, bridge, custodian, or bank is required?
7. What price limit am I signing, and where does displayed liquidity come from?
8. Which legal entity or program would I rely on if something fails?

The answers describe the risk allocation. They do not produce a universal recommendation.