Aave v3 introduces Risk Stewards to manage supply and borrowing

Aave v3 has added new features to the protocol with its new permissions granularity. The system of roles includes RISK_ADMIN, POOL_ADMIN, and EMERGENCY_ADMIN. A Risk Steward smart contract receives one or more of these roles from Aave governance, which allows for an extra layer of validation and logic to control what the Steward owner can do. While it is simple for the community to give granular control over the management of all different parameters to Risk Stewards, the challenge lies in ensuring decentralization and self-protection of the protocol from even trustable entities like service providers.

To simplify community voting overhead and operations, the proposal is to start with the simplest Risk Steward case - an increase in supply and borrow caps. The initial Risk Steward will be a CapsPlusRiskSteward smart contract created per each Aave v3 instance. It will be ownable by a 2-of-2 multisig with one signer being a representative of Gauntlet (@Pauljlei) and another from @ChaosLabs. The owner will have permissions to call functions that increase supply and borrow caps of all assets in Aave v3 pools. These functions will have limitations enforced on-chain, such as the cap to be increased should be strictly higher than the current one, only one increase per asset allowed every five days, and the supply and borrow caps can be increased up to a maximum of 50% of their current value. There is no timelock on changes as this is focused on operational optimization.

Option 1 and 2 of the proposal approve the initiative, with the first setting a maximum increase of 50% of the current value every 5 days, while the second proposes a more flexible approach with a maximum 100% increase. Risk providers will decide the exact value depending on their analysis. Option 3 implies that the Risk Stewards exploration should continue but with different initial configurations in the case of CapsPlusSteward.

From a design perspective, the initial iteration's objective is to have a workable pilot with no downside rather than a perfect system. The community can iterate on it depending on their needs. The procedure around the usage of this Steward is something that is left for the risk providers to decide, but it should be transparent and compatible with current practices.

The proposal has received a total of 18,379 votes. Of those, 99.66% voted in favor of 100% maximum increase limit while only 0.28% voted in favour 50% maximum increase limit.

Check BTC Peers guide of the most promising crypto