AIP - 96: Adjust savings rate update methodology

Hello,

This is a proposal to update the operational way with which the rates in Angle savings product (stEUR and stUSD) are updated.

Context

The way rates for stEUR and stUSD are currently computed is explained in details here. Precisely speaking, they are updated on all the chains where the contracts are deployed by the guardian multisig when the following conditions are met:

• last rate update was 7 days ago
• or, current rate is too high and causes the protocol to lose money
• or, the computed rate differs from the current rate by a factor 0.5%

With stUSD typically deployed on 4 different chains, this means that 4 different guardian transactions are needed to update the rate on the different chains. The time and cost for each rate update scales linearly with the amount of chains supported.

Another thing that happened with stUSD is that rates have tended to have a quite high variance, and with the high liquidity of USDA with respect to USDC. Sometimes stUSD rate had to more than double.

Proposal

Proposal is to update the savings contracts so that trusted addresses as well can update the rate and not just a guardian address. This will typically allow a keeper address (= a bot) to take part in rate updates.

To reduce a bit the variance of the stUSD rate and smoothen rates increase and decrease we also propose to adjust the rate modification policy so that the stUSD or stEUR rate cannot vary by more than 30% in a 24h period.

Implementation

Adding this trusted role for who can update the rate requires upgrading the savings contract. You may find the proposed updated implementation on this PR here.

stEUR and stUSD contracts will have to be deployed with the same implementation on all these chains.

In terms of trusted address, we propose here to use a bot by Angle Labs, typically this address: 0xa9bbbDDe822789F123667044443dc7001fb43C01 on every chain.

Value to the protocol

This will allow us as a protocol to be more aggressive when it comes to making the stEUR and stUSD products available on a new chain. Right now, the costs and time to maintain this scales linearly with the number of chains supported. With a fully automated infrastructure relying on trusted keepers, the protocol could scale the places on which the stEUR and stUSD are natively available.

Smoothing rate updates and ensuring that there are never large variations will guarantee to people who enter in the product that the variance of the rate is never bigger than the threshold introduced here.

In terms of risk, this is also fairly limited. The risk is that the keeper infrastructure gets corrupted and that the bot fails or someone takes ownership of the addresses trusted to do so. In effect, this will be easily detectable and a rogue keeper could only set the rate up to the maximum rate decided by governance (which can rapidly revoke the trusted address)

Future steps

We could work on further increasing the trustlessness of the system by for instance onboarding other forms of keepers based on more decentralized infrastructures.

Voting Options

1. For, adjust methodology
2. Against, do nothing