I want use to vote in order for us to burn 
1B $well token. To create more value to $well token and community. This will bring new people onboard. Let’s consider it.
Thanks for bringing up the idea of a WELL burn, it’s a topic that sparks interest within the community.
That said, before considering a burn of this scale, it’s crucial that we first focus on resolving the protocol’s outstanding bad debt. Restoring the protocol’s financial health should be the priority, as it directly impacts long-term stability and community trust.
It’s also important to look at the regulatory side. Token burns can raise legal questions, and it’s worth examining how other protocols, like Uniswap, EtherFi, Cake, etc, approach similar mechanisms. This helps us evaluate what’s possible and how much protocol revenue such actions would require.
On top of that, the protocol is already taking steps that support WELL’s value. Reserve auctions have been consistently used to repurchase WELL and boost staking yields. Just last month, 5.4M WELL were acquired through these auctions.
In my opinion, the model shown above would be a strong direction to move toward, but before considering it, we need to evaluate and resolve the points I mentioned earlier.
2 Likes
So when will the bad debt be paid of? And what will happen once everything is done? I have voted already
The snapshot vote to cover the bad debt with reserves was approved. The next step is to prepare the proposal and submit it on-chain once ready (TBA).
Before we resolve this bad debt, is everything being considered to ensure we don’t get rolled over again?
What i’m really asking, is every “i” dotted and evey “t” crossed.
New protocols in place and a check three times no mistakes are made which can be exploited.
I have no objecting on writing the debt off but I do have concerns that more instants of the what happened on both the 10th of October and 4th of November happening again.
@Cookiebizkit We appreciate your concern and would like to inform you about the steps the protocol has taken to ensure incidents like these won’t happen again.
First, a bit of background on the nature of these incidents. On October 10th the oracle price of certain alts crashed 90% in a matter of minutes, and quickly rebounded. These oracles, which report price updates weighted more heavily from venues with higher trading volumes, were particularly influenced by a coordinated selloff and liquidation cascade on Binance. DEX prices for these assets did not dislocate as severely, which created an arbitrage opportunity for an attacker to flash loan assets with high collateral factors (e.g. USDC), borrow alts, and immediately sell them for a profit. As prices rebounded, liquidators would not step in: it was unprofitable for the same reason the arbitrage existed in the first place (selling collateral to repay flash-loaned debt was insufficient to repay the flash-loan). Ultimately this exploit was enabled by two main components 1) high collateral factors on USDC & cbBTC and 2) volatile alts can be borrowed. The good news is that the borrow caps for these alts effectively capped the profitability of this exploit Although it’s unfortunate it created over 1M in bad debt, this amount can be covered with reserves. Without the caps it could’ve been much worse (10M+).
Since then, we have substantially lowered the borrow caps for alts, particularly those in the impacted markets. This incident suggests that, for certain assets, borrowing should potentially be prohibited entirely.
On November 4, an attacker exploited a momentary Chainlink oracle mispricing that briefly valued 1 wrsETH at $5.8 billion. The same address had carried out the October 10 incident, indicating this is an automated bot or contract that scans for and instantly exploits such pricing anomalies. By depositing wrsETH as collateral during the brief window of extreme overvaluation, the attacker was able to borrow heavily against it. Borrow caps once again proved critical in containing the damage, this exploit could otherwise have been catastrophic. We immediately isolated the wrsETH market by disabling new supplies and borrows. The incident triggered a full audit of all Chainlink oracles used across Moonwell. Going forward, we wish to enforce stricter collateral listing criteria and only use oracles with a proven resilient track record. Additionally, we are developing an automated system that will use the Cap Guardian role to almost instantly pause new supplies and borrows across the protocol the moment an oracle anomaly of this nature is detected. Therefore if something like this happens again, the window where an exploit is viable greatly shrinks.