Adapter Overview

Reciprocally-covered asset vaults will often need to be customized for the protocol whose token we’re accepting. When the token is a default yield-bearing token, such as (current) Yearn tokens, no customization needs to be made: a token can come into the vault and gain maximum value just sitting there. When the token has extra staking needed, such as a Sushiswap liquidity provider token that needs to be staked into Onsen to get maximum return, it will need a custom adapter made. Another time when a custom adapter needs to be made is if rewards for the underlying token (uToken) are not given based on increased value but rather given as separate rewards, such as Aave aTokens and Compound cTokens that require users to manually withdraw rewards.

General Functionality

While different protocols need different actions to be taken with their adapters, the main functionality is generally the same:

1. Maximize rewards within the protocol. We’re not making yield aggregators with strategies staking in a bunch of protocols, that’s for the protocols we cover. But we don’t want users using those protocols to not be able to get covered without receiving the full built-in rewards.

2. Withdraw rewards if they need to be withdrawn so that the rewards are in the contract.

3. If rewards are not in the underlying token, allow the vault to sell them for the underlying token as to make it auto-compounding. This means that if a ARMOR-ETH Sushi LP is staked and it gets SUSHI tokens in return, we withdraw those tokens then sell them for more ARMOR-ETH Sushi LP tokens that we can stake again, increasing the value of users RCAs without them needing to do any work.

Technical Functionality

To achieve all of this general functionality, protocols will need unique functionality in the functions within the contract. All adapter contracts have 5 extra functions, whether or not they are used by the specific adapter:

1. _afterMint: This will be called if after every mint actions need to be taken, such as staking in Sushi’s Onsen program.

2. _afterRedeem: This will be called after redeem (before tokens are sent back to the user) for protocols with the same type of functionality so that we can withdraw tokens from staking and send them back.

3. _uBalance: The default of this is just the underlying token balance of the vault, but in situations (such as the above staking ones), this may need to take into account balances in different contracts to get the true balance.

4. getReward: If reward must be manually withdrawn, this is called to withdraw them.

5. purchase: Purchase is used to allow users to purchase rewards tokens in exchange for underlying tokens in case they are different. This purchase will result in the buyer getting the reward tokens (such as SUSHI) for a bit of a discount, and the vault gaining more of its underlying token, which automatically increases the value of each RCA.