Decentralised exchange software: comparing your options before you launch a DEX

You rarely need to write a decentralised exchange from scratch. Most DEXs are forks of open-source AMM contracts, white-label packages built on those forks, or front ends over existing liquidity. The real choices are which code base you trust, what its license allows, and how you will attract liquidity once it is live.

This page compares the off-the-shelf routes. For a ground-up engineering walkthrough of AMM and order-book design, read the companion decentralized exchange development guide.

What "DEX software" actually includes

A working DEX has three layers, and a package may cover some or all of them:

• On-chain contracts. A factory that deploys pools, the pool contracts that hold reserves and price trades, and a router that handles multi-hop swaps, slippage limits and deadlines. Optional: farms, staking, governance tokens, fee distribution.
• Indexing. A subgraph or custom indexer that turns events into pool stats, charts and history. Front ends cannot efficiently compute these from raw RPC calls.
• Front end. Wallet connection, token lists, a routing algorithm that finds the best path, price impact warnings and liquidity management screens.

The main options compared

Understanding the AMM designs you can fork

Constant product (x·y=k)

Each pool holds two tokens; the product of reserves stays constant across swaps, so price moves along a curve as one side is depleted. Liquidity providers deposit both tokens and receive pool shares (LP tokens). It is simple, robust and well understood. Its weakness is capital inefficiency: most liquidity sits at prices that never trade. The design is described in Uniswap's own documentation, and its many forks (SushiSwap and PancakeSwap began as Uniswap v2 forks) prove the code base.

Concentrated liquidity

LPs choose a price range, which concentrates depth near the current price and gives traders better execution with less capital. The cost is complexity: positions are NFTs rather than fungible LP tokens, fee accounting is tick-based, and LPs face sharper impermanent loss when price leaves their range. Most professional liquidity on EVM chains now sits in this style of pool. See building a Uniswap-like exchange for how the versions differ.

Stable-swap curves

Curve-style invariants keep price nearly flat around 1:1, which suits stablecoin and liquid-staking pairs. They need careful parameter choice; a poorly tuned amplification coefficient can be exploited when a peg breaks.

On-chain order books

High-throughput chains such as Solana and purpose-built app-chains support central limit order books on-chain. They suit professional traders but need market makers from day one, which an AMM does not.

Licenses: read them before you fork

Open-source does not always mean "free to copy commercially". Some DEX code has been released under the Business Source License, which restricts production use for a period before converting to an open license. Uniswap v3's core code, for example, was under BSL until its change date in 2023, after which it became GPL. Newer versions of various protocols have their own terms, sometimes with use grants controlled by governance. Check:

• The license file in the exact repository and commit you fork.
• Whether front-end code, SDKs and the routing service have different licenses than the contracts.
• Whether trademarks (names, logos) are restricted even when code is open.

Evaluating a white-label DEX package

White-label vendors sell speed. What you need to verify is what you are actually deploying. Ask for:

1. Code provenance. Which upstream repository and commit is this based on, and what diffs were made? A clean diff against upstream is the fastest way to review.
2. Audit evidence. An audit of the vendor's modified contracts, not just the upstream project's audit. Changes to fee logic or token handling are where new bugs appear.
3. Admin powers. List every owner-only function. Can the operator pause swaps, change fees, mint reward tokens, or upgrade contracts? Each one should be behind a multisig and, ideally, a timelock.
4. Full source ownership. You need the contracts, front end, indexer and deployment scripts, with rights to modify.
5. Token handling. Does the router correctly handle fee-on-transfer and rebasing tokens, or at least reject them safely?
6. Front-end security. DNS and hosting compromises have been used to swap contract addresses in DEX front ends. Ask about deployment controls and consider IPFS-hosted builds.

A white-label swap exchange can be a reasonable choice, but treat the vendor's code as untrusted until reviewed.

Liquidity: the problem software cannot solve

A new DEX with shallow pools quotes bad prices, so aggregators route around it and traders do not come back. Teams typically try one or more of: seeding pools from a treasury, liquidity mining (paying LPs in a governance token, which tends to attract mercenary capital that leaves when rewards drop), partnering with token projects launching on the chain, or courting professional market makers for concentrated pools. If you only need users to swap, integrating an aggregator is cheaper than building liquidity; the 1inch-style aggregator guide covers that route.

Security checklist for any DEX deployment

• Use a time-weighted or external price feed for anything that relies on prices. Spot pool prices are manipulable within a single transaction using flash loans.
• Protect against reentrancy, especially with tokens that have transfer hooks (ERC-777-style callbacks).
• Enforce user-specified minimum output and deadlines in the router to limit sandwich attacks.
• Verify all deployed contracts on the block explorer and publish addresses.
• Run an independent smart contract audit on every modified contract and set up a bug bounty.
• Monitor pools for abnormal activity and have a documented pause procedure if the design includes one.

Matching the option to your situation

A few common scenarios and the route that usually fits:

• A new L1 or L2 without a native DEX. A straightforward constant-product fork, deployed early and audited, fills the gap. Ecosystem grants are often available for exactly this, and simplicity makes it easier for other projects to integrate.
• A token project that wants its own venue. Usually a mistake. Liquidity is better placed in an established DEX on your chain, where aggregators already route. Your own exchange splits liquidity and adds contracts you must secure.
• A team with a genuinely new pricing idea. Build it as a pool type or hook on an established protocol where possible. You keep the novel part small and auditable and inherit the rest.
• A wallet, game or payments app that needs swaps. Integrate an aggregator or a DEX's SDK, and optionally add an interface fee. No contracts of your own required.
• A trading-focused venue for professional users. Consider an order-book design on a high-throughput chain or a hybrid exchange model rather than an AMM fork.

Whichever route you take, plan for operations after launch: indexer uptime, token list curation (and removal of scam tokens from your default list), front-end hosting, and incident response.

Costs and timelines: reasoned estimates

A lightly modified constant-product fork with a branded UI, indexer and farms can be deployed in four to eight weeks by two or three engineers, though audit lead times often add a month or more. A concentrated-liquidity fork with a polished front end and position management is typically a three-to-six-month effort. Custom pool logic on top of an existing protocol varies widely with complexity. In every case, budget separately for audits, a bug bounty, liquidity incentives and the indexer's hosting.

Frequently asked questions