Examples of decentralized crypto exchanges include protocols that execute trades through onchain smart contracts and liquidity pools, alongside other onchain marketplace designs. The evidence available for this article supports a limited set of examples: a token-pair pool model and Seaport, a marketplace protocol whose orders specify offered assets and required consideration. It does not verify a broad catalog of named, currently deployed exchanges, so this is a scoped explanation rather than a ranking or complete directory.

What counts as a decentralized crypto exchange?

For this article, a decentralized exchange (DEX) means a protocol-based system for arranging or executing asset trades through onchain components. The term is often used broadly, so it helps to separate the protocol from an interface. A website or wallet application can provide a way to interact with a protocol without being the protocol itself; similarly, a protocol’s documented function should not be inferred from the branding of an interface.

“Decentralized” is not a single technical feature. Execution, administration, custody, governance, and the interface can be organized differently. The evidence here supports describing particular trading and marketplace mechanisms, but it does not support scoring the examples by degree of decentralization. The examples below are illustrative, not exhaustive, and their inclusion does not establish current availability, network coverage, liquidity, safety, popularity, or suitability.

A further distinction is useful: a marketplace order protocol is not automatically equivalent to a general-purpose token-swap exchange. A catalog should identify what a named protocol actually does, rather than group every onchain asset interaction under one label.

Examples of decentralized crypto exchanges using liquidity pools

Uniswap v2 provides a documented example of a pool-based exchange design. A liquidity pool holds deposited reserves of a token pair, and those reserves supply the inventory from which swaps execute. Liquidity-provider shares represent contributions to the pool. This description is specifically about Uniswap v2 pools; it should not be generalized to every Uniswap version or every automated market maker.

The defining classification point in this example is the source of trade inventory: a contract-held token-pair pool, rather than an offchain limit order book. A pool is a mechanism, not a universal recipe. Other automated market makers may use different curves, assets, fees, or accounting, so the Uniswap v2 model cannot stand in for every pool-based protocol.

The source evidence supplied for this article does not substantiate current protocol descriptions for other familiar names, such as Curve or Balancer. Naming them as verified examples without current primary documentation would go beyond the evidence. Nor does the evidence provide a checked list of Uniswap deployments across networks. Readers researching a particular deployment would need to verify its protocol documentation and network context separately.

This section is deliberately not a general tutorial on automated market makers. It identifies the pool-based example and the mechanism that makes it fit that category; broader explanations of pool pricing and trading mechanics belong in a separate AMM explainer.

Order-book and other non-pool exchange designs

Decentralized trading systems need not all follow a pool-based execution path. Order-book, auction, intent-based, cross-chain, and hybrid designs are recognized categories of DEX execution, but naming a category does not verify that any particular system is currently operating or that it qualifies as a decentralized exchange in every relevant sense. A named example requires evidence about its protocol function and settlement path.

Seaport offers a useful, carefully bounded contrast. It is an onchain marketplace protocol in which an order represents assets offered by one side and consideration required from the side that fulfills it. That structure illustrates an alternative way to express and fulfill an asset exchange. The evidence does not establish that Seaport is a general-purpose token-swap exchange, so it should be described as a marketplace protocol rather than treated as interchangeable with a pool-based DEX.

The distinction prevents category errors in exchange lists. A pool-based swap protocol, a marketplace protocol, an aggregator that coordinates sources, and an interface that presents a trading workflow can be related without doing the same job. Evidence about one role does not establish another. The available evidence does not verify a named decentralized order-book exchange or a current non-pool token-swap protocol for inclusion here; it is more accurate to state that limitation than to force an example.

How to read the examples by network and protocol role

The supported evidence describes Uniswap v2’s pool mechanism and Seaport’s offer-and-consideration order structure. It does not establish current network deployments for either example, so this article attaches no network labels. A protocol name alone is not enough to confirm which chain a particular instance uses, whether that instance is active, or whether its design is identical to another deployment.

When classifying another entry in a DEX list, begin with its primary protocol documentation. Check whether it describes an exchange protocol, a marketplace, an aggregator, a router, or an interface. Then identify the documented execution and settlement model and the specific network environment, if verified. These are separate questions: the fact that an application can route a user to onchain components does not establish that the application itself is the underlying exchange protocol.

A protocol can also be composed with other onchain components. That relationship does not erase the distinction between the protocol’s own role and the roles of its dependencies. For this catalog, no claims are made about fees, security, liquidity, access in particular jurisdictions, or operational availability. Those points require separate, current evidence and are not needed to classify the examples by design.

What this list does—and does not—establish

The evidence-supported examples illustrate different onchain roles: Uniswap v2 pools use reserves of a token pair as swap inventory, while Seaport orders define offered assets and required consideration for fulfillment. Seaport is a marketplace-protocol contrast, not evidence that it has the same function as a token-swap exchange.

This list is not exhaustive and does not establish which systems are currently available or deployed on any particular network. Inclusion is not an endorsement or a conclusion about decentralization, safety, trading conditions, popularity, or suitability. It is a way to distinguish documented protocol mechanisms while keeping interfaces and related services separate from the protocols they may expose. General AMM mechanics and broader comparisons between centralized and decentralized exchanges are outside this article’s scope.

Sources and references