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:
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:
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:
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:
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:
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:
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:
user
address
The address of the user
Return Values:
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:
user
address
The user address
Return Values:
DataTypes.UserConfigurationMap
The configuration of the user
The DataTypes.UserConfigurationMap
struct is composed of the following fields:
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:
address[]
The addresses of the underlying assets of the initialized reserves
Last updated