# Solvency and Liquidation This page is the detailed safety story for AEGIS Engine: the collateral floor, how solvency is enforced, what keepers do to restore unhealthy vaults, and what residual loss can remain. If you read nothing else, the thesis is: A borrower's obligation is denominated in the same L-units as the collateral backing it; the floor is computed from observable pool state; and the keeper lane has two independent modes. Residual loss is bounded and allocated to sL first-loss. ### The collateral floor, precisely Given a vault v on pool p at current √P, the minimum L-value of the vault's assets is: C\_min(v) = L(idle0, idle1, √P) + sum over attached CL NFTs \[L\_burn(NFT, √P)] \+ sum over attached LO NFTs \[L\_burn(LO, √P)] Where: * L(idle0, idle1, √P) = the L-units that a full-range position would yield at the current √P given token balances idle0, idle1. Computed via the √K identity (see R-0008 in the Engine repo). * L\_burn(NFT, √P) = the L-units returned if the NFT were fully burned at √P. For a CL NFT, this uses the NFT's liquidity, tickLower, tickUpper relative to the current tick — it collapses to a closed-form expression depending on whether √P is inside, above, or below the range. * L\_burn(LO, √P) = for a Limit Order (LO NFT), this depends on whether the tick has been crossed. If crossed, the LO's filled side; if not, the bucket's pre-fill value. The critical properties: 1. No oracle. C\_min is derived entirely from Uniswap v4's own state (tick, ranges, balances). There is no external price feed to be stale, manipulated, or fail to update. 2. Monotone in price moves. As √P changes, C\_min updates smoothly. There are no discontinuities; no sudden collateral drops from one block to the next beyond what the pool's tick move implies. 3. Conservative at session start. C\_min is evaluated at session-end (lockVault); the borrower's actions inside a session can temporarily push balances around, but the end-state is what matters. 4. Bounded NFT count. MAX\_NFTS\_PER\_VAULT = 4 (compile-time). This caps the computational cost of C\_min per session and makes the floor deterministic. The SAFE multi-NFT bound (R-0008) ensures the sum-of-parts never overstates the actual L that would be recovered if all NFTs were burned simultaneously. This is the mathematical backbone of the Engine safety story. ### The solvency inequality A vault is solvent at session-end if and only if: rLWad × borrowIndexWad / 1e18 ≤ C\_min × MAX\_LTV\_PIPS / 1\_000\_000 Expanded: * Left side: real debt in L-WAD (nominal principal times accumulated interest). * Right side: MAX\_LTV\_PIPS = 980\_000 → 98% of the collateral floor. If the inequality is false at lockVault, the entire transaction reverts. There is no partial success path. #### Why 98%, not 80% A 98% max-LTV is aggressive by money-market standards (Aave uses 75-85% typical, highest risk markets up to 90%). The reason AEGIS can run so tight: * The collateral is the same asset as the debt (L in the pool). There is no cross-asset basis risk. * Price moves of the pair move collateral and debt denomination together — if √P moves, both the L-units owed and the L-units held move the same way relative to token0/token1 balances. * LVR-style losses for the borrower's NFT positions do show up in the floor, but they are bounded by the same pool's math. The 2% cushion exists to absorb: * Interest accrual between blocks (not much, but non-zero). * Minor tick-move noise between when the borrower constructed the transaction and when it lands on-chain. * Keeper bounty room (peel bounty eats a fraction of the idle balance). A 98% setting is the tightest AEGIS can safely run; loosening it would waste capital efficiency without material safety benefit, tightening would make too many routine operations revert. ### The utilization cap In addition to the per-vault LTV check, the market has a global constraint: totalRlBorrowed ≤ (equityLWad / 1e18) × UTILIZATION\_CAP\_PIPS / 1\_000\_000 UTILIZATION\_CAP\_PIPS = 950\_000 (95%). This ensures there is always some L in the pool that is not borrowed — important because: * If 100% of the market's L were borrowed, there would be nothing left in the pool for trading, and swap depth would collapse. * Repay requires the pool to absorb returned liquidity; leaving room means repayment paths are always available. * Keepers need pool depth to execute micro-liquidation; some unborrowed L is a precondition for the keeper lane's functioning. ### Keeper mode 1: peel Peel reduces the amount of attached NFT liquidity in a vault, increasing the vault's idle balance, without touching the debt ledger. #### When peel applies * The vault's LTV is above a peel-eligibility threshold (TODO: confirm threshold — working assumption is slightly below MAX\_LTV\_PIPS, e.g. 900\_000 PIPS / 90%). * The vault has at least one attached CL or LO NFT. #### What the keeper does 1. Picks an NFT in the vault. 2. Calls peel(vaultId, nftIndex, dL, bounty) on the router, reducing the NFT's liquidity by dL. 3. Receives a bounty denominated in the pair's tokens, paid from the vault's post-peel idle balance. #### What the protocol enforces * dL is capped such that the post-peel vault is still solvent (or at least closer to solvent than pre-peel). * The bounty is bounded by policy — TODO: confirm bounty cap in BPS — working assumption is 50 bps of the peeled L value. * The peel cannot push the vault into a worse state than before. #### The Peel event emits Peel(vaultId, nftKind, tokenId, dL, cMinPre, cMinPost, bountyPaid). Keepers and indexers can reconstruct the full peel history of a vault from this stream. ### Keeper mode 2: micro-liquidation Micro-liquidation is the action of last resort when peel is insufficient (e.g., all NFTs are either fully unwound or would be pushed past their tick boundaries by further peel, or the vault has only idle balances left). It performs an AEGIS-owned swap inside the pool to rebalance the vault's idle into a shape that can repay debt. #### When micro-liq applies * The vault is above LTV threshold. * A TWAP gate is passing: the pool's 30-minute TWAP is within N\_TICKS = 5 of the current price. If the TWAP deviation is too large, the action reverts with TwapBandExceeded. * There is sufficient pool depth to complete the swap within configured slippage. #### What the keeper does 1. Calls microLiq(vaultId, dRl, tickLimit, zeroForOne, amountIn) on the router. 2. The router executes a swap on the pool: tokenIn → tokenOut at the pool's current price (within tickLimit). 3. Uses the resulting tokens to mint L and reduce the vault's rLWad. #### What the protocol enforces * TWAP gate. This is the key defense. An attacker who manipulates the pool price to trigger micro-liq at an unfair level can't succeed because the TWAP won't follow. N\_TICKS = 5 means the instantaneous price can't drift more than 5 ticks from the 30-minute average before micro-liq is blocked. * LTV improvement. Post-swap LTV must be <= pre-swap LTV (the swap must help, not hurt). * Session guards. The entire micro-liq is wrapped in the standard session lifecycle; if anything is off, the transaction reverts. #### The MicroLiq event emits MicroLiq(vaultId, rL, tickLimit, twapOk, ltvPre, ltvPost, zeroForOne, amountIn). #### Why no bounty Peel has a bounty because it is pure service work: the keeper takes on gas, the protocol compensates. Micro-liquidation has no bounty because the keeper benefits from the price action of the swap itself — they pick the most favorable moment to act on the swap side, and the protocol lets them capture that. This aligns incentives without needing an explicit fee. #### Why micro-liq doesn't seize collateral Notice what micro-liquidation does not do: it does not transfer collateral to the keeper, does not rebate liquidators with discounted assets, does not have "liquidation bonus" parameters. The keeper's only compensation is the favorable price at which the AE-owned swap executes. This is intentional: * No "liquidation cascade" spiraling down as each liquidation signals the next. * No keeper getting a windfall on a market stress event. * Keeper competition pushes the action toward the most efficient possible price for the vault. ### The residual loss path If peel and micro-liquidation together cannot restore a vault to solvency — e.g., the pool is too thin for micro-liq and the NFTs have been fully unwound — the vault's debt can exceed its collateral floor. When the vault is eventually closed (or force-closed), the uncovered L is debited from equityLWad, reducing the sL share price. This is the only mechanism by which sL share price can decrease. In every other situation (fee accrual, interest accrual, POL reinvestment), share price only goes up. #### Who bears it * Only sL holders of the affected pool. Cross-pool insulation is strict: a loss on pool A does not touch pool B. * sL holders have always been first-loss. There is no junior tranche, no insurance fund, no external backstop. #### How much can it be Bounded by: * The vault's outstanding debt at the moment of default. * Capped at 100% of the vault's debt (you cannot lose more than was borrowed against a single vault). * In aggregate, capped at the pool's total equity (you cannot lose more than the pool's LPs collectively deposited). Realistically, for most vaults in most markets, the peel + micro-liq lane successfully restores solvency long before the vault reaches the point where loss would be debited from equityLWad. The residual-loss scenario is a stress-state for thin pools or extreme market conditions. ### How much margin for error do LPs have The protocol's structural margin for sL holders on a given pool: 1. Borrowers have a 2% gap between LTV (98%) and their hard solvency line. Practically, many borrowers maintain a larger buffer to avoid peel risk, so actual LTV distributions skew lower. 2. Keeper bounty on peel eats a small fraction of the vault's idle before any loss reaches sL. 3. Peel itself is the primary safety lever — it can unwind NFT liquidity long before the vault's debt gets anywhere close to default. 4. Micro-liq catches the long tail where idle rebalancing is needed. For LPs evaluating a pool: the risk of sL loss is essentially the risk that the pool's liquidity becomes too thin for the keeper lane to function, and a specific vault goes insolvent, and the lost L is larger than the per-pool equityLWad cushion. These conditions layer; the probability of all three co-occurring on a liquid pool is small, but not zero. ### Stress scenarios Some scenarios worth thinking through: #### Pair volatility spike A large move in the pair price moves every vault's NFT positions in and out of range. Vaults with concentrated NFTs may see sharp C\_min drops. Keepers peel the worst offenders; the surge fee in DFM extracts LVR compensation during the move. Most vaults are fine; a few may need micro-liq. #### Pool TVL drain If LPs withdraw sL in bulk during a stress event, equityLWad drops. Utilization rises. The utilization-rate curve steepens. Borrowers see higher interest costs, incentivizing repay. Keepers find it harder to execute micro-liq if the pool is shallow. In the worst case, sL redemptions may face temporary constraints if the full-range pooled position doesn't have enough idle liquidity to meet them. #### Oracle mis-behavior If TruncGeoOracleMulti reverts, the DFM hook emits ExternalCallFailed and falls back to manualFeePpm. DFM fees are wrong for that block, but the pool remains functional. Engine's safety model doesn't depend on the DFM oracle — C\_min is computed from v4 state directly. So oracle issues are a fee-quality issue, not a solvency issue. #### Hook authorization removed mid-session AegisEngine.hookAllowed(hook) = false while sessions are in flight: existing sessions complete normally; new sessions on that pool revert. This is designed for emergency response. LPs and borrowers can always withdraw / repay; no one is locked in. #### Governance action If governance changes a tunable parameter (e.g., raises marketProtocolFeeBps), existing positions continue to function. There are no position-invalidating governance actions — all changes are parameter tweaks within bounded ranges, and all compile-time constants are, by definition, unchangeable without a new deployment. ### Summary The AEGIS Engine safety model rests on four structural properties: 1. The collateral floor is computed from observable pool state, not oracles. 2. Debt and collateral are denominated in the same asset (L), eliminating cross-asset basis risk. 3. The keeper lane has two independent modes (peel, micro-liq) with gating that prevents manipulation. 4. Any uncovered loss is bounded and allocated to sL holders of the affected pool, who have always been first-loss. The residual risk is real and bounded. Nothing in this design eliminates risk; it shapes where risk sits and who bears it. --- # 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/solvency-and-liquidation.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.