# The Safety Model A credit system is as trustworthy as the worst-case behavior of its solvency model. This page spells out AEGIS Engine's solvency model: the √K collateral floor, the LTV and utilization caps that govern it, and the session-level guards that make the whole thing enforceable. If you only read one thing on this page, read the next section. Everything else follows from it. ### The √K floor AEGIS Engine does not value collateral in USD. It values collateral in units of pool liquidity it could be converted into at the current pool state. Concretely, for a vault v on pool p, the collateral floor C\_min(v) is: The minimum number of L units that the vault's idle balances plus the burnable output of every attached CL/LO NFT would produce, if minted back into a full-range position at the pool's current √P. This is what the CollateralFloorMath library computes. It is conservative: it never over-states collateral, and it handles the multi-NFT case with a SAFE bound that remains conservative for every value of N up to MAX\_NFTS\_PER\_VAULT. A vault is considered solvent if its debt in L is at or below its floor times the LTV cap: **rL(v) ≤ C\_min(v) × MAX\_LTV\_PIPS / PIPS** Two observations: * C\_min is a function of current pool state, specifically √P. When the pool moves, C\_min moves. This is the intended behavior — collateral valued in pool units should track the pool. * C\_min is deterministic and bounded by on-chain state only. No external oracle, no off-chain input, no trusted reporter enters the formula. ### Why no oracle is needed The question a lending protocol typically asks is "is this collateral worth more than this debt, denominated in a common unit of account (like USD)?" That question requires a price. AEGIS Engine asks a different question: "if we minted back the L this vault owes, would the vault's own tokens cover it at the pool's current state?" That question does not require a price — the answer comes directly from the pool's √P and the vault's own token balances. This is why the protocol can issue credit without an oracle in the solvency path. The trade-off is that debt is denominated in L, not in USD — so a borrower who wants a particular USD exposure has to manage that exposure separately. (That is what borrowers typically do by swapping the borrowed tokens into whatever asset they actually want.) ### The three caps Three parameters bound how far any single vault or market can lean: * MAX\_LTV\_PIPS = 980\_000 (98%) — compile-time. A vault can borrow up to 98% of its C\_min. This is a structural ceiling: at 100% LTV, a sharp pool move would leave lenders short, so the cap keeps a small structural buffer. * UTILIZATION\_CAP\_PIPS = 950\_000 (95%) — compile-time. A market cannot have more than 95% of its L borrowed at any one time. This protects lenders' ability to redeem and the pool's ability to absorb inflows/outflows without hitting edge cases. * HARD\_LTV\_BPS = 9\_900 (99%) — a second, stricter ceiling used in the liquidation path. A vault cannot be left above 99% LTV even transiently inside the session. These are enforced at lockVault(v) time — the moment a session ends for a vault. Inside a session, intermediate states can briefly be above the caps, as long as the final state passes. This flexibility lets borrowers run atomic rebalances, repay-then-reborrow, and other multi-step operations without artificial rejection. A few things deliberately are not parameters: * The caps are not tunable by governance. They are compile-time constants. Changing them requires a contract upgrade — which, given AEGIS's governance model, is a Timelock operation with visible delay. * There is no per-pool "risk parameter" that lets governance raise an individual pool's LTV. Risk configuration is in the hook/DFM/policy layer, not in the core solvency check. ### The session guard The solvency check only works if nothing can bypass it. AEGIS Engine enforces this through the session pattern: 1. Every mutation is gated by unlockVault(v). Only the vault owner or an approved operator, operating inside an active aeStart frame, can unlock a vault. 2. Every session ends with lockVault(v), which must pass the LTV and utilization checks or the entire transaction reverts. 3. The session epilogue enforces that no vaults remain unlocked at session end and no stray pending NFT attachments are left hanging. If either is true, the transaction reverts. 4. The VaultRegistry refuses to transfer a vault NFT while the vault is unlocked in a session. You cannot transfer a half-mutated vault to someone else. The effect is that there is no way to put a vault into an under-collateralized state at the end of a transaction. You can do whatever you want mid-session, but you cannot commit anything that fails the cap. ### The keeper envelope If a vault's floor drops below its debt between transactions — because the pool's √P moves and the vault's collateral no longer covers rL × MAX\_LTV\_PIPS / PIPS — a keeper can call stabilize(v). The keeper's toolkit is bounded: * The operation must improve the vault's state (C\_min\_post > C\_min\_pre for peel, or LTV-must-improve for micro-liq). * The operation must respect a TWAP guard: any swap happens inside a ±N\_TICKS = ±5 tick window around the current TWAP (TWAP\_WINDOW = 30 minutes). * The operation auto-selects its input side from the vault's own idle imbalance. Keepers do not get to choose the direction. * A small bounty (in the vault's currencies) is paid to the keeper. Bounty sizes are capped by compile-time bps constants; see Liquidations and Keepers. What keepers cannot do: * They cannot liquidate an already-solvent vault. The entry conditions require the vault to be unsafe. * They cannot move the pool price outside the TWAP band. The swap reverts if it would. * They cannot sell the vault's collateral at an arbitrary price on an external venue. All swaps happen on the same pool using the same AMM curve. * They cannot pile on. A failed keeper call returns zeros cleanly; there is no "retry and try harder" path that compounds into a cascade. ### What the safety model does not protect against Being honest about limits is part of the model: * Sharp, sudden price moves that outpace keeper reaction. If the pool moves faster than any keeper can react, a vault can become under-collateralized below the point where a single keeper action can heal it. In that case, repeated micro-liquidations will eventually restore health, but in the meantime rL > C\_min and lenders are exposed to first-loss. * Uniswap v4 correctness. AEGIS inherits its swap accounting, liquidity math, and ERC-6909 settlement from Uniswap v4. If there is a bug in the v4 PoolManager, AEGIS is affected. * DFM hook correctness. A pool that uses a custom DFM-compatible hook inherits that hook's behavior. The AE hook allow-list is one-way; approved hooks cannot be removed. * User key management. Vault NFTs are bearer tokens. If a borrower's key is compromised, the attacker can close out the vault. AEGIS does not add a custodial layer here. ### How the pieces fit together A concise restatement of the safety model: Debt is denominated in L. Collateral is measured as the pool-native L that the vault's idle and attached NFTs would produce at the current √P. Solvency is a structural inequality between these two quantities. The session pattern ensures every transaction that commits has to satisfy the inequality. Keepers restore solvency through bounded, pool-aware operations with TWAP protection. No external oracle enters the path. --- # 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/the-safety-model.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.