Decentralized exchanges and automated market makers

What makes an exchange decentralized?

A decentralized exchange (DEX) is an arrangement in which trading can be executed using blockchain-based rules rather than a single operator's private matching ledger. The phrase does not promise that every component is decentralized. A website may have an operator, a protocol may have an upgrade administrator, and pricing may depend on a small number of liquidity providers. A user can interact with a smart contract directly or through an interface, but accessibility of the interface and openness of the underlying contract are separate properties.

A swap means exchanging one crypto-asset for another. In a common DEX design, a user authorizes a smart contract to exchange assets against a pool of available assets. In another design, participants submit orders that are matched according to protocol rules. These are different market structures. A DEX may settle trades on-chain, but settlement does not establish the identity, legal capacity, or intention of another participant. It also does not make all transaction data immediately understandable without decoding contract events.

How a liquidity pool replaces the traditional order book

Reserves, price, and the simplest formula

An automated market maker (AMM) is a system of rules that quotes exchanges using assets held in a liquidity pool. Liquidity providers (LPs) contribute assets to that pool and may receive a claim on their proportional share, subject to the design. The simplest widely taught model is a constant-product pool with two reserves, x and y. Its idealized relation is x × y = k. When a trader adds one asset and takes out the other, the reserve ratio changes, so the marginal exchange rate changes too. This is a model for understanding price impact, not a statement that all real AMMs use the same mathematics.

Consider an illustrative pool holding 100 units of Asset A and 1,000 units of Asset B. Ignoring trading fees and other complications, k equals 100,000. If a swap adds 10 units of A, keeping k constant leaves about 909.09 units of B, so the pool releases about 90.91 units of B. The average exchange rate differs from the initial quoted ratio of 10 B per A. This difference is an example of price impact caused by the trade's size relative to pool depth. The illustration does not include transaction costs or network fees.

Other AMM designs and routing

Some pools use weighted reserves, stable-asset curves, concentrated liquidity, or hybrid mechanisms. Concentrated liquidity lets participants allocate liquidity to selected price ranges; that may improve depth inside a range while exposing the position to becoming inactive when the market price moves outside it. An aggregator can search multiple pools or routes to obtain an execution path, but it adds routing logic and dependence on its own interface or contract integrations. An advertised best quote is not an execution guarantee.

A DEX transaction may pass through several contracts and pools. A visible token transfer can therefore represent one part of a larger route rather than a direct bilateral trade. Analysts should read transaction logs and contract calls in context. Transfer counts, swap events, and address counts answer different questions. In particular, a contract address that receives assets during a swap is not automatically the ultimate economic beneficiary.

Fees, slippage, and arbitrage

AMMs commonly charge a swap fee, which may compensate liquidity providers or other protocol participants according to its rules. Slippage can arise because a pool's price changes between the moment a transaction is prepared and executed, or because the transaction itself moves the price. Network transaction fees are separate. A limit or tolerance set by a software interface can determine whether a swap executes or fails; it does not eliminate the underlying volatility or execution risk.

Arbitrage is trading that seeks to exploit differing prices across venues or pools. It often brings AMM prices closer to prices observed elsewhere, but it is not a perfect or costless mechanism. Network delays, transaction fees, competition, and settlement constraints affect what arbitrageurs can do. During volatile periods, the pool price can deviate from a broader market reference for a time. Thus, a pool's instantaneous ratio is not necessarily a reliable external valuation for financial reporting or collateral assessment.

The position of a liquidity provider can change in composition when traders rebalance the pool. Impermanent loss is a common label for the difference between a liquidity-provider position's value and the value of simply holding its contributed assets under a specified comparison, excluding or accounting for fees as stated. The label can be misleading because a realized withdrawal can crystallize that difference. Fee income may offset some effects but is not a guarantee of an overall gain. Readers should avoid turning a general concept into a promise of returns.

Transaction ordering and execution risk

Why public visibility changes the market

Pending transactions may be visible to some network participants before inclusion in a block. Those participants can respond by submitting other transactions. Maximal extractable value (MEV) describes value obtainable from selecting, including, excluding, or ordering transactions in a block. One manifestation is a sandwich pattern in which trades occur around another trade and worsen its execution. This course discusses the pattern as a market-integrity risk, not as a trading technique.

Transaction ordering is not universally transparent, and different networks handle pending transactions differently. Some systems provide private submission routes, batch auctions, or other mitigations, each with its own trust and availability considerations. A reviewer should not assume that identical quoted prices imply identical execution results. Evidence may include the transaction's submission time, included block, events, price effects, and any observable related transactions; conclusions about intent demand more than a visual sequence.

Governance, control, and oversight

A DEX can include smart contracts, an interface, an administrator, liquidity providers, governance voters, off-chain teams, and external data sources. The meaningful question is who can change code, alter fee settings, pause features, upgrade contracts, or influence access. These capabilities are evidence of potential control but do not alone determine a specific person's legal status. Fully automatic execution does not eliminate human influence in development, deployment, and governance.

FATF's Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers (2021), interpreting FATF Recommendation 15, says that software as such is not a VASP, but identifiable owners or operators who maintain control or sufficient influence and provide covered services can fall within the VASP perimeter. IOSCO's Policy Recommendations for Decentralized Finance (DeFi) (December 2023) likewise emphasize identifying responsible persons, managing conflicts, and considering operational and market-integrity risks. Neither statement means that every open-source developer is automatically a regulated intermediary; facts and applicable law matter.

A manager comparing venues should assess transparency of fee and pricing rules, admin privileges, audit practices, oracle dependencies, and processes for handling incidents. An auditor may seek code versions, event logs, and administrative-change histories. A legal reviewer should separate automated mechanics from jurisdiction-specific obligations and avoid assuming a website's claim of decentralization decides the issue.

A practical reading of an AMM swap

Suppose a transaction swaps A for B using two pools and charges a protocol fee in addition to a network fee. The public record may show approvals, internal token movements, and one final token receipt. The amount the user receives depends on the executed route and prevailing reserve conditions, not simply the interface quote viewed moments earlier. A useful reconstruction lists the initiating account, called contracts, input and output assets, actual amounts, fees, and events. It does not assume each intermediate contract owns funds beneficially.

The analytical lesson is not that AMMs are better or worse than centralized order books. They allocate responsibility differently: some rules are transparent in deployed code, while risks migrate to contract logic, administrative controls, liquidity concentration, and transaction ordering. Clear professional explanations identify the economic mechanism and the evidence supporting it without predicting outcomes.

Exam focus: Explain how a pool-based AMM differs from an order book; distinguish reserves, price impact, slippage, and fees; recognize governance and transaction-ordering dependencies; and avoid equating the word decentralized with absence of control or legal responsibilities.