Strategies

We are actively working on increasing the capital efficiency of any idle funds deposited into our contracts. Strategies is a set of tools that allows us to redirect idle funds and put them to work.

Interface

All of the Strategies we implement should be compliant with the following interface. As you will see not all of the methods need to actually do something, but they are available to the strategy designer.

interface IStrategy {
    function getDestination() external view returns (address);
    function currentBalance() external view returns (uint256);
    function beforeLendTokensSent(uint256 _amount) external;
    function afterLendTokensReceived(uint256 _amount) external;
    function beforeColTokensSent(uint256 _amount) external;
    function afterColTokensReceived(uint256 _amount) external;
}

Essentially all of these methods are just hooks that are being called by the lending pools at the appropriate moment against a strategy contract specified during the deployment of the pool.

Architecture

Here you can see the deployment layout of the contracts involved. Many different pools should be able to refer to the same strategy contracts. Strategy contract should be able to return the data on how much funds each pool has invested into a strategy in each token.

General Structure

For example if the Strategy A could be depositing USDC lend tokens into AAVE. Then all pools should be able to deposit USDC lend funds into AAVE with lenders discretion via that one contract and yet the funds in those pools should always be isolated.

Approvals

When the lender creates a pool with a strategy via the factory, the specific strategy address is passed to the pool's initialize function as bytes32. This is done because each strategy address comes prepended with flags. Here is how a sample strategy could look like:

Approval Masks

Here you can see that the very first bit dictates if the lending pool should give an infinite approval of lend tokens to the strategy. The second bit is the approval for collateral tokens and the third is the ERC4626 vault shares that Strategy contract points to when depositing lend tokens. Forth is the vault shares of the vault where collateral is deposited. You can get the address of the ERC4626 vault that the strategy points to, with getDestination() function. At the end of the bytes32 you can find the address of the strategy itself. Here is the summary of this information:

Bit (From Left)	Purpose
0	If set to 1, max approve lend token to strategy contract.
1	If set to 1, max approve collateral token to strategy contract.
2	If set to 1, max approve shares of the destination contract returned by getDestination(lendToken).
3	If set to 1, max approve collateral tokens of the destination contract returned by getDestination(colToken).
23-63	Address of the Strategy contract.

Example:

Assuming a strategy at address (0xDEaDBEEF) takes all the lend funds and deposits them into AAVE via a ERC4626 vault the encoding for it would be the following:

Here you see that the lending pool will need to approve the lend token, because when depositing into AAVE the strategy will pull lend tokens from the pool. We also need to approve the ERC4626 vault shares because when withdrawing funds from AAVE via the ERC4626 back into the pool, strategy will burn pool's vault shares.