# AEGIS for Borrowers

If you're going to use AEGIS Engine to borrow, it helps to have a precise picture of what you're actually borrowing and what you owe. This page gives the pragmatic borrower's view, complementing the mechanistic How Borrowing Works.

### What you're borrowing

You are borrowing L — Uniswap v4 liquidity units — from a specific pool. When the borrow is executed, Engine:

1. Burns L worth of the pool's pooled full-range position.
2. Hands you the two tokens that came out of the burn, at whatever √P the pool was at the instant of the burn.
3. Books you for rL debt, which starts accruing interest.

The important thing: you do not borrow "USDC" or "ETH" or any specific asset. You borrow liquidity, and what comes out depends on the pool's current state. In an ETH/USDC pool with √P near 2000, a borrow of dL gives you roughly equal value in each token. As the price moves, the split at the moment of borrow moves with it.

#### Why that's actually useful

This may sound strange at first — "I just wanted to borrow USDC" — but the structure has real advantages for common strategies:

* **Hedged positions.** If you want USD exposure, borrow from an ETH/USDC pool, keep the USDC, and swap the ETH on the open market to lock in your position. The resulting synthetic is indistinguishable from a standard ETH-collateralized USDC loan except it has no oracle risk and no liquidation cascade.
* **Liquidity provisioning.** If you want to LP a different (possibly concentrated) range, borrow and deploy without selling what you have.
* **Atomic rebalancing.** Inside one transaction, borrow, swap, LP, repay — a common pattern for sophisticated strategies.

#### Why that might not be useful

If your actual need is a loan against your ETH to hold a stablecoin, and the relevant pool's volatility means your collateral floor moves with √P, you may find AEGIS noisier than a stable-oracle lender. The trade-off: oracle lenders give you a smoother LTV number, but the oracle itself is the source of the cascade risk that AEGIS doesn't have. Which you prefer depends on what you care about.

### What you owe

Your debt is measured in L, not USD. Every time the pool accrues interest, your rL principal rises at the borrowIndexWad rate. Every time you repay, the amount of L you mint back reduces your debt.

Practical implications:

* Your debt does not track USD. If the pool's √P moves, the USD-equivalent of your debt moves with it. Your collateral also moves with it — they move together because they're both pool-native.
* Interest is variable. The rate is a function of pool utilization. Higher utilization → higher rate. You can read the current rate from the pool's fullUtilizationRate view; the actual rate paid is a standard kinked curve below/above UTIL\_KINK (see the rate oracle docs).
* No fixed-rate option in v1. If you need a fixed rate, you'll need to hedge the variable rate externally. Some integrators build fixed-rate products on top of Engine via rate swaps.

### How much you can borrow

Your maximum borrow is bounded by two caps:

* LTV cap. Your rL cannot exceed 98% of your C\_min. You can borrow up to that ratio, but you probably don't want to — a small adverse pool move can push you over.
* Market utilization cap. Your borrow, combined with all other borrows in the pool, cannot exceed 95% of the pool's total L. If the pool is already near the cap, your borrow is bounded by the headroom.

### The concrete flow

Depending on how you're interacting with Engine:

#### Through the AEGIS app

1. Connect a wallet.
2. Pick a pool. You'll see the pool's current √P, utilization, and rate curve.
3. Create a vault (if you don't have one in that pool).
4. Deposit collateral — either token of the pair, and/or attach Uniswap v4 CL positions you already hold.
5. Enter a desired borrow amount. The app shows you projected LTV, projected utilization, and projected rate.
6. Submit. The router handles session, unlock, borrow, and credit in one transaction.

The borrowed tokens land in your vault's idle. You can withdraw them to your wallet in the same transaction or later.

#### Via the router directly

An integrator batch looks like:

PM.unlock:

&#x20; AE.aeUnlock:

&#x20;   \[Phase-0]

&#x20;   CREATE\_VAULT(poolKey)

&#x20;   ATTACH\_NFT(vaultId, nftRef)        // optional

&#x20;   \[Phase-1]

&#x20;   UNLOCK\_VAULT(vaultId)

&#x20;   DEPOSIT\_IDLE(vaultId, token0, amount0)

&#x20;   DEPOSIT\_IDLE(vaultId, token1, amount1)

&#x20;   BORROW\_L(vaultId, dL)

&#x20;   WITHDRAW\_IDLE(vaultId, token0, amount, to=borrower)  // or keep idle

&#x20;   WITHDRAW\_IDLE(vaultId, token1, amount, to=borrower)

&#x20;   LOCK\_VAULT(vaultId)

See Router and Actions Reference for the full action set and opcodes.

### Managing your vault

#### Day-to-day

* Monitor LTV. Your vault's health depends on C\_min which depends on the pool's √P. Watch the pool.
* Top up if needed. Depositing more idle or attaching more NFTs raises C\_min and drops your LTV.
* Repay partially. Any amount of rL can be repaid. You do not need to close the vault to reduce your debt.

#### Approaching the LTV cap

If your LTV rises toward 98%, you have three options:

1. Deposit more collateral. Idle top-up immediately raises C\_min.
2. Repay some debt. Providing tokens and calling repayL reduces rL and your LTV.
3. Let it ride. If you're confident the pool will revert, you can sit above your target. But if it breaches 98%, keepers can stabilize you at a small bounty cost.

The keeper operation (see Liquidations and Keepers) is not punitive. You pay a small bounty (bps) and your vault ends up healthier. It is explicitly not an auction — you do not lose a large discount to a liquidator.

#### Closing out

To close your vault completely:

1. Ensure enough idle or fresh deposit to repay your full rL.
2. Call repayL(vaultId, dL=0) — the sentinel repays the full outstanding principal.
3. Detach any NFTs back to yourself.
4. Withdraw remaining idle.

The vault NFT persists (it's yours, in VaultRegistry). You can reuse it for future positions on the same pool, or transfer it, or simply leave it.

### Borrower-specific risks

Beyond the universal AEGIS risks (see Risk Overview):

* Your LTV moves with the pool. C\_min is a function of √P. A sharp adverse move increases your effective LTV without you doing anything. This is the expected behavior — your collateral is priced in pool units that track the pool — but it means you have to monitor or use automation.
* Keeper bounty on your vault if you breach. If you cross the cap, a keeper will call stabilize. You pay a small bounty cost and your position is partially restored. Not punitive, but not free.
* Utilization-affected rate. If utilization in your pool spikes (e.g., during a volatile period), your interest rate spikes too. Rates above the kink point are steep.
* Swap-side execution risk. If you use borrowed tokens to open a broader position (swap into something else, LP elsewhere), that execution is separate from Engine — it's subject to its own slippage, routing, and counterparty risks.

### What borrowers typically do

Without editorializing: the common patterns integrators have built on Engine include:

* Looped LP — borrow L, deploy into a concentrated range in the same pool or a different pool, earn fees, hedge externally.
* Synthetic token exposure — borrow, swap one side away to concentrate into the asset you want, repay when the trade is complete.
* Cross-pool arbitrage — borrow liquidity from one pool, use it to execute arbitrage that doesn't require your own balance sheet.
* MEV and sandwich avoidance — borrow at the moment of a planned trade instead of signaling demand by pulling liquidity, then repay.

Engine is intentionally a primitive. What you do with it is your choice; the protocol doesn't have opinions.


---

# 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-borrowers.md?ask=<question>
```

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.
