Pool

Introduction

The Pool smart contract is the protocol's main user-facing contract, as most user interactions with Mystic occur via the Pool contract. It exposes the liquidity management methods that can be invoked using either Solidity or Web3 libraries.

Pool is covered by a proxy contract and is owned by the PoolAddressesProvider of any given market. All admin functions are callable by the PoolConfigurator contract defined in the PoolAddressesProvider. By interacting with Pool, users can:

• Supply

• Withdraw

• Borrow

• Repay

• Enable/disable supplied assets as collateral

• Liquidate positions

Methods

Supply

``` function supply(

address asset,

uint256 amount,

address onBehalfOf,

uint16 referralCode

) public virtual override ```

This method supplies a certain amount of an asset into the protocol, minting the same amount of corresponding myTokens and transferring them to the onBehalfOf address. For example, if a user supplies 100 USDC and onBehalfOf address is the same as msg.sender, they will get 100 myUSDC in return.

When supplying, the Pool contract must have allowance() to spend funds on behalf of msg.sender for at least the amount for the asset being supplied. This can be done via the standard ERC20 `approve()` method on the underlying token contract.

Input Parameters:

Name	Type	Description
asset	address	The address of the underlying asset being supplied to the pool
amount	uint256	The amount of asset to be supplied
onBehalfOf	address	The address that will receive the corresponding myTokens. This is the only address that will be able to withdraw the asset from the pool. This will be the same as msg.sender if the user wants to receive myTokens into their own wallet, or use a different address if the beneficiary of myTokens is a different wallet
referralCode	uint16	Referral supply is currently inactive, you can pass 0

This code is used to register the integrator originating the operation, for potential rewards. 0 if the action is executed directly by the user, without any middle-men.

Withdraw

``` function withdraw(

address asset,

uint256 amount,

address to

) public virtual override ```

This method withdraws an amount of underlying asset from the reserve, burning the equivalent myTokens owned. For example, if a user has 100 myUSDC and calls withdraw(), they will receive 100 USDC, burning the 100 myUSDC.

If user has any existing debt backed by the underlying token, then the maximum amount available to withdraw is the amount that will not leave the user's health factor < 1 after withdrawal.

When withdrawing to another address, msg.sender should have myTokens to they may be burned by Pool.

Input Parameters:

Name	Type	Description
asset	address	The address of the underlying asset to withdraw, not the myToken
amount	uint256	The underlying amount to be withdrawn (the amount supplied), expressed in wei units. Use type(uint).max to withdraw the entire aToken balance
to	address	The address that will receive the underlying asset. This will be the same as msg.sender if the user wants to receive the tokens into their own wallet, or use a different address if the beneficiary is a different wallet

Borrow

``` function borrow(

address asset,

uint256 amount,

uint256 interestRateMode,

uint16 referralCode,

address onBehalfOf

) public virtual override ```

This method allows users to borrow a specific amount of the reserve underlying asset, provided the borrower has already supplied enough collateral, or they were given enough allowance by a credit delegator on the corresponding debt token (myVariableLoanToken). For example, if a user borrows 100 USDC passing their own address as onBehalfOf, they will receive 100 USDC into their wallet and 100 variable debt tokens.

NOTE: If onBehalfOf is not the same as msg.sender, then onBehalfOf must have supplied enough collateral via supply() and have delegated credit to msg.sender via approveDelegation().

Mystic's referral program isn't active at the moment, meaning you can pass 0 as referralCode. This program may be activated in the future.

Input Parameters:

Name	Type	Description
asset	address	The address of the underlying asset to borrow
amount	uint256	The amount to be borrowed, expressed in wei units
interestRateMode	uint256	Should always be passed a value of 2 (variable rate mode)
referralCode	uint16	Referral supply is currently inactive, you can pass 0
onBehalfOf	address	This should be the address of the borrower calling the function if they want to borrow against their own collateral, or the address of the credit delegator if the caller has been given credit delegation allowance

Repay

```

function repay(

address asset,

uint256 amount,

uint256 interestRateMode,

address onBehalfOf

) public virtual override

```

Repays a borrowed amount on a specific reserve, burning the equivalent debt tokens owned. For example, if a user repays 100 USDC, the 100 variable debt tokens owned by the onBehalfOf address will be burned.

When repaying, the Pool contract must have allowance to spend funds on behalf of msg.sender for at least the amount for the asset you are repaying with. This can be done via the standard ERC20 approve() method on the underlying token contract. Please note you cannot call repay() multiple times in the same block.

Input Parameters:

Name	Type	Description
asset	address	The address of the borrowed underlying asset previously borrowed.
amount	uint256	The amount to repay, expressed in wei units. Use type(uint256).max in order to repay the whole debt, ONLY when the repayment is not executed on behalf of a 3rd party. In case of repayments on behalf of another user, it's recommended to send an amount slightly higher than the current borrowed amount
interestRateMode	uint256	Only available option is 2 (variableRateMode)
onBehalfOf	address	The address of the user who will get their debt reduced/removed. This should be the address of the user calling the function if they want to reduce/remove their own debt, or the address of any other borrower whose debt should be removed

setUserUseReserveAsCollateral

```

function setUserUseReserveAsCollateral(

address asset,

bool useAsCollateral

) public virtual override ```

This method allows suppliers to enable/disable a specific supplied asset as collateral, as it sets the asset of msg.sender to be used as collateral or not. Do note, an asset in Isolation Mode can only be enabled to use as collateral if no other asset is already enabled to use as collateral.

The user won’t be able to disable an asset as collateral if they have an outstanding debt position which could be left with the Health Factor < HEALTH_FACTOR_LIQUIDATION_THRESHOLD.

Input Parameters:

Name	Type	Description
asset	address	The address of the underlying asset supplied
useAsCollateral	bool	True if the user wants to use the supply as collateral, false otherwise

liquidationCall

```

function liquidationCall(

address collateralAsset,

address debtAsset,

address user,

uint256 debtToCover,

bool receiveAToken

) public virtual override ```

This method liquidates a non-healthy position collateral-wise, meaning one with a Health Factor below 1. To expand on this - when the health factor of a position is below 1, the caller (liquidator) repays the debtToCover amount of debt of the user getting liquidated. This is part or all of the outstanding borrowed amount on behalf of the borrower. The caller then receives a proportional amount of the collateralAsset (discounted amount of collateral) plus a liquidation bonus to cover market risk.

Liquidators can decide if they want to receive an equivalent amount of collateral myTokens instead of the underlying asset. When the liquidation is completed successfully, the health factor of the position is increased, bringing the health factor above 1.

Liquidators can only close a certain amount of collateral defined by a close factor. Currently the close factor is 0.5. In other words, liquidators can only liquidate a maximum of 50% of the amount pending to be repaid in a position. The liquidation discount applies to this amount.

In most scenarios, profitable liquidators will choose to liquidate as much as they can (50% of the user position). If you wish to do this, the debtToCover parameter can be set to uint(-1) and the protocol will proceed with the highest possible liquidation allowed by the close factor. To check a user's health factor, use [getUserAccountData()].

Liquidators must approve() the Pool contract to use debtToCover of the underlying ERC20 of the asset used for the liquidation.

Input Parameters:

Name	Type	Description
collateralAsset	address	The address of the underlying asset used as collateral, to receive as result of the liquidation
debtAsset	address	The address of the underlying borrowed asset to be repaid with the liquidation
user	address	The address of the borrower getting liquidated
debtToCover	uint256	The debt amount of borrowed asset the liquidator will repay
receiveAToken	bool	true if the liquidator wants to receive the myTokens equivalent of the purchased collateral, false if they want to receive the underlying collateral asset directly

getUserAccountData

```

function getUserAccountData(address user) external view virtual override returns (

uint256 totalCollateralBase,

uint256 totalDebtBase,

uint256 availableBorrowsBase,

uint256 currentLiquidationThreshold,

uint256 ltv,

uint256 healthFactor

)

```

Returns the user account data across all the reserves.

Input Parameters:

Name	Type	Description
user	address	The address of the user

Return Values:

Name	Type	Description
totalCollateralBase	uint256	The total collateral of the user in the base currency used by the price feed
totalDebtBase	uint256	The total debt of the user in the base currency used by the price feed
availableBorrowsBase	uint256	The borrowing power left of the user in the base currency used by the price feed
currentLiquidationThreshold	uint256	The liquidation threshold of the user
ltv	uint256	The loan to value of the user
healthFactor	uint256	The current health factor of the user

getUserConfiguration

```

function getUserConfiguration(

address user

) external view virtual override

returns (

DataTypes.UserConfigurationMap memory

) ```

Returns the configuration of the user across all the reserves.

Input Parameters:

Name	Type	Description
user	address	The user address

Return Values:

Type	Description
DataTypes.UserConfigurationMap	The configuration of the user

The DataTypes.UserConfigurationMap struct is composed of the following fields:

Name	Type	Description
data	uint256	Bitmap of the user's collaterals and borrows. It is divided into pairs of bits, one pair per asset. The first bit indicates if an asset is used as collateral by the user, the second whether an asset is borrowed by the user. The corresponding assets are in the same position as getReservesList(). For example, if the hex value returned is 0x40020, which represents a decimal value of 262176, then in binary it is 1000000000000100000. If we format the binary value into pairs, starting from the right, we get 1 00 00 00 00 00 00 10 00 00. If we start from the right and move left in the above binary pairs, the third pair is 10. Therefore the 1 indicates that third asset from the reserveList is used as collateral, and 0 indicates it has not been borrowed by this user

getReservesList

```

function getReservesList(

)external view virtual override

returns (

address[] memory

)

```

Returns the list of the underlying assets of all the initialized reserves. It does not include dropped reserves.

Return Values:

Type	Description
address[]	The addresses of the underlying assets of the initialized reserves