🛣️Router - Combining Protocol Interactions

Combining protocol interactions

• Contract Name: BaseRouter.sol

• Contract Source: https://github.com/AngleProtocol/angle-router/blob/main/contracts/BaseRouter.sol

• ABI:

3KB

TransparentUpgradeableProxy.json

AngleRouterV2 ABI

1. Introduction

Router contracts are contracts designed to allow users to combine many different actions together across the different modules of the protocol and other protocols in a single transaction.

There is one router contract implementation per chain on which minting an Angle stablecoin is natively supported.

Across all chains, router contracts implementations rely on a mixer() function that can be called with a set of instructions, including the different actions it can perform and their parameters.

Instructions can range from transferring funds to another address, performing a swap on 1Inch, depositing in an ERC4626 contract, wrapping the native token of a chain (e.g ETH to wETH), ...

Some actions are possible on some chains but not on others, and we recommend to look at the implementation of the contract to view what kind of actions are supported.

The list of all potentially available actions is defined in the ActionType enum.

2. Contract Details

Interfaces

Router contracts are upgradeable contracts which all inherit from the BaseRouter contract. As such they all implement Initializable.

Types

In this section, we introduce the types which are needed to interact with the mixer function of the contract.

ActionType

Enum corresponding to the arguments for the actions to perform in the mixer() function.

enum ActionType {
    transfer,
    wrapNative,
    unwrapNative,
    sweep,
    sweepNative,
    uniswapV3,
    oneInch,
    claimRewards,
    gaugeDeposit,
    borrower,
    swapper,
    mint4626,
    deposit4626,
    redeem4626,
    withdraw4626,
    prepareRedeemSavingsRate,
    claimRedeemSavingsRate,
    swapIn,
    swapOut,
    claimWeeklyInterest,
    withdraw,
    mint,
    deposit,
    openPerpetual,
    addToPerpetual,
    veANGLEDeposit,
    claimRewardsWithPerps
}

Some actions were specific to Angle Core Module which has been wound down, and should therefore no longer be useful.

PermitType

Arguments required for the mixer() function to perform the grant allowances to msg.sender through permit signatures.

• token

• owner: address to approve

• value

• deadline

• v

• r

• s

PermitVaultManagerType

Type of data to pass to the router contract in the mixerVaultManagerPermitFunction to approve an address (normally the router) for all the vaults

• vaultManager

• owner

• approved: whether to approve or not the owner for all the vaults in the VaultManager

• deadline

• v

• r

• s

3. Key Mechanisms & Concepts

mixer

function mixer(
        PermitType[] memory paramsPermit,
        ActionType[] memory actions,
        bytes[] calldata data
    ) external nonReentrant {

This function allows to combine calls to different function within the protocol and beyond in a composable manner.

Parameters:

• 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 it

• actions: 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 and encode data for these functions.

Decoding Data

For some actions, there is an 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.

mixerVaultManagerPermit

    function mixerVaultManagerPermit(
        PermitVaultManagerType[] memory paramsPermitVaultManager,
        PermitType[] memory paramsPermit,
        ActionType[] memory actions,
        bytes[] calldata data
    ) external;

This function is a wrapper built on top of the 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.

Parameters:

Beyond the 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.