# Overview
### What is Affluent?
Affluent (formerly Factorial Finance) is infrastructure for Trustless Asset Management, delivering the most seamless access to global yield sources.
Our mission is to make professional, yet fully trustless yield strategies available to everyday users through Telegram-native experiences that hide DeFi complexity and empower frictionless finance. Affluent strikes a deliberate balance: automation with human judgment, retail simplicity with institutional rigor, and sophisticated infrastructure with a intuitive interface.
Through expert-managed vaults operating under code-enforced rules, users interact with a clean Telegram front-end while their liquidity is continuously optimized for performance and safety behind the scenes. Innovation should benefit everyone—not just early adopters.
It is time for **trustless asset management** to prosper.
### Key Features
* **TVM-Optimized Architecture:** Designed to leverage TON Virtual Machine’s parallel-processing capabilities
* **Modular Design, Minimal Overhead:** Highly composable components minimize on-chain message traffic
* **Open Participation:** Anyone can launch a lending market or create a vault
* **Non-Custodial by Design:** Users retain full ownership of their assets at all times
# Concept
### Affluent Market
**Affluent Market** is the core liquidity engine of the protocol. Users can supply assets as collateral, borrow against them, repay loans, and liquidate under-collateralized positions—all within a single, permissionless pool.
**Key Functions:**
* **Supply & Borrow**: Earn interest on supplied asset or use them as collateral to borrow
* **Dynamic Interest Rates**: Rates adjust automatically based on liquidity status
* **Oracle Integration** : Real-time price feeds secure collateral valuations
* **Liquidation Process** : Robust liquidation of risky positions to protect the lenders’ liquidity
### Factory
**Factory** enables permissionless creation of new markets. This allows anyone to create a pool without needing centralized approval, fostering open and decentralized lending.
{% hint style="info" %}
Once the codebase is fully battle-tested, pool creation will become completely permissionless.
{% endhint %}
**Key Functions:**
* **Seamless Pool Deployment**: Initialize a new market in decentralized manner
* **Standardized Parameters**: Consistent market setup for operational integrity
### Strategy Vault
Affluent’s **Strategy Vault** extends beyond simple liquidity allocation. It allows Vault Managers—appointed by the owner—to lend, borrow, swap, and rebalance on behalf of depositors, producing diversified and sustainable yields.
**Key Functions:**
* **Streamlined Yield Optimization** : One-click access to multi-step investment strategies
* **Adaptive Risk Management** : Expert teams continuously monitor and adjust risks
* **Permissionless Liquidity** : Freely deposit or withdraw anytime, subject to liquidity conditions
* **Transparent Operations** : All policies and transactions are fully auditable in real time
# Market
### Isolated Market
Affluent utilizes an isolated market model, where each liquidity pool operates independently without interacting with others. This design safeguards users in other markets from exposure to unforeseen risks while allowing new liquidity pools to be rapidly and securely deployed for any token.
### Supply & Borrow
Participants may supply liquidity to earn interest or post collateral to borrow assets. Borrowing limits and eligible assets are determined by the collateral mix the user provides.
Action
Description
supply
Deposit assets into an Affluent Market.
withdraw
Redeem supplied assets.
borrow
Borrow against posted collateral.
repay
Repay borrowed assets.
liquidate
Seize collateral of under‑collateralized accounts.
#### Market Freeze
Market Freeze temporarily suspends risk-increasing transactions, such as borrowing or collateral withdrawal, during periods of unreliable market pricing. It is primarily triggered to protect lender capital, especially in RWA markets where fair value may be compromised or illiquid.
### Parameters
#### Asset‑Specific
Parameter
Purpose
Risk Factor
Quantifies potential loss given market volatility and liquidity
* Risk Assessment : This loan request is rejected because the resulting Risk Ratio would exceed MaxRiskRatio, even though the Leverage remains acceptable
$$
RiskRatio = \frac{$ 40}{\color{blue}{$ 40}} = \color{red}{100%}
$$
$$
Leverage = \frac{$ 100}{$ 40} = \color{blue}{250%}
$$
#### case1-2) Borrow +$20 TON
Asset
Supply
Borrow
Net Asset
Risk Value
TON (A)
$100
+$20
$80
$32
USDT (B)
-
$40
-$40
$0
Total Value (A + B)
$100
$60
$40
$32
* Risk Assessment : Both risk metrics (Risk Ratio and Leverage) are within the market’s MaxRiskRatio and MaxLeverage limits
$$
RiskRatio = \frac{$ 32}{$ 40} = \color{blue}{80%}
$$
$$
Leverage = \frac{$ 100}{$ 40} = \color{blue}{250%}
$$
### Case2) Borrow $60 TON against $100 tsTON
* Parameter
* \[Asset] Risk Factor : TON 40%, USDT 0%, tsTON 5%
* \[Market] MaxRiskRatio : 80%, MaxLeverage : 300%
| Asset | Supply | Borrow |
|
| ----------------------- | ------ | ------- | ----------------------------------- | -------------------------------------------------- |
| **TON (A = a1 + a2)** | $100 | $70 | $30 | $12 |
| TON (a1) | - | $60+$10 | - | - |
| tsTON (a2) | $100 | - | - | $5 |
| **USDT (B)** | - | - | - | - |
| **Total Value (A + B)** | $100 | $70 | **$30** | **$17** |
* Risk Assessment : A further loan request is rejected because the resulting Leverage would exceed MaxLeverage, even though the Risk Ratio remains acceptable.
$$
RiskRatio = \frac{$ 17}{$ 30} \approx \color{blue}{56.7%}
$$
$$
Leverage = \frac{$ 100}{$ 30} \approx \color{red}{333%}
$$
# Interest Rate Model
The interest-rate model is critical both for rewarding lenders appropriately and for maintaining healthy market liquidity. Rates adjust dynamically with each asset’s utilization ratio, incentivizing liquidity to flow where it is most needed and keeping pools balanced.
Each market can deploy its own interest-rate contract, independent of the lending pool itself. This modular approach—fully aligned with Affluent’s architecture—offers maximum flexibility and easy customization.
### Parameters
Interest Rate Model is asset-specific parameter. Default model is **Jump Rate Model**, which features two utilization “kinks,” creating three slope segments:
Parameter
Description
Base Rate
Interest rate when utilization is 0 %
Kink Points
Utilization thresholds where the slope of the curve changes
Slopes
Rate of interest-rate increase within each utilization band
### Interest Rate Model
#### Utilization Ratio
$$
U\_{t}= \frac {Total \ Borrowed {}} {Total \ Supplied\_{}}
$$
#### Borrow Rate
$$
Borrow(U\_t)= R\_{0} + Slope\_{low} \cdot \min\[U\_{t}, U\_{low}] \ + \ Slope\_{medium}\cdot \min\[\ \max\[0,U\_{t} - U\_{low}],U\_{high}-U\_{low}] \ + \ Slope\_{high}\cdot \max\[0, U\_{t}-U\_{high}]
$$
Where:
* $$R\_0$$ : Base Rate
* $$U\_{low}$$ : Lower kink point
* $$U\_{high}$$ : Higher kink point
* $$Slope\_{low}$$ : Slope at Utilization Ratio lower than $$U\_{low}$$
* $$Slope\_{medium}$$ : Slope at Utilization Ratio between $$U\_{low}$$ and $$U\_{high}$$
* $$Slope\_{high}$$ : Slope at Utilization Ratio higher than $$U\_{high}$$
#### Supply Rate
$$
SupplyRate(U\_t) = Borrow(U\_t) \cdot U\_t
$$
# Liquidation
### Liquitable Account
An account becomes eligible for liquidation whenever **either** of the following metrics breaches the market’s **liquidation threshold**.
$$
Risk Ratio = \frac{\sum\_{i}{f\_i\cdot abs(S\_i -B\_i)}}{S -B}
$$
$$
Leverage = \frac{S}{S -B}
$$
> Liquidation thresholds : `LiquidationRiskRatio` and `LiquidationLeverage` are set at the market level.
To reduce **Risk Ratio**, a user can lower exposure to higher-risk assets.
To reduce **Leverage**, repaying a portion of the debt is most effective.
At high leverage, both metrics become more sensitive to price swings, so proactive management is critical.
### Liquidation Process
1. **Continuous Monitoring**
Constantly tracks each account’s Risk Ratio and Leverage, flagging any position that approaches liquidation thresholds
2. **Action Preparation**
When a liquitable account is detected, liquidators (or automated bots) prepare to intervene, selecting the debt portion to be repaid and the collateral asset to seize
3. **Execution**
The liquidator submits a transaction to repay part of the borrower’s outstanding debt. The repayment amount is capped by `liquidationCloseRatio`, ensuring only a limited slice of the position can be liquidated in a single event
4. **Collateral Seizure**
In return, the liquidator claims the chosen collateral, receiving an extra incentive defined by `liquidationBonus`
### Key Parameters
Parameter
Scope
Purpose
Liquidation Close Ratio
Market
Caps how much of a position can be liquidated in a single transaction, protecting borrowers from full liquidation at once.
Liquidation Bonus
Asset
Percentage premium awarded to liquidators, incentivizing fast action and maintaining market health.
# Oracle
The **Oracle** contract serves as a bridge for retrieving asset price data, using **Redstone** as the underlying data provider. It integrates to deliver real-time asset prices, ensuring that all operations such as vault pricing and liquidation processes, are calculated based on up-to-date market data.
**Key Features:**
1. **RedStone Price Feeds** – Pulls live asset prices from RedStone’s decentralized oracles
2. **Stateless Queries** – Fetches data on demand, ensuring every price is fresh without storing state
3. **Permissionless Access** – Any contract can call the Oracle to retrieve price data as needed.
# Risks
### Smart Contract Risk
Affluent’s contracts could, in theory, contain vulnerabilities or logic errors that jeopardize funds. To mitigate this, all contracts undergo rigorous, independent audits by leading security firms before deployment.
### Oracle Risk
The protocol depends on decentralized oracles for price data. Incorrect feeds—caused by data errors or outages—can lead to mis-priced collateral or liquidations. Affluent integrates highly reliable, decentralized providers and employs redundancy and on-chain sanity checks to minimize this exposure.
### Underlying Asset Risk
Both the lending markets and Strategy Vaults are exposed to movements in the assets they hold. A sharp decline or unexpected failure of an underlying token can lead to under-collateralisation or direct losses. Vault Managers conduct rigorous due-diligence when selecting assets, favouring those with deep liquidity and credible fundamentals. In addition, every asset is subject to an exposure cap, ensuring that no single position can jeopardise overall vault health.
### Liquidation Risk
If a borrower’s Risk Ratio or Leverage breaches market thresholds, collateral is partially liquidated. Strategy Vaults face the same risk whenever they employ leverage—for example in looping or structured borrow strategies. Vault Managers continuously monitor vault metrics and adjust positions pre-emptively so that leverage and risk ratios remain well below liquidation triggers.
### Liquidity Risk
Liquidity represents the ability to access supplied assets. In a lending market, insufficient pool liquidity may temporarily delay withdrawals. Strategy Vaults introduce an additional layer: assets may already be deployed across multiple strategies, making immediate redemption difficult. To mitigate this, each Vault Manager maintains a cash buffer—an idle liquidity reserve—specifically to meet user withdrawals on demand. The protocol’s dynamic interest-rate model further attracts fresh deposits during periods of tight liquidity, restoring normal withdrawal cadence.
# Overview
### Infrastructure for Trustless Asset Management
**Strategy Vault** redefines DeFi asset management by integrating a transparent, trustless infrastructure with professional human oversight. Managed by expert Vault Managers strictly governed by code-enforced rules and safeguarded through structured oversight mechanisms, it enables users to confidently access optimized, risk-adjusted yields through intuitive one-click investments.
**Core Principles:**
* **Mass Adoption:** Eliminate DeFi learning curve, driving mass adoption through seamless integration with Telegram.
* **Open Design:** Allow participants to create and customize their own investment vehicles effortlessly.
* **Diverse Strategies:** Aggregate and manage diverse yield opportunities from multiple sources through vault infrastructure.
* **Off-chain Hybrid:** Mitigate risks associated with purely automated on-chain systems by carefully leveraging trustless off-chain interactions.
* **Truly Trustless:** Every component of the architecture enforces trustless financial interactions among participants.
### How it Works
The architecture of Strategy Vault incorporates layered accountability: Vault Managers are constrained by owner-defined strategies; owners’ decisions undergo mandatory guardian oversight; and guardians remain ultimately accountable to depositors, ensuring comprehensive protection at every stage.
Additionally, asset logistics are outsourced to specialized market makers, significantly reducing operational risk within the vault, isolating it from external contract vulnerabilities, and ensuring smooth and secure asset management.
# Roles
### Owner
Vault Owners can create, configure, and manage vault settings, including permissions, asset policies, and transaction controls.
* **Upgrade Controls:**
* Vault Upgrade \[Timelocked]
* Oracle Configuration \[Timelocked]
* **Authorization:**
* Set Owner: \[Timelocked] Transfer or renounce ownership (single address)
* Set Manager: Appoint or replace vault manager (single address)
* Set Guardian: \[Timelocked] Assign or replace guardian (single address)
* Set Fee Rate: Define management fee rate (capped at 2%)
* Set Fee Recipient : Assign recipient for management fees
* Adjust Timelock : \[Timelocked when decreasing] Modify timelock duration
* **Asset Management:**
* Asset Configuration: \[Timelocked] Define allowed assets. Cap asset exposure
* Immediate execution for decreasing exposure cap
* Lending Pool Configuration: \[Timelocked] Specify authorize and configure pools
* Immediate execution for decreasing exposure cap
* Leverage Cap: \[Timelocked if increase leverage] Limit maximum leverage of vault
* PriceDeviation\_Tolerance : Set max slippage allowed on swaps
### Guardian
Guardians preserve vault integrity by:
* Cancelling any pending timelocked action
* Blocking vault upgrades or authorisation changes
* Vetoing asset‑management changes that would raise risk
### Vault manager
The Vault Manager operates under Owner‑defined rules and pool‑level risk parameters. Actions outside authorized assets or markets are disallowed.
* **Swap:**
* Executes only between whitelisted assets
* Slippage limit must remain within the Owner‑defined tolerance
* **Lending Pool Interaction:**
* Restricted to whitelisted Affluent Markets that enforce their own oracle and risk settings
* **Cash Buffer**
* Maintains idle liquidity to satisfy immediate withdrawals
* `getVaultData` exposes real‑time balances, cash reserves, and per‑market allocations
# Timelock
Certain vault actions that could negatively impact user interests (e.g., increasing leverage limits or modifying risk parameters) are protected by a **timelock**. This ensures users have adequate time to respond, such as withdrawing their funds if they disagree with proposed changes, and offers critical protection if vault owner keys are compromised.
**Key Features:**
* The **Owner** or **Guardian** can revoke pending actions during the timelock
* Timelock durations can range from 0 to a delay of up to 2 weeks (minimum of 24 hours recommended)
**Owner Actions Subject to Timelock:**
* Vault Upgrades
* Oracle Configuration Changes
* Ownership Transfer or Renouncement
* Gurdian Assignment or Replacement
* Reduction of Timelock Duration
* Asset Configuration Adjustment :
(e.g., adding/removing whitelisted assets, increasing exposure caps)
* Lending Pool Configuration Adjustment :
(e.g., adding/removing whitelisted pools, increasing exposure limits)
* Increasing Leverage Cap
#### Vault Upgradability
* Affluent Vault is designed to be upgradable to:
* Maintain liquidity continuity even if transactions fail, distinct from EVM environments
* Support necessary oracle integrations when introducing new assets
* After ownership is renounced, a vault becomes non-upgradable and immutable
# Fee
#### Management Fee
Vault Owner sets a **management-fee rate**, capped at 2% of the vault’s net asset value (NAV). The protocol cannot participate in the governance of the vault. Fees accrue continuously and are paid by minting new vault shares to that address.
#### Withdrawal Fee
A fee charged on withdrawals acts as a friction mechanism to discourage sudden, large-scale liquidity drains (bank runs) from the strategy. This fee helps protect the Net Asset Value (NAV) and the long-term yield of remaining investors by offsetting transaction costs and potential market impact caused by urgent unwinding of positions.
# Oracle-Verified RFQ
### What is OVR?
OVR (**Oracle-Verified RFQ**) is a secure and transparent asset-swapping channel specifically designed for Vault Managers within Affluent. When a Vault Manager initiates a swap, multiple market makers compete by providing quotes to ensure the best execution price.
All proposed prices are verified against oracle. If a quote deviates beyond the pre-defined slippage threshold, the trade is automatically rejected, ensuring only fair, market-aligned transactions are executed.
### Why it Matters?
OVR enforces strict execution rules that shield depositors from excessive slippage and poor pricing. By requiring every quote to remain within an owner-defined tolerance—validated against an oracle—the system blocks trades that could erode user returns. Continuous competition among market makers further compresses costs, delivering better yields even during volatile market conditions.
### Market Maker
Market Makers act as the execution layer between Vault Managers and external protocols. They handle asset swaps, minting, burning, and cross-chain bridging, implementing each vault’s strategic intent without exposing it to unnecessary smart-contract risk. By sourcing quotes and settling trades within oracle-verified price bands, Market Makers ensure efficient delivery of tokenised assets and strategies—including RWAs, DeFi, and CeFi—so Affluent users can access sophisticated opportunities with minimal friction.
### Key Parameters
| Parameter | Description | Configuration |
| ----------------------------- | ----------------------------------------------------------------------------------------------- | ------------------- |
| **Price-Deviation Tolerance** | Maximum slippage permitted per trade, set by the vault owner. | `sendSetRFQConfig` |
| **Min / Max Buy-Asset Value** | Per-order bounds on trade size and slippage, defined by the Vault Manager when creating an RFQ. | In each RFQ payload |
These parameters keep every transaction within predefined risk limits while still allowing Market Makers to compete on price
# Risk Management
#### Deposit Cap
A maximum deposit limit can be set to prevent excessive funds from entering the strategy at once. This mechanism ensures that large, sudden inflows do not rapidly consume exit liquidity or undermine the stability and effectiveness of the current asset allocation strategy.
#### Queue System Implementation
To ensure the Vault can stably process large-scale deposit and withdrawal requests, the Vault Manager executes underlying trades only under optimal market conditions. This prevents adverse market impact and preserves fairness.
Operation Method:
1. Pending State: User deposit or withdrawal requests are first routed to a "Pending Queue."
2. Manager Confirmation: The Vault Manager monitors market variables (e.g., liquidity depth, volatility) and confirms the optimal exchange rate.
3. Batch Execution: Requests are bundled into a "Batch Transfer" and executed simultaneously. This method minimizes market slippage and ensures fair, consistent pricing for all participants within the batch.
# Cross-Chain account
By leveraging Cross-Chain technology, the Vault can securely transfer assets between the TON Chain and external Chains, allowing access to a broader range of DeFi yield opportunities.
#### Cross-Chain Account
A dedicated proxy smart contract account is deployed on each external chain. This account receives execution commands from the TON Vault and executes transactions on its behalf, acting as the operational gateway for external DeFi protocols.
#### Strict Cross-Chain Control
The system enforces strict multi-layered security protocols for all cross-chain operations:
* **Asset/Protocol Whitelist:** The TON Vault pre-specifies and rigorously enforces a whitelist defining which assets the cross-chain account is permitted to hold.
* **Price Deviation Tolerance:** The system compares the total account value immediately before and after a cross-chain transaction. If the value deviates beyond a set tolerance threshold (e.g., due to hacking, smart contract bugs, or abnormal slippage), the transaction is immediately reverted. This serves as a core safeguard protecting assets from abnormal losses during execution.
* **Cross-Chain Integrity:** Messages transmitted between the TON and other chains via the messaging layer (e.g., LayerZero) are rigorously verified to prevent forgery or replay attacks. An integrated error handling mechanism ensures the state across the TON and external chains always remains consistent and synchronized.
#### Cross-Chain workflow description
# Affluent Vault in Telegram Wallet
### **1. How do I find Affluent Vaults in the “Earn” section?**
{% embed url="" %}
1. Open **TON Wallet (**[How to Use the TON Wallet](/tutorial/affluent-vault-in-telegram-wallet/how-to-use-the-ton-wallet))
2. Tap **Earn** (bottom-right in the menu)
3. Select any Affluent product you see, for example:
* **USDT Earn**
* **Gold Earn (XAUt)**
* More vaults coming soon
You will now see the vault’s details and the deposit button.
### **2. How to Use Affluent Vaults?**
{% embed url="" %}
**Deposit:**
1. Choose the vault you want to use
2. Tap **Deposit**
3. Type in the amount you want to add
4. Confirm the transaction inside the TON Wallet
Your funds are now safely stored in Affluent’s Vault and start earning yield seamlessly.
**Checking Balance:**
1. Tap **Earning Assets** in the TON Wallet “Earning” Section
2. You will see:
* Your deposited assets
* Current balance (generated yields are included)
**Withdraw:**
1. Select the vault you deposited into (USDT, Gold)
2. Tap **Withdraw**
3. Enter the amount
4. Withdrawal types:
1. Instant Withdrawal: Enter the desired amount & confirm the transaction, and receive assets instantly
2. Regular Withdrawal: If the desired withdrawal amount is higher than the Vault’s reserve amount, your withdrawal will be settled within 24 hours
# How to Use the TON Wallet
### **1. How do I open TON Wallet inside Telegram?**
**Navigate to the “Search” bar**
* Tap the search bar in Telegram
* Type **@wallet**
* Open the official Wallet bot and create the wallet
Once you have created the wallet, TON Wallet will be displayed in your Telegram Settings. TON Wallet automatically connects to your Telegram account (No extra app or download needed).
### **2. What does TON Wallet look like?**
Telegram has two types of wallets (Crypto Wallet & TON Wallet), Affluent works only with the non-custodial, which is the TON Wallet.
> Note: To get full access to Affluent’s Vault, please make sure you switch your wallet to the TON Wallet.
TON Wallet has three main parts:
#### **TON Wallet**
* Shows your balance
* Shows your wallet address
* Allows you to **send**, **deposit**, or **withdraw** crypto
#### **Swap**
* Allows you to exchange one token for another instantly
(for example: TON → USDT)
#### **Earn**
* This is where you will find **Affluent Vaults (USDT, Gold)**
* You can deposit assets here to earn yield
# Overview
Factorial is built on The Open Network (TON), utilizing its parallelism and scalability to provide a decentralized, permissionless lending solution. The core components of the system include the Pool and Account contracts, which allow users to supply assets as collateral, borrow against their collateral, and manage their lending positions efficiently. The architecture ensures data integrity and prevents race conditions through a robust lock mechanism.
### **Features**
* **Factory-Based Deployment**:The protocol uses a factory contract to streamline the deployment of lending contracts. This approach simplifies the process for users and allows for efficient management and scaling of lending operations within the TON network.
* **TVM Compatibility**: The architecture is specifically designed to align with the TVM's parallel processing capabilities. To manage the concurrent operations effectively, we implemented a read-write lock mechanism on user-specific data, ensuring data integrity and preventing race conditions during transactions.
* **Modular Design with Minimal Message Overhead**: While modularity is a core principle of the architecture, the design also prioritizes minimizing the number of messages exchanged within the network. This approach helps to reduce transaction costs and latency, enhancing the overall efficiency of the protocol.
* **External DeFi Integration**: The architecture supports seamless integration with external DeFi protocols through a plugin system. Each plugin acts as an independent contract responsible for managing connections to external DeFi services, thereby isolating this functionality and allowing the core protocol to remain focused on lending operations.
# Concept
### Liquidity Pool
The **Liquidity Pool** is a core component of the lending protocol, enabling users to supply assets as collateral, borrow against them, repay debts, and liquidate under-collateralized accounts. The pool manages liquidity, interacts with the oracle for real-time price data, and ensures secure and consistent transactions through the use of an account-locking mechanism.
**Key Functions of the Pool:**
* **Collateral Management**: Users can supply fungible tokens (e.g., stablecoins or other assets) as collateral, which are then locked in the pool to secure loans.
* **Borrowing Mechanism**: Users can borrow assets based on the value of their supplied collateral. The pool calculates each user’s Risk ratio, ensuring that they do not borrow more than allowed.
* **Interest Rate Management**: The pool interacts with the Interest Rate Manager (IRM) to adjust interest rates based on the liquidity status of the pool and overall market demand.
* **Oracle Integration**: The pool requests real-time price data from the **oracle** during borrowing and liquidation operations, ensuring accurate calculations of collateral values and liquidation thresholds.
* **Liquidation Process**: The pool allows users to liquidate underwater accounts by seizing collateral in exchange for settling the borrower's debt.
### Factory
The **Factory** contract is designed to enable permissionless creation of new lending pool contracts. This allows anyone to create a pool without needing special permissions, fostering an open and decentralized environment for lending operations.
{% hint style="info" %}
Once the code is sufficiently tested and proven, it will be opened permissionlessly.
{% endhint %}
**Key Functions of the Factory:**
* **Permissionless Pool Deployment**: The factory allows anyone to deploy and initialize a new **Pool** contract, enabling the protocol to scale in a decentralized manner. This permissionless functionality ensures that no centralized authority controls the creation of pools, making the system truly open.
* **Standardized Pool Initialization**: The factory ensures that all newly created pools follow a consistent and standardized process for setup, ensuring operational integrity across the network.
### Vault
The **Vault** is designed to manage users' assets across multiple pools on their behalf. Since it can be challenging for users to actively monitor and manage their assets across multiple pools in real-time, the vault serves as a middle layer, ensuring efficient asset management via a manager or smart contract. The vault simplifies the interaction for users while maintaining consistent and secure asset management across the system.
# Market
### Isolated Pool
Each liquidity pool operates independently and does not interact with others, a feature referred to as "**isolated pools**." This isolation ensures that even if a specific token in one pool suffers a catastrophic event, such as a hack that renders it worthless, the impact is contained within that pool, protecting users of other pools from any fallout. This characteristic fosters a decentralized environment where liquidity pools for any token can be quickly and safely deployed.
### Supply & Borrow Asset
In the market, users can either supply liquidity to a specific pool or borrow assets from it. The types and amounts of assets that users can borrow are determined by the composition of the collateral they supply.
The system evaluates user accounts for risk and determines borrowing limits based on established risk parameters. For a detailed explanation of how risks are assessed and borrowing caps are determined, refer to the [Account Risk](/factorial-legacy/account-risk).
# Oracle
The **Oracle** contract serves as a bridge for retrieving asset price data, using **Redstone** as the underlying data provider. It integrates with the Pool contract to deliver real-time asset prices, ensuring that all operations involving collateral and liquidation are calculated based on up-to-date market data.
**Key Features:**
1. **Price Retrieval with Redstone**: The Oracle fetches asset prices from Redstone's decentralized data providers. This enables the Pool contract to perform accurate calculations for borrow limits, collateral values, and liquidation thresholds.
2. **Stateless Design**: The Oracle does not persist any pricing information internally. It processes requests in real time, ensuring that price data is fresh and relevant.
3. **Permissionless Access**: The Oracle can be queried by any contract (such as Pool) to retrieve price data for various assets.
# Risk
### Smart Contract Risk
Smart contracts can contain vulnerabilities or bugs within their code, potentially impacting the protocol or its underlying assets. To address these risks, Factorial undergoes rigorous external audits by professional third-party security firms.
### Oracle Risk
Factorial relies on decentralized oracles to provide accurate data feeds. While oracles enhance protocol functionality, they can also introduce risks, such as incorrect valuations due to data inaccuracies or system failures. To minimize these risks, Factorial integrates reliable decentralized oracles, which are designed to deliver secure and tamper-resistant data feeds, enhancing reliability and reducing exposure to potential disruptions.
### Underlying Asset Risk
The performance of collateral assets and overall market stability play a critical role in maintaining the health of the ecosystem. Fluctuations in the value or liquidity of collateral can lead to under-collateralization or potential bad debt. The responsibility for assessing these risks lies entirely with the pool owners who create and manage the markets. Pool owners set and adjust the risk parameters, ensuring they align with the specific collateral and market conditions of their pools.
### Liquidation Risk
Factorial market operates with own risk assessment model for liquidation. If Risk Ratio or Leverage of the borrower’s account exceeds the threshold, the collateral may be liquidated. Borrowers must carefully select their markets and actively monitor their positions to maintain healthy account ratios and avoid liquidation events.
### Liquidity Risk
Liquidity represents the ability to access supplied assets. Insufficient liquidity within a market may temporarily prevent lenders from withdrawing their funds. Liquidity risks can be mitigated by using its interest rate model, which dynamically adjusts to market conditions. Before supplying liquidity, it’s important to review the market’s interest rate model to better understand potential withdrawal timelines and liquidity availability.
# Account Risk
The goal of measuring account risk is to maintain stability and minimize risk for both lenders and borrowers. Most lending protocols do this by comparing borrowed assets to collateral(supplied) value, using a Loan-to-Value (LTV) ratio based on the collateral type. Factorial takes it further with a scenario-based approach that factors in "worst-case" outcomes, offering a smarter, more resilient way to evaluate account stability.
### Motivation
The traditional **Loan-to-Value (LTV)** model has inherent limitations when assessing risk for collateralized loans.
1. **Correlation Oversight:** The LTV model fails to account for offsetting price risks when the collateral and loan assets are highly correlated. For example, borrowing TON by supplying tsTON or a TON-USDT LP token as collateral. In such cases, the impact of TON’s price fluctuations on account health is partially or fully offset. However, the LTV model does not factor in this offset, leading to overly conservative or inaccurate risk assessments.
2. **Nonlinear Risk Dynamics:** When DEX LP tokens are used as collateral, the LTV model fails to account for impermanent loss, which occurs as the pool rebalances due to price fluctuations in the underlying assets. By ignoring this dynamic, the LTV model inaccurately assesses the true risk profile of LP collateral.
To address these issues, Factorial introduces a comprehensive risk assessment model that applies to all collateral and loan asset types:
1. **Correlation-Based Risk Offset:** When the collateral and loan assets share underlying correlations, the risk is dynamically offset, reflecting reduced price volatility.
2. **Redefining Collateral Risk:** Collateral with DeFi positions is assessed by factoring in both underlying asset risks and DeFi-specific risks like impermanent loss, and smart contract vulnerabilities, etc., ensuring a comprehensive risk evaluation.
This framework ensures a more accurate and adaptable risk assessment, enhancing both the security and efficiency of lending activities across all types of collateral and loan assets, and setting a new standard for DeFi risk management.
***
### Calculation
$$
Risk Ratio = \frac{\sum\_{i}{f\_i\cdot abs(S\_i -B\_i)}}{S -B}
$$
$$
Leverage = \frac{S}{S -B}
$$
* $$f\_i$$ : Risk Factor of i-th Asset
* $$S\_i$$ : Supplied dollar value of i-th asset in an account \[ S : Total Supplied ]
* $$B\_i$$ : Borrowed dollar value of i-th asset in an account \[ B : Total Borrowed ]
* Assets within DeFi positions are decomposed and calculated in as the same as native assets.
#### Risk Parameter
* **Risk Factor** of i-th asset
* Asset risk : inherent asset risk (ie. market risk, volatility, liquidity risk, etc.)
* DeFi risk : contract/impermanent loss risk
* **Max Risk Ratio:** The maximum allowable risk ratio to open or adjust a position.
* **Liquidation Risk Ratio:** The threshold at which an account becomes subject to liquidation.
* **Max Leverage:** The maximum leverage permitted for opening or adjusting a position.
* **Liquidation Leverage** : The threshold at which an account becomes subject to liquidation.
# Accessing Simple Borrowings
### Case1) Borrow $40 USDT against $100 TON
* parameter
* Risk Factor : TON - 40%
* MaxRiskRatio : 80%, MaxLeverage : 300%
| Asset | Supply | Borrow | Net Asset | Risk Value |
| ------------------- | ------ | ------ | --------- | ---------- |
| TON (B = b1) | $100 | - | $100 | $40 |
| Native (b1) | $100 | - | - | - |
| USDT (C = c1) | - | $40 | -$40 | $0 |
| Native (c1) | - | $40 | - | - |
| Total Value (B + C) | $100 | $40 | $60 | $40 |
* Risk status
* Risk ratio = total risk value / net asset = $40 / $60 = 66.7% ≤ MaxRiskRatio ⇒ OK
* Leverage = total supply / net asset = $100 / $60 = 167% ≤ MaxLeverage ⇒ OK
#### case1-1) Borrow +$20 USDT
| Asset | Supply | Borrow | Net Asset | Risk Value |
| ------------------- | ------ | ----------------------------------------- | --------- | ---------- |
| TON (B = b1) | $100 | - | $100 | $40 |
| Native (b1) | $100 | - | - | - |
| USDT (C = c1) | - | $60 | -$60 | $0 |
| Native (c1) | - | $40 +$20 | - | - |
| Total Value (B + C) | $100 | $60 | $40 | $40 |
* Risk status
* Risk ratio = $40 / $40 = 100% > MaxRiskRatio → Fail
* Leverage = $100 / $40 = 250% ≤ MaxLeverage
#### case1-2) Borrow +$20 TON
| Asset | Supply | Borrow | Net Asset | Risk Value |
| ------------------- | ------ | ------------------------------------- | --------- | ---------- |
| TON (B = b1) | $100 | $20 | $80 | $32 |
| Native (b1) | $100 | +$20 | - | - |
| USDT (C = c1) | - | $40 | -$40 | $0 |
| Native (c1) | - | $40 | - | - |
| Total Value (B + C) | $100 | $60 | $40 | $32 |
* Risk status
* Risk ratio = $32 / $40 = 80% ≤ MaxRiskRatio ⇒ OK
* Leverage = $100 / $40 = 250% ≤ MaxLeverage ⇒ OK
### Case2) Borrow $60 TON against $100 tsTON
* parameter
* Risk Factor : TON - 40%, USDT - 0%, LST - 5%
* MaxRiskRatio : 80%, MaxLeverage : 300%
| Asset | Supply | Borrow | Net Asset | Risk Value |
| ----------------------------- | -------- | ------- | --------- | ---------- |
| **DeFi position (A = a1+a2)** | - | - | - | - |
| DEX (a1) | - | - | - | - |
| Liquid Staking (a2) | $100 | - | $100 | $5 |
| **TON (B = b1 + b2)** | **$100** | $60 | **$40** | **$16** |
| Native (b1) | - | $60 | - | - |
| DeFi position (b2, from A) | $100 | - | - | - |
| **USDT (C = c1 + c2)** | - | - | | **$0** |
| Native (c1) | - | - | - | - |
| DeFi position (c2, from A) | - | - | - | - |
| **Total Value (B + C)** | **$100** | **$60** | **$40** | **$21** |
* Risk status
* Risk ratio = $21 / $40 = 52.5% ≤ MaxRiskRatio ⇒ OK
* Leverage = $100 / $40 = 250% ≤ MaxLeverage ⇒ OK
#### case2-1) Borrow +$20 TON
| Asset | Supply | Borrow | Net Asset | Risk Value |
| ----------------------------- | -------- | ------- | --------- | ---------- |
| **DeFi position (A = a1+a2)** | - | - | - | - |
| DEX (a1) | - | - | - | - |
| Liquid Staking (a2) | $100 | - | $100 | $5 |
| **TON (B = b1 + b2)** | **$100** | $80 | **$20** | **$8** |
| Native (b1) | - | $60+$20 | - | - |
| DeFi position (b2, from A) | $100 | - | - | - |
| **USDT (C = c1 + c2)** | | | | **$0** |
| Native (c1) | | | - | - |
| DeFi position (c2, from A) | | | - | - |
| **Total Value (B + C)** | **$100** | **$80** | **$20** | **$13** |
* Risk status
* Risk ratio = $13 / $20 = 65% ≤ MaxRiskRatio ⇒ OK
* Leverage = $100 / $20 = 500% > MaxLeverage → Fail
# Assessing Leveraged Yield Position
### Case1) Borrow $35 USDT against $100 stTON-USDT LP token
* parameter
* Risk Factor : TON - 40%, USDT - 0%, LST - 5%, LP - 5%
* MaxRiskRatio : 80%, MaxLeverage : 300%
| Asset | Supply | Borrow | Net Asset | Risk Value |
| ----------------------------- | -------- | ------- | --------- | ---------- |
| **DeFi position (A = a1+a2)** | - | - | - | - |
| DEX (a1) | $100 | - | $100 | $5 |
| Liquid Staking (a2) | $50 | - | $50 | $2.5 |
| **TON (B = b1 + b2)** | $50 | - | $50 | $20 |
| Native (b1) | - | - | - | - |
| DeFi position (b2, from A) | $50 | - | - | - |
| **USDT (C = c1 + c2)** | **$50** | $35 | $15 | **$0** |
| Native (c1) | - | $35 | - | - |
| DeFi position (c2, from A) | $50 | - | - | - |
| **Total Value (B + C)** | **$100** | **$35** | **$65** | **$27.5** |
* Risk status
* Risk ratio = $27.5 / $65 = 42% ≤ MaxRiskRatio ⇒ OK
* Leverage = $100 / $65 = 154% ≤ MaxLeverage ⇒ OK
### Case2) Building Delta-neutral LP position
{% hint style="info" %}
step1) Alice wants to provide liquidity to the TON-USDT pair but aims to minimize value fluctuations caused by TON price changes. To achieve this, she balances the amount of TON($66 value) in the $100 of LP with the borrowing amount.
{% endhint %}
| Asset | Supply | Borrow | Net Asset | Risk Value |
| ----------------------------- | -------- | ------- | --------- | ---------- |
| **DeFi position (A = a1+a2)** | - | - | - | - |
| DEX (a1) | $100 | | $100 | $5 |
| Liquid Staking (a2) | - | | - | - |
| **TON (B = b1 + b2)** | **$50** | $66 | **-$16** | **$6.4** |
| Native (b1) | - | $66 | - | - |
| DeFi position (b2, from A) | $50 | - | - | - |
| **USDT (C = c1 + c2)** | **$50** | | $50 | **$0** |
| Native (c1) | - | | - | - |
| DeFi position (c2, from A) | $50 | | - | - |
| **Total Value (B + C)** | **$100** | **$66** | **$34** | **$11.4** |
* Risk status
* Risk ratio = $11.4 / $34 = 33.5% ≤ MaxRiskRatio ⇒ OK
* Leverage = $100 / $34 = 295% ≤ MaxLeverage ⇒ OK
{% hint style="info" %}
step2) Half of the borrowed TON is swapped for USDT and supplied back to the DEX as liquidity. The resulting $66 worth of LP tokens is then used as collateral to borrow additional TON.
{% endhint %}
| Asset | Supply | Borrow | Net Asset | Risk Value |
| ----------------------------- | -------- | -------- | --------- | ---------- |
| **DeFi position (A = a1+a2)** | - | - | - | - |
| DEX (a1) | $100+$66 | - | $166 | $8.3 |
| Liquid Staking (a2) | - | - | - | - |
| **TON (B = b1 + b2)** | **$83** | $110 | **-$27** | **$10.8** |
| Native (b1) | - | $66+$44 | - | - |
| DeFi position (b2, from A) | $83 | - | - | - |
| **USDT (C = c1 + c2)** | **$83** | | $83 | **$0** |
| Native (c1) | - | | - | - |
| DeFi position (c2, from A) | $83 | | - | - |
| **Total Value (B + C)** | **$175** | **$110** | **$56** | **$19.1** |
{% hint style="info" %}
step3) By repeating the previous process, Alice ends up with $200 worth of LP tokens and $100 worth of borrowed TON, creating a position that is neutral to TON price movements.
\[Disclaimer] Due to the nature of the DEX LP, the composition of the LP changes as TON price fluctuates, perfect neutrality is unattainable. Instead, this strategy allows for a position with significantly reduced sensitivity to price changes.
{% endhint %}
### Case3) Leveraging LP position
{% hint style="info" %}
step1) Bob wants to build leveraged LP position by supplying $100 of TON-USDT LP token. Then the user borrowed $33 of TON and USDT each.
{% endhint %}
| Asset | Supply | Borrow | Net Asset | Risk Value |
| ----------------------------- | -------- | ------- | --------- | ---------- |
| **DeFi position (A = a1+a2)** | - | - | - | - |
| DEX (a1) | $100 | - | $100 | $5 |
| Liquid Staking (a2) | - | - | - | - |
| **TON (B = b1 + b2)** | **$50** | $33 | **$17** | **$6.8** |
| Native (b1) | - | $33 | - | - |
| DeFi position (b2, from A) | $50 | - | - | - |
| **USDT (C = c1 + c2)** | **$50** | $33 | $17 | **$0** |
| Native (c1) | - | $33 | - | - |
| DeFi position (c2, from A) | $50 | - | - | - |
| **Total Value (B + C)** | **$100** | **$66** | **$34** | **$11.8** |
* Risk status
* Risk ratio = $11.8 / $34 = 35% ≤ MaxRiskRatio ⇒ OK
* Leverage = $100 / $34 = 294% ≤ MaxLeverage ⇒ OK
{% hint style="info" %}
step2) Borrowed assets can be used as liquidity provision to DEX, minting $66 worth of LP tokens. This LP tokens can then be used as collateral to borrow additional assets.
If Bob repeats this process, he could provide liquidity up to times the initial invested capital.
{% endhint %}
| Asset | Supply | Borrow | Net Asset | Risk Value |
| ----------------------------- | -------- | -------- | --------- | ---------- |
| **DeFi position (A = a1+a2)** | - | - | - | - |
| DEX (a1) | $292 | - | $292 | $14.6 |
| Liquid Staking (a2) | - | - | - | - |
| **TON (B = b1 + b2)** | **$146** | $97 | **$49** | **$19.6** |
| Native (b1) | - | $97 | - | - |
| DeFi position (b2, from A) | $146 | - | - | - |
| **USDT (C = c1 + c2)** | **$146** | $97 | $49 | **$0** |
| Native (c1) | - | $97 | - | - |
| DeFi position (c2, from A) | $146 | - | - | - |
| **Total Value (B + C)** | **$292** | **$194** | **$98** | **$34.2** |
* Risk status
* Risk ratio = $34.2 / $98 = 35% ≤ MaxRiskRatio ⇒ OK
* Leverage = $292 / $98 = 298% ≤ MaxLeverage ⇒ OK
# Liquidation
### Liquitable Account
The **Risk Ratio** and **Leverage** is the key metric used to assess the health of an account:
$$
Risk Ratio = \frac{\sum\_{i}{f\_i\cdot abs(S\_i -B\_i)}}{S -B}
$$
$$
Leverage = \frac{S}{S -B}
$$
When an account’s **Risk Ratio** or **Leverage** approaches the **liquidation threshold**, it becomes a **liquitable account**, indicating a heightened risk of liquidation. To lower the Risk Ratio, users can reduce their exposure to volatile assets. If leverage is the issue, decreasing the borrowed amount is the most effective way to stabilize the account.
The specific impact of these indicators on liquidation depends on the types of supplied and borrowed assets. However, when leverage is high, both the Risk Ratio and Leverage become more sensitive to changes in asset prices, requiring careful attention to avoid crossing the thresholds.
### Liquidation Process
If an account becomes liquidatable, liquidators monitor and intervene by repaying part or all of the outstanding loan and taking ownership of the collateral (supplied asset). At this point, the liquidator can choose any collateral within the account to seize.
The extent of a partial liquidation is capped by the **liquidation\_close\_ratio** specified by each market, which limits how much of the position can be liquidated in a single event. This cap is designed to protect borrowers by preventing their positions from being entirely liquidated at once, giving them a chance to recover and stabilize their accounts.
### Liquidator Bonus
Without timely liquidation, the collateral’s value could drop below the loan amount, leaving the protocol and lenders at risk of losses. The **liquidator bonus** rewards liquidators with an additional portion of the collateral(supplied asset) they seize when they intervene to liquidate a **liquitable account**. The bonus acts as a financial incentive for liquidators to act quickly, ensuring the lending pool’s health and preventing prolonged exposure to underwater positions.
# Interest Rate Model
### Overview
The interest rate model plays a pivotal role not only in providing appropriate returns for lenders but also in managing liquidity risks effectively. Interest rates are dynamically adjusted based on the utilization rate of the liquidity pool, ensuring that the pool remains balanced and functional.
Each liquidity pool can adopt various interest rate models, which are implemented as separate contracts independent of the pools themselves. This design aligns with Factorial's modular architecture, allowing for greater flexibility and customization across different pools.
### Interest Rate Parameter
Each pool has distinct interest rate parameters for each asset. The default interest rate model used is the **Jump Rate Model**, which features two kink points based on the utilization ratio of the borrowed asset.
* Base Rate ($$R\_0$$) : The interest rate when utilization is 0.
* Kink point ($$U\_{low}$$, $$U\_{high}$$) : These thresholds define ranges of utilization at which the slope of the interest rate curve changes.
* Slopes ($$Slope\_{low}$$, $$Slope\_{medium}$$, $$Slope\_{high}$$) : The rate at which interest increases within each utilization range.
### Interest Rate Model
* Utilization Ratio of the target asset in the pool is determined as follows:
$$
U\_{t}= \frac {Total \ Borrowed {}} {Total \ Supply\_{}}
$$
* Borrow Rate
$$
Borrow(U\_t)= R\_{0} + Slope\_{low} \cdot \min\[U\_{t}, U\_{low}] \ + \ Slope\_{medium}\cdot \min\[\ \max\[0,U\_{t} - U\_{low}],U\_{high}-U\_{low}] \ + \ Slope\_{high}\cdot \max\[0, U\_{t}-U\_{high}]
$$
* Supply Rate
$$
SupplyRate(U\_t) = Borrow(U\_t) \cdot U\_t
$$
# Vault Overview
### Motivation
Vault has one loan asset and can allocate deposits to multiple pools. Vaults offer users a way to provide liquidity and earn interest passively. They have a system to automate risk management so that users are not required to make these decisions. Instead, Vault actively curates a risk exposure for all deposited assets. The Vaults operate in a non-custodial way and users maintain full control over their assets. Users can look at the state of the vault at any time and withdraw their liquidity at their discretion.
### Features
* **Supply Liquidity and Auto-rebalance** : Users can supply their assets into the Vault, which automatically allocates liquidity across multiple strategies. The system continuously monitors market conditions and rebalances positions to ensure optimal performance without user intervention.
* **Shared Liquidity : V**aults enable liquidity sharing among multiple pools, maximizing capital efficiency. This pooled approach reduces idle assets and enhances the overall utilization rate across the ecosystem.
* **Optimize Risk-adjusted Return :** Vault managers assess the risk and return profile of each liquidity pool to allocate assets strategically. By focusing on maximizing returns relative to the level of risk, it ensures users gain the best possible yield while maintaining a prudent approach to capital deployment.
* **Tailored Risk Management** : Each Vault is designed to cater to varying risk appetites, allowing users to choose investment strategies that align with their individual preferences. By offering a range of options with different risk-return profiles, vaults enable users to manage their exposure effectively while pursuing strategies that suit their financial goals.
# Concept & Role
### Concept
* **Vault** : Automates asset management across multiple pools for owner.
* **Public Vault :** Specific type of vault that allows users to deposit assets in exchange for shares, representing ownership of the vault.
* **Supply Asset :** The underlying token or asset provided by users or the owner for allocation across different pools.
* **Vault APY** : The annual percentage yield generated by the vault, reflecting the returns from its aggregated strategies.
* **Allocated Pools** : The liquidity pools that are selected for asset allocation.
### Role
* **Owner :** Creator of vault. Owner can decide whitelisted liquidity pool to allocate liquidity and delegate authority for asset allocation to a designated manager.
* **Liquidity Provider(Shareholders)** : Users can deposit liquidity in public vault. Liquidity providers receive pool shares proportional to their deposit, granting ownership rights to the corresponding share.
* **Vault Manager :** Delegated by owner to manage asset allocation, Vault Manager is responsible for setting target weights for liquidity pools and rebalancing assets accordingly. Asset withdrawal(from the vault) is restricted to LPs.
# Governance & Fee
The Vault is governed by its owner :
* Has the authority to appoint a manager.
* Determines which liquidity pools are eligible for the Vault’s allocations by maintaining a whitelist.
* Factorial is not involved in the governance and operation of each vaults.
# Benefits
### Lender
* **Simplified Lending:** Vaults provide a single point of entry, removing the complexity of navigating isolated markets.
* **Passive Management:** Vaults automatically rebalance funds, optimizing the risk-return profile without active involvement from lenders.
* **Tailored Risk Exposure:** Vaults cater to various risk appetites, offering options with different risk-return profiles to suit individual financial goals.
### Borrower
* **Enhanced Liquidity Access:** Borrowers gain access to a deeper liquidity pool due to the Vault's aggregated management across multiple pools.
* **Competitive Rates:** Efficient liquidity allocation by the Vault can lead to more stable and competitive borrowing rates.
* **Flexible Collateralization:** Borrowers may experience better borrowing conditions as the Vault optimizes risk management across different pools.
### Risk Experts/Protocols
* **Effortless Deployment:** With permissionless infrastructure, risk experts can easily create and manage revenue-generating products without needing extensive coding or resources.
* **Direct User Engagement:** Vaults allow risk experts to directly serve users. This creates a more scalable business model while better aligning with the needs and priorities of individual users.
* **Audited and Secure:** The Vault’s infrastructure is audited and secure, lowering barriers to entry and ensuring trustworthiness in risk assessment and management practices.
# Yield Boosting Overview
### What is Yield Boosting?
**Yield Boosting** is the overarching practice of enhancing returns on assets by employing strategies that optimize capital efficiency. It encompasses any method where assets are deployed or reinvested to compound returns, often leveraging the unique opportunities provided by DeFi apps. Yield Boosting is not limited to a specific tactic but represents the philosophy of maximizing productivity from available capital, balancing risk and reward for superior portfolio performance.
### Key Benefits
* **Enhanced Capital Efficiency:** Yield boosting maximizes the utility of each asset by repeatedly cycling it through yield-generating opportunities, effectively doing more with less capital.
* **Increased Returns:** By leveraging borrowed funds and compounding the yields, users achieve significantly higher returns compared to traditional way.
* **Flexibility in Strategy:** Users can choose from a variety of assets (e.g., LSTs, LP tokens) and tailor their approach based on risk tolerance and market conditions.
* **Access to Advanced Strategies:** Yield boosting democratizes sophisticated investment approaches, allowing DeFi participants of all sizes to benefit from advanced compounding techniques typically reserved for large institutions.
# Leveraged Yield Strategy
### Concept
**Leverage Yield Strategy** is a specific approach within yield-boosting framework. It involves borrowing additional funds against collateralized assets to reinvest in yield-generating activities. The mechanics of leverage yield involve using borrowed assets as collateral to secure additional loans, which are subsequently reinvested into yield-generating protocols. By repeating this loop, users can amplify their exposure and returns. While the strategy promises heightened rewards, it comes with increased risks, including liquidation due to market volatility and fluctuating borrowing costs.
### **Examples**
1. **Looping with Liquid Staking Tokens (LSTs):**
A user deposits **liquid staking tokens** (e.g., tsTON or stTON) as collateral to borrow additional assets. The borrowed assets are reinvested to acquire more liquid staking tokens, which are then looped back as collateral. This creates a cycle of compounding returns from staking rewards while increasing the overall exposure to staking yields.
2. **Using DEX LP Tokens:**
A user provides liquidity on a decentralized exchange (DEX), receiving **LP tokens** in return. These LP tokens, representing the user’s share in the liquidity pool, are used as collateral to borrow additional assets. The borrowed assets are then deployed back into the pool or other yield-generating strategies, amplifying the user's returns through compounding.
Detailed process of these examples are as followed.
# Looping LST
#### **Looping with Liquid Staking**
Liquid staking involves locking tokens in a staking protocol to earn rewards while receiving a derivative token that represents the staked assets. This derivative can be used as collateral to borrow additional assets, enabling a leverage loop.
1. **Initial Staking:** A user stakes a base token (e.g., TON) in a liquid staking protocol (e.g., Tonstakers, Bemo, etc.) and receives a derivative token (e.g., tsTON, stTON, etc.).
2. **Collateralizing:** The tsTON is deposited into Factorial as collateral to borrow more TON.
3. **Looping:** The borrowed TON is staked again to mint more tsTON, repeating the process to maximize staked assets.
4. **Yield Generation:** The compounded tsTON balance accrues staking rewards while maintaining exposure to the underlying asset.
**Key Considerations:**
* **Interest Rates:** Borrowing costs must be lower than staking yields for the strategy to remain profitable.
* **Volatility Risk:** Significant price fluctuations in tsTON or TON could trigger liquidation events.
* **Protocol Compatibility:** Ensure the chosen protocols support the required assets and leverage functionality.
# Looping DEX LP
Providing liquidity to decentralized exchanges (DEXs) can also leverage yield strategies, particularly by using LP (Liquidity Provider) tokens as collateral.
**How It Works:**
1. **Initial Liquidity Provision:** A user provides two assets (e.g., TON and USDT) to a DEX liquidity pool and receives LP tokens representing their share of the pool.
2. **Collateralizing LP Tokens:** These LP tokens are used as collateral in a Factorial to borrow additional assets (e.g., TON or USDT).
3. **Reinvestment:** The borrowed TON and USDT can be paired to provide additional liquidity, minting more LP tokens and repeating the process.
4. **Yield Generation:** Users earn trading fees, DEX and Foundation incentives, and potentially staking rewards on the compounded liquidity.
**Key Considerations:**
* **Impermanent Loss:** Volatility between the two paired assets could reduce returns if the pool’s asset ratio changes significantly.
* **Borrowing Costs:** Ensure that lending rates are lower than the combined yield from fees and rewards.
* **Farming Incentives:** Some pools offer additional token rewards, which can significantly enhance profitability.
# Bespoke Features
Since the TVM environment differs from the EVM, special conditions are required for users aiming to engage in yield boosting. Factorial caters to these specific needs by offering specialized features designed to support such users effectively.
### Core Components
#### **Power Account**
Power Account feature allows users to operate with undercollateralization, under specific conditions, enabling easier and more flexible position management. Additionally, account owner can delegate certain execution to a designated manager, who can handle transactions and optimize strategies on the user's behalf.
#### **Integrated Risk Management**
Managed at the account level, enabling a comprehensive approach that considers the correlations between assets and broader DeFi risks. Critical actions are gated by Factorial’s advanced risk tests, ensuring safety and feasibility before execution.
### Toolkit
#### Cockpit
Users need to repeat the process of borrowing assets, providing liquidity, and re-collateralizing multiple times. This tool simplifies the otherwise tedious calculations and actions, streamlining the entire process for efficiency.
#### **Simulator**
Under the assumption of functionalities like flash loans, simulator provides simulation results within a controlled environment, testing the maximum leverage a user can achieve with given capital.