# What is AEGIS Engine? AEGIS Engine is a pool-native liquidity and credit engine built on Uniswap v4. In one sentence: it turns an AMM pool's liquidity into a borrowable resource, and it does so without ever taking custody of user tokens and without depending on an external price oracle for solvency. This page explains what Engine is as a system. Later pages explain why the design choices matter (The Big Idea), how borrowing against a pool actually works (How Borrowing Works), and what keeps it safe (The Safety Model). ### The product, concretely Engine consists of four contract surfaces a user or integrator will interact with: 1. **AegisEngine** — the singleton core contract. Holds market state, vault state, the sL share ledger, and the L-unit debt ledger. Every mutation goes through a session that AegisEngine orchestrates. 2. **AegisRouterV1** — the periphery / canonical router. Handles Uniswap v4 PoolManager.unlock orchestration, pre-funds the engine during a session, and exposes a batch of action opcodes that let integrators compose multiple operations in a single transaction. 3. **AegisHook** — the Uniswap v4 hook that an AEGIS-enabled pool installs. Quotes dynamic fees via the DynamicFeeManager, maintains oracle observations, and reinvests a share of fees into the pooled full-range position that backs sL shares. 4. **VaultRegistr**y — an ERC-721 that issues a borrower's vault NFT. Transferring the NFT transfers ownership of the vault (subject to session-unlocked restrictions). Engine depends on two supporting managers that are part of the same deployment: * **OracleManager** — a Uniswap-truncated-oracle ring buffer per pool. Used by the hook during swaps and by keepers to soft-enforce TWAP-bounded liquidation behavior. * **LimitOrderManager** — a bucket/epoch-based limit order book integrated as NFT-wrapped positions that vaults can attach to their collateral. And it reuses the DFM stack for fees: * **DynamicFeeManager + PoolPolicyManager** — dynamic fee engine + risk/policy registry. ### What a lender does A lender ("liquidity provider") deposits a balanced pair of tokens into a specific pool through the router. In exchange, Engine mints sL shares tied to that pool (tokenId = PoolId under ERC-6909). The deposited tokens become part of a single, pooled full-range position that Engine manages on behalf of all lenders in that pool. Key properties: * **sL is pool-scoped.** A share of pool A cannot be burned against pool B. * **Share price is monotonically non-decreasing.** Fees accumulated by the pooled position raise the share price over time; redemption never pays less than proportional to the current pool state. * **Redemption is permissionless.** You can always burn your sL shares back into your share of the pool's current token holdings, subject to the pool having sufficient idle capacity (see [utilization cap](http://../06-trust-risk-status/solvency-and-liquidation.md#utilization-cap)). ### What a borrower does A borrower ("vault owner") opens a vault (an ERC-721 from VaultRegistry) bound to a single pool. Into that vault they can deposit: * Idle token balances in either pool currency. * Up to MAX\_NFTS\_PER\_VAULT Uniswap v4 concentrated-liquidity NFTs or AEGIS limit-order NFTs. When attached, ownership of these NFTs transfers to the engine; they are returned on detach. The borrower then calls borrowL with a desired amount of L — a unit of Uniswap liquidity. Engine burns L worth of the pooled full-range position (reducing sL backing proportionally) and credits the resulting token amounts to the vault's idle balance. The vault now owes L back to the lenders. Repayment works in reverse: the borrower provides the two tokens, Engine mints L worth of full-range liquidity back into the pooled position, and the vault's debt is reduced. Critically, the borrow and repay are equity-neutral in L: the number of L units owed equals the number of L units destroyed from the shared position. Nothing about the mechanic creates or destroys value in the lender pool. ### What a keeper does If a vault becomes unsafe — collateral below the required floor — a keeper can call stabilize(v) on the router. This triggers one of two operations: * **Peel.** If the vault has attached CL or LO NFTs, Engine reduces liquidity on one of those NFTs and routes the resulting tokens back into the vault's idle, improving its C\_min (collateral floor). * **Micro-liquidation.** If there are no attachable NFTs to peel from, Engine performs a small, TWAP-bounded, AE-owned swap between the vault's two idle balances, then uses the rebalanced tokens to mint L and repay a slice of the debt. Both operations must improve the vault's health. Both operate under a TWAP guard and a ±N-tick limit. Keepers are paid a small bounty in the vault's currencies. There is no traditional "auction" liquidation. See Liquidations and Keepers for the full picture. ### What makes it "pool-native" Three structural choices put Engine in a different category than most lending/margin protocols: 1. **No ERC-20 custody at rest.** At the end of every transaction, AegisEngine holds zero ERC-20 balances. Token movement happens only inside Uniswap v4's PoolManager.unlock frame, using the PoolManager's ERC-6909 claim accounting. A user's deposit is never "in the Engine contract" — it is always either in the PoolManager as part of the shared position, or in the user's own wallet. 2. **Oracle-free solvency.** Collateral adequacy is not a USD valuation. It is a structural check: if the vault's borrowed L were fully withdrawable at the pool's current √K, would the vault's idle balances plus attached NFTs cover the resulting debt? This is the √K floor, and it is computed entirely from on-chain state. 3. **One-pool scope.** A vault is bound to exactly one pool at creation. There is no portfolio netting, no cross-pool collateral, and no cross-pool contagion path. This narrows what Engine can do (no portfolio margin), but it also narrows the failure modes. --- # 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-2-core-engine-concepts/what-is-aegis-engine.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.