> For the complete documentation index, see [llms.txt](https://docs.curvance.com/app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.curvance.com/app/developer-docs/lending-protocol.md).

# Lending Protocol

## Market Design Principles

Curvance markets are built with a focus on risk management, liquidity efficiency, and economic security. The protocol employs a novel market architecture that enables both capital efficiency and strong risk management.

### Thesis-Driven Markets

Curvance creates thesis-driven micro-ecosystems. Each Market Manager focuses on a specific financial thesis:

* Interest-bearing stablecoins.
* Bluechip long market exposure.
* Volatile LP tokens for a particular DEX or perpetual platform.
* Other specialized asset categories.

This targeted approach allows for customized risk parameters appropriate for each asset class, rather than forcing disparate assets to share the same risk model.

### Systemic Risk Reduction

By segregating markets by thesis, Curvance minimizes the contagion risk between asset classes. A volatility event in one market doesn't propagate to unrelated markets, protecting the overall protocol health. Isolated Market Managers are designed to contain risk within their boundaries. If extreme market conditions impact one Isolated Market Manager, other Market Managers remain unaffected, ensuring protocol stability.

## Core Market Components

### Curvance Token System

**Curvance Tokens (cTokens)** are ERC4626 vault shares representing user deposits. Each cToken wraps exactly one underlying asset. Deposits increase the cToken's asset accounting and mint shares. Available liquidity remains in the cToken contract, while borrowed liquidity is tracked as `marketOutstandingDebt` and per-account debt, and the underlying is transferred to the borrower.

* **Lending liquidity:** holders of cToken shares are the suppliers. Interest accrual increases cToken asset accounting and can raise share value through the exchange rate. Realized bad debt reduces that asset accounting, so the exchange rate is not guaranteed to only increase. User share balances stay fixed unless they mint, burn, transfer, or have collateral seized.
* **Debt accounting for borrowers:** when a user borrows from the cToken, no cToken shares are minted to them. Instead, the cToken records their debt in an internal `_debtOf` mapping and delivers the underlying directly. Debt grows with interest and is denominated in the underlying asset.
* **Collateral:** an account can post its cToken shares as collateral to support borrowing. Collateral status is tracked per-account via `collateralPosted[account]`.

**Designating a cToken as borrowable in a given market** is governed by the token's configured `debtCap`, not by the `isBorrowable()` function alone. `isBorrowable()` distinguishes the contract type (`BorrowableCToken` vs. pure-lending `BaseCToken`), and is `true` for every live cToken in current deployments. Whether a specific cToken can actually be borrowed from inside a market is determined by `TokenConfig.debtCap > 0`. An asset with `debtCap = 0` cannot be borrowed in that market. It is collateral-only only when collateralization is also enabled through that market's collateral configuration.

This unified approach simplifies the token architecture while maintaining the flexibility for assets to serve different roles within the lending protocol.

<figure><img src="/files/9U5y8EVKBYlKVY4ArzJa" alt=""><figcaption></figcaption></figure>

### Market Manager

The Market Manager is the central contract that:

* Manages risk parameters for all tokens in its isolated market.
* Handles collateral posting and borrow authorization.
* Coordinates liquidation processes (dynamic close factor, dynamic liquidation incentive, auction gating).
* Runs position health checks for borrows and collateral-removing redeems, withdrawals, and transfers. Deposits and mints are checked for listing and mint pause status.
* Each `BorrowableCToken` is linked to a Dynamic Interest Rate Model at deployment and can update that link through `setIRM()`. The Market Manager stores market risk parameters and cap configuration, but it does not wire cTokens to IRMs.

### Position Lifecycle

1. **Deposit:** User deposits underlying assets and receives cTokens representing\
   their share of the pool.
2. **Collateral Posting:** User activates their cTokens as collateral to secure\
   borrowing capacity.
3. **Borrowing:** User borrows underlying assets from borrowable cToken markets\
   against their collateral.
4. **Repayment:** User repays borrowed assets plus accrued interest to reduce debt\
   obligations
5. **Withdrawal:** User redeems cTokens for underlying assets after ensuring\
   adequate collateralization or full debt repayment.

## Asset Management

### Collateral and Debt Management System

The asset management has several key components:

* **Collateral Caps**: Each cToken has a maximum amount of shares that can be posted as collateral, limiting exogenous risk exposure.
* **Debt Caps:** Each cToken has a maximum amount of underlying assets that can be borrowed, providing additional risk management for lending exposure.
* **Collateral Posting:** Assets are posted as shares, allowing caps to grow proportionally with any yield-generating strategies.&#x20;
* **Cap Management:** Both collateral and debt caps can be decreased even if current utilization is above the new cap, which prevents new risk while not forcing position unwinding.&#x20;
* **Dual-cap risk control:** the combination of collateral caps, which limit how many shares can be posted as collateral, and debt caps, which limit borrow-side exposure, provides risk management across both sides of the lending market. Collateral caps are not deposit caps; cTokens can hold deposits beyond the amount that can be posted as collateral.

### Dynamic Liquidation Engine (DLE)

The Dynamic Liquidation Engine enables more nuanced position management:

#### Liquidation State Machine:

1. **Healthy position:** collateral value exceeds required thresholds; `lFactor = 0`.
2. **Soft liquidation threshold:** when the collateral-to-debt ratio falls below the soft threshold, partial liquidations begin. `lFactor` interpolates upward from 0.
3. **Hard liquidation threshold:** when the ratio falls below the hard threshold, complete liquidation is permitted with maximum penalty. `lFactor = WAD` (1e18).
4. **Bad debt handling:** bad debt is not a separate `lFactor` threshold. It is realized during liquidation when the collateral shares needed to cover the debt plus liquidation compensation exceed the account's posted shares. The realized amount is reported as `badDebtRealized` and the debt cToken reduces `_totalAssets`, passing the loss to lenders through the exchange rate.

#### OEV Liquidation Auctions

Curvance features a next-generation liquidation auction system, OEV (Oracle Extractable Value) that maximizes MEV capture:

1. Auction permissions and market unlocks:
   1. Approved auction addresses can unlock a specific Market Manager for auction-based liquidations during the current transaction.
   2. Approved auction addresses can set transient liquidation configuration for a specific collateral cToken, including optional auction close factor and liquidation incentive values.
   3. If both the unlocked market and unlocked collateral match, the liquidation receives the auction priority buffer and any transient parameters. If an auction liquidation is misconfigured, it reverts.
2. Batch liquidation execution:
   1. `liquidate()` and `liquidateExact()` accept arrays of accounts, allowing multiple accounts to be processed in one transaction.
   2. The on-chain loops process accounts sequentially, not concurrently.
3. Off-chain auction coordination:
   1. Off-chain bidding and solver ordering happen outside the core lending contracts.
   2. The on-chain lending contracts enforce auction permissions, market and collateral unlocks, transient liquidation parameters, and liquidation accounting.

### Risk Modeling

Curvance enhances risk modeling through:

1. **Asset-Specific Risk Parameters:** Each asset has customized collateralization requirements.
2. **Three-Tier Liquidation System:** Soft, hard, and bad debt thresholds for graduated liquidation responses.
3. **Position-Health-Responsive Liquidations:** Close factor and liquidation incentive scale with `lFactor`, so deeper shortfall permits larger and more punitive liquidations.
4. **Bad Debt Socialization:** When liquidation realizes `badDebtRealized` because the account's posted collateral cannot cover the debt plus liquidation compensation, the debt cToken reduces `_totalAssets`, passing the loss to lenders through the exchange rate.

The overall architecture provides a powerful framework for managing diverse asset classes while maintaining protocol solvency and capital efficiency.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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.curvance.com/app/developer-docs/lending-protocol.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.