A decentralised exchange looks simpler than a centralised one. There is no custody stack, no onboarding pipeline, no withdrawal approval flow.
What replaces them is harder in a different way: code that holds value, is public, is immutable once deployed, and is being actively probed by people who profit from finding a mistake.
AMM or order book
This is the first fork and it shapes everything after.
Automated market makers price trades against a pool using a formula. Liquidity exists as soon as someone deposits, with no market makers required. The cost is capital inefficiency and impermanent loss for providers, and worse pricing on large trades.
Order books match bids and asks the way a traditional venue does. Better pricing, familiar to serious traders, and much harder on-chain because every order placement and cancellation is a transaction. Viable on fast chains or hybrid designs where matching happens off-chain and settlement on-chain.
Most new token markets need an AMM, because the honest problem is that nobody is making a market in your pair yet. Mature markets with real volume can support a book.
Which chain
The chain decision is a distribution decision more than a technical one.
Deploy where your users already hold assets. A technically superior chain with none of your audience on it produces an elegant DEX nobody trades. Bridging friction is real and most users will not cross it for a venue they have not heard of.
Practical considerations: transaction cost determines whether small trades make sense, block time determines how bad MEV exposure gets, and existing DeFi depth determines whether your pools can route through anything else.
Bootstrapping liquidity
The uncomfortable truth is that incentives buy depth and do not buy retention.
Liquidity provider rewards work — capital arrives quickly and the book looks healthy. Then rewards taper and most of that capital leaves, because it was never there for the trading.
What retains depth is volume, and volume comes from either a pair people genuinely want to trade or a structural advantage: better routing, lower fees, an asset unavailable elsewhere.
So design the end state first. What makes an LP stay when rewards stop? If there is no answer, the incentive programme is buying a number rather than a market.
MEV is a design decision
On most chains, the default behaviour exposes your users to sandwich attacks. A trader submits a swap, a searcher front-runs it, and the user gets a worse price.
This is not a bug you patch later — it is a property of how the chain orders transactions, and the DEX has to design around it:
- Slippage protection with sensible defaults rather than a field users ignore.
- Private transaction routing where the chain supports it.
- Batch auctions or frequent batch clearing, which remove ordering advantage entirely.
Users rarely understand MEV and reliably notice that their fills are worse than quoted.
Oracles, where relevant
Pure AMMs do not need price oracles. Anything with leverage, lending or liquidations does, and the oracle becomes the most attacked component in the system.
Use established providers with multiple independent sources, apply sanity bounds so an impossible print cannot trigger liquidations, and design what happens when the feed is stale — because at some point it will be.
Where the effort actually goes
Not the swap contract. That part is well-understood and largely a matter of building carefully on audited standards.
The effort concentrates in:
- Routing, finding the best path across pools and chains.
- The subgraph and indexing layer, which makes the front end usable and is invariably underestimated.
- The web application, where wallet connection, transaction states and error handling decide whether people trust the venue.
- LP tooling, position management and analytics for the people supplying your depth.
Before mainnet
Minimal custom code on top of audited standards. Two independent third-party audits, with remediation and re-review before deployment. Formal verification on anything where a bug is unrecoverable. A bug bounty live before meaningful value arrives.
Immutable means immutable. Everything that is expensive to get wrong has to be got right the first time.
Common questions
What is the difference between a CEX and a DEX?
A centralised exchange holds user funds and matches orders on its own infrastructure. A decentralised exchange settles trades through smart contracts while users keep custody of their assets throughout. The trade is real in both directions: a CEX gives you speed, depth and recourse when something goes wrong; a DEX gives you self-custody and composability with the rest of on-chain finance.
Should a DEX use an AMM or an order book?
An AMM when you need liquidity to exist from day one without market makers, which is most new token markets. An order book when your users are sophisticated traders who expect limit orders, tight spreads and depth they can read. Order books on-chain are viable on fast chains and hybrid designs; on slower chains the economics rarely work. Many serious DEXs run both models for different asset classes.
How does a new DEX get liquidity?
Through incentive design in the early period and genuine trading demand after it. Liquidity provider rewards bootstrap depth, but rewards alone attract capital that leaves the moment they stop. What keeps depth is real volume, which comes from either a token pair people actually want to trade or a structural advantage such as better routing or lower fees. Plan for what happens when incentives end, before they start.
What are the main risks in DEX development?
Smart contract bugs, oracle manipulation, and MEV. Contract bugs are addressed through minimal code built on audited standards plus independent third-party review. Oracle risk is addressed by using established providers with multiple sources and sanity bounds. MEV requires deliberate design choices around ordering and slippage protection, because the default behaviour on most chains exposes users to sandwich attacks.
Does Corum8 build DEXs?
Yes. We build AMM and order-book DEXs, routing and aggregation layers, LP incentive mechanics, the web application and subgraph, and coordinate independent third-party audits before mainnet. We have been building on-chain systems since 2016 with 95+ specialists.
