Integrating Aave: Yield and Its Tradeoffs

If you're writing contracts that use, hold or manage user funds, you might want to consider using those funds for potentially generating yield, subject to explicit user expectations and protocol risks. What's the catch?

Yield is compensation for taking risks, and keeping funds liquid can be an intentional requirement. The decision belongs in the product’s documented custody and risk model. The way these lender/borrower systems work is quite simple conceptually. Once you understand the mechanism and risk involved, you can decide if it's worth it for you or not.

The lending platforms have significantly risen over the last 1-2 years. The core idea in all of them is the same even though the implementations might differ a lot. We will be using Aave mostly as example, but you may have heard of other platforms as well such as Maker, Compound, dYdX, BlockFi or Curve.

Aave is an Ethereum-based pooled-liquidity money market protocol for different tokens. This means you can either borrow a token on Aave or lend it. All borrowers are paying a fee to the lenders and that's where the interests come from. The exact rates can vary and the available rate modes depend on the version. The current V3 borrow API specifies variable rate mode.

In return for lending tokens the lenders receive a respective interest-earning version of the token, e.g., aTokens in Aave or cTokens in Compound. In Aave your aToken balance will automatically increase over time and you can later trade back 1 aToken to 1 original token. That's in contrast to Compound where simply the exchange rate back to the original token changes over time, but your cToken balance won't change. The result will be the same, but the smart contract integration will be slightly different.

 What about the latest trend of yield farming?

You might heard of yield farming and the Compound's COMP token. If you are lending out money or borrowing money you will receive the COMP token for free on top. Similarly Aave has a new token coming up.  They are intended to be used for governance for the protocol, but you could also just sell them. How to integrate those depends on the system. In the original 2020 context, the AAVE governance-token transition was still upcoming; this goes beyond the scope of the article, but if you want to optimize every little bit of income, then you want to make sure you retrieve those as well once it's possible.

What happens if a borrower runs out of money?

You can imagine that at some point the collateral of a borrower might loose too much in value. Liquidation eligibility depends on the configured collateral thresholds and health factor; it can arise before collateral value falls below debt value.

That's why those positions will be automatically liquidated. If a liquidation happens too late it could be a potential security problem. To prevent such a scenario, there exist automated liquidator bots. Great, now we know how it works, but how can you actually use it?

The original integration used Aave v1: deposit into its lending pool and redeem through the aToken. Those method signatures and Kovan addresses are historical. For a V3 integration, begin with the Pool supply and withdraw documentation and the deployment address for the selected chain and market. Version changes require more than replacing addresses.

The conceptual lifecycle is still supply, accrue and withdraw. The wrapper is withdrawn because those steps also need correct per-user accounting, token transfers, liquidity handling and a clear policy for the accrued interest.

Remember that Aave automatically increases the aToken balance. So if we allow a user to only withdraw what they deposited, we just loose all the extra aTokens since they are now stuck in our contract. You have two options how you could handle this:

1. Use all extra interests and do something with them.
1. Make a raffle (looking at PoolTogether) or some other fun way to distribute the funds.
2. Donate them to charity.
3. Pay it out to yourself. You could make your app completely for free and just use the money from the interests as payment.

2. Or return them fairly to users. One fun way you could achieve this is by minting new tokens that represent ownership of deposited funds in your contracts. For any withdrawal a user burns the tokens again. Then you can see how much of the total supply those tokens are and refund them an equal share of the current aToken balance.
   

If you read the Aave documentation for the redeem function, it states

redeem() will fail if the aTokens to be redeemed are being used as collateral. Please refer to the transferAllowed() function to understand how to check if a specific redeem/transfer action can be performed.

Collateral restrictions and insufficient available liquidity are different reasons a withdrawal can fail. Protocol pauses, asset behavior and other conditions can matter too. Do not promise that a retry will succeed at a particular time; the application needs explicit behavior when funds cannot be withdrawn.

Well this really depends and everything comes with a trade-off. For a good overview of lending rates, check out the 30 Day Averages on https://defirate.com/lend/.

Those new markets enable completely new business models that weren't thinkable before. We are living in exciting times and new ideas come up literally every week. It's no better time to start your own idea than now!

 I actually have been involved in one new project myself. It hasn't been officially announced yet, so I can't give away too much. But you may want to look at https://magicbet.io/ (placeholder website should hopefully be working by the time you read this) and keep an eye open for it. Maybe you can already guess what it's all about after reading the post and given its name. ;)