💱Swapper - Helper for Liquidations and Auto-Leverage

Swapper - Helper for liquidations and auto-leverage

Contract Name: Swapper
Contract Source: https://github.com/AngleProtocol/borrow-contracts/tree/main/contracts/swapper

1. Introduction

The Swapper contract is an example contract developed by Angle Labs to show how to swap collateral for stablecoins during the liquidation process or to swap stablecoins for collateral during the auto-leverage process in the Borrowing Module. This is a side contract with no specific role in the Borrowing Module.

Documentation here is given as a helper for those who might be interested in building their own contracts or in using Angle Labs' contract.

2. Contract Details

Interface

Implements the ISwapper interface. This contract is not upgradeable (even though upgradeable versions of it could be deployed).

Constants and Immutable Variables

angleRouter: Reference to a router contract of the protocol
core: Reference to the Core contract of the module which handles all Access Control logic
wStETH: Wrapped StETH contract
uniV3Router: Uniswap Router contract
oneInch: 1Inch Router

Mappings

The contract stores three different mappings to check whether Uniswap, 1Inch and Angle routers have been approved for a given token

3. Key Mechanisms & Concepts

Besides a function to change allowance for a given token accessible by governance, there is only one key function available in this contract: it is the swap function.

    function swap(
        IERC20 inToken,
        IERC20 outToken,
        address outTokenRecipient,
        uint256 outTokenOwed,
        uint256 inTokenObtained,
        bytes memory data
    ) external

Generally, the swap function in the ISwapper interface notifies a contract that an address should be given outToken from inToken. In this case, this function swaps the inToken to the outToken by either doing mint, or burn from the protocol or/and combining it with a UniV3 or 1Inch swap, or with a StETH wrap.

No slippage checks are performed at the end of each operation, only one slippage check is performed at the end of the call.

Parameters:

inToken: Address of the token received
outToken: Address of the token to obtain
outTokenRecipient: Address to which the outToken should be sent
outTokenOwed: Amount of outToken owed by the outTokenRecipient. If the Swapper is called during an interaction with a VaultManager contract, for the operation to succeed, the outTokenRecipient's outToken balance should be greater than outTokenOwed at the end of the call. It does not mean that the swap of inTokenObtained should produce at least outTokenOwed.
inTokenObtained Amount of collateral obtained by a related address prior to the call to this function. This swapper implementation assumes that the inToken have been obtained on this contract directly (and therefore that there is no need for a transferFrom)
data: Extra data needed (to encode Uniswap swaps for instance). Specifically, in this implementation, data should be the abi-encoded version of parameters placed in the following order and of the following type:
1. address intermediateToken: Optional address that can be given to specify in case of a burn the address of the collateral to get in exchange for the stablecoin or in case of a mint the collateral used to mint. If the swap call does not involve any mint/burn, then this parameter can be the zero address
2. address to: Address to receive the surplus amount of token at the end of the call. This is the address to receive the leftover inToken and outToken of the swap
3. uint256 minAmountOut: For slippage protection, it is the min amount of outTokens checked at the end of the call
4. uint128 swapType: Type of the swap to execute: if swapType == 3, then it is optional to swap. 0 corresponds to a UniswapV3 swap, 1 corresponds to a oneInch swap, 2 is to wrap StETH to wStETH.
5. uint128 mintOrBurn: Whether a mint or burn operation should be performed beyond the swap: 1 corresponds to a burn and 2 to a mint. It is optional. If the value is set to 1 or 2 then the value of the intermediateToken should be made non null
6. bytes data: It's an optional variable to be used either for Uniswap swaps (in which case it is the path), or a 1Inch payload.

When using this contract as a who contract in a VaultManager call, it is important to make sure that this address is the to address as it needs to receive the inToken.

PreviousSettlement - Closing VaultManager contracts NextImplementation Details

Last updated 1 year ago

1. Introduction

Documentation here is given as a helper for those who might be interested in building their own contracts or in using Angle Labs' contract.

2. Contract Details

Interface

Implements the ISwapper interface. This contract is not upgradeable (even though upgradeable versions of it could be deployed).

Constants and Immutable Variables

angleRouter: Reference to a router contract of the protocol

core: Reference to the Core contract of the module which handles all Access Control logic

wStETH: Wrapped StETH contract

uniV3Router: Uniswap Router contract

oneInch: 1Inch Router

Mappings

The contract stores three different mappings to check whether Uniswap, 1Inch and Angle routers have been approved for a given token

3. Key Mechanisms & Concepts

Besides a function to change allowance for a given token accessible by governance, there is only one key function available in this contract: it is the swap function.

    function swap(
        IERC20 inToken,
        IERC20 outToken,
        address outTokenRecipient,
        uint256 outTokenOwed,
        uint256 inTokenObtained,
        bytes memory data
    ) external

No slippage checks are performed at the end of each operation, only one slippage check is performed at the end of the call.

Parameters:

inToken: Address of the token received

outToken: Address of the token to obtain

outTokenRecipient: Address to which the outToken should be sent

outTokenOwed: Amount of outToken owed by the outTokenRecipient. If the Swapper is called during an interaction with a VaultManager contract, for the operation to succeed, the outTokenRecipient's outToken balance should be greater than outTokenOwed at the end of the call. It does not mean that the swap of inTokenObtained should produce at least outTokenOwed.

inTokenObtained Amount of collateral obtained by a related address prior to the call to this function. This swapper implementation assumes that the inToken have been obtained on this contract directly (and therefore that there is no need for a transferFrom)

data: Extra data needed (to encode Uniswap swaps for instance). Specifically, in this implementation, data should be the abi-encoded version of parameters placed in the following order and of the following type:

address intermediateToken: Optional address that can be given to specify in case of a burn the address of the collateral to get in exchange for the stablecoin or in case of a mint the collateral used to mint. If the swap call does not involve any mint/burn, then this parameter can be the zero address
address to: Address to receive the surplus amount of token at the end of the call. This is the address to receive the leftover inToken and outToken of the swap
uint256 minAmountOut: For slippage protection, it is the min amount of outTokens checked at the end of the call
uint128 swapType: Type of the swap to execute: if swapType == 3, then it is optional to swap. 0 corresponds to a UniswapV3 swap, 1 corresponds to a oneInch swap, 2 is to wrap StETH to wStETH.
uint128 mintOrBurn: Whether a mint or burn operation should be performed beyond the swap: 1 corresponds to a burn and 2 to a mint. It is optional. If the value is set to 1 or 2 then the value of the intermediateToken should be made non null
bytes data: It's an optional variable to be used either for Uniswap swaps (in which case it is the path), or a 1Inch payload.

When using this contract as a who contract in a VaultManager call, it is important to make sure that this address is the to address as it needs to receive the inToken.