DEX development is the work of writing and deploying smart contracts that let users swap tokens from their own wallets, at prices set by an on-chain formula or order book, without any company holding the users' funds. The difficult tasks are choosing a market design that attracts liquidity, getting the contracts audited and protecting users from MEV bots, which profit by reordering or front-running users' transactions.
This page is a build guide covering the market designs, the contracts and off-chain services, security, chains, the order of work and cost. The decentralized exchange software guide compares ready-made DEX scripts and white label products instead.
Choose a market design first
The market design decides how a DEX finds prices and matches trades, and every later choice depends on it. Five designs are common in 2026.
Constant-product AMM
Uniswap v2 made this design popular. Each pool holds two tokens. Fees aside, a trade must keep the amount of token x multiplied by the amount of token y the same, a rule written x ยท y = k. Anyone can add both tokens in the current ratio and receive LP tokens that record their share of the pool.
The design is simple, has run for years and works for any pair, but its liquidity is spread across every possible price, so most of the capital sits idle. Liquidity providers (LPs) also suffer impermanent loss when the price of one token moves against the other.
Concentrated liquidity
Uniswap v3 lets each LP place liquidity inside a chosen price range, and each position is an NFT. Far more liquidity then sits near the current price, and pools can have several fee tiers. Concentrated-liquidity contracts need complex price math, LPs must manage their ranges, and audits take longer.
Uniswap v4 launched in January 2025, moving all pools into one contract and adding hooks: custom code that runs at set points in a pool's life, such as before or after a swap. Developers can build new pool behavior as hooks without writing a whole exchange.
Stable-swap curves
Curve-style pools suit two assets that should be worth the same, such as two dollar stablecoins, or a token and its liquid staking version. While the pool holds both assets in similar amounts, swaps happen at close to one-to-one with very low slippage. When the pool becomes unbalanced, its prices change like those of a constant-product pool, so this design suits pegged assets and not volatile pairs.
On-chain order books
A central limit order book on Ethereum mainnet is costly, because every order and every cancellation pays gas. Order books work on high-throughput chains and on app-specific chains, and dYdX moved its v4 exchange to its own Cosmos-based chain for this reason.
Intents and batch auctions
In an intent design, the user signs a message that states the trade they want, and solvers or market makers compete to fill it. In a batch auction, the protocol collects orders for a short period and settles them together at one price. Both designs can reduce MEV and improve prices. Aggregators that route trades across many pools form their own category, covered in the DEX aggregator guide.
| Design | Typical use | Main weakness | Build complexity |
|---|---|---|---|
| Constant-product AMM | New and long-tail tokens, simple launches | Idle capital, impermanent loss | Low |
| Concentrated liquidity | Major pairs, professional LPs | Complex math, active range management | High |
| Stable-swap | Pegged assets | Large losses for LPs if a peg breaks | Medium |
| On-chain order book | Active traders on fast chains or app-chains | Needs market makers and high throughput | High |
| Intent or batch auction | MEV protection, best price for the user | Needs enough active solvers | High |
Fork, build on v4 or write from scratch
Many DEXs started as forks of Uniswap v2. A fork of well-audited code is a reasonable start, but three warnings apply.
- License. Check the license of every repository. Uniswap v2 core is GPL-3.0, while Uniswap v4 core uses the Business Source License 1.1, which allows live production use only under specific grants from Uniswap. The limit ends on 15 June 2027, or on an earlier date if Uniswap sets one, and v4 core then becomes MIT-licensed. Curve's contracts use a custom license, so read it before you copy them.
- Audit coverage. A small change to forked code removes the original audit's coverage for that code path, and several forks were drained through such edits.
- Reason to exist. A fork with no new feature gives LPs no reason to move liquidity from the original.
Uniswap v4 also offers a newer option: build hooks instead of an exchange. A team can write hooks that add dynamic fees, on-chain limit orders or custom price feeds to pools inside Uniswap v4's existing contract. The Uniswap clone guide and the PancakeSwap clone guide walk through the classic designs.
The contracts in a typical AMM DEX
- Factory. The factory deploys a new pool for each token pair, and for each fee tier in concentrated-liquidity designs, and records each pool's address.
- Pool or pair. The pool holds the reserves, enforces the pricing formula, mints and burns LP shares, collects fees and exposes a price oracle.
- Router. Users call the router, which handles multi-hop paths, wraps native ETH or BNB, enforces the user's minimum output and deadline, and pulls tokens through approvals or signed permits.
- Position manager. In concentrated-liquidity designs, the position manager wraps each position as an ERC-721 NFT.
- Governance and fee switch. These optional contracts let a DAO or multisig turn on a protocol fee, change parameters or upgrade parts through a timelock.
- Incentives. Staking or gauge contracts pay reward tokens to LPs, and reward programs need their own design, because rewards can attract liquidity that leaves when the rewards end.
Off-chain services in decentralized exchange development
Trades settle on-chain, but users reach the DEX through software that the team hosts. Plan for these services:
- a web app, also published on IPFS so it stays reachable if the team's servers go down
- an indexer that turns contract events into pool, price and volume data, either a subgraph on The Graph or a custom indexer
- a token list with sensible defaults and warnings for scam tokens
- RPC nodes or an RPC provider
- analytics, and monitoring that alerts the team when a pool behaves abnormally
The web app is also where teams usually apply sanctions screening and geographic blocks, if their lawyers say these are needed.
Security
Most DEX exploits follow a few patterns:
- Price oracle manipulation. A pool's current spot price is a weak oracle, because an attacker can move it with a flash loan inside one transaction. Use time-weighted average prices or external oracles, keeping in mind that a time-weighted price lags fast market moves, and an external oracle adds a dependency on its operator.
- Reentrancy and callback abuse. Token callbacks, hooks and flash swaps can call the DEX contracts again while an earlier call is still running. Update balances before any external call, and lock functions against a second entry.
- Rounding and precision. A fixed-point rounding error in the user's favor, repeated many times, can drain a pool.
- Non-standard tokens. Some tokens take a fee on each transfer, change balances automatically or return no success value, which breaks simple balance accounting.
- Admin key risk. An upgradeable contract controlled by one key fails if that key is lost or stolen, so use a multisig and a timelock.
Plan at least one independent audit of the final code, and two for new math, then open a public bug bounty after launch. The smart contract audit guide explains what an audit covers and what it does not.
MEV and user protection
Bots watch the public mempool, where pending transactions wait. A bot can trade just before a user's swap and just after it, a pattern called a sandwich attack. No AMM can remove MEV completely, but a DEX can limit the damage in four ways:
- set tight default slippage limits
- enforce a deadline on every swap
- offer private transaction submission through protected RPC endpoints
- offer batch-auction or intent-based execution for large orders
Choosing a chain
Ethereum mainnet has the deepest liquidity and the most contracts to integrate with, and it has the highest fees. Layer 2 rollups such as Arbitrum, Optimism, Base and ZKsync Era run EVM code at a fraction of the cost, and much new DEX activity happens there. BNB Smart Chain has large retail volume, while Solana and other non-EVM chains need different programs, languages and tools. Each extra chain adds audit and monitoring work, so many teams launch on one chain and expand when users ask for more.
DEX development process
- Define the market. Decide which assets and users the DEX serves, and why LPs will move liquidity from an existing exchange.
- Specify the mechanism. Write down the pricing formula, fee model, oracle design and governance powers before any code.
- Build and test. Write unit tests, fuzz tests and invariant tests (Foundry is the common tool), plus fork tests against mainnet state.
- Audit and fix. Freeze the code, run the audit, fix the findings and have the auditor review the fixes.
- Run a testnet and a guarded launch. Deploy on mainnet with deposit caps or a short list of approved pools, monitor the pools, then lift the limits.
- Bootstrap liquidity. Seed the pools, work with market makers or run reward programs with fixed end dates.
- Operate. Keep monitoring, incident runbooks, the bug bounty and a governance process for upgrades.
Revenue models
Swap fees go mainly to LPs, but a protocol can take a share of those fees through a fee switch. Uniswap's UNIfication proposal, for example, turned on protocol fees for v2 pools and selected v3 pools on Ethereum after governance approved it in December 2025. Other options are a fee charged by the web app and income from a token treasury. A protocol fee lowers LP income, and a web app fee can push traders to other front ends.
Cost and timeline drivers
The following figures are a reasoned estimate, not a quote. A careful modified fork of a known AMM with a custom web app needs two or three smart contract and front-end engineers for two to four months, plus one audit, and often costs from about one hundred thousand to several hundred thousand US dollars, including the audit.
A new mechanism, such as a new pricing formula, an order book on an app-chain or a solver network, can take a larger team a year or more. Decentralized crypto exchange development costs depend most on four things:
- how new the math is
- the number of chains
- the number of audits
- whether governance and a token must exist at launch
Frequently asked questions
How is a DEX different from a centralized exchange?
A DEX settles trades in smart contracts, and users keep their tokens in their own wallets until the swap runs, while a centralized exchange holds customer funds and runs an internal order book. The white label crypto exchange guide covers the centralized model.
Can I just fork Uniswap?
You can fork code whose license allows your use. Uniswap v2 is GPL-3.0, and v4 core stays under the Business Source License until June 2027 at the latest. A fork still needs an audit of every change, its own liquidity and a reason for users to switch.
Which AMM design should a new DEX use?
Teams use constant-product pools for new and long-tail tokens and stable-swap curves for pegged assets, while teams that target major pairs and professional LPs use concentrated liquidity or Uniswap v4 hooks.
How long does DEX development take?
A modified fork can reach an audited mainnet launch in a few months, but a new mechanism usually takes a year or more, including several audits.
What do decentralized exchange development services include?
These services usually cover swap and pool contracts, a router, a web app, an indexer, an independent audit and deployment support. Liquidity is not part of the software, so the project still needs a plan to attract LPs.