AAVE stETH listing options

Proposals
1

AAVE Request for Comments (ARC) to add stETH support on AAVE has been published a few days ago. Based on positive community feedback a similar proposal has received earlier this year, we assume it is safe to go ahead and discuss technical implementation options of this listing.
Unlike most other assets listed on AAVE, stETH is a rebaseable token, meaning the token balance updates on a daily basis. Although there’re other rebaseable tokens on AAVE (e.g. AMPL), we want to explore options available to Lido rather than just following in their footsteps.

AAVE’s aToken and debtToken

AAVE is a decentralized non-custodial liquidity protocol where users can participate as depositors or borrowers. Depositors provide liquidity to the market to earn a passive income, while borrowers are able to borrow in an overcollateralized (perpetually) or undercollateralized (one-block liquidity) fashion.

aTokens are interest-bearing tokens that are minted and burned upon deposit and withdraw. The aTokens’ value is pegged to the value of the corresponding deposited asset at a 1:1 ratio, and can be safely stored, transferred or traded. All interest collected by the aTokens reserves are distributed to aTokens holders directly by continuously increasing their wallet balance.

debtTokens are interest-accruing tokens that are minted and burned on borrow and repay, representing the debt owed by the token holder.

Possible astETH mechanics

stETH being a rebaseable token prevents us from using generic aToken as provided by AAVE. Including Lido rebasing mechanics is critical to preserve stETH’s productivity within AAVE protocol. We can see two options, each of them involves meaningful changes to how stETH and astETH would behave.

Option 1. Rebase astETH but keep debtToken balance stable.

  1. At any time, user can deposit x stETH to mint x astETH.
    Total astETH supply increases by x.
  2. At any time, user can burn x astETH for x stETH.
    Total astETH supply decreases by x.
  3. At any time, userA can transfer x astETH to userB.
    userA’s astETH balance reduces by x.
    userB’s astETH balance increases by x.
    Total astETH supply remains the same.
  4. When stETH’s supply rebases, astETH rebases, while debtToken doesn’t. The astETH rebase only mirrors the rewards of ‘unborrowed’ stETH in the lending pool.

In this case, the borrower holds the debtToken representing exactly the same amount of stETH they have initially borrowed and keeps the staking rewards. At lower interest rates, this would work as a self-paying loan, and draw part of staking rewards from stETH liquidity providers towards the borrowers.

Option 2. Rebase astETH and debtToken.

  1. At any time, user can deposit x stETH to mint x astETH.
    Total astETH supply increases by x.
  2. At any time, user can burn x astETH for x stETH.
    Total astETH supply decreases by x.
  3. At any time, userA can transfer x astETH to userB.
    userA’s astETH balance reduces by x.
    userB’s astETH balance increases by x.
    Total astETH supply remains the same.
  4. When stETH’s supply rebases, both astETH and debtToken rebase as well.

In this case, the borrower holds the debtToken representing the same amount of stETH they have borrowed plus staking rewards accrued. In terms of borrowing, it completely removes potential safe profit from borrowing stETH but creates better opportunities for stETH liquidity providers.

What option is preferable?

We propose implementing option 2.
Better APR for depositors encourages using stETH as collateral, rather than borrowing it. With stETH’s tight peg and passive yield, we expect stETH to be a perfect collateral asset.
Besides, rebasing the whole stETH lending pool appears to be a more clear behavior from the users’ standpoint.

However, there could be more factors to consider. This post is an invitation to discuss the proposed approach, please, share your thoughts and concerns.

9 Likes
2

Any reason that option 2 is preferred versus just onboarding wstETH, which accumulates rebased into token value without changing the balance?

1 Like
3

The only reason we prefer stETH over wstETH here and everywhere else is better UX (no need to wrap/unwrap).

3 Likes
4

Perhaps aave UI could integrate wrapping/unwrapping into the same transaction as deposit/withdrawal with a zap mechanism? Not sure if this would still lead to higher gas costs or not…

Are there any material technical risks for users or aave protocol from using new atoken contract?

2 Likes
5

The wrapping/unwrapping option is worth exploring. From the UI standpoint, there’s a trick though: wstETH balance wouldn’t exactly match the stETH balance at deposit. Combined with higher gas costs, it still hurts the UX IMO.
For a new aToken contract, there indeed can be contract-related risks, so we believe we should go the way AMPL did – get our code reviewed by AAVE and audited by an established security assessment provider.

1 Like
6

I think option 2 makes sense as well. Borrowing of stETH generally doesn’t feel like the optimal strategy unless someone wanted to short ETH.

Regarding wstETH vs stETH that was an internal discussion and we kept coming back to stETH from a UX perspective. I believe following the path AMPL carve out with code reviews and audits should help mitigate these concerns. Love to hear others thoughts as well.

5 Likes
7

I understand that with Option 1 would leave lenders with a lower staking reward (since the borrowers receive stETH for how much they borrow). However, wouldn’t this be countered by the interest rate? Markets would borrow stETH up to the point where the staking reward rate = borrow interest rate. Reflexer has created a ton of incentives to prop up borrowing demand for RAI, which helped bump up lending rates on RAI. Wouldn’t a similar phenomenon happen through Option 1?

2 Likes
8

The main motive in integration with AAVE is to enable users to operate with stETH as a reliable collateral. Get the expected and easily predictable growth by investing funds (in the case of option two, the deposit will grow comparable to stETH without the mathematics of interest), use the coin as a reliable collateral with a low probability of collapse of the health factor. Option one requires additional pool settings and pumping interest in the coin, which in the end may not give the expected behavior. In light of this, I’d go with a more conservative option 2 for integration.

2 Likes
9

I’m personally in favor of option 1 bc it’s the UX people expect from AAVE and we won’t confuse people about how it works. If lenders don’t want to lend at bad APR, they can opt out of it, I think. The other options would be to not enable borrowing stETH at all for now.

10

Option 1 seems like a bad idea for a few reasons, despite being a bit more intuitive for users (who may not expect borrow balances to rebase).

  1. stETH depositors would almost certainly see lower return on collateral vs holding stETH directly (not in aave) - this is due to aave charging a reserve factor on interest paid, plus natural inefficiency of utilization based lending markets where borrow rate would tend to stabilize at stETH natural rate of return, but deposit rate would be only borrow rate * utilization (which will always be less than 100%).

  2. higher borrowed utilization of stETH collateral increases user risk of borrowers becoming insolvent, or of the stETH pool lacking sufficient liquidity for user withdrawals on demand.

To deal with borrower UX for option 2, we could encourage aave UI to show borrow rate as the sum of utilization based borrowing cost plus lido staking reward rate. And same goes for deposits, sum of aave deposit rate plus staking rewards rate.

3 Likes
11

With option 1, lending out stETH would have an unexpected sense of getting “derisked” stETH yield - regardless of slashings and penalties, you get your AAVE APR, even if it’s lower than stETH staking rewards. Looks like an okay product.

2 Likes
12

We’ve spent some time exploring options including experimental ones (e.g. rebase variable debtToken and keep stable debtToken’s balance stable), but in the end, the conservative approach seems to be most safe and reliable. The approach we want to take includes:

  • Not rebasing variable debtToken
  • Not having stable debtToken at all
  • Having borrowing switched off for stETH at the moment of listing.*
    *We might turn it on later in case borrowing stETH will be of interest.

Here’s a spec draft with a more in-depth description of the proposed mechanics.

5 Likes