After a bug on the rsETH (Kelp DAO) smart contracts infrastructure has been detected, causing an unexpected over-minting to a fee recipient account controlled by Kelp DAO, we would like to give visibility to the community about the following:
- For precaution, we have recommended the Aave Protocol Guardian to freeze (stopping new supplying/borrowing and setting LTV0, cutting new collateral exposure) rsETH across all Aave instances: v3 Core, v3 Prime, v3 Arbitrum, v3 Base.
- We can confirm from our immediate analysis that Aave is NOT be affected, as the inflation of total supply has no impact on how the protocol uses the asset (e.g. exchange rate), in combination with the precautionary freezing and Kelp DAO temporarily halting aspects like mint/burn and exchange rate updates.
- For what we understand at the moment, there has not been any type of “exploit” to rsETH: the over-minting happened as a consequence of faulty logic, on a privileged/permissioned address of the system.
We will continue the investigation and monitor the situation for any follow-up action.
6 Likes
As a follow-up to the community, we would like to elaborate on the incident last week and what we think is the appropriate next step.
As aforementioned, on April 30th, Kelp DAO had a bug on rsETH after an upgrade of one of its smart contracts. The contract involved was the so-called LRTOracle, which, amongst others, is in charge of recalculating/exposing the exchange rate of rsETH to its underlying, and other secondary mechanisms like fee accrual to the Kelp DAO treasury. The bug materialised precisely in this last component:
- Under certain conditions of exchange rate growth of the asset due to re/staking rewards, part of that “growth” is allocated as a fee to the Kelp DAO treasury by minting rsETH.
- During the upgrade executed on 30th April, one of the internal calculations resulted in the fee to mint of rsETH to be over-scaled to 10^36 magnitude, instead of the expected 10^18.
- This resulted in the detected over-minting by an extra 10^16 (fee being a percentage, so 10^(18-2)) on the rsETH supply, but isolated to the configured treasury address.
Even if this over-minting was an important problem, regarding how Aave consumes the asset, there were some protections in place (from before the faulty upgrade) that resulted in zero impact on the v3 system instead of triggering liquidations due to the exchange rate dropping.
More precisely, rsETH has by design an approach of “circuit-break” on unexpected exchange rate updates: if a drop of its value is high-enough as to not fit into one caused by slashing, 1) the update of the exchange rate doesn’t get applied and 2) the whole system enters into a kind of bunker mode, with deposits and withdrawals of the asset paused automatically.
When Kelp detected the issue, the next steps they took were to:
- First, and even if the system was already paused, apply redundant protections on aspects like disabling all potentially problematic points: reducing the fee percentage defined in the contract (protocolFeeInBps) to 0, to not allow the logic branch of fee minting to even activate on the LRTOracle contract.
- Burn the over-minted rsETH from the treasury to recover supply consistency.
- Prepare another upgrade of the contract in parallel to fix the logic.
During that time, we instructed the Aave Protocol Guardian to freeze and set LTV0 on rsETH across networks to limit the exposure of the Aave system.
For extra transparency, some other high-level aspects:
- During the whole incident, and as expected due to the role of Aave being a main venue for users of rsETH, the Kelp DAO team was responsive in all our requests, and very transparent on the procedure.
- Following our internal procedures on assets like rsETH we analysed in the past for onboarding, we monitor asset upgrades like this one, and always check with the team regarding its content and security procedures applied. In this case, the upgrade was security audited and still contained the problem, which is unfortunate.
- It is worth it to mention that in the pre-onboarding discussions with Kelp, amongst the changes we requested was to put redundant exchange rate protections in the asset for over-reduction/over-growth. In this scenario, these happened to be completely critical to have zero impact on Aave and any other major DeFi system using rsETH.
- The Kelp DAO team outlined to us a series of procedure improvements on their side to avoid this type of scenario again, involving, amongst other, stricter guidelines on numeric magnitudes used on rsETH smart contracts, redundant security audits, improved test flows, or even more “circuit-breaker” logic.
- From the Aave side, we would double down on protecting against these types of vectors. For example, PoR (Proof-of-Reserve) for staking/restaking assets has already reached decent maturity, and Aave already has active infrastructure to support it, with not many changes.
Considering the previous, we think it is reasonable now to unfreeze the rsETH asset, and we will recommend the Aave Protocol Guardian to do so after 1 day.
We can confirm the Aave Protocol Guardian has unfrozen rsETH across all Aave instances (v3 Core, v3 Prime, v3 Arbitrum, v3 Base) and the asset is fully operative on Aave again.
1 Like