# 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)?. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.aegis.markets/part-5-dfm-dynamic-fee-mechanism/what-is-aegis-dfm.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.