# AEGIS for Liquidity Providers If you are providing liquidity into an AEGIS-enabled pool, there are two related questions worth answering: 1. What exactly am I holding? 2. Where does the return come from? This page answers both, then walks through the concrete actions (deposit, redeem, monitor) and the specific risks that apply to lenders. ### What you hold: sL shares When you provide liquidity into an AEGIS Engine pool, you receive sL shares. Specifically: * sL is an ERC-6909 token issued by AegisEngine itself (the singleton). It is not a separate ERC-20. * Each pool has its own sL. The ERC-6909 tokenId equals the pool's PoolId. * Your balance is your claim on that pool's shared full-range position. If the pool's position holds L\_total liquidity and sL\_total shares are outstanding, one of your shares represents L\_total / sL\_total liquidity. This means sL is pool-scoped, not protocol-wide. You cannot burn pool A's sL against pool B. A user can hold sL in many pools simultaneously; each is independent. Unlike an ERC-20 pool-share token, ERC-6909 doesn't have a built-in "transferable receipt" UX. The AEGIS app handles this; integrators who want a wrapping layer can build one on top. ### Where the return comes from Two sources. Both flow through the same sL share price. #### 1. Trading fees The pooled full-range position earns swap fees on every trade through the pool. The dynamic fee (computed by DFM) means the fee per swap varies with pool volatility — higher during volatile periods, lower during calm ones. Unlike a vanilla Uniswap v4 position, the fee schedule is not a fixed tier. Fees realize into L through a deliberate mechanism: * During a swap, the hook credits accrued fees to the pool's \_pendingFees. * On the next modifyLiquidity or liquidity-touching operation, the hook reinvests pending fees into the full-range position (subject to MIN\_REINVEST\_LIQUIDITY and a cooldown). * On reinvestment, Engine counts the reinvested L as new equity, which raises sL share price. Only reinvested (mintable) fees raise the share price. One-sided residues that cannot be minted into liquidity sit off-equity until the pool's imbalance allows them to mint. #### 2. Borrower interest Borrowers pay interest on their rL principal, accruing via borrowIndexWad. This accrues as additional L in the market's equityLWad, which means new share price. In other words: when a borrower pays interest, part of it goes to the treasury (via protocol-minted sL) and part of it goes to lenders (via raising the existing sL share price). #### Share price is monotonically non-decreasing A structural guarantee: under honest operation, sL share price never goes down. Fees and interest only add to L. Redemptions burn sL at the current share price, which means redeemers always get their proportional claim. The exception — and the one thing a responsible LP should understand — is first-loss on bad debt. If a vault's debt exceeds its collateral floor and keepers cannot fully restore it, the shortfall is borne by sL holders in that pool: equityLWad is reduced by the uncovered L, and share price drops. This is not an oracle-cascade event; it is the normal first-loss property of being the lender. ### Depositing LP flows go through AegisRouterV1 like all Engine operations. The conceptual flow is: 1. The router calls PoolManager.unlock. 2. Inside the unlock frame, the router calls AegisEngine.aeUnlock. 3. The router takes your two tokens via PoolManager.sync + transferFrom + settleFor(AE). 4. Engine calls modifyLiquidity with a positive delta, minting sL shares to the caller. 5. The session ends, the unlock frame closes, and the PoolManager enforces delta-zero. In practice, the AEGIS app handles all of this for you. As an LP you: * Connect a wallet. * Pick a pool. * Enter the amounts of token0 and token1 you want to deposit. * Approve and submit. There is no minimum lock-up. You can redeem anytime. The protocol charges no deposit fee. You pay network gas and the small cost of the router's atomic flow. #### Balance requirements Because the pool is full-range, deposits should be balanced to the pool's current reserves ratio. If you deposit an imbalanced pair, some portion will remain unused as dust — Engine enforces a minimum liquidity threshold (MIN\_LIQUIDITY = 1\_000) and may revert a deposit that produces zero shares. #### Min-share guard modifyLiquidity enforces a minimum share mint to prevent dust attacks. If the shares minted would round to zero, the call reverts with ERR\_ZERO\_SHARES. ### Redeeming Redemption is the reverse: burn sL, withdraw your proportional tokens. Conceptually: 1. Open a session via the router. 2. Call modifyLiquidity with a negative share amount. 3. Engine burns your shares and credits you with the proportional share of the pool's token holdings at the current √P. 4. Router calls take(currency, to, amount) to move the tokens from PM to your address. 5. Session ends. What can delay a redemption? The utilization cap. If the pool is at 95% utilization — meaning 95% of the pool's L is currently borrowed — redemption is limited to the idle portion until borrowers repay, interest accrues, or additional deposits arrive. This is intentional: it protects the remaining lenders from a run. In practice this is rare because utilization has to be very high before it starts limiting redemptions, and the rate curve pushes utilization down as borrowers pay more to borrow marginal L. ### Monitoring Lender-relevant values exposed via AegisStateView / AegisStateLibrary: * Per-pool: equityLWad (total equity in L, including residues), sL\_totalSupply, totalRlBorrowed, borrowIndexWad, fullUtilizationRate, current utilization. * Per-LP: sL balance (ERC-6909 balanceOf), implied L share (balance / totalSupply × equityLWad). * Per-pool fee state: current baseFeePPM, surgeFeePPM, inCap flag. The AEGIS subgraph (aegis-engine-subgraph) indexes these for easier querying. TODO: add subgraph URL when deployed — see the Live Pools page for the current index location. ### Risks specific to lenders Beyond the general AEGIS risks (smart contract, governance, Uniswap v4 correctness — see Risk Overview), lenders should understand: * First-loss on under-collateralized vaults. If a vault's debt exceeds its floor and keepers can't close the gap, sL holders in that pool eat the uncovered L. This is rare, but it is how the math works. * Impermanent loss, full-range. A full-range LP is exposed to the standard v3/v4 IL curve. In sustained trending markets, token holdings shift. This is not an AEGIS-specific * risk but it applies. * Utilization-bounded redemption. If the pool is at the cap, redemption is temporarily bounded to idle. You can always redeem something; sometimes the full amount has to wait for borrower repayments or new deposits. * Pool-scope. A bug or parameter change on one pool's hook does not affect other pools. But a bug in the core Engine affects every pool that uses it. ### What AEGIS does not promise Here are things AEGIS explicitly does not promise: * **No guaranteed yield.** Fees and interest depend on pool activity and borrower demand. Some pools may produce little of either; lenders in those pools may earn very little. * **No insurance fund.** There is no protocol-run backstop that covers bad debt. The risk is borne by lenders in the affected pool. * **No price-correlated returns.** sL share price moves with pool state, not with any external benchmark. If the pool underperforms, sL does too. If those trade-offs are acceptable, sL gives you a passive full-range exposure with volatility-aware fees and additional interest from a captive borrower market — a combination that does not exist in vanilla Uniswap. --- # 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/aegis-for-liquidity-providers.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.