How to Design a Fee Structure for Your AMM

An Automated Market Maker's (AMM) fee structure determines how trading fees are collected, distributed, and potentially used for protocol governance. The primary fee is the swap fee, a percentage charged on each trade. This fee is the main revenue source for liquidity providers (LPs) who supply assets to pools. Common swap fee tiers range from 0.01% for stablecoin pairs to 1% or more for exotic or volatile assets. The fee must be high enough to compensate LPs for impermanent loss risk, but low enough to remain competitive with other DEXs and centralized exchanges.

Beyond the base swap fee, advanced AMMs implement multi-tier or dynamic fee models. Uniswap V3 introduced concentrated liquidity, allowing LPs to set custom fee tiers (0.01%, 0.05%, 0.30%, 1.00%) per pool. Curve Finance uses a dynamic fee that adjusts based on pool imbalance, increasing as the pool deviates from its target ratio to penalize large, imbalancing trades. Some protocols also implement a protocol fee, a small cut (e.g., 10-25%) of the swap fee directed to a treasury or token stakers, as seen in Sushiswap's xSUSHI model.

When designing your fee structure, key technical parameters must be defined in the smart contract. The fee is typically applied by calculating the input amount minus the fee before the swap math. For a constant product AMM (x * y = k), the calculation in Solidity might look like:

solidityCopy
uint256 amountInWithFee = amountIn * (10000 - feeBasisPoints);
uint256 numerator = amountInWithFee * reserveOut;
uint256 denominator = (reserveIn * 10000) + amountInWithFee;
uint256 amountOut = numerator / denominator;

Here, feeBasisPoints represents the fee (e.g., 30 for a 0.30% fee). The fee is deducted from amountIn before calculating the new reserves.

Consider the economic trade-offs carefully. A high fee attracts LPs but discourages trading volume. A low fee does the opposite. Analyze your target asset pairs: stablecoin pools can sustain lower fees due to minimal impermanent loss, while new or illiquid token pairs may require higher fees to bootstrap liquidity. Also, decide on fee distribution timing—fees can be accrued as pool shares (increasing the value of LP tokens) or claimed separately. The choice impacts contract complexity and LP user experience.

Finally, incorporate upgradeability and governance. Fee parameters should not be hardcoded. Use an owner or governance mechanism to adjust fees in response to market conditions. However, changes should be transparent and gradual to maintain trust. Document the fee logic clearly for users and auditors. A robust fee structure, combined with deep liquidity, is what transforms a simple AMM contract into a sustainable financial primitive.

Designing a fee structure requires a clear understanding of your AMM's invariant function. The choice between a constant product formula (like Uniswap v2), a stable swap (like Curve), or a concentrated liquidity model (like Uniswap v3) dictates fundamental fee dynamics. Each model has different sensitivity to price impact and liquidity distribution, which directly influences how fees are earned and what fee rates are sustainable. You must decide this first.

You need to analyze the target asset pair and its typical trading behavior. A pool for a volatile ETH/USDC pair has different needs than a stablecoin USDC/USDT pool. Key metrics to research include average trade size, daily volume, and existing fee rates on leading DEXs. For example, Uniswap v3 commonly uses 0.3%, 0.05%, and 1% fee tiers, while Curve stable pools often charge 0.04%. Your fee must be competitive while covering potential impermanent loss for LPs.

The technical implementation involves modifying the core pool contract's swap function. A fee is typically taken as a percentage of the input token amount before the swap logic executes. In a simple constant product pool, the formula adjusts to k = (x + (input_amount - fee)) * y. You must decide where the fee tokens are accrued—often within the pool's liquidity reserves—and how they are distributed to liquidity providers, either pro-rata or via a separate staking mechanism.

Consider the tokenomics of your protocol's governance token. Many AMMs, like SushiSwap, use a portion of swap fees to buy back and distribute their native token or direct them to a treasury. This design choice turns the fee structure into a core component of your token's value accrual. You must model the sustainability of this outflow and its impact on LP yields versus token holder incentives.

Finally, you must plan for upgradeability and parameter adjustment. Fee structures may need to change due to market conditions. Will you use a mutable parameter controlled by a governance vote, a timelock contract, or a more complex algorithmic adjustment based on pool utilization? Smart contract security is paramount; any fee logic is a high-value target for exploits and must be thoroughly audited.

A static fee model charges a fixed percentage on every swap executed through the liquidity pool. Unlike dynamic models that adjust based on volatility or volume, static fees offer simplicity and transparency. For most AMMs like Uniswap V2 or PancakeSwap, this fee is typically between 0.05% and 0.30%, paid in the output token of the swap. The fee is deducted from the input amount before the swap calculation, directly increasing the pool's reserves and rewarding liquidity providers (LPs). This creates a clear, self-sustaining economic loop for the protocol.

Implementing the fee begins in the core swap function. The logic follows a specific sequence: first, calculate the fee amount, then deduct it from the input, and finally execute the trade with the remaining amount. Here is a simplified Solidity snippet illustrating the process:

solidityCopy
function swap(uint amountIn) external returns (uint amountOut) {
    uint fee = (amountIn * FEE_BPS) / 10000; // FEE_BPS = 30 for 0.30%
    uint amountInAfterFee = amountIn - fee;
    // ... calculate `amountOut` based on `amountInAfterFee` and pool reserves
    // ... transfer tokens and update reserves
    _mintFee(fee); // Accrue fee to LPs
}

The key is ensuring the fee is collected and allocated correctly before the constant product formula x * y = k is applied to the net input.

The accrued fees must be distributed to liquidity providers. The most common method is to permanently reinvest fees into the pool reserves. This increases the value of each LP token (like Uniswap's UNI-V2), allowing providers to realize their earnings when they burn their tokens to withdraw their share. An alternative, less common approach is to periodically claim fees in a separate transaction. The _mintFee function in the example above would handle minting new LP tokens corresponding to the fee growth, ensuring the pool's total supply reflects the added value.

When designing your fee structure, consider these key parameters: the fee percentage, the fee recipient (usually the pool itself), and the denomination (always the input token). It's critical to integrate fee logic with slippage protection; users specify a minimum output, which should be calculated after the fee is taken. Furthermore, forked codebases must ensure fee on/off switches and owner-controlled fee setters are removed or secured to prevent centralization risks and align with decentralization principles.

Static fees are best suited for general-purpose pools with stable trading pairs. Their limitations become apparent in volatile markets or for exotic assets, where a dynamic fee model might better balance LP profitability against trader cost. However, for most decentralized exchanges, a well-implemented static fee between 0.05% and 0.30% provides a robust, understandable, and battle-tested revenue mechanism that directly incentivizes the liquidity essential for a healthy marketplace.

Automated Market Makers (AMMs) generate revenue through swap fees, typically a fixed percentage of each trade. The classic 0.3% model popularized by Uniswap V2 is simple but inflexible. Modern AMMs require more sophisticated fee structures to adapt to market conditions, optimize for different asset types, and compete effectively. A fee model must achieve several goals: compensate liquidity providers (LPs) for risk, fund protocol development or treasury, and remain attractive to traders relative to competitors. The design process starts by defining your protocol's target assets (e.g., stablecoins, volatile pairs, long-tail assets) and its value proposition.

A dynamic fee model adjusts the swap fee based on real-time market data. This allows the protocol to capture more value during high-volatility periods (justifying higher LP risk) and remain competitive during calm markets. A common approach uses an oracle for volatility targeting. For instance, you could implement a formula where the fee fee = baseFee + (volatilityMultiplier * oracleVolatility). If the 24-hour volatility for an ETH/USDC pool exceeds 5%, the fee might increase from 0.05% to 0.30%. Curve Finance's tricrypto pools use a similar mechanism, adjusting fees based on internal price deviations to protect LPs from impermanent loss during market swings.

Tiered fee structures segment liquidity within a single pool, allowing LPs to choose a risk/return profile. Traders are routed to the most favorable tier, creating a competitive internal market. A basic two-tier system might offer: a low-fee tier (e.g., 0.01%) for stablecoin swaps with concentrated liquidity, and a high-fee tier (e.g., 0.30%) for wide-range, volatile asset liquidity. Uniswap V4 hooks will enable this natively, letting pool creators set custom fee logic. In code, a tiered system requires separate internal accounting for each fee tier's liquidity and a routing algorithm that finds the best effective price for the trader across all available tiers.

Implementing these models requires careful smart contract architecture. For a dynamic fee, you need a secure oracle (like Chainlink) or an internal metric (like a moving average of price changes) to feed your fee calculation. The update frequency must be gated to prevent manipulation. A tiered system is more complex, requiring a FeeTier struct that stores the fee percentage, total liquidity, and token reserves for each tier. The core swap function must iterate through tiers to compute optimal output. Always include a fee controller—a governance-managed address that can update base parameters or pause dynamic adjustments in case of market emergencies.

When designing your fee model, analyze existing protocols. For volatile pairs, consider dynamic fees pegged to volatility indexes. For stable or correlated assets, very low fixed fees (0.01%-0.05%) are standard to attract volume. Remember that fees directly impact a pool's effective price impact for traders. Use simulations and historical data to model LP returns and trader slippage under different regimes. The final structure should be transparent, difficult to manipulate, and clearly communicated to users, as fee predictability is a key component of user trust and protocol sustainability.

A protocol fee is a percentage of the trading fees generated by an AMM's liquidity pools that is diverted to a designated protocol-owned address, such as a treasury or a fee distributor contract. This mechanism, often called a "fee switch," is a critical revenue model for decentralized protocols. Unlike the standard liquidity provider (LP) fee that rewards pool contributors, the protocol fee is a claim on the protocol's underlying economic activity. Major DEXs like Uniswap (which can activate a fee switch via governance) and SushiSwap have implemented variations of this model.

Designing the fee structure requires balancing several factors. The total fee taken from a swap is split between LPs and the protocol. A common model is a 10-30-60 split: a 0.05% swap fee could be split as 0.01% (20%) to the protocol and 0.04% (80%) to LPs. Key design decisions include the fee tier (e.g., 0.01%, 0.05%, 0.30%), the protocol's share percentage, and whether fees are taken in the input token, output token, or a combination. The fee must be competitive to avoid driving volume to other pools while generating meaningful revenue.

Implementation typically involves modifying the pool's core swap function. In a constant product AMM (x * y = k), the protocol fee is calculated and withheld before the remaining amount is used in the constant product formula. Here's a simplified Solidity snippet illustrating the logic:

solidityCopy
function swap(uint amountIn, uint minAmountOut) external returns (uint amountOut) {
    uint protocolFee = (amountIn * PROTOCOL_FEE_BPS) / 10000; // e.g., 10 bps = 0.1%
    uint lpFee = (amountIn * LP_FEE_BPS) / 10000;
    uint amountInAfterFee = amountIn - protocolFee - lpFee;

    // Calculate `amountOut` using `amountInAfterFee` and constant product formula
    // ...

    _safeTransfer(PROTOCOL_TREASURY, protocolFee); // Send protocol fee
    // Add `lpFee` to pool reserves for LPs
    // Transfer `amountOut` to user
}

The fee switch itself is often a separate, upgradeable module or a governor-controlled flag that toggles the PROTOCOL_FEE_BPS from 0 to its active value.

Security and upgradeability are paramount. The fee collection address should be a multisig or a timelock-controlled contract to prevent centralization risks. The fee logic should be thoroughly audited, as errors can break the pool's invariant or allow fee theft. Consider making the fee switch permissioned (e.g., controlled by governance) and gradual; Uniswap's v3 factory allows a 10% fee switch that can be increased incrementally. This prevents sudden, drastic changes to LP economics that could cause liquidity flight.

Finally, consider the tax and regulatory implications of collecting fees, which may vary by jurisdiction. The fee switch is a powerful tool for protocol sustainability, transforming a DEX from pure infrastructure into a value-accruing business. Successful implementation requires clear communication with LPs, a transparent governance process for activation, and a well-defined use of proceeds (e.g., buyback-and-burn, treasury funding, grants) to align incentives with the protocol's long-term stakeholders.

Automated Market Maker (AMM) fee revenue is primarily generated from a percentage taken from each trade, paid by the trader and distributed to liquidity providers (LPs). The core design choices are the fee tier (e.g., 0.05%, 0.30%, 1.00%) and the distribution mechanism. The fee tier is a trade-off: lower fees attract more trading volume, while higher fees offer greater returns per trade. Protocols like Uniswap V3 use multiple, concentrated liquidity tiers to cater to different asset pairs and volatility profiles.

To model potential LP returns, you must estimate Annual Percentage Yield (APY). A simplified model is: APY = (Annual Fee Revenue) / (Total Value Locked). Annual Fee Revenue is estimated as (Daily Volume * Fee Tier * 365). For example, a pool with $1M daily volume and a 0.30% fee generates $3,000 daily, or ~$1.1M annually. If the TVL is $10M, the gross fee APY is ~11%. Real-world models must factor in impermanent loss, which can significantly offset fee earnings, especially for volatile pairs.

Advanced fee structures incorporate mechanisms to enhance sustainability. Protocol fee switches, like the one implemented by SushiSwap, allow a portion (e.g., 10-25%) of the LP fees to be diverted to the protocol treasury. This creates a revenue stream for development and security without overly penalizing LPs. Another model is dynamic fees, which adjust based on market conditions; Balancer V2's Gauntlet integration can recommend fee changes in response to volatility or arbitrage opportunities to optimize LP returns.

When designing your structure, analyze your target assets. Stablecoin pairs (e.g., USDC/USDT) tolerate very low fees (0.01%-0.05%) due to high volume and low volatility, competing on efficiency. Exotic or volatile pairs may justify 1%+ fees to compensate LPs for higher risk. Always benchmark against leading AMMs and use agent-based simulations to test fee impacts on volume, TVL, and arbitrageur behavior before deployment.

Designing an effective fee structure is an iterative process. After selecting a model—be it a static fee, dynamic model like Uniswap v3's volatility-based tiers, or a custom formula—you must implement it in your smart contracts. For a basic static fee, the core logic is a single calculation in your swap function. For example, in a Solidity-based AMM, you would deduct the fee from the input amount before calculating the output: uint256 fee = amountIn * feeBps / 10000; uint256 amountInAfterFee = amountIn - fee;. This fee is then typically added to the pool's reserves, accruing value for liquidity providers.

Thorough testing is non-negotiable. Use a development framework like Foundry or Hardhat to write comprehensive unit and integration tests. Simulate high-volume trading, edge cases like minimal swaps, and the interaction of fees with other contract functions like addLiquidity. For dynamic models, test that fee adjustments trigger correctly based on your chosen oracle data or time-weighted average price (TWAP) calculations. Failing to test fee logic is a common source of economic exploits and lost protocol revenue.

Before mainnet deployment, consider a phased rollout. Launching on a testnet allows for public feedback and bug bounties. A guarded launch or "gradual release" on mainnet, perhaps with initially capped total value locked (TVL), can mitigate risk. Monitor key metrics post-launch: fee revenue per pool, volume impact after fee changes, and LP retention rates. Tools like Dune Analytics or The Graph are essential for this analysis.

Your fee structure is not set in stone. Be prepared to iterate based on data and community governance. Many successful AMMs, like Balancer with its Gauntlet-powered fee management, use off-chain analysis and on-chain votes to adjust parameters. Document your fee logic clearly for users and developers in your protocol's documentation, and consider publishing an on-chain fee switch that allows a decentralized autonomous organization (DAO) to update parameters within safe bounds.

To dive deeper, study the source code of leading AMMs. Analyze Uniswap v2's fixed 0.30% fee, Uniswap v3's tiered (0.05%, 0.30%, 1%) structure, and Curve's stable swap model. Research papers on optimal fee setting, such as "Automated Market Making and Loss-Versus-Rebalancing" by Angeris et al., provide rigorous theoretical backing. The next step in your journey is to move from theory to a deployed, audited, and economically sustainable contract.