CLOB(deCentralized Lending Order Book)

📖 Centuari Protocol — deCentalized Lending Order Book (CLOB) Matching Engine

📌 Overview

In traditional DeFi lending protocols, liquidity provision and borrowing often rely on pooled automated market makers (AMMs) or static peer-to-pool models. However, Centuari innovates by integrating a Central Limit Order Book to deCentalized Lending Order Book as its core matching infrastructure, enabling lenders and borrowers to directly submit and compete through limit orders.

This allows the protocol to achieve:

• Dynamic interest rate discovery

• Precise underwriting exposure control

• Composable order-based lending markets

---

📌 How It Works: Lender & Borrower Matching

In Centuari:

• Lenders submit lend orders, specifying the amount of assets they’re willing to lend, the fixed interest rate, and market duration.

• Borrowers submit borrow orders, detailing how much they wish to borrow, the maximum rate they’re willing to pay, and the loan period.

The CLOB matches these orders based on:

• Price Priority (lowest lending rate matched first)

• Time Priority (earliest order gets filled first when rates match)

• Collateral / Underwriting Validation (through MRVCE and Oracle)

Once a match occurs:

• The system locks the lender’s liquidity.

• The borrower’s underwriting capacity (backed by RAV) is validated.

• The position is opened, and repayment obligations are tracked.

---

📌 Code-Level Example: Match Orders Function

Taken from CentuariCLOB.sol:

matchOrders(Id marketId, uint256 maxMatchCount) external onlyOwner {
    MarketConfig storage market = CentuariCLOBDSLib.getMarket(marketId);
    
    OrderQueueLib.matchOrders(
        market.orderQueue,
        market.priceTickSize,
        maxMatchCount
    );
}

Explanation:

• This function matches up to maxMatchCount pairs of orders from the order queue of a given marketId.

• The OrderQueueLib.matchOrders function is responsible for performing the actual matching logic, following price-time priority rules.

• Only the protocol owner or authorized service operator can trigger this function, ensuring controlled order execution.

---

📌 Order Structure & Data Model

Defined in CentuariCLOBDSLib.sol:

struct Order {
    Id id;
    address trader;
    Side side;          // Lend or Borrow
    uint256 amount;     // Principal value
    uint256 rate;       // Fixed interest rate
    Status status;      // Open, Matched, Cancelled
    uint256 createdAt;
}

Details:

• Side differentiates lenders from borrowers.

• rate allows fixed-rate lending markets, unlike variable-rate pool protocols.

• status tracks order lifecycle, facilitating transparency and dispute resolution.

• createdAt is used for time priority matching.

---

📌 Integration with Oracle, RAV, and Liquidation System

Once orders are matched:

1. The borrower’s underwriting capacity is validated via the Modular Risk-Weighted Virtual Collateral Engine (MRVCE).

2. The system queries oracle feeds for real-time prices, converts collateral to Risk-Adjusted Value (RAV) using governance-defined risk weights.

3. If underwriting capacity suffices, the position is confirmed.

4. If the borrower defaults:

   • The system triggers liquidation based on a liquidity preference tier, liquidating the most liquid assets first (e.g., stETH before EIGEN).

   • The liquidation process uses oracle prices to determine collateral value and open CLOB orders to auction the seized collateral, protecting lenders and maintaining market solvency.

---

📌 Why Use a CLOB for DeFi Lending?

Advantage	Explanation
True Market Discovery	Rates are set by supply and demand through visible limit orders, not static curves.
Order Customization	Lenders and borrowers can specify exact terms: amount, duration, rate.
Composability	CLOB integrates smoothly with underwriting and oracle validation processes.
Capital Efficiency	Orders remain open until matched — no idle capital stuck in a pool.
Slashing Integration	CLOB clearing can trigger liquidation orders on default events, enforcing underwriting obligations.

---

📌 Conceptual Process Flow

1. Operator submits underwriting capacity.

2. Borrower submits borrow order (amount, rate, duration).

3. Lender submits lend order (amount, rate).

4. CLOB matches orders based on price-time priority.

5. Oracle verifies real-time prices for underwriting validation.

6. Risk Engine computes total RAV for borrower.

7. If valid → position opened, else rejected.

8. If default → liquidation executed via preference-based CLOB clearing.

---