# The Big Idea: Turning Liquidity Into Credit Almost every credit system in DeFi works by stacking two separate markets on top of each other: a trading market that produces a price, and a lending market that uses that price to value collateral. The lender sits across the table from the borrower; a price oracle sits between them; and the whole arrangement only works as long as the oracle honestly reports the trading market. AEGIS Engine collapses that stack into one layer. Lenders and borrowers interact with the same pool that produces the price, and the price never has to be quoted to anyone — the collateral check reads it off of the pool directly. This page explains the reframe and the three consequences that fall out of it. ### The reframe: "liquidity" is already a unit A Uniswap v4 pool's state is captured by two primary quantities: * √P — the square root of the current price, stored with Q64.96 fixed-point precision. * L — the liquidity of every position in the pool, stored as uint128. L has a precise meaning: a position with L = x contributes x \* some-function-of-price tokens to the pool at any given price. When the price moves, the token split of that position changes, but the L itself does not. Most protocols treat L as a detail of the AMM's internal plumbing. AEGIS Engine treats it as a unit of denomination — the thing you borrow, the thing you owe, and the thing the accounting is measured in. * A lender who deposits into Engine receives sL shares proportional to the L they added to the pooled position. * A borrower borrows L directly. Engine burns L worth of the pooled position and hands the borrower the two tokens that come out. * Debt is tracked in L-units on a per-vault ledger, with interest accrued via a standard compounding borrowIndexWad. * Repayment mints L back from the two tokens the borrower provides and reduces the debt. Because every mint and every burn of L goes through the same pooled full-range position, the lender side is always precisely whole: the L owed by the borrow ledger is exactly the L missing from the position. This is the equity-neutrality invariant that sits at the bottom of the design. ### Consequence 1: collateral can be checked without a price If debt is denominated in L and collateral is denominated in the same pool's two tokens, the question "is this vault safe?" has a structural answer that doesn't require an oracle: If we minted back all the L this vault owes, using the vault's idle and attached positions at the pool's current √K, would we have enough tokens? And would anything be left over? This is the √K floor. It is a conservative lower bound on the vault's collateral value, computed directly from: * The vault's idle token balances. * The token amounts that would be recovered if every attached CL / LO NFT were burned at the current √P. * The pool's current √K (the geometric mean of the two pool reserves, in L-units). No external price enters the computation. No oracle feed can be manipulated to trigger a liquidation at a price the pool isn't actually at. If the pool's √P moves, the floor moves with it — because they are computed from the same state. This is the single most important property of Engine, and [The Safety Model](http://./the-safety-model.md) covers it in detail. ### Consequence 2: the cascade failure mode doesn't exist Oracle-based liquidations fail catastrophically when the liquidation process and the oracle are tied together. The pattern that has caused most DeFi credit blowups looks like: 1. Oracle ticks down. 2. Liquidation bots sell borrower collateral at the oracle price. 3. The sell pressure pushes the true market down further. 4. Oracle ticks down again. 5. Go to step 2. The cascade only terminates when liquidity is exhausted. In Engine, there is no oracle to tick. The collateral check is structural. When a vault's floor drops below its debt, the keeper operation is a bounded, pool-aware operation — either peeling a slice of one attached NFT, or swapping the vault's own idle balances within a ±N-tick window under TWAP protection. Neither operation is allowed to fail a vault faster than the pool's own price moves, and neither one dumps external sell pressure on the market. This does not mean Engine is "can't be liquidated." It means the mechanism that connects oracle lag to contagious liquidations is not present. Vaults can still become under-collateralized in sharp adverse price moves; the system's job is to handle that case safely, not to pretend it can't happen. ### Consequence 3: LP shares and debt share the same pool, the same fees, the same interest Traditional lending and AMM LP'ing are separate economies. In Engine, they are the same economy viewed from two sides: * Lenders provide tokens → Engine adds full-range L to the pool → trading fees accrue to the pooled position → sL share price rises. * Borrowers pull L out → Engine credits them tokens → borrowers pay variable-rate interest back into the pool's index → sL share price rises again. The interest rate is governed by a Frax-inspired VariableInterestRate oracle with a kinked utilization curve. Utilization — the fraction of L in the pool currently borrowed — drives the rate. A configurable protocol fee rakes a share of interest into protocol-owned shares; the rest increases sL share price. For lenders this means the return source is transparent: trading fees and interest from borrowers of the same pool. For borrowers it means the cost of borrowing is legible: it's the supply-and-demand price of L in their specific pool. ### Why this matters beyond Engine itself The pool-native approach has implications beyond one protocol: * It suggests a general pattern for building credit in AMM-based systems: if a debt's unit is the AMM's native liquidity unit, you get solvency-by-construction. * It suggests a different composition surface: routers, vault strategies, and keepers can now compose borrowing and LP'ing as primitives that share state, rather than as two separate balance sheets that need reconciliation. * It suggests a cleaner trust boundary: the protocol's honest operation depends on Uniswap v4's correctness and AEGIS's own contract correctness, but not on any external price-reporting party. The next two pages walk through the concrete mechanics: [How Borrowing Works](/part-2-core-engine-concepts/how-borrowing-works.md) shows the step-by-step borrow/repay cycle, and [The Safety Model ](/part-2-core-engine-concepts/the-safety-model.md)shows the √K floor, the LTV/utilization caps, and the keeper guards that together keep the design safe. --- # 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-big-idea-turning-liquidity-into-credit.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.