> 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-2-core-engine-concepts/what-is-aegis-engine.md). # 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.