At Aave Companies we often work with other community contributors to review upcoming proposed changes to the protocol and pay particular attention to changes that are crucial.
In this development update, we provide our assessment of BGD Labs’ proposed changes to the stkAAVE and stkABPT contracts, as described here. You can find the first commit we reviewed here, and the last commit reviewed here.
Earlier, we shared a report with BGD Labs containing all our findings based on our review of the first commit. BGD Labs reviewed our findings, provided clarifications and refined the code, where appropriate.
None of our findings were considered a security concern or of high risk. Instead, the findings typically related to code style, design decisions and discussion about the newly implemented mechanics.
However, in addition to the findings in our report, there are some aspects of BGD’s recommended code changes that we want to highlight for transparency and visibility. These are important features mentioned in the code docs and properties for the AIP by BGD Labs.
Aave DAO cannot slash 100% of the AAVE staked at stkAAVE contract
There is a technical limitation in the stkAAVE contract that impedes the DAO from slashing 100% of AAVE staked in the stkAAVE contract.
It is unlikely that the DAO would want to slash all the staked AAVE, however it could happen in the case of low AAVE liquidity staked and a shortfall event that requires an extremely large slash.
stkAAVE holders earn AAVE rewards with no risk during post-slashing state
It is the purpose of the module that the stkAAVE users are backstopping the protocol with their staked AAVE, therefore, in case a slash event occurs, it is possible that the amount of AAVE they can withdraw is less than what was initially staked. After the slashing event, there is a period of “post-Slashing” state where certain features are disabled, meaning that no additional staking, cooldown or slashing can occur. During this state, the users can freely unwind their positions and withdraw the unslashed AAVE tokens.
While this is reasonable, it is important to highlight that rewards are ongoing, and users are earning AAVE rewards without the risk of another slashing event. Therefore, users are encouraged to keep their tokens in the stkAAVE contract until the slash is settled (thus earning maximum rewards with no risk of further slashing).
Change on event emissions can affect integrations
The current version of stkAAVE is emitting Staked and Redeem events whenever a new stake or redeem action happens. The new implementation is emitting events with the same names (Staked / Redeem) but different signatures, which may impact integrations.
event Staked(address indexed from, address indexed onBehalfOf, uint256 amount); event Redeem(address indexed from, address indexed to, uint256 amount);
event Staked(address indexed from, address indexed to, uint256 assets, uint256 shares ); event Redeem(address indexed from, address indexed to, uint256 assets, uint256 shares );
We suggest applications that are dependent on these events directly or via subgraph adjust the logic based on the block number of the upgrade execution.
Inclusion of GHO Logic
Finally, we want to highlight the importance and value of the addition of the GHO logic, which provides the ability to give discounts on the borrow rate of GHO to stkAAVE holders. We appreciate that the GHO logic is included, supporting the DAOs upcoming native stablecoin.
After a comprehensive technical review of the new implementation of stkAAVE, and new features and changes as described in the BGD Labs post, we conclude that we have not identified any key technical issues that would impact the upgrade.
We appreciate BGD Labs’ willingness to engage with us in discussions, and the clarifications and responses they provided to all our questions.