AngleRouter01.sol
mixer()
function first loads or receives all the funds needed for further actions, either through receiving, claiming, or withdrawing tokens.claimRewards
, only for gauges of type 0 and 1claimWeeklyInterest
gaugeDeposit
withdraw
mint
deposit
openPerpetual
addToPerpetual
veANGLEDeposit
VaultManager
to create a vault, add or remove collateral, borrow stablecoins, repay a debt, permit an asset or transferring debt to another vault: borrower
mixer
transaction.Initializable
and ReentrancyGuardUpgradeable
from Open Zeppelin.mixer
function of the contract.mixer()
function.claimRewards
(only for gauges of type 0 and 1)claimWeeklyInterest
gaugeDeposit
withdraw
mint
deposit
openPerpetual
addToPerpetual
veANGLEDeposit
borrower
ParamsSwapType
argument when calling the mixer()
function. It indicates if the swap needs to be performed through UniswapV3 or 1Inch.UniswapV3
oneINCH
WrapStETH
None
mixer()
function and performing a token swap. Users should be wary of using the correct routes to not risk losing funds. In particular they should make sure the end token of the swap is collateral
.inToken
: token to swap for the collateralcollateral
amountIn
: amount received and to be swappedminAmountOut
: slippage protectionargs
: path of the swap on UniswapV3 if swapType
is UniswapV3
, or the payload (data) received by the 1Inch API if swapType
is oneINCH
.swapType
: defined aboveinToken
amountIn
mixer()
function to perform the grant allowances to msg.sender
through permit signatures.token
owner
: address to approvevalue
deadline
v
r
s
mixerVaultManagerPermitFunction
to approve an address (normally the router) for all the vaultsvaultManager
owner
approved
: whether to approve or not the owner
for all the vaults in the VaultManager
deadline
v
r
s
poolManager
perpetualManager
sanToken
gauge
governor
: address of the governorguardian
: address of the guardianuniswapV3Router
: address of Uniswap V3 routeroneInch
: address of 1inch routerparamsSwap
). Yet the protocol does not verify the payload given and cannot check that the swap performed by users actually gives the desired out token: in this case funds will be lost by the user.PermitType
, TransferType
, ParamsSwapType
, ActionType
are given in the above Types section.paramsPermit
: Array of params PermitType
used to approve the router for a set of tokens with the permit
standard. Users willing to interact with the contract with tokens that do not support permit should approve the contract for these tokens prior to interacting with itparamsTransfer
: Array of params TransferType
used to transfer tokens to the routerparamsSwap
: Array of params ParamsSwapType
used to swap tokens previously transferred to the routeractions
: List of actions to be performed by the router (in order of execution)data
: Array of encoded data for each of the actions performed in this mixer. Before calling an action, it is important to make sure to read the documentation of the associated internal functions to know how to exactly specify parameters.mixer
contract.mint
, deposit
, openPerpetual
, addToPerpetual
, withdraw
), users are required to give in the corresponding data
the proportion of the amount of token they have brought prior to the router (through direct transfer or a swap) they want to use for the operation. If you want to use all the USDC you have brought (through an ETH -> USDC swap for instance) to mint stablecoins, you should use BASE_PARAMS
as a proportion.mint
and the rest for an openPerpetual
, proportion used for the mint
should be 50% (that is BASE_PARAMS/2
), and proportion for the openPerpetual
should be all that is left that is 100% (= BASE_PARAMS
).addressProcessed
parameter which lets users precise whether they know the protocol contracts addresses or have specified an associated address. For instance, users may not know all our StableMaster
address and only know the corresponding AgToken
address, in which case if there is a parameter addressProcessed
, they should set it to no and if the parameter is stablecoinOrStableMaster
they should give the stablecoin address.claimRewards
address user
: address of the user to claim rewards foruint256 proportionToBeTransferred
: proportion of the claimed ANGLE tokens to be transferred back to the router to perform actions on itaddress[] memory claimLiquidityGauges
: Liquidity gauges where to claimuint256[] memory claimPerpetualIDs
: Perpetual IDs where to clambool addressProcessed
address[] memory stablecoins
address[] memory collateralsOrPerpetualManagers
claimWeeklyInterest
address user
: user to claim foraddress feeDistributor
: contract to claim onbool letInContract
: whether the claimed sanTokens should stay in the router
contract to be used for other actionsveANGLEDeposit
address user
: user to deposit foruint256 amount
gaugeDeposit
address user
: user to deposit foruint256 amount
: proportion of the staked token to depositaddress stakedToken
: token to depositaddress gauge
: gauge where to depositbool shouldClaimRewards
deposit
address user
: user to deposit foruint256 amount
: amount to deposit (it's a proportion of the corresponding's collateral balance)bool addressProcessed
address stablecoinOrStableMaster
address collateral
: token to deposit (it can be null if addressProcessed
)address poolManager
: PoolManager associated to the collateral (null if addressProcessed
is not true)address sanToken
: SanToken associated to the collateral
(null if addressProcessed
is not true)withdraw
uint256 amount
: amount of sanTokens to withdraw (it's a proportion of the sanToken balance available on the router)bool addressProcessed
address stablecoinOrStableMaster
address collateralOrPoolManager
mint
address user
: user to mint foruint256 amount
: amount to mint (it's a proportion of the corresponding's collateral balance)uint256 minStableAmount
: slippage protectionbool addressProcessed
address stablecoinOrStableMaster
address collateral
: token to deposit (it can be null if addressProcessed
)address poolManager
: PoolManager associated to the collateral (null if addressProcessed
is not true)openPerpetual
address user
: user to open perpetual foruint256 amount
: amount to put as a margin (it's a proportion of the corresponding's collateral balance in the router contract)uint256 amountCommitted
: committed amount in the perpetual contract to createuint256 extremeRateOracle
: Maximum oracle value at which the vault should be createduint256 minNetMargin
: Minimum margin to store in the vaultbool addressProcessed
address stablecoinOrPerpetualManager
address collateral
: Collateral to open perpetual from (it can be null if addressProcessed
is true)addToPerpetual
uint256 amount
: amount to add to the margin (it's a proportion of the corresponding's collateral balance in the router contract)uint256 vaultID
: ID of the vault to add collateral tobool addressProcessed
address stablecoinOrPerpetualManager
address collateral
: Collateral associated to the perpetual contract of interest (it can be null if addressProcessed
is true)borrower
address collateral
: Collateral associated to the VaultManager
of interestaddress stablecoin
: Stablecoin associated to the VaultManager
contractaddress vaultManager
: Contract to calladdress to
address who
ActionBorrowType[] memory actionsBorrow
bytes[] memory dataBorrow
bytes memory repayData
angle
function in VaultManager
contracts. You can look at the corresponding docs of the function here.msg.value > 0
), then to wrap to wETH you need to specify as inToken
the wETH address, and to wrap to wstETH, you need to specify as inToken the wstETH address.mixer
function used to grant approval to a VaultManager
contract before performing actions on it through a gasless permit signature and then revoking this approval after these actions. It's normally safe to leave approval to the router contract on all your vaults for a VaultManager
as it is checked that you cannot instruct to the router actions on a vault you do not control.mixer
standard parameters, this function has a paramsPermitVaultManager
parameter with all the different permit data needed to grant or revoke allowances to different VaultManager
contracts. In the array, the signatures for granting approvals must be given before the signatures to revoke approvals.mixer
functions, the router contract includes some wrappers which make it easy for anyone to interact with Angle contracts.user
: Address to send the stablecoins to.amount
: Amount of collateral to use for the mint.minStableAmount
: minimum amount of token minted that needs to be receivedstablecoin
: Stablecoin to mintcollateral
: Collateral to use to mintdest
: Address to send collateral toamount
: Amount of stablecoin
to burnminCollatAmount
: Minimum amount of collateral to receivestablecoin
: Address of the agToken to burn.collateral
: Address of the collateral token to receiveperpetualManagers
addresses to be passed instead of the stablecoins
and collaterals
ones.claimRewards
from multiple gauges of types 0 (boosted) and 1 (perpetuals). Rewards from gauges of types > 1 cannot be claimed using this function or the router.user
: Address of the user on behalf of who the rewards are claimed.liquidityGauges
: Addresses of the contracts to claim fromperpetualIDs
: List of perpetual IDs to claim from, if claiming rewards from perpetual gaugesstablecoins
: Addresses of the stablecoins the perpetualIDs are linked tocollaterals
: Addresses of the collaterals the perpetuals from perpetualIDs
are from.perpetualManagers
: Addresses of the concerned perpetual managers where to claimperpetualManager
contract, the perpetualManagers
and perpetualIDs
array can be made empty.user
: address of the user on behalf of whom the router should claim the interest. feeDistributor
: address of the FeeDistributor contract to claim from. If the claimed interest (sanUSDC/EUR tokens) need to be used by the router to perform other actions, then letInContract
should be set to True
.amount
is the amount of collateral to withdraw.True
if the address provided as stablecoinOrStableMaster
and collateralOrPoolManager
are the StableMasterβs and PoolManagerβs, and False
if it is the stablecoinβs and collateralβs.mixer()
function to swap the tokens sent by users into tokens accepted as collateral by the protocol.inToken
is the token sent by the user to be swapped by the router into accepted collateral. To swap from ETH or WETH, inToken
should be the address of the WETH contract and ETH will be wrapped by the function. amount
is the amount of inToken
. args
are the arguments that need to be passed to the specific protocols functions.args
are not checked, meaning that users should be very careful of providing the same destination token in the path or payload than the collateral they specify in paramsSwap
of the mixer, or they risk losing their funds.setGovernorOrGuardian
addStableMaster
and removeStableMaster
: to add support for a stablecoin in the protocoladdPairs
and removePairs
: to add/remove collateral-stablecoin pairs, with their dedicated liquidity gaugessetLiquidityGauges
changeAllowance
recoverERC20