How to Implement Automated Market Maker (AMM) Logic

An Automated Market Maker (AMM) is a decentralized exchange protocol that uses a mathematical formula to price assets. Instead of matching buy and sell orders in an order book, traders swap tokens against a liquidity pool, a smart contract holding reserves of two or more tokens. The most common formula is the constant product invariant x * y = k, popularized by Uniswap V2. Here, x and y represent the reserves of two tokens in the pool, and k is a constant. When a trader buys token y with token x, the pool's x increases and y decreases, but their product must always equal k. This relationship automatically determines the swap price and creates slippage: larger trades cause greater price impact.

Implementing a basic constant product AMM requires calculating the output amount for a given input. The formula Δy = (y * Δx) / (x + Δx) determines how much token y (Δy) a user receives for depositing Δx of token x. A 0.3% fee is typically deducted from the input amount before the swap calculation. In Solidity, the core swap function involves ensuring the invariant k is maintained after fees and verifying the pool has sufficient reserves. Developers must also implement liquidity provision functions that allow users to deposit paired assets in the correct ratio to mint LP tokens, which represent their share of the pool.

For stablecoin pairs (e.g., USDC/DAI), the constant product model creates excessive slippage. Stable swap AMMs like Curve's Stableswap use a hybrid invariant: A * (x + y) + (x * y) = A * (D^2) + (D^3 / (4*x*y)). This formula creates a "flatter" curve within a price range near 1:1, offering significantly lower slippage for like-valued assets. The variable A is an amplification coefficient set by governance; a higher A makes the curve flatter. Implementing this requires more complex math, often using the Newton's method for approximation within the contract to solve for D (the total liquidity) and output amounts.

Critical considerations for AMM implementation include security and gas optimization. Reentrancy guards (using Checks-Effects-Interactions pattern or OpenZeppelin's ReentrancyGuard), proper decimal handling (e.g., using 1e18 for scaling), and overflow protection are essential. For production, most developers fork and customize audited codebases like Uniswap V2's core contracts or the Vyper-based Curve pool contracts. Understanding these core mechanics is the first step to building advanced DeFi primitives like concentrated liquidity (Uniswap V3) or integrating AMM logic into broader protocols for lending or derivatives.

To implement AMM logic, you must first understand the underlying blockchain infrastructure. This requires proficiency in a smart contract language like Solidity (for Ethereum and EVM chains) or Rust (for Solana). You'll need to be comfortable with concepts like state variables, functions, and events. Familiarity with development frameworks such as Hardhat, Foundry, or Anchor is essential for testing and deployment. A working knowledge of token standards, particularly ERC-20, is non-negotiable, as AMMs primarily facilitate trades between these fungible assets.

The mathematical core of an AMM is its bonding curve, which defines the relationship between the reserves of two tokens in a pool. The most common model is the Constant Product Market Maker (x * y = k), popularized by Uniswap V2. In this model, the product of the quantities of two tokens (x and y) must remain constant (k) before and after a trade, which automatically determines the price. Understanding this formula, along with concepts like slippage (price impact of a trade size) and impermanent loss (divergence loss for liquidity providers), is critical for implementing swap and liquidity functions correctly.

You will need to interact with existing contracts and infrastructure. This includes knowing how to use oracles like Chainlink for price feeds if your AMM requires external price data, and understanding decentralized governance mechanisms if the protocol will be community-owned. Security is paramount; you must be adept at writing secure code to prevent common vulnerabilities like reentrancy attacks, integer overflows, and front-running. Auditing your code or using formal verification tools should be part of your development lifecycle.

Finally, practical implementation involves designing several key smart contract components: a factory contract to deploy new liquidity pools, a pair/pool contract that holds reserves and executes swaps, and a router contract that handles the complex logic for user-facing operations (e.g., adding liquidity with optimal token ratios). You should study the source code of established AMMs like Uniswap V2 (for its elegant simplicity) or Uniswap V3 (for concentrated liquidity) to see these patterns in action.

At the heart of an Automated Market Maker (AMM) is a simple, deterministic mathematical rule. The Constant Product Formula states that for a liquidity pool containing two assets, X and Y, the product of their quantities must remain constant. This is expressed as x * y = k, where x is the reserve of token X, y is the reserve of token Y, and k is the constant product. This invariant ensures that as one token is purchased from the pool, its reserve decreases, causing its price relative to the other token to increase non-linearly. This mechanism of bonding curves automatically adjusts prices based on supply and demand without an order book.

To calculate the output amount when swapping, you solve the invariant. If a trader wants to swap Δx amount of token X for token Y, the new reserve of X becomes x + Δx. To keep k constant, the new reserve of Y must be y' = k / (x + Δx). The amount of Y the trader receives, Δy, is the difference: Δy = y - y'. This yields the core swap formula: Δy = y - (k / (x + Δx)). This calculation is performed on-chain for every trade, and the resulting price impact increases with the size of the trade relative to the pool's liquidity.

Implementing this in a smart contract involves managing the reserves and enforcing the invariant. Below is a simplified Solidity code snippet demonstrating the core logic. The contract updates the reserve state after verifying the trader has supplied sufficient input tokens and that the output amount is positive.

solidityCopy
// Simplified AMM swap function (no fees)
function swap(uint amountXIn) public returns (uint amountYOut) {
    uint newReserveX = reserveX + amountXIn;
    // Calculate new reserveY using constant product formula: k = x * y
    uint newReserveY = (reserveX * reserveY) / newReserveX;
    // Amount of Y to send to trader
    amountYOut = reserveY - newReserveY;
    // Update state reserves
    reserveX = newReserveX;
    reserveY = newReserveY;
}

In production AMMs like Uniswap, a 0.3% trading fee is added to the model. This fee is deducted from the input amount before the swap calculation, and the fee liquidity is added back to the reserves, incrementally increasing k and rewarding liquidity providers. The formula with a fee φ (e.g., 0.003) becomes: (x + Δx * (1 - φ)) * (y - Δy) = k. This small modification is crucial for sustainability, as it ensures the pool is not depleted by arbitrageurs and generates yield from trading volume. The fee also affects the effective exchange rate received by the trader.

Understanding this model is key to analyzing impermanent loss and pool dynamics. When the external market price of the two assets diverges, arbitrageurs trade against the pool to rebalance its price, changing the ratio of reserves. Liquidity providers own a share of both reserves, so their portfolio value compared to simply holding the assets can decrease—this is impermanent loss. The Constant Product Formula's convex curve shape dictates the magnitude of this loss, which is highest for large price movements. Developers use this model to simulate returns and risks when designing or interacting with DeFi protocols.

An AMM pool contract manages two token reserves and defines the pricing algorithm. The most common is the constant product formula popularized by Uniswap V2, where the product of the two reserve amounts must remain constant before and after a trade (reserveA * reserveB = k). This formula determines the exchange rate: the price impact of a trade increases non-linearly as the pool's liquidity is depleted. The contract must also track the total supply of liquidity provider (LP) tokens, which represent a share of the pooled assets.

The contract requires several key functions. The swap function allows users to trade one token for another, updating the reserves according to the formula and charging a small fee (e.g., 0.3%) that is added to the reserves. The mint function issues new LP tokens when a user adds liquidity, calculating the amount based on the current reserves to maintain fair ownership. Conversely, the burn function destroys LP tokens and returns the proportional share of both underlying tokens to the user who is removing liquidity.

A critical implementation detail is the handling of the initial liquidity deposit. The first depositor sets the initial price ratio. To prevent manipulation, many protocols, like Uniswap V2, lock a minimum amount of LP tokens (sent to address zero) on the first mint. All subsequent price calculations and LP token minting are based on the updated k constant. The contract must also implement a flash loan-resistant design by performing all balance checks and state updates within a single transaction.

Here is a simplified Solidity snippet for the core swap logic, excluding fees for clarity:

solidityCopy
function swap(uint amountAOut, address to) external {
    uint reserveA = reserve0;
    uint reserveB = reserve1;
    require(amountAOut < reserveA, "Insufficient liquidity");
    
    uint amountBIn = getAmountIn(amountAOut, reserveA, reserveB);
    require(IERC20(tokenB).transferFrom(msg.sender, address(this), amountBIn), "Transfer failed");
    
    _update(reserveA - amountAOut, reserveB + amountBIn);
    require(IERC20(tokenA).transfer(to, amountAOut), "Transfer failed");
}

function getAmountIn(uint amountAOut, uint reserveA, uint reserveB) internal pure returns (uint amountBIn) {
    // amountBIn = (reserveB * amountAOut) / (reserveA - amountAOut)
    amountBIn = (reserveB * amountAOut) / (reserveA - amountAOut);
}

Security is paramount. The contract must guard against common vulnerabilities: - Reentrancy attacks: Use the checks-effects-interactions pattern. - Rounding errors: Favor integer math and decide on rounding direction (always in favor of the pool). - Oracle manipulation: If the pool price is used as an oracle, consider implementing a time-weighted average price (TWAP) like Uniswap V2. The contract should also emit standard events (Swap, Mint, Burn) for off-chain indexing and user interface updates.

After deploying the core pool contract, the next step is to build a factory contract that can create instances of these pools for any ERC-20 token pair. This factory ensures a single canonical pool for each pair, manages the pair addressing scheme (often using create2), and serves as a registry for the entire protocol's liquidity.

At the heart of every AMM is the constant product formula: x * y = k. Here, x and y represent the reserves of two tokens in a liquidity pool, and k is a constant. This invariant ensures that the product of the reserves remains unchanged before and after a trade. When a user swaps token A for token B, they deposit Δx of token A into the pool. To maintain the constant k, the pool must calculate and output Δy of token B, where (x + Δx) * (y - Δy) = k. The resulting amount is derived by solving for Δy: Δy = y - (k / (x + Δx)).

Implementing this in a smart contract requires handling fees and preventing rounding errors. A standard approach deducts a protocol fee (e.g., 0.3%) from the input amount Δx before the swap calculation. The fee is kept in the pool, incrementally increasing the value of k and rewarding liquidity providers. The core swap function must also account for slippage, which is the difference between the expected and actual output price due to the trade's size relative to pool liquidity. Contracts typically require a user to specify a minimum output amount to protect against front-running and excessive slippage.

Here is a simplified Solidity function outline for a swap:

solidityCopy
function swap(uint amountIn, uint minAmountOut) external {
    uint fee = amountIn * protocolFee / 10000;
    uint amountInAfterFee = amountIn - fee;
    uint newReserveX = reserveX + amountInAfterFee;
    uint newReserveY = constantK / newReserveX;
    uint amountOut = reserveY - newReserveY;
    require(amountOut >= minAmountOut, "Slippage too high");
    // Update reserves and transfer tokens...
}

This logic ensures the pool's invariant is maintained, fees are collected, and users are protected from unfavorable trades.

Beyond the basic constant product model, advanced AMMs implement concentrated liquidity (like Uniswap V3) or stable swap curves (like Curve Finance). Concentrated liquidity allows liquidity providers to set custom price ranges, making capital efficiency the primary innovation. The swap math becomes more complex, involving virtual reserves and piecewise calculations within ticks. Understanding the foundational x*y=k model is essential before exploring these advanced designs, as they all build upon the same core principles of invariant preservation and fee mechanics.

The core of an Automated Market Maker (AMM) is its invariant function, which defines the mathematical relationship between the assets in a pool. The most common model is the constant product formula x * y = k, where x and y are the reserves of two tokens and k is a constant. This formula ensures that the product of the reserves remains unchanged by trades, creating a predictable price curve where price is the ratio of the reserves. When a liquidity provider (LP) deposits assets, they must do so in a ratio that maintains the current price, minting them new LP tokens representing their share of the pool.

To implement deposit logic, your smart contract must calculate how many LP tokens to mint. First, determine the pool's total supply of LP tokens. If it's the first deposit, the minted amount is sqrt(reserveA * reserveB). For subsequent deposits, the amount is (amountA / reserveA) * totalSupply. The contract must enforce that the user deposits both tokens in the exact current reserve ratio to prevent dilution. A critical check is ensuring the minted tokens are greater than zero to avoid locking funds. Uniswap V2's UniswapV2Pair.sol is the canonical implementation of this logic.

The withdrawal function is the inverse. A user burns their LP tokens to redeem their proportional share of both reserve assets. The amount of each token returned is calculated as (liquidity / totalSupply) * reserveA and (liquidity / totalSupply) * reserveB. The contract must transfer these amounts to the user and safely burn the LP tokens. Always perform these transfers after updating the internal state reserves to prevent reentrancy attacks, a best practice formalized in the Checks-Effects-Interactions pattern. This ensures the contract's state is consistent before any external calls.

Beyond basic deposits, consider implementing features like protocol fees. Many AMMs collect a small fee (e.g., 0.05%) on trades, which is distributed to LPs. This can be done by inflating the value of k over time or by minting extra LP tokens to a fee address. Furthermore, your contract must accurately track accumulated fees per LP position, which is complex without external helper contracts. Many modern AMMs use concentrated liquidity, which requires tracking fees per tick or price range, a significant increase in logic complexity compared to the simple constant product pool described here.

When testing your implementation, focus on edge cases: the first deposit, tiny deposits that round to zero LP tokens, massive deposits that could overflow calculations, and withdrawals that drain the pool. Use a framework like Foundry or Hardhat to simulate these scenarios. The security of the liquidity provision logic is paramount, as bugs can lead to permanent loss of user funds. Always audit your code or use well-audited libraries like the Solidity SDK from Uniswap Labs.

An Automated Market Maker (AMM) is a decentralized exchange protocol that uses a mathematical formula to price assets. The most common model is the constant product formula x * y = k, where x and y are the reserves of two tokens in a pool, and k is a constant. This invariant ensures that the product of the reserves remains unchanged by trades. When a user swaps token A for token B, they add Δx to the x reserve and receive Δy from the y reserve, causing the price to move along a bonding curve. The core swap logic calculates the output amount based on this invariant and an applied fee.

Implementing the swap function requires precise calculation to maintain the invariant and deduct fees. First, calculate the output amount Δy a user should receive for an input Δx before fees: Δy = y - (k / (x + Δx)). A protocol fee (e.g., 0.05% for Uniswap v2) is then applied. This is typically deducted from the input amount, so the actual Δx used in the invariant calculation is reduced. The fee is added to the pool's reserves, incrementally increasing the value of each liquidity provider's (LP) share. This mechanism ensures LPs are compensated for impermanent loss and providing capital.

Liquidity providers earn fees proportional to their share of the pool. When an LP deposits assets, they receive LP tokens, which represent a claim on the pool's underlying reserves and accrued fees. The exchange rate of LP tokens increases as fees accumulate. For example, if an LP owns 10% of the pool's LP tokens, they are entitled to 10% of the total reserves upon withdrawal, which will be larger than their initial deposit due to collected fees. This automated fee distribution is the primary incentive for LPs. Smart contracts must accurately track total LP token supply and calculate share values using reserve balances.

A basic Solidity implementation highlights these concepts. The swap function would: 1) Ensure input amount > 0, 2) Calculate k from current reserves, 3) Deduct fee from input amount (e.g., inputAmount * 997 / 1000 for a 0.3% fee), 4) Calculate new reserve of input token, 5) Solve the constant product formula for the output token amount, 6) Update reserves and transfer tokens. The mint function for adding liquidity calculates LP tokens based on the deposit's proportional value relative to existing reserves, protecting LPs from dilution.

Advanced AMMs like Uniswap v3 introduce concentrated liquidity, allowing LPs to provide capital within specific price ranges. This increases capital efficiency but requires more complex logic to track multiple liquidity positions and fees accrued within each tick interval. The fee calculation must aggregate earnings across all active ticks where a swap occurred. Understanding the basic constant product model is essential before tackling these advanced implementations, as they build upon the same core principles of invariant preservation and fee-based LP incentives.

The constant product formula x * y = k is the cornerstone of AMMs like Uniswap V2. By maintaining this invariant, the pool provides continuous liquidity, with prices determined algorithmically by the ratio of the two reserve assets. Your implementation should include precise, overflow-protected calculations for getAmountOut to determine swap outputs and getAmountIn for required input amounts, using integer math to avoid floating-point errors.

For production, this basic logic must be extended with critical security and economic features. Implement a protocol fee mechanism (e.g., a 0.05% fee sent to a treasury), a deadline parameter to protect users from stale transactions, and slippage tolerance checks. You must also add events for all state changes (Swap, Mint, Burn) to allow off-chain indexers to track pool activity, which is essential for front-ends and analytics.

Next, integrate your AMM logic with a user interface. Use a library like ethers.js or viem to connect to your deployed contract. A basic UI needs functions to: approve token spends, addLiquidity, removeLiquidity, and swapExactTokensForTokens. For price displays, call the getReserves function and calculate the current price as reserve1 / reserve0.

To deepen your understanding, study the source code of established AMMs. The Uniswap V2 Core contracts are the canonical reference for the constant product model. For more advanced concepts, examine Uniswap V3 with its concentrated liquidity or Balancer V2 with its weighted pools and asset manager architecture.

Finally, consider the broader ecosystem. Your AMM can be composed with other DeFi primitives: use it as a price oracle for lending protocols, integrate flash loans for arbitrage, or allow liquidity positions to be tokenized as NFTs for use in other financial applications. The constant product AMM is a foundational building block for decentralized finance.