Sorry, to hear we have not been meeting the needs of the community with our lack of responses. As a community member and part of the core Anchor team, I have been monitoring this closely. We are trying to make sure all stakeholders, even those that don’t post here on the forum are on the same page with where the community is directing this. We need a successful vote which means a prop that most agree on and not a premature prop like 10.
For the record, I think we should refund everyone. It’s the proper thing to do and I stand behind you all on that. Getting to how that is done is where things are holding us back. The yield reserve is low and IMO don’t think we can risk that. That’s my personal option.
You will hear more from me early next week. Thank you for your patience on this.
Offloading millions of ANC tokens is simply transferring the loss incurred from risk taker (borrower) onto the holder and LP provider (saver) of the ANC token.
This is not an acceptable solution and needs to be taken off the table.
There’s nothing in the documentation that suggests community owned ANC will be used to provide compensation for technical issues.
The ANC I’m referring to is actually ANC that is due to bLUNA holders but never been distributed. Using these funds to compensate those who used their bLUNA as collateral seems like the most acceptable usage of these funds at this time. As I suggested, we could use a sort of public schedule of sales, much like how TFL performed the consistent burn of the community pool LUNA. This will limit the impact of the selling of the ANC. Its estimated that the value needed to make each person liquidated whole is around 9M UST. At around a value of 3 UST per ANC, it would take 3M ANC tokens to compensate the token holders. Also correction, earlier I said it was from the Overseer contract, actually I’m talking about the airdrops due to the bLUNA Hub contract.
Now do I think it is right to do this? Yes, because the protocol behaved in a way that was unexpected. As ANC Governance stakers, holders, LP stakers, its up to us to make the best decisions for the future of the protocol. Those affected aren’t fly by the night mercenary investors, they are real people who are major supporters of the protocol. Yes, they knew the risk. Yes, there is no obligation to make them whole but there is option to do so, and I don’t think its wrong to have this conversation due to the circumstance.
Finally, on the subject of the usage of community funds, although my idea does not actually use any community funds, I will say, there is nothing that prevents the community from spending the community pool as they see fit, governance is not bound by any guidelines really, Governance stakers should be willing and able to pivot as needed to meet the needs of the market and the user base of Anchor.
Personally I think people should focus on the first part and then worry about the second.
My personal opinion (not the company) is that there was a fault in the system, and that compensation is warranted.
I’m deliberately not trying to assign blame, or where the fault occurred… just that one happened.
I agree that those are the two questions to answer,
From what I’m reading and understanding, majority seems to be in favor of compensation; Speaking for myself personally, I’m 100% in favor of compensation as this was a system failure and it’s important to maintain an interest in borrowing on Anchor;
No matter where the fault came from, Anchor Protocol is reponsible for compensating it’s users and it’s also the protocol that profits from them. If the fault lies with a particular oracle implementation then perhaps this gives weight to integrating with other oracles, such as chainlink which I believe has been mentioned in the past. With this thought in mind, these are the options I see available:
Yield Reserve
There have been some concerns due to the small size of the pool and the instability of it’s replenishes, on how this could impact the protocol in future.
Give ANC from the Community Pool
Concerns over price impact on the token, and how that may affect stakers and LPers.
Swap ANC from the Community Pool into UST (over a period of time) and give that to affected parties
Not sure how feasible this is, and who would be available to execute this plan, it has been done by TFL with the Luna Community Pool, but that gives no assurances that the same could be done here.
As for my personal opinion on this second point, I’d prefer option 3 but I’d also be okay with option 2, while I initially believed the yield reserve would be a valid choice, the concerns expressed and the overall market conditions have also left me worried about pursuing this option.
Hope we can move forward towards some form of consensus on how to tackle this issue.
We need to be extremely careful about what precedent is being set here. Those who were liquidated were walking a fine line in a market that has regular flash crash events.
Are ANC tokens going to be sacrificed for every technical issue going forward? What message are we sending out here?
We also need to be honest with everyone. This is a decentralized protocol without any guarantees or a compensation fund. Every single user of Anchor is taking a risk.
I just had a chat with Do on Twitter Spaces and it sounds like
He agrees that restitution is warranted.
He thinks funds should come from Anchor, not from TFL.
In that case, it sounds like we need to make a decision between Options #3 and #4. If we start with Option #3, where is the best place to raise the ~$9M? My personal preference:
Luna staking airdrops: Not sure this is actually benefitting the protocol. It’s likely leading to just sell pressure at this point.
Community reserves: Lots of reserves still, likely has way more than it can possible spend.
Borrower incentives: This helps keep borrowing alive and active, so probably the worst option of the three to shrink.
Do we have any analysis on what price impact is expected on the sale of $9M of ANC tokens?
What is the communication plan to holders and LP providers of the ANC token?
Are ANC tokens officially going to be used for future compensation purposes for all technical issues? If yes, where is this information going sit within the documentation? What is and what is not going to be covered?
Let’s be clear about what we are proposing. Savers / investors (of the ANC token) are going to be paying the price (potentially without even knowing) for those who took risks within the protocol.
We are also setting up a potential moral hazard situation, where there will be an assumption that all losses will be covered for all technical issues.
Is it fair to characterize those liquidated as collateral damage?
I would be lying if I didn’t worry about this exact scenario with my own investment. “How accurate and GENUINE is the oracle’s data?!” People need to trust and believe that the platform is operating correctly as as intended.
If the oracle is passing improper or inaccurate data and users get liquidated–that’s the worst possible reflection on the platform. The right thing to do is compensate those who were liquidated and fix the problem. The platform will bounce back stronger in the long run because of it.
If nothing is done–how many others may lose faith in Anchor? How much damage will occur and can the platform recover from that?
I’m surprised the media hasn’t picked up on this yet.
Really curious about this too. I don’t mind this proposal getting rejected, but there are supposed to be total of ~24M ANC voting no. I don’t see this reflected in the below vote history?
That proposal that’s being voted down is not a real proposal and isn’t actually tied to the discussion happening here. No reason to even pay attention to it.
Agree with this sentiment, its not about setting up some morale hazard or a precedent for the future. Its about ensuring trust in the protocol moving forward.
Technical issues are a risk that are built into the system that has no formal compensation scheme. I do not understand why we are even discussing compensation.
This exact same risk still exists regardless if there’s a patch for the faulty price feed. If this happens again are we going to offer compensation again? Who is going to pay for it?
There needs to be a disclaimer on the website that clearly outlines the risks.
If the community wants to provide a compensation scheme for technical issues then let’s set one up. But let’s not rob Peter to pay Paul by passing the cost onto other users in the system.
Borrowing confidence should not be based on compensation.
Confidence can only return when we have clearer assurances on the technical side the issue is fully investigated and fixed.
This liquidation bug likely happened more than just on 9 Dec 2021, there are users complaint on 4 Dec 2021unjusted liquidation below 60% limit. However, the team has yet to investigate despite repeated requests make by users. The team should do a complete investigation on this liquidation bug, not only on 9 Dec but all possible unjustly liquidation happened, the very least users complained liquidation. Only then a complete compensation plan for ALL affected users are justly treated.
While the discussion is primarily focused on from which party/project fund should be sourced for reimbursement, it is also worth to consider whether it will be in form of UST/ANC/LUNA (or combinations).
How feasible would it be if the funds were given back in the form of the following:
(I will refer the oracle bug related liquidation event on Dec. 9th as liqbugev.)
Amount to reimburse = Total value liquidated - sold off liquidation = blunas (or beth) @ correct oracle price at liqbugev (example: ~$66).
This would in effect should save some opportunity cost should the LUNA price at the time of reimbursement rise compared to correct oracle price at liqbugev. (of course, should LUNA price fall below at the time of reimbursement compared to oracle price at liqbugev, should be vice versa).
sorry but what are you talking about ? This proposal is not about robbing Peter. This proposal is about returning funds to users that got robbed. The collateral unjustly liquidated was not sent over to Peter. In fact, the collateral lies in the reserves and it should be redistributed back to the affected users.
An oracle not showing the right price is ol’ Binance practices, that’s a red flag. Playing it all this down to “just tech issues” is an even stronger red flag.
Anyway. Whales are voting against the proposal. It will get rejected and end of the story.