Onchain Atlas

Dynamic Fees

Instead of charging every trade the same fixed percentage, the exchange adjusts its fee in real time based on market conditions like volatility or trading volume.

Also called: adaptive fees · variable trading fees · volatility-scaled fees

What it is

Dynamic fees are a design where the trading fee charged by a decentralized exchange (DEX) changes automatically instead of staying fixed (like a flat 0.3% on every trade). The fee moves up or down based on measurable conditions — recent price volatility, how much volume is flowing through the pool, or how imbalanced the pool has become — so the exchange can charge more when trading is risky for liquidity providers and less when it's calm and trading should be encouraged.

How it works

  1. A liquidity pool holds two (or more) assets that traders swap against, and liquidity providers (LPs) earn a cut of every trade as their incentive to supply capital.
  2. The protocol tracks some real-time signal — recent price volatility, trade size relative to pool depth, order flow imbalance, or time since the last trade — as an input to a fee formula.
  3. Before each swap executes, the contract (or an attached "hook" module in newer AMM designs) recalculates the fee rate based on the current value of that signal.
  4. During calm, balanced markets, the fee stays low to attract volume and stay competitive with other venues.
  5. During high volatility or when a large directional trade risks moving the price a lot, the fee rises — compensating LPs for the extra risk they take on (informed traders exploiting stale prices, a problem known as adverse selection or "loss-versus-rebalancing").
  6. The elevated fee is collected the same way a normal fee would be, added to the pool or distributed to LPs, just recalculated dynamically rather than fixed at pool creation.
  7. Some designs let the fee adjust asymmetrically depending on trade direction, further discouraging exactly the trades that would hurt LPs most at that moment.
  8. Because the formula runs on-chain and reads on-chain data (or a combination of on-chain state and permissioned oracle input), no human sets the fee in real time — it's fully rule-based.

Why designers use it

  • Reduces the "adverse selection tax" LPs pay to arbitrageurs who trade against stale prices right after volatility spikes, by charging those trades more.
  • Keeps fees competitively low during quiet markets so a pool doesn't lose ordinary trading volume to cheaper venues.
  • Lets a single pool serve both quiet, tight-spread trading and volatile, wide-spread trading without needing separate pools for each regime.
  • Can be tuned per asset pair, letting exotic or highly volatile pairs charge structurally higher baseline fees than stable pairs.

Failure modes

  • Formula gaming: if the fee formula is predictable and reacts to observable on-chain signals, sophisticated traders can structure trades (splitting, timing, or triggering the signal first) to land in a lower-fee window.
  • Oracle or signal manipulation: if the volatility/volume signal itself can be manipulated (e.g., via a flash loan moving price briefly), an attacker could force the fee down right before executing a large trade.
  • LP unpredictability: because fees change constantly, LPs have a harder time estimating expected yield, which can deter participation compared to a simple fixed-fee pool.
  • Overcorrection lag: if the fee formula reacts to volatility with a delay, it may raise fees only after the risky trade has already happened, protecting LPs too late.
  • Complexity risk: more moving parts in the fee logic (especially external "hooks" or plugins) mean a larger attack surface and more ways a bug can misprice trades.

What to check before using it

  • Decide which signal (volatility, imbalance, volume, time-since-last-trade) actually correlates with the risk you're trying to price, and validate it against historical data before deploying.
  • Check whether the signal your formula reads can be manipulated within a single transaction or a short window, and if so, harden it (time-weighted averages, multi-block confirmation).
  • Model LP returns under both calm and volatile regimes to confirm the dynamic range of fees genuinely compensates for the extra risk rather than just adding complexity.
  • Consider how the fee logic interacts with other protocol features (hooks, routers, aggregators) that may not anticipate a moving fee.
  • Publish the fee formula and its current inputs transparently, since traders and LPs both need to reason about pricing to use the pool confidently.

Experiments that used it · 3

Shown oldest first, so you can watch the design evolve.

Ambient Finance
A single-contract DEX (formerly CrocSwap) that fused full-range, concentrated, and knockout limit-order liquidity into one AMM — technically ahead of Uniswap v4 but commercially eclipsed after points-driven TVL evaporated.
2023 technically successful commercially unsuccessful
Meteora DLMM
Solana liquidity protocol that replaced continuous concentrated-liquidity curves with discrete, zero-slippage price bins and per-bin dynamic fees, becoming a dominant venue for memecoin and token-launch liquidity before its co-founder resigned amid insider-trading allegations tied to the LIBRA memecoin collapse.
2023 ongoing
Uniswap V4 Hooks
A programmable AMM architecture that lets developers attach custom smart-contract logic ('hooks') to liquidity pools at key lifecycle points, turning Uniswap from a fixed AMM into an extensible platform.
2025 major success