# Overview

### Supply - Earn and Collateralize

Supplying assets to <code class="expression">space.vars.FORK\_NAME</code> allows users to earn interest and, optionally, use their supplied tokens as collateral for borrowing. When an asset asset is supplied, a corresponding amount of aTokens (e.g., aUSDC, aWETH) are minted to the recipient address, which are interest-bearing ERC-20 tokens representing balance of underlying tokens that increases in balance over time by accruing yield from the borrowing activity in the pool.

Withdrawing is the process of redeeming aTokens for the underlying asset, including any accrued interest. Withdrawals are subject to availability of unborrowed liquidity enforced through over-collateralizaiton and interest rate mechanism, and the collaterization of any active borrow positions.

### Borrow - Manage Exposure

Borrowing enables users to access liquidity by utlizing supplied assets as collateral. This process is always overcollateralized, meaning the value of the collateral exceeds the borrowed amount. The protocol manages risk through a Health Factor, which determines the safety of a user's position, and liquidation thresholds, which trigger collateral liquidation if the Health Factor drops below parameter threshold. When a user borrows assets, their borrow position balance is represented by variableDebtTokens (e.g., variableDebtUSDC), which are ERC-20 tokens that track the outstanding borrow balance and accrue interest over time.

Repayment of borrowed assets can be done at any time, and borrow positions are indefinite as long as the overcollateralization is maintained. The Health Factor fluctuates based on the value of the supplied collateral and the borrowed assets, which can change with market conditions and accrued interest. <code class="expression">space.vars.FORK\_NAME</code> utilizes oracles to provide real-time price feeds of the assets, providing inputs to the calculation of the Health Factor and triggering liquidations when necessary to maintain the protocol's over-collateralization.

\
\ <br>


# Liquidity Protocol

A **liquidity protocol** is a decentralised system of smart contracts that facilitates the transfer of digital assets. As a leading liquidity protocol that operates on a supply and borrow model, <code class="expression">space.vars.FORK\_NAME</code> enables users to supply their assets to liquidity pools and, in return, allows other participants to borrow from those pools using their own collateral. The protocol currently operates on the Somnia network, with potential for future multi-chain expansion.

One of the key features of a decentralised liquidity protocol is its non-custodial nature, meaning users maintain control over their assets at all times. Interaction with the protocol happens through self-custodial wallets, allowing users to supply or borrow funds directly, without relying on intermediaries. All of this is managed through publicly accessible and permissionless smart contracts, which execute and verify transactions based on predefined conditions, such as collateral ratios and market parameters, providing a transparent and trustless experience.


# Liquidity Pool

A **liquidity pool** is an <code class="expression">space.vars.FORK\_NAME</code> market instance that enables users to participate as suppliers or borrowers. <code class="expression">space.vars.FORK\_NAME</code> approved parameters, such as reserve configurations and collateralization thresholds, define each pool. Suppliers provide liquidity into the pool that borrowers can access through overcollateralised positions. In return, suppliers earn interest, while borrowers can obtain liquidity against their collateral, all facilitated through decentralised smart contracts.

<code class="expression">space.vars.FORK\_NAME</code> liquidity pools operate on a blockchain network configured with parameters that define the chain and reserve parameters. Parameter decisions must balance liquidity demands for various actions with risk management. The use of smart contracts validate parameters, executing the actions of borrowing, repaying, and liquidation processes seamlessly without intermediaries. This decentralised approach enhances the transparency, efficiency, and security of financial interactions within the pool.

The core actions that can be taken on the liquidity pool are:

### Supply

SuppliersLiquidity Pools

Supplying tokens to the <code class="expression">space.vars.FORK\_NAME</code> Protocol allows users to earn interest on their digital assets and utilise supplied tokens as collateral. When tokens are supplied, they are transferred to the <code class="expression">space.vars.FORK\_NAME</code> liquidity pool, a system of smart contracts that facilitates overcollateralised borrowing of tokens. In <code class="expression">space.vars.FORK\_NAME</code>, supplied tokens automatically accrue interest based on the current market supply rate. As the balance of supplied tokens increases, interest is accrued dynamically, reflecting the current rate allocated to suppliers.

Interest rates for supplied tokens are determined by the borrow utilisation rate, which measures the proportion of assets currently borrowed against the total supplied in the pool. These parameters, including collateralisation requirements and interest rates for suppliers and borrowers, are influenced by onchain inputs such as token balances, oracle prices, and the borrow utilisation ratio. As liquidity is supplied, borrowed, repaid, or withdrawn from the pool, the interest rates are updated accordingly.

### Withdraw

SuppliersLiquidity Pools

<code class="expression">space.vars.FORK\_NAME</code> Protocol allows suppliers to withdraw their supplied tokens, including accrued interest, as long as there is sufficient unborrowed liquidity in the reserve. The withdrawal amount is limited by the available underlying assets, and that the user’s ability to maintain a sufficient collateral ratio for their borrow position. Periphery contracts with features such as withdraw and switch, allow users to redeem their supplied liquidity in a different token, providing more options for efficient asset management.

When withdrawing with an active borrow position, it’s crucial to maintain a healthy collateralisation ratio to avoid liquidation. Reducing collateral can lower the health factor, increasing the risk of liquidation. To remain safe, after the withdrawal, the account must stay above the liquidation threshold parameters. Therefore, withdrawals require careful management and consideration of the overall borrow positions to avoid liquidation.

### Borrow

BorrowersLiquidity Pools

Borrowing tokens from the <code class="expression">space.vars.FORK\_NAME</code> Protocol allows users to access liquidity by using their supplied tokens as collateral, unlocking capital without selling their assets. However, borrowers face liquidation risk if the value of their collateral falls below the required threshold. Interest rates are determined dynamically, influenced by protocol factors and can change over time based on protocol parameters set by <code class="expression">space.vars.FORK\_NAME</code> team. Interest accrues based on the utilisation rate, which reflects the percentage of supplied liquidity that is borrowed. Higher utilisation rates lead to higher interest rates, adjusting with demand. Each reserve has specific parameters designed to incentivize both borrowers and suppliers.

To maintain a healthy ratio and avoid liquidation risk, borrowers should actively monitor their collateralization level, keeping their health factor in check, to assure their borrow positions remain overcollateralised even as market conditions change or interest accrues.

### Repay

BorrowersLiquidity Pools

Repaying borrowed tokens in the <code class="expression">space.vars.FORK\_NAME</code> Protocol is an important step for managing borrow positions. Borrowers can repay using the same tokens they borrowed, or repay with aTokens (collateral tokens) of the same underlying token. In addition, there are periphery contracts available that simplify the process by allowing repayment with other tokens, such as other collateral assets, without the need to manually convert them beforehand. This flexibility makes it easier for borrowers to manage and close their positions when needed.

Repayment increases the collateralisation ratio, ensuring adequate collateralization and preventing liquidation. By boosting the collateral relative to what is borrowed, repayment prevents assets from being liquidated and allows borrowers to safely withdraw part of their collateral.


# Reserve

A **reserve** is an instance of a token within an <code class="expression">space.vars.FORK\_NAME</code> liquidity pool. Each reserve is configured with parameters that manage risk and optimise liquidity. These parameters can vary across different markets, even for the same underlying token, allowing <code class="expression">space.vars.FORK\_NAME</code> to adapt to various network and pool conditions.

### Key Reserve Parameters

1. **Loan-to-Value (LTV)**: The maximum amount that can be borrowed relative to the collateral’s value. For example, a 75% LTV allows borrowing 75% of the collateral’s value. An asset with an LTV of 0% cannot be enabled as collateral.
2. **Liquidation Threshold**: Defines the point at which a position becomes at risk of liquidation. If the threshold is exceeded, the position could be liquidated to repay the borrower's debt.
3. **Borrowing Enabled**: Determines whether liquidity of a reserve can be borrowed.
4. **Caps**: Supply and Borrow caps limit the total amount of a token that can be supplied and borrowed from a reserve. These caps are crucial for maintaining liquidity and preventing overexposure during volatile market conditions​.
5. **Interest Rate Model**: Interest rates in <code class="expression">space.vars.FORK\_NAME</code> adjust dynamically based on the utilisation of the liquidity pool. As more liquidity is borrowed, interest rates rise to reflect the reduced availability of assets, creating conditions that enough liquidity remains for withdrawals and liquidations. The rates are controlled by parameters that set the base rate and slopes for utilisation​.

###

###


# Incentives

Incentives within the <code class="expression">space.vars.FORK\_NAME</code> Protocol encourage active participation from suppliers and borrowers, enhancing liquidity and the overall efficiency of the protocol. It should be noted that there is no one source of various incentive initiatives, but they can originate from multiple sources, including external entities interested in promoting liquidity for specific reserves.

### Liquidity Pool Incentives

Incentives can also be applied to the supply or borrow side of <code class="expression">space.vars.FORK\_NAME</code> liquidity pools, promoting activity of the incentivised reserve. By offering rewards to suppliers and borrowers of certain assets on <code class="expression">space.vars.FORK\_NAME</code>, the visibility and adoption of tokens can be boosted. Such external incentives require approval.

Approved incentives are distributed continuously over time proportional to the amount of liquidity a user supplies or borrows. Users can claim these rewards via the protocol’s incentive controller, which manages the allocation and distribution of incentives. This system adds value for those actively participating in the protocol while aligning user interests with the health and stability of the <code class="expression">space.vars.FORK\_NAME</code> ecosystem.

<br>


# Oracle

Each reserve within the <code class="expression">space.vars.FORK\_NAME</code> Protocol is associated with an oracle contract. These oracle contracts are responsible for reporting the market price of assets in the protocol, which is essential for determining collateralisation requirements.

In <code class="expression">space.vars.FORK\_NAME</code>, oracles are configured by protocol administrators through the AaveOracle contract. Once set, the oracle contract automatically submits price feed updates based on its internal logic (time-based, deviation-based, etc.).

### Types of Oracles in Use

Currently, there are two primary types of oracle contracts utilised on production <code class="expression">space.vars.FORK\_NAME</code> markets:

1. **Chainlink Price Feeds**: Chainlink oracles provide highly reliable, decentralised price data for various assets. These price feeds pull data from multiple sources and aggregate them, minimising the risk of manipulation or outages.
2. **Correlated Assets Price Oracle (CAPO)**: CAPO is designed for assets that have a strong correlation with another asset's price. For example, wrapped tokens can use this oracle to mirror the price of their underlying assets. CAPO leverages specialised logic to adjust and submit prices that follow the movements of these correlated assets.


# Flash Loans

Flash Loans are special transactions that allow the borrowing of an asset, as long as the borrowed amount (and a fee) is returned before the end of the transaction (also called One Block Borrows). These transactions do not require a user to supply collateral prior to engaging in the transaction. There is no real world analogy to Flash Loans, so it requires some basic understanding of how state is managed within blocks in blockchains.

Flash Loans are an advanced concept aimed at developers. You must have a good understanding of EVM, programming, and smart contracts to be able to use this feature.

### Overview

Flash-loan allows users to access liquidity of the pool (only for reserves for which borrow is enabled) for one transaction as long as the amount taken plus fee is returned or (if allowed) debt position is opened by the end of the transaction.

<code class="expression">space.vars.FORK\_NAME</code> V3 offers two options for flash loans:

* flashLoan(): Allows borrower to access liquidity of ***multiple reserves*** in single *flashLoan* transaction. The borrower also has an option to open variable rate borrow position backed by supplied collateral or credit delegation in this case.\
  NOTE: *flash loan fee* is waived for approved flashBorrowers (managed by ACLManager)
* flashLoanSimple(): Allows borrower to access liquidity of *single reserve* for the transaction. In this case flash loan fee is not waived nor can borrower open any debt position at the end of the transaction. This method is gas efficient for those trying take advantage of simple flash loan with single reserve asset.

#### Execution Flow

For developers, a helpful mental model to consider when developing your solution:

1. Your contract calls the Pool contract, requesting a Flash Loan of a certain amount(s) of reserve(s) using flashLoanSimple() or flashLoan().
2. After some sanity checks, the Pool transfers the requested amounts of the reserves to your contract, then calls executeOperation() on receiver contract .
3. Your contract, now holding the flash loaned amount(s), executes any arbitrary operation in its code.
   * If you are performing a **flashLoanSimple**, then when your code has finished, you approve Pool for flash loaned amount + fee.
   * If you are performing **flashLoan,** then for all the reserves either depending on interestRateMode passed for the asset, either the Pool must be approved for flash loaned amount + fee or must or sufficient collateral or credit delegation should be available to open debt position.
   * If the amount owed is not available (due to a lack of balance or approval or insufficient collateral for debt), then the transaction is reverted.
4. All of the above happens in 1 transaction (hence in a single ethereum block).

#### Applications of Flash Loans

<code class="expression">space.vars.FORK\_NAME</code> Flash Loans are already used with <code class="expression">space.vars.FORK\_NAME</code> V3 for liquidity switch feature. Other examples in the wild include:

* Arbitrage between assets, without needing to have the principal amount to execute the arbitrage.
* Liquidating borrow positions, without having to repay the debt of the positions and using discounted collateral claimed to payoff flashLoan amount + fee.

#### Flash loan fee

The flash loan fee is initialized at deployment to 0.05% and can be updated via Governance Vote. Use FLASHLOAN\_PREMIUM\_TOTAL to get current value.

Flashloan fee can be shared by the LPs (liquidity providers) and the protocol treasury. The FLASHLOAN\_PREMIUM\_TOTAL represents the total fee paid by the borrowers of which:

* Fee to LP: FLASHLOAN\_PREMIUM\_TOTAL - FLASHLOAN\_PREMIUM\_TO\_PROTOCOL
* Fee to Protocol: FLASHLOAN\_PREMIUM\_TO\_PROTOCOL

At initialization, FLASHLOAN\_PREMIUM\_TO\_PROTOCOL is set to 0.

### Step by step

#### 1. Setting Up

Your contract that receives the flash loaned amounts **must** conform to the IFlashLoanSimpleReceiver or IFlashLoanReceiver interface by implementing the relevant executeOperation() function.

Also note that since the owed amounts will be *pulled* from your contract, your contract must give allowance to the Pool to pull those funds to pay back the flash loan amount + premiums.

#### 2. Calling flashLoan() or flashLoanSimple()

To call either of the two flash loan methods on the Pool, we need to pass in the relevant parameters. There are 3 ways you can do this.

1. From an EOA ('normal' ethereum account)

   To use an EOA, send a transaction to the relevant Pool calling the flashLoan() or flashLoanSimple() function. See the Pool docs for parameter details, ensuring you use your contract address from step 1 for the receiverAddress.
2. From a different contract

   Similar to sending a transaction from an EOA as above, ensure the receiverAddress is your contract address from step 1.
3. From the *same* contract

   If you want to use the same contract as in step 1, use address(this) for the receiverAddress parameter in the flash loan method.

Never keep funds permanently on your FlashLoanReceiverBase contract as they could be exposed to a 'griefing' attack, where the stored funds are used by an attacker.

#### Completing the flash loan

Once you have performed your logic with the flash loaned assets (in your executeOperation() function), you will need to pay back the flash loaned amounts if you used flashLoanSimple() or interestRateModes = 0 in flashLoan() for any of the assets in modes parameter.

* **Paying back a flash loaned asset**

  Ensure your contract has the relevant amount + premium to payback the borrowed asset. You can calculate this by taking the sum of the relevant entry in the amounts and premiums array passed into the executeOperation() function.

  You **do not** need to transfer the owed amount back to the Pool. The funds will be automatically *pulled* at the conclusion of your operation.
* **Incurring a debt (i.e. not immediately paying back)**

  If you initially used a mode=1 or mode=2 for any of the assets in the modes parameter, then the address passed in for onBehalfOf will incur the debt **if** the onBehalfOf address has previously approved the msg.sender to incur debts on their behalf.

  This means that you can have some assets that are paid back immediately, while other assets incur a debt.

<br>


# Credit Delegation

Credit delegation allows a supplier to contribute liquidity to the <code class="expression">space.vars.FORK\_NAME</code> protocol to earn interest, and delegate borrowing power (i.e. their credit) to other users. The enforcement of the borrow position and its terms are agreed upon between the supplier and borrowers, which can be either offchain via legal agreements or onchain via smart contracts.

This enables:

* The supplier (aka delegator) to earn extra yield on top of the yield they already earn from the protocol.
* The borrowers (aka delegatees) to access uncollateralized liquidity.

Borrow by *delegatee* must be consistent with *delegator* eMode category. For eg. if a delegator eMode category is STABLECOINS, then

* Delegator can only borrow STABLECOINS eMode category asset.
* In case *delegator* approve credit to *delegatee* for non STABLECOINScategory (for eg. weth), then borrow would revert.

The *delegatee* cannot abuse credit approval to liquidate *delegator* i.e. if the borrow puts *delegator's* position in HF < HEALTH\_FACTOR\_LIQUIDATION\_THRESHOLD, then borrow will fail.

### Approving the delegation

The approveDelegation or delegationWithSig function on the VariableDebtToken contract must be called by the supplier (delegator), approving the borrower (delegatee) a certain amount.

This is done for each debt token that needs to be delegated.

The delegator does not need to already have supplied funds in the protocol to approveDelegation. However, **before** the delegatee executes borrow, there must be sufficient collateral supplied by delegator in the protocol.

### Borrowing the credit

The borrower (delegatee) calls the borrow function on the Pool, using the supplier's (delegator's) address in final parameter onBehalfOf.

The borrower's available credit is reduced by the borrowed amount.

### Repaying the credit

Anyone can repay the borrow position *OnBehalf* of the user, by calling one of the following Pool functions - repay or repayWithPermit. The supplier (aka creditor) can also use the repayWithATokens function to repay a borrow position with their *aTokens* of the underlying asset in the same pool.

<br>


# Risks

The <code class="expression">space.vars.FORK\_NAME</code> Protocol offers decentralised access to liquidity but is not without risks. Robust risk management measures, including smart contract audits and carefully set risk parameters, are in place to help mitigate risks. Below is an overview of key risks and mitigation efforts.

### Smart Contract Risk

Smart contracts can contain software bugs or other vulnerabilities within the protocol code and the underlying reserve tokens. To mitigate these risks, <code class="expression">space.vars.FORK\_NAME</code> code is publicly available for audit and has undergone multiple external third-party professional audits. Any proposed changes to the protocol code are thoroughly reviewed and approved prior to implementation by the <code class="expression">space.vars.FORK\_NAME</code> team. Additionally, the protocol runs a continuous bug bounty program to incentivize external developers to identify and report any issues they may find so they can be fixed.

### Oracle Risk

<code class="expression">space.vars.FORK\_NAME</code> relies on third-party oracles for price feeds and external data, such as redemption ratios for liquid staking tokens. This reliance introduces potential risks such as incorrect valuations if an oracle fails or is compromised. To reduce this risk, <code class="expression">space.vars.FORK\_NAME</code> uses decentralised oracles like Chainlink, which provide tamper-resistant data feeds, greater reliability, and security measures.

### Collateral Risk

<code class="expression">space.vars.FORK\_NAME</code> continuously tracks collateral performance and market stability. The value and liquidity of assets used as collateral can fluctuate, leading to the risk of under collateralisation or bad debt. <code class="expression">space.vars.FORK\_NAME</code> mitigates these risks by setting key risk parameters such as loan-to-value (LTV) ratios and liquidation thresholds. These parameters are continuously monitored by risk service providers and can be adjusted by <code class="expression">space.vars.FORK\_NAME</code> team to respond to market conditions.

### Network / Bridge Risk

<code class="expression">space.vars.FORK\_NAME</code> operates across multiple blockchain networks and bridges, each with potential risks such as congestion, censorship, or security vulnerabilities. To address these types of risks, <code class="expression">space.vars.FORK\_NAME</code> uses a careful network onboarding framework that thoroughly vets new networks and bridges before they are integrated into the protocol. Only thoroughly reviewed and secure systems are integrated, minimising risk.

<br>


# Deployed Contracts

| Name                          | Address                                                                                               | ABI |
| ----------------------------- | ----------------------------------------------------------------------------------------------------- | --- |
| Pool                          | [0xEC67...0168](https://explorer.somnia.network/address/0xEC6758e6324c167DB39B6908036240460a2b0168)   | ABI |
| WrappedTokenGateway           | [0xc97d...78dB9](https://explorer.somnia.network/address/0xc97d0602b501B5123a0558dDFEb2A28fD6C78dB9)  | ABI |
| PoolAddressesProvider         | [0x1C13...5f752](https://explorer.somnia.network/address/0x1C13Fea2A9a3Ae9962f12B6afAC1AFcd8205f752)  | ABI |
| PoolConfigurator              | [0x9B67...5bE8](https://explorer.somnia.network/address/0x9B67C48e6E8FE1c4e59B83358bf66C82168be7E8)   | ABI |
| UiPoolDataProvider            | [0x5ef8...89e3E](https://explorer.somnia.network/address/0x5ef828E2C7C55eea505dA3310b0831eD01189e3E)  | ABI |
| UiIncentiveDataProvider       | [0x7327...719b5](https://explorer.somnia.network/address/0x732771d89b2D15a17Ed66aAD43b7bc37116719b5)  | ABI |
| ACLManager                    | [0xCf97...98C32](https://explorer.somnia.network/address/0xCf974cC0C04c49Fb1fD52Bd538Fb366544B98C32)  | ABI |
| WalletBalanceProvider         | [0xcEd6...4da8A](https://explorer.somnia.network/address/0xcEd68D9Acd2663ECCc875996690b1380A754da8A)  | ABI |
| TreasuryCollector             | [0x2BaC...2E6b1D](https://explorer.somnia.network/address/0x2BaC9d4D33B6AbBDD29ac050e03Be0a1032E6b1D) | ABI |
| AaveProtocolDataProvider      | [0x6A8c...9bAF10](https://explorer.somnia.network/address/0x6A8c1d9ff923B75D662Ee839E4AD8949279bAF10) | ABI |
| DefaultIncentivesController   | [0xdA28...95acC](https://explorer.somnia.network/address/0xdA28C6035EA2026E51a697cBEe1FaFaAbA495acC)  | ABI |
| IncentivesEmissionManager     | [0x3eD8...ca5bC](https://explorer.somnia.network/address/0x3eD88b09ff521e17C00c847826bb551C1b3ca5bC)  | ABI |
| PoolAddressesProviderRegistry | [0xac5b...79bCB7](https://explorer.somnia.network/address/0xac5ba04B233A8Dfe0d013c705Ce6B7B36179bCB7) | ABI |
| AaveOracle                    | [0x9b7B...eAaFc](https://explorer.somnia.network/address/0x9b7B5d69a08071ce74C2f3D655038E3b782eAaFc)  | ABI |
| RepayWithCollateral           | [0x8629...204EF](https://explorer.somnia.network/address/0x8629ed5d0C8E5DFd9046FC22FA78598b2Dd204EF)  | ABI |
| CollateralSwitch              | [0xEdDB...9f1b](https://explorer.somnia.network/address/0xEdDB7c126a52DF950a339827A003940CcCe39f1b)   | ABI |
| DebtSwitch                    | [0xf754...c86b9C](https://explorer.somnia.network/address/0xf7544c81d6D28cf683dD776c25376Ce468c86b9C) | ABI |
| WithdrawSwitchAdapter         | [0x3294...9fD8](https://explorer.somnia.network/address/0x3294F7a00994036563010f9F58F3AacFb35B9fD8)   | ABI |
| ACLAdmin                      | [0xD856...1177](https://explorer.somnia.network/address/0xD8566788e827B2fFb258655Ef9d476C5Cc551177)   | ABI |


# Audits

{% embed url="<https://github.com/protofire/Tokos-Audits/blob/main/Deployment%20Verification%20-%20Tokos.pdf>" %}

{% embed url="<https://github.com/protofire/Tokos-Audits/blob/main/Audit%20Tokos%20-%20QuickSwap%20Adapter.pdf>" %}

{% embed url="<https://github.com/protofire/Tokos-Audits/blob/main/Audit%20Tokos%20-%20FallbackOracle.pdf>" %}


# FAQ

### GENERAL

**What is Tokos?**

Tokos is a decentralised liquidity protocol deployed on the Somnia network. It enables users to supply digital assets to earn interest, and to borrow against their collateral in a transparent, non-custodial way.

***

**How do I interact with Tokos?**

You can connect your self-custodial wallet (such as MetaMask or WalletConnect) to the Tokos app, choose an asset, and supply or borrow directly through smart contracts.

***

**Do I need a wallet to interact with Tokos?**

Yes. Tokos is fully non-custodial - all actions (supply, withdraw, borrow, repay) happen directly from your wallet.

***

**What is the cost of interacting with Tokos?**

You pay standard Somnia network gas fees and, if borrowing, interest on the borrowed amount. There are no Tokos platform fees for normal lending operations.

***

**How can I access Tokos?**

Tokos is available through the Tokos App or any integrated dApp that interacts with the Tokos smart contracts on Somnia.

***

**How can I try out Tokos without using actual funds?**

You can connect to the Tokos Testnet (Somnia Testnet), where test tokens can be obtained from a faucet to simulate supplying and borrowing.

***

**Can funds be frozen?**

No. Tokos is non-custodial - only you have control of your assets. However, withdrawals can be temporarily limited if the liquidity pool is fully utilised (i.e., most assets are borrowed).

***

**Why do I need to approve tokens?**

Before interacting with Tokos, you must approve the protocol’s contracts to access specific tokens. This is a standard ERC-20 requirement for all DeFi protocols.

***

### RISK

**What are the risks involved in using Tokos?**

Main risks include smart contract vulnerabilities, oracle errors, and extreme market volatility that may lead to liquidations.

***

**What steps are taken to mitigate risks?**

Tokos contracts are externally audited, use Chainlink oracles for price data, and rely on over-collateralisation to ensure solvency. Parameters such as loan-to-value (LTV) and liquidation thresholds are monitored and can be adjusted by protocol administrators.

***

### SUPPLYING & EARNING

**How do I supply?**

Connect your wallet, select an asset, and click “Supply.” Your tokens are deposited into the liquidity pool and you receive aTokens that represent your position and accrue interest.

***

**How much can I earn?**

Earnings depend on market conditions - specifically the utilisation rate (how much of a pool is borrowed). The higher the borrowing demand, the higher the supply rate.

***

**Are there limitations to supply?**

Some reserves have supply caps to control liquidity risk.

***

**Where are supplied tokens stored?**

Supplied tokens are held by Tokos smart contracts on the Somnia blockchain. You receive aTokens in your wallet representing your share.

***

**How do I withdraw?**

Click “Withdraw” in the Tokos app. You can withdraw your supplied tokens (plus accrued interest) provided enough liquidity is available.

***

**Can I opt-out of my asset being used as collateral?**

Yes. You can disable “Use as Collateral” in the UI. The asset will continue earning interest but will not back any borrow positions.

***

### BORROWING

**How do I borrow?**

Supply collateral, enable it as collateral, and select the asset you wish to borrow. Borrowing requires over-collateralisation.

***

**How much can I borrow?**

Your borrow limit is defined by the LTV ratio of your supplied assets. For example, an asset with a 75% LTV allows borrowing up to 75% of its value.

***

**Why would I borrow instead of selling my assets?**

Borrowing allows you to access liquidity while keeping exposure to your existing tokens (e.g., ETH, WSOMI).

***

**How do I repay my borrow position?**

You can repay any time using the borrowed asset or, in some cases, directly with your collateral via adapter contracts.

***

**How much would I pay in interest?**

Interest rates change dynamically based on pool utilisation. You can view current rates in the Tokos app.

***

**When do I need to pay back the borrow position?**

There is no fixed repayment date - positions remain open as long as the Health Factor stays above the liquidation threshold.

***

### LIQUIDATIONS

**What is Health Factor?**

Health Factor measures how safe your borrow position is. If it drops below 1, part of your collateral can be liquidated.

***

**What happens when my Health Factor is reduced?**

If your Health Factor falls below the liquidation threshold, a portion of your collateral may be sold to repay your debt.

***

**What are liquidations?**

A mechanism that maintains the protocol’s solvency by selling under-collateralised positions.

***

**How much is the liquidation penalty?**

A small percentage (defined per reserve) is added on top of the repaid amount during liquidation.

***

**Can you give an example?**

If you borrowed 100 USDC against collateral worth $150, and its value dropped so your Health Factor fell below 1, part of your collateral would be sold to cover the 100 USDC plus the liquidation penalty.

***

**What is a good Health Factor?**

A value above 2 is considered safe. Closer to 1 means higher liquidation risk.

***

**How can I avoid getting liquidated?**

Monitor your Health Factor and maintain extra collateral, especially during high volatility.

***