> For the complete documentation index, see [llms.txt](https://docs.aegis.markets/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aegis.markets/part-5-dfm-dynamic-fee-mechanism/what-is-aegis-dfm.md).

# What is AEGIS DFM?

AEGIS DFM — Dynamic Fee Mechanism — is a Uniswap v4 hook that replaces a pool's static fee tier with a two-component dynamic fee, and automatically compounds a share of trading fees into protocol-owned full-range liquidity.

DFM is the longest-running, most battle-tested component of AEGIS. It predates Engine, ships with its own audit coverage (Spearbit / Cantina), and runs as a standalone v4 hook on its own. Pools can use DFM without Engine; Engine pools always include DFM behavior.

### What it does, in one paragraph

When a swap hits an AEGIS-enabled pool, the DFM hook quotes a fee that depends on two things: a base fee that tracks the pool's realized volatility over a medium horizon, and a surge fee that spikes briefly after sudden price moves and decays back toward zero. Both are computed entirely from pool state (ticks, block timestamps) — no external feeds. A configurable share of every fee is redirected into a protocol-owned full-range position, which grows pool depth over time. The rest flows to LPs as normal.

The practical effect: LPs capture more of the economic surplus during volatile periods, without actively managing their positions, and the pool's long-run liquidity depth grows with its own trading activity.

### The components

DFM is five contracts, each with a focused responsibility:

1. Spot.sol — the Uniswap v4 hook itself. Orchestrator. Installed as the pool's hooks address.
2. DynamicFeeManager.sol — the fee engine. Computes and stores per-pool fee state (baseFeePPM, surgeFeePPM, inCap, budget counters).
3. TruncGeoOracleMulti.sol — the adaptive truncated-geometric-mean oracle. Produces the tick observations that drive the base fee formula and enforces a max-ticks-per-block (MTB) cap.
4. PoolPolicyManager.sol — the policy registry. Stores per-pool risk parameters, fee splits, cap budgets, and step-engine settings.
5. FullRangeLiquidityManager.sol — the POL vault. Compounds a share of collected fees into the pool's full-range position.

They compose roughly like this:

Trader → PoolManager → Spot (hook)

                         ├─→ DynamicFeeManager.prepareSwap()  // quote fee

                         ├─→ TruncGeoOracleMulti.push()       // record observation

                         ├─→ DynamicFeeManager.finalizeSwap() // update fee state

                         └─→ FullRangeLiquidityManager.reinvest()  // POL compound

Policy parameters flow from PoolPolicyManager into all of the above at configuration time.

Each contract has its own one-pager in the AEGIS\_DFM/docs/one\_pagers/ directory with storage layout, invariants, and gas notes. For auditors, the AEGIS\_Statement\_of\_Intended\_Behavior.md in that same repo is the canonical behavioral spec.

### Why a hook, not a patch to Uniswap

Uniswap v4's core design lets hooks alter almost every lifecycle event of a pool — initialize, modify-liquidity, swap, donate — without modifying v4 itself. DFM uses this to:

* Quote a pool-specific fee per swap (instead of a static fee tier).
* Record observations into its own oracle (not v4's built-in oracle).
* Steer a configurable share of collected fees to the POL vault.
* Update fee state after each swap.

Because it's a hook, DFM is opt-in at pool-creation time. Pools that don't install the AEGIS hook behave like vanilla Uniswap v4 pools; pools that do inherit everything described here.

### The two-fee idea, intuitively

A static fee tier is a flat line. At the 30 bp tier, every swap pays 30 bp, regardless of the pool's volatility. This over-charges during calm markets (routers send flow to lower-fee venues) and under-charges during volatile markets (LPs eat adverse selection that the fee doesn't cover).

DFM's fee is not flat. It has two components:

* Base fee: a slow-moving number that follows realized volatility. In calm conditions it drifts low; in sustained volatility it rises. The step cadence and step size are both governed by policy.
* Surge fee: a fast-moving spike that fires on sudden volatility — specifically when a single-block price move exceeds the oracle's MTB cap. Surge adds multiplicatively to base, then decays linearly over a configured period (default 6 hours).

Because both components are computed from observable pool state, the fee automatically adapts to conditions. An LP doesn't choose a tier and hope; the pool itself finds the right fee.

### The POL story

A configurable share of every fee collected on an AEGIS-enabled pool is redirected into a protocol-owned full-range liquidity position managed by FullRangeLiquidityManager. Over time, this accumulates:

* Deeper full-range liquidity on the pool.
* Aligned interests between the protocol and LPs — POL grows when trading volume grows, and it grows without issuing new tokens.
* A natural backstop of liquidity that won't leave during volatility (protocol doesn't manage short-term LP positions).

In Engine pools, the POL is the same pooled full-range position that backs sL shares. The two stories are unified: the DFM's POL compounding mechanism and Engine's sL equity accretion are the same event, counted from different angles.

### What DFM is not

A few clarifications:

* Not a MEV extractor. DFM doesn't front-run, doesn't sandwich, doesn't route flow anywhere. It adjusts the fee on each pool independently.
* Not a rebalancer. DFM never moves LP positions. The POL is full-range; individual LPs manage their own positions.
* Not a liquidity bootstrapper. The POL grows from trading volume, not from token issuance or TVL incentives.
* Not an oracle for other protocols (directly). The TruncGeoOracleMulti exposes observe/consult views that external consumers can use, but its primary purpose is driving DFM's own fee formula.

### When to use DFM without Engine

Protocols, DAOs, and aggregators can install the DFM hook on a pool without ever touching Engine. Typical reasons:

* Better LP capture on a niche pair. If the pair has volatile windows and a static tier is leaving money on the table, DFM can improve LP economics without rebuilding the pool.
* Campaign pools. Launch a pool with a specific fee trajectory (high initial, decaying base, surge-on-volatility) via policy-manager configuration.
* Protocol-owned liquidity growth. Allocate a share of every swap to POL and grow the book organically.

### When Engine adds value

If a pool has:

* Meaningful volume (enough to generate lending demand).
* A borrower constituency (strategies, LPs, arbitrageurs who want to unlock liquidity without closing positions).
* No existing oracle path for lending (because oracle dependence is what borrowers are trying to avoid).

…then enabling Engine on top of DFM adds a second revenue stream for LPs (interest) and a primitive (pool-native credit) for borrowers. For the mechanics, see [What is AEGIS Engine](/part-1-start-here/what-is-aegis.md)?.