AMM DEX Development on Uniswap V2/V3 with Audit

When we took on the first AMM DEX for a DeFi client, a miscalculation of price impact led to a $50k loss within an hour. Since then, we double-check every formula and rely only on battle-tested patterns. Building an AMM DEX is not just writing a smart contract—it's a complex system: pricing math, MEV protection, pool economics, and UX. In this article, we break down how to build a DEX from scratch: from the constant product formula to mainnet deployment. We've already delivered DEXs for 10+ projects, with total value locked exceeding $50M. Our experience spans Ethereum, Arbitrum, Polygon, and BNB Chain. If you're planning your own DEX launch, you'll need more than code—you need market-making and security expertise. Here we share practical solutions.

Why the Constant Product Formula is Still Relevant

AMM (Automated Market Maker) replaces the traditional order book with a mathematical formula. Uniswap V2 popularized x * y = k—the product of reserves remains constant. The price of token X in units of Y is price = y / x. During a swap, the trader contributes Δx and receives Δy, accounting for a 0.3% fee. Price impact—the price shift—is directly proportional to the trade size relative to the pool. This is fundamental: large orders get poor pricing in small pools.

The formula with fee: Δy = y * Δx * (1 - fee) / (x + Δx * (1 - fee)). Despite its simplicity, it's inefficient for assets with the same price (stablecoins). That's where Curve's hybrid formula comes in.

How Concentrated Liquidity Changes Capital Efficiency

Uniswap V3 introduced concentrated liquidity: LPs specify a price range [Pa, Pb]. Outside that range, liquidity is inactive. Formulas: x = L * (1/√P - 1/√Pb), y = L * (√P - √Pa). Capital efficiency increases 100-4000x for stablecoin pairs, but LPs face a more complex impermanent loss.

AMM DEX Smart Contract Architecture

A typical architecture consists of Factory, Pair (Pool), and Router contracts. The Factory creates pools via CREATE2:

contract AmmFactory { mapping(address => mapping(address => address)) public getPair; function createPair(address tokenA, address tokenB) external returns (address pair) { require(tokenA != tokenB, "IDENTICAL_ADDRESSES"); (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA); require(token0 != address(0), "ZERO_ADDRESS"); require(getPair[token0][token1] == address(0), "PAIR_EXISTS"); bytes memory bytecode = type(AmmPair).creationCode; bytes32 salt = keccak256(abi.encodePacked(token0, token1)); assembly { pair := create2(0, add(bytecode, 32), mload(bytecode), salt) } IAmmPair(pair).initialize(token0, token1); getPair[token0][token1] = pair; getPair[token1][token0] = pair; } } 

The Pair contract is the core: it stores reserves, issues LP tokens, executes swaps with optimistic transfer and invariant check. The flash loan pattern is embedded via callback:

function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock { (uint112 _reserve0, uint112 _reserve1,) = getReserves(); if (amount0Out > 0) _safeTransfer(_token0, to, amount0Out); if (amount1Out > 0) _safeTransfer(_token1, to, amount1Out); if (data.length > 0) IUniswapV2Callee(to).uniswapV2Call(msg.sender, amount0Out, amount1Out, data); uint balance0 = IERC20(_token0).balanceOf(address(this)); uint balance1 = IERC20(_token1).balanceOf(address(this)); uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0; uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0; require(amount0In > 0 || amount1In > 0, "INSUFFICIENT_INPUT_AMOUNT"); uint balance0Adjusted = balance0 * 1000 - amount0In * 3; uint balance1Adjusted = balance1 * 1000 - amount1In * 3; require(balance0Adjusted * balance1Adjusted >= uint(_reserve0) * _reserve1 * 1000**2, "K"); _update(balance0, balance1, _reserve0, _reserve1); } 

The Router contract provides multi-hop routes, slippage protection, and deadline.

MEV and Reentrancy Protection

A classic sandwich attack: an MEV bot inserts a buy before the victim's swap and a sell after. Protection: Slippage tolerance—the user sets a maximum price impact; private mempool (Flashbots); commit-reveal schemes; batch auctions (CoW Protocol)—all orders executed at a single price.

Reentrancy protection: the mutex lock uses a single storage slot, saving ~2300 gas compared to OpenZeppelin's ReentrancyGuard.

uint private unlocked = 1; modifier lock() { require(unlocked == 1, "LOCKED"); unlocked = 0; _; unlocked = 1; } 

Tokenomics and Governance

We recommend a two-tier fee structure: LP fee (0.3%) + protocol fee (0.05%), even if the protocol fee is initially turned off. Governance tokens are distributed via liquidity mining using the MasterChef pattern (SushiSwap). Simplified formula: pendingReward = userLPBalance * (accRewardPerShare - userRewardDebt) / 1e12.

Frontend and UX

Critical components: swap interface with real-time price impact, liquidity management with range visualization (for V3), charts via The Graph, wallet integration (wagmi + viem, WalletConnect v2), transaction simulation through Tenderly.

How to Deploy an AMM DEX in 5 Steps

1. Develop smart contracts (Factory, Pair, Router) with Foundry tests.
2. Security audit (Slither, Mythril, Echidna) and formal verification.
3. Deploy to testnet, integrate with frontend.
4. Test liquidity pools with real tokens.
5. Deploy to mainnet, set up monitoring (Tenderly, Etherscan API).

What's Included in AMM DEX Development

Why Order Development from Us?

We guarantee code quality and audit readiness. Our track record—over 10 successful DEX projects, including Layer 2 integrations (Arbitrum, Optimism). We use proven patterns and libraries. Uniswap V2 Whitepaper is the foundation we adapt to your needs. Automated Market Maker is the key mechanism at the core. Contact us for a free consultation and project evaluation. Order turnkey AMM DEX development—from idea to deployment and support.