# GnoLend v0
### Lending Platform on Gno.land

*⚠️ This version is deprecated and no longer maintained. Please refer to the [latest version](https://hackmd.io/@stefann/stefans-proposal).*

## 1. Protocol Overview
GnoLend is a non-custodial lending protocol on Gno.land that facilitates lending and overcollateralized borrowing of crypto assets. The protocol operates through **isolated lending pools**, where each pool contains a single **GRC20 token**.

When users deposit assets into a pool, they receive **interest-bearing gTokens**, which represent their share of the lending pool. These gTokens accrue interest via a **static rate mechanism** and are transferable as **GRC20 tokens**. Users can borrow assets from any pool by providing collateral that exceeds their borrowed position value, with borrowing limits determined by asset-specific **Loan-to-Value (LTV) ratios**.

### Lending Pool State Variables
Each lending pool maintains the following key data:

- **Total Supplied Assets** – Tracks the amount of assets deposited into the pool.
- **Total Borrowed Assets** – Measures the outstanding borrowed funds.
- **Accumulated Interest Rates** – Stores interest accrual for both suppliers and borrowers.
- **Asset-Specific Risk Parameters** – Defines collateral factors, liquidation thresholds, and borrow limits.

### Price Discovery & Risk Management
- **Price Discovery**: The protocol derives asset prices from **Gnoswap's liquidity pools**, using the **sqrtPriceX96 format** with appropriate decimal normalization.
- **Risk Management**: A **health factor system** monitors position collateralization. If a position's **health factor drops below 1**, it becomes eligible for **liquidation**, allowing liquidators to repay debt in exchange for discounted collateral.

## 2. Core Mechanics
GnoLend uses an **interest-bearing token model**, where users receive **gTokens** upon depositing assets into lending pools. These gTokens represent the user's share of the pool, including accrued interest. The system functions similarly to Aave’s aTokens, ensuring that depositors earn yield passively while maintaining liquidity through transferable **GRC20-compliant gTokens**.

### 2.1. Interest Accrual
Interest accrues continuously per block for both suppliers and borrowers. The protocol initially applies **static interest rates**, set through governance for each asset. Interest is compounded using the following formulas:

Supply Interest = Principal * (1 + supplyRate)^blocks
Borrow Interest = Principal * (1 + borrowRate)^blocks

When users supply assets, they receive **gTokens at a 1:1 ratio** to their deposit. Interest accrues over time, but instead of increasing the gToken balance, the **Liquidity Index** grows, which increases the redeemable value of gTokens.

Each user’s claimable amount is determined as:

redeemableAmount = gTokenBalance * (currentLiquidityIndex / initialLiquidityIndex)

This eliminates the need for an exchange rate mechanism, as **gTokens always represent a proportional share of the lending pool, with accrued interest embedded in the Liquidity Index**.

### **2.2. Position Management**

Users can manage their positions through the following actions:

1. **Supply assets** to a lending pool and receive gTokens in return.
2. **Enable or disable collateral** to determine which supplied assets can be used for borrowing.
3. **Borrow assets** against enabled collateral, up to the asset’s Loan-to-Value (LTV) limit.
4. **Repay borrowed amounts**, including accrued interest, to restore borrowing capacity.

#### **Borrowing Limit Calculation**
The maximum amount a user can borrow is determined by the value of their supplied collateral and the asset-specific LTV ratio:

maxBorrow = collateralValue * LTV

Ensuring that all loans remain **overcollateralized** helps maintain protocol security and mitigates liquidation risks.

### 2.3. Price Feed Implementation
Currently, Gno.land lacks a reliable Oracle for token price feeds; therefore, the protocol relies on Gnoswap's liquidity pools for price discovery.

Prices are derived from **Gnoswap's concentrated liquidity pools**, where prices are stored in the **sqrtPriceX96 format**—a fixed-point representation commonly used in automated market makers (AMMs). The actual price is extracted and adjusted for token decimals through the following calculations:

#### 2.3.1. Converting `sqrtPriceX96` to Actual Price
Since the price is stored in a square root format, we first **square the `sqrtPriceX96` value** to obtain the raw price. However, because `sqrtPriceX96` is a **Q96 fixed-point number** (meaning it has 96 fractional bits), squaring it results in a **Q192 fixed-point number**. To bring it back to a standard integer format, we divide by 2^192:

price = (sqrtPriceX96 * sqrtPriceX96) / (2^192)

#### 2.3.2. Adjusting for Token Decimals
Different tokens have different decimal precisions (e.g., USDC has 6 decimals, while GNOT has 12). To correctly scale the price, we adjust by the **difference in decimals between token0 and token1**:

adjustedPrice = price * (10^(token0Decimals - token1Decimals))

This ensures that the computed price is properly denominated based on the token pair's decimal format.

Through this approach, the protocol extracts reliable price data directly from **Gnoswap's liquidity pools**, making it functional even without an external Oracle.

### **2.4. Liquidation Mechanism**

The protocol uses a **health factor** to determine position safety. If a user's health factor falls below **1**, their position becomes eligible for liquidation.

#### **2.4.1. Health Factor Calculation**
The health factor represents the ratio of collateral value to borrowed value, adjusted by the liquidation threshold:

healthFactor = (collateralValue * liquidationThreshold) / borrowValue

- If **healthFactor > 1**, the position is safe.
- If **healthFactor ≤ 1**, the position can be liquidated.

#### **2.4.2. Liquidation Process**
When liquidation occurs:
- **Liquidators can repay up to 50% of the outstanding debt.**
- In return, they receive the equivalent collateral **at a discount**, defined by the **liquidation bonus**.

#### **2.4.3. Collateral Received by Liquidator**
The amount of collateral liquidators receive is determined as follows:

collateralReceived = debtRepaid * (1 + liquidationBonus) / collateralPrice

Where:
- `debtRepaid` = Amount of debt the liquidator covers.
- `liquidationBonus` = Additional collateral received as an incentive.
- `collateralPrice` = Market price of the collateral asset.

This mechanism ensures that undercollateralized positions are **efficiently liquidated**, maintaining protocol solvency and protecting lender funds.

### **2.5. Position Monitoring**

The protocol continuously tracks key metrics for each user position to ensure accurate risk assessment and prevent undercollateralized borrowing. All values update dynamically with every user action.

#### **1. Collateral Value**
- Total value of all supplied assets, converted into the **base currency** (GNOT).
- Computed as:

Collateral Value = Sum(Asset Amount * Price)

- Used to determine borrowing limits and liquidation risk.

#### **2. Total Borrowed Value**
- The total outstanding debt, including accrued interest.
- Tracked per asset and converted into the **base currency**:

Borrowed Value = Sum(Borrowed Amount * Price)

- Determines how much more a user can borrow before reaching the limit.

#### **3. Health Factor**
- Represents how safe a position is relative to its liquidation threshold.
- Calculated as:

Health Factor = (Collateral Value * Liquidation Threshold) / Borrowed Value

- If **Health Factor < 1**, the position is **eligible for liquidation**.

#### **4. Available Borrowing Power**
- The additional amount a user can borrow before reaching the max LTV.
- Formula:

Max Borrowable = (Collateral Value * LTV) - Borrowed Value

- If **Available Borrowing Power = 0**, the user cannot borrow more.

#### **5. Liquidation Price**
- The price at which the collateral value drops low enough to trigger liquidation.
- Computed per collateral asset:

Liquidation Price = (Borrowed Value / Collateral Amount) * Liquidation Threshold

- If the market price falls below this, liquidation can occur.

These metrics ensure that user positions are **accurately monitored** and that **risk is managed dynamically**, preventing protocol insolvency.

## 3. Governance
The protocol operates under a decentralized governance model, enabling GNL token holders to actively participate in decision-making processes. This governance framework extends GnoSwap's existing system to accommodate lending-specific parameters. Token holders engage in protocol governance by voting on various aspects, including:

- **Pool Creation**: Deciding on the establishment of new lending pools.
- **Risk Parameters**: Setting and adjusting parameters such as collateral factors and liquidation thresholds to manage protocol risk.
- **Interest Rate Adjustments**: Modifying interest rate models to ensure competitive and sustainable lending and borrowing rates.
- **Emergency Controls**: Implementing measures to protect the protocol during unforeseen events or market volatility.

For more details on how the GnoSwap governance model works, refer to GnoSwap Governance [Documentation](https://docs.gnoswap.io/core-concepts/governance) and [Implementation](https://github.com/gnoswap-labs/governance).

## 4. User Inteface

The protocol's user interface provides functionality similar to other lending platforms like Aave and Compound on Ethereum. It allows users to monitor and manage their positions.

### 4.1. Features

- **Position Monitoring**: Displays active deposits, borrows, and overall account status.
- **Health Factor & Risk Management**: Shows health factor, borrowing power, and liquidation thresholds.
- **Collateral Management**: Allows users to enable or disable collateral for borrowing.
- **Interest Rates & Market Data**: Provides real-time supply and borrow rates, and liquidity data.

The interface is designed to provide essential data and controls for managing lending and borrowing operations.

## 5. Future Improvements

The initial version of GnoLend implements core lending functionality with static interest rates and Gnoswap price feeds. Future updates will focus on improving capital efficiency, risk management, and user functionality.

### 5.1. Oracle Implementation
Once a reliable Oracle system becomes available on Gno.land, the protocol will integrate a more robust price feed system using **Volume-Weighted Average Price (VWAP)** from Gnoswap pools. This will aggregate price data over multiple time windows to reduce price manipulation risks. The VWAP calculation will incorporate **trading volume and liquidity depth** to improve accuracy.

For more information on VWAP, refer to [GnoSwap VWAP implementation](https://github.com/gnoswap-labs/vwap).

### 5.2. Dynamic Interest Rate Model
The current static interest rate model will transition to a **utilization-based dynamic interest rate system**. Interest rates will adjust automatically based on pool utilization, ensuring more efficient capital allocation and better liquidity management.

### 5.3. Flash Loans
Flash loans will allow users to execute atomic transactions such as **arbitrage, collateral swaps, and liquidations** without upfront capital. These loans must be borrowed and repaid within the same block, with a small fee contributing to protocol revenue.

### 5.4. Protocol Incentives
An incentive system will be introduced to support protocol sustainability and efficiency by:
- Encouraging liquidity provision in key markets
- Maintaining optimal utilization rates
- Incentivizing timely liquidations
- Rewarding long-term protocol participants

These improvements will enhance GnoLend’s functionality and adaptability as the ecosystem evolves.