Earlier today, 18th April 2026, the Aave Guardian was alerted to a potential exploit involving rsETH. Starting at 18:52 UTC, the Guardian initiated immediate freezes on rsETH and wrsETH markets across all deployments where the asset is listed.
All Aave pools remain safe and fully operational. The incident is scoped to the rsETH asset and does not stem from a vulnerability in the Aave protocol itself. The underlying cause is being investigated by Kelp, LayerZero, and other relevant teams, and we are coordinating closely with them as the situation develops.
Aave V3
The Guardian froze rsETH and wrsETH markets across all deployments where the asset is listed. Freezing these markets prevents new deposits and new borrows against rsETH as collateral while the situation is assessed. Existing positions are unaffected by the freeze itself.
The Protocol Security Council applied equivalent protective measures on Aave V4, disabling new supply and borrow activity against rsETH. Protective configuration updates were executed via the Aave Core Hub (tx 1) and on the Kelp E Spoke (tx 2).
Updates
We will post updates in this thread as the situation evolves. Thank you to the Guardian members and service providers who mobilized quickly on this.
I am not here to make a grave dance or point fingers. However, we must confront the reality that we could have done things differently. I truly believed we had learned our lesson from the Curve drama that shook this protocol to its core not long ago. This rsETH incident is even more serious because it strikes at the heart of our technical safety during a time of extreme vulnerability for our risk infrastructure.
How can we prevent this from happening again? We must acknowledge that Aave Guardians, while incredibly diligent, operate on human timelines. In a dark forest where malicious actors move at the speed of the mempool, relying on manual intervention is no longer a viable security strategy for a protocol of this scale. We need to prioritize the development and integration of on-chain agents that can act autonomously to halt withdrawals or freeze caps when specific malicious patterns are detected. If we cannot defend at the speed of code, we are simply waiting for the next exploit. Maybe the implementation of a withdrawal cooldown for everyone? I know it could sound too drastic, but for me having a huge amount of bad debt is way worse.
It appears listing rsETH in its current form was a mistake or at least a failure of conservative parameterization. It is particularly frustrating to see that the recent study titled Financial Dynamics and Interconnected Risk of Liquid Restaking specifically highlighted these type of systemic risks just last month. The caps were not safely placed, and the protocol is now paying the price in reputation.
Having to use the Umbrella module assets is a path born of desperation. This should never be viewed as a standard buffer or a “cost of doing business.” If Aave continues to incur bad debt through aggressive listings, it will eventually break the confidence of our most loyal depositors and future module participants. Once that trust is gone, no amount of collateral can bring it back.
I am calling on our risk providers to do better. I would much rather see Aave host fewer assets and grow at a measured, sovereign pace than provide endless options that compromise our fundamental security. DeFi has been battered since the start of the year and confidence is crashing across the entire ecosystem.
As a precautionary follow-up to the rsETH freeze, the Protocol Guardian has frozen WETH on Core, Prime, Arbitrum, Base, Mantle, and Linea. The action prevents new borrows against WETH collateral as we continue to monitor the situation.
I think the pratical way of avoiding this kind of attack is to have a progressive/esclated delay of large amount borrow/draw. To always put the risk under the cover of basic safty module.
This is a good idea, perhaps something like a Time Weighted Average Borrow mechanism where only a specified maximum number of tokens can be borrowed per time slot. This would allow instant liquidity when borrowing volume isn’t particularly high and time for guardians to freeze the market if its from an exploit.
@LlamaRisk A simple feature addition for Risk avoidance should act as a layer of defence for future: X amount of borrows within Y period of time for new addresses on AAVE that have borrowed less than Z times in the past A days.
I have a question and a suggestion for everyone to discuss.
A question
This incident with rseth does not appear to be a counterfeit coin, but rather a theft of assets held by the project team through a bridging mechanism, which the hackers exploited. In this case, should AAVE bear responsibility for lending assets to the thief by pledging real assets as collateral?
To give a real-world example, if a fraudster takes fake gold to a bank and uses it as collateral to obtain a loan, should the bank bear the loss? I believe so. Banks should have the ability to distinguish genuine gold from counterfeit.
However, if a thief takes stolen real gold to a bank for a mortgage loan, should the bank bear the responsibility? This is different from point 2. Currently, rseth should fall under point 2.
An idea
Could we establish a points system, similar to those in most current airdrop projects, but instead of airdrops, for risk control? Users could accumulate points through long-term activity, borrowing and lending. Higher points grant greater borrowing power. New addresses would need to accumulate sufficient points to reach their matching lending limit, preventing a strange address from suddenly generating a $100 million loan. This is similar to a VIP loyalty program. I believe this could significantly reduce the occurrence of such events.
Apologies if this is a bit blunt, but none of these solutions address the actual problem here: complete lack of risk management for this asset. The deposit cap should have been significantly smaller.
Many projects’ airdrop reward programs are actually based on this kind of system, they just haven’t implemented it for this purpose. Perhaps AAVE could pioneer this model.Many projects’ airdrop reward programs are actually based on this kind of system, they just haven’t implemented it for this purpose. Perhaps AAVE could pioneer this model.
Today’s rsETH exploit in KelpDAO could easily repeat tomorrow with another similar derivative product. In my view, it would be healthier for the ecosystem if derivative products (such as liquid restaking tokens) are no longer accepted as collateral in lending protocols going forward. While Aave faced hundreds of millions of dollars in bad debt from rsETH collateral, Morpho experienced almost zero exposure. This clearly demonstrates how protective Morpho’s permissionless and isolated vault architecture is against these types of risks. I believe improvements and developments can be made in this area for both Aave and the broader DeFi ecosystem. I sincerely hope Aave recovers strongly from this incident and continues its journey on even firmer ground. Best regards and good luck with your work.
First of all v4 is released, then also the markets there have been frozen cause it has nothing to do with the protocol itself. It’s the rseth asset, that’s it. No bug or hack or whatever in the Aave protocol.
The protocol’s non-isolation mechanism has already revealed its drawbacks. The current DeFi world is no longer at a stage where ensuring one’s own security guarantees safety; any external risk can lead to losses, as this incident demonstrates. Why is Morpho largely unaffected? Because even with the existence of this rseth market, it only affects a specific pool, rather than emptying the entire pool at once.