# Why AEGIS Exists Two problems in DeFi keep recurring. AEGIS is built to address both inside a single, pool-native design. ### Problem 1: Static fees under-compensate liquidity providers Uniswap pools charge a fixed fee tier — typically 5, 30, or 100 basis points — regardless of what the market is doing. In practice, market conditions are not fixed. Volatility, volume, and adverse selection all fluctuate constantly, and a static fee is essentially a bet that the average pair behavior is a good match for the fee tier. When markets are calm, a 30 bp fee is often too high to attract the best routing flow. When markets are volatile, the same 30 bp is often too low to compensate the LP for the loss-versus-rebalancing (LVR) they are absorbing. The result is well-documented: professional LPs have migrated from passive positions into concentrated liquidity, active management, and off-chain hedging — solutions that are either capital-intensive, operationally complex, or only available to sophisticated participants. AEGIS DFM addresses this by making the fee itself a function of the pool's observable state. A slow-moving base component tracks realized volatility; a fast-moving surge component spikes during rapid price moves and decays over time. Both components are computed from pool ticks and block timestamps — no external price feeds — and a configurable share of collected fees is compounded into a protocol-owned full-range position, deepening the book over time. The core mechanism claim is simple: a fee that adapts to volatility captures more of the economic surplus that a static fee leaves on the table. ### Problem 2: Credit systems depend on oracles they shouldn't Most on-chain lending and margin systems price their collateral using an external oracle — a Chainlink feed, a TWAP from another venue, a ratio between two vaults. This design has a structural weakness that has produced most of the catastrophic failures in DeFi credit: * If the oracle lags real-time price, arbitrageurs extract value at the cost of healthy positions. * If the oracle leads, benign price action triggers liquidations that wouldn't have been necessary. * If the oracle can be manipulated — even briefly, even on a thin venue — the entire book can be liquidated at a price nobody actually trades at. The cascading failure mode looks like this: an oracle ticks in one direction; liquidations fire at the oracle price; liquidation sell-pressure pushes the real market in the same direction; the oracle ticks again; more liquidations fire; the cascade accelerates until liquidity is exhausted. Users who were nowhere near the "true" liquidation boundary lose their collateral. The design rationale for this structure — "we need a price" — has always been in tension with the observation that the thing being quoted is itself a market. AEGIS Engine takes a different approach. The collateral check is not "how much is this collateral worth in USD?" It is "if we pulled every lender's liquidity out at the pool's current √K, would the borrower still have enough tokens to cover their debt?" This is a purely structural question that can be answered from on-chain state with no external input. It is a conservative bound, not a spot price, and it does not move faster than the pool itself moves. Because the solvency check is derived from the same pool the borrowing occurs against, the cascade failure mode that has caused so much damage to oracle-dependent lenders does not exist in AEGIS Engine. This is the single most important property of the design, and it is what makes pool-native credit possible at all. ### Why both in one protocol DFM and Engine are not two unrelated products stitched together. They share: * **The same Uniswap v4 hook stack.** The hook that quotes a dynamic fee is the same hook that orchestrates fee reinvestment into protocol-owned liquidity — which, for Engine pools, is the same pooled full-range position that backs sL shares and L credit. * **The same oracle.** TruncGeoOracleMulti / OracleManager provides the TWAP observations that DFM uses to compute fees and that Engine uses as a soft-enforcement check on keeper liquidations. * **The same policy manager.** Risk parameters, fee splits, and cap budgets are all read from PoolPolicyManager, keeping the economic configuration for a pool in one place. \ Conceptually: *DFM makes a pool worth participating in for LPs.* *Engine makes the same pool's liquidity productive as credit.* The two together turn a Uniswap pool from a passive trading venue into an active, self-tuning liquidity and credit market. ### What AEGIS does not try to do A few things are explicitly out of scope: * **Cross-pool margin.** Every position in Engine is collateralized by the single pool it lives in. There is no portfolio netting across pools, and no cross-pool contagion path. * **Leveraged long/short trading UX.** Engine exposes borrowable liquidity, not synthetic exposure to an asset. Applications that want a trading product can build it on top; Engine itself is infrastructure. * **A new stablecoin.** There is no pegged unit of account. All accounting is in pool-native liquidity units (L) and the underlying pool's two tokens. * **Prescriptive governance.** Parameter changes go through a Compound-style Timelock. There is no rapid-reaction governance and no runtime pause. See Governance and Roles. --- # 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-1-start-here/why-aegis-exists.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.