WIP33: WePiggy Protocol Incident Resolution
Proposal Number: WIP33
Proposal Title: WePiggy Protocol Incident Resolution
Proposal Author(s): Core Devs
Related Proposals / Dependencies: N/A
Replacement Proposal / Replaces: N/A
In this proposal, I, @DeFi.Panda, as the holder of WPC and a member of the WePiggy community, call on all community members to have an in-depth discussion on the resolution to the CHE abnormal liquidation incident of the WePiggy protocol and rework the resolution. I have also given the standards and procedures that I think are reasonable in this proposal.
I highly appreciate the core development team’s hard-working on solving problems, so does the community.
However, unlike centralized products, I think the decision-maker of the decentralized lending protocol should be the community. This is in line with the governance positioning of WPC and the spirit of DAO.
The team’s attitude towards this incident tended to be calm and even hoped to deal with it as soon as possible, skipping the necessary community discussions and voting stages. This may lead to unreasonable compensation for the WePiggy protocol in the future, and cause the affected user to pursue unlimited liability from the WePiggy protocol. This also violates the principles of DeFi and DAO.
Therefore, I think the community should decide what kind of incidents to compensate, the source of compensation, the upper limit of compensation, the process of compensation, and the specific implementation standards. And then, corrections should be made to the incident resolution proposed by the core development team, the current resolution should be replaced, to preserve the status of WPC as a governance token and the long-term rights of WPC holders.
4.1 Upgrade the Current Mining Logic on Ethereum Mainnet
“At 5:21 (UTC+8) on DEC 15, 2021, WePiggy-OEC protocol experienced a short-term error in the CHE oracle, causing the CHE price in WePiggy to be much higher than the market price, and resulting in abnormal liquidations for users who borrowed CHE assets. Based on prices at the time of the incident, the total loss of user assets was approximately US$400,000.”
Subsequently, the WePiggy core development team used the funds belonging to the protocol (including: reserves, other income, WPC risk reserve) to pay 100% of the users’ losses in the incident in advance.
4.2 Reference Case: Compound’s DAI Market ~85M Abnormal Liquidation Incident
To better explain my suggestion, here we take Compound 85 million USD DAI abnormal liquidation incident as the starting point for observation, because the incident is very similar to this one.
The Compound community put forward a discussion: https://www.comp.xyz/t/dai-liquidation-compensation/684
The questions in the discussion are of great reference to the WePiggy community:
Was the market price of DAI on Coinbase Pro fair? Was it intentional manipulation, or a market dislocation?
Were impacted users aware of the risk?
Do impacted users deserve compensation? Why?
If so, how should compensation be calculated?
If so, should compensation come from reserves, or by distributing COMP?
Does compensating users create a social contract that doesn’t already exist? Does a social contract already exist? How would compensation change the future activity of users?
Finally, after discussion, the Compound community rejected the proposal to use COMP as compensation, and finally passed the proposal to use DAI reserves as compensation.The compensation amount is equal to the liquidation penalty, namely: 85,222,475 DAI x 8% = 6,817,798 DAI.
Compensation proposal 1 (Use COMP as compensation, rejected):
Compensation proposal 2 (Use DAI as compensation, rejected):
4.3 Some basic considerations and improvement plans
The resolution adopted by the COMP community, as a result, is similar to the resolution adopted by the WePiggy core development team. But I think the WePiggy community should have its own compensation standards and procedures, and it is a plan that needs to be agreed upon by the community.
Specifically, there are mainly the following aspects:
What kind of incidents should be compensated?
Taking this accident as an example, the oracle provided by a third party made a serious abnormal quotation, which in turn caused the users of the WePiggy protocol to suffer abnormal liquidation losses.
Perhaps many people think: Obviously, this is a problem caused by the OEC oracle using a single price source. Therefore, the most fundamental problem of this incident should be that WePiggy mistakenly chose an oracle that shouldn’t be believed. As long as the team chooses the “correct” one, there is no problem.
However, I think the same thing may happen on Chainlink, the industry-leading decentralized oracle network. From a long-term perspective, the abnormal quotation of Chainlink is still a high probability event.
The Russian financial crisis directly led to the collapse of the US Long-term Capital Management Corporation. Who would have thought that a large sovereign could default before it happened? I believe that Chainlink’s probability of an abnormal quotation will not be lower than the probability of a major sovereign’s debt default.
Even in the course of WePiggy’s incident, some nodes of Chainlink had quotation problems as well (about 20% deviation). In my opinion, these nodes should be the same as OEC oracles, and they are all affected by Coinmarketcap’s abnormal quotation.
In DeFi space, integration between protocols and infrastructure is inevitable. Composability is also the advantage and charm of DeFi. So, on the premise that the team has publicized the oracle information and the user is fully aware of the premise, should such an oracle incident be blamed on the protocol itself, and let the community bear full responsibility?
In addition to user losses caused by problems with services provided by third parties, there are many other possibilities, such as:
a. The market price of a listed asset is manipulated, but the prices in all trading markets are the same
b. Losses caused by protocol bugs
c. Losses caused by application front-end bugs
d. Losses caused by improper management of the private key of the contract deployment address
e. Losses caused by some vulnerabilities on listed assets
f. Losses caused by illiquidity of some listed assets, part of the debt cannot be liquidated, resulting in bad debts in the protocol
g. Other possibilities
I hope all the community users can add more to the above.
But, the key point is: what standard should be used there, to determine what kind of incident should be compensated?
Here are my answers:
a. Should not be compensated by WePiggy protocol
b. Should be compensated by WePiggy protocol
c. Should be compensated by WePiggy protocol
d. Should be compensated by WePiggy protocol
e. Should not be compensated by WePiggy protocol
f. Should not be compensated by WePiggy protocol
When introducing third-party services, the team should provide adequate disclosure to ensure that the community is aware of this risk. Community users should put forward their different opinions on the introduction of risks during the publicity period.
In short, my opinion is:
If it is a third-party service problem, in principle, the WePiggy protocol may not be liable. If community members believe that the protocol must compensate users upon an incident, they can also initiate a discussion and submit a formal proposal and the WPC holders in the community will vote on whether to support it.
4.3.2 Loss assessment
Whether it is the affected user, the community, the third party, and the development team can calculate the losses by analyzing the transaction details on the blockchain, so I won’t repeat it here.
4.3.3 Compensation source and upper limit
In this part, three aspects need to be considered:
1 What assets can be used to compensate users
2 Since WePiggy is a multi-chain deployment protocol, should each chain have a debt ceiling, and how much is appropriate?
3 If there is a major incident, even if all the available assets can not make up for the loss, what should be done?
My answer to this is:
1 The compensation source has been mentioned in the incident report: The mining pool extra rewards in the early days of the protocol; reserves in WePiggy lending protocol, the risk reserve part of WPC token distribution.
2 The risk should not expand indefinitely. The loss of users on a certain chain should be mainly compensated by all the reserves on that chain;
if it is not enough, should use the mining pool extra rewards in the early days of the protocol (this part of the funds, I think it is common to all chains, although not much);
if it is still not enough, should use WPC risk reserve, the exact amount of WPC risk reserve that can be used for compensation according to the WPC distribution proportion of that chain at the time of the incident, and settle according to the average WPC market price in the 14 days before the incident.
3 The protocol should not bear debts exceeding the debt ceiling. Otherwise, even if they promised compensation, their solvency would be greatly reduced due to the impact of the incident, making the repayment of debts become empty talk. Based on this, it is also necessary to publicize the upper limit of compensation for each chain so that users can clearly understand the existence of risks.
4.3.4 Compensation process
1 Incident investigation and evidence collection (On-chain information collection, protocol emergency risk control, multi-party joint investigation)
2 Community governance voting (According to the incident report, figure out what happened, how much losses, how to compensate, and initiate a formal proposal
3 Advance payment for user losses (after the proposal has been passed, the community will supervise the development team to execute it)
4 Recovery of incident losses (if there is a hacker attack)
4.3.5 Other Considerations
In addition to the main process, some other things should also be specified, such as:
1 After the advance payment, if the hacker returned part of the funds to the team address or user address (it’s common in the crypto field), the team or user should actively communicate with the community and return the funds. Otherwise, the community should take all necessary means to make them return.
2 The protocol should provide periodic asset risk analysis reports and re-adjust the risk parameters of assets regularly. The market is not static, and assets that are too risky should be removed from the lending market protocol, which is even much more important than new features.
As a lending protocol, that is, a decentralized bank, the asset security of the protocol is the first priority, rather than introducing various long-tail assets or launching new lending functions with new risks.
I believe that this is why Compound is so restrained in launching new assets. In contrast, Aave is more radical. But I hope that WePiggy will learn from Compound, even more conservative than Compound, and eliminate the risks introduced by long-tail assets as much as possible.
At last, here I also call on the WePiggy core development team to learn from this incident, learn from history, spend more time to make the security solution better than other lending protocols.
A bank does not need many functions, the more functions and the more complicated it is, the more risks are introduced, and the higher the possibility of incidents. Many projects are pursuing the ultimate capital utilization rate, WePiggy does not need to follow.
As a user who participated on the first day of the project and watched the team and the community gradually grow and expand, WePiggy carries some of my expectations for the Chinese background project.
I hope that WePiggy is a long-term, stable and reliable bank that can even only list mainstream assets, so that my funds are extremely safe and I can sleep well.
Even a black swan event like the “March 12 Crash” (Ethereum fell by 50% in a day, and other altcoins fell by 80%) happens, because WePiggy only supports mainstream assets and the security risk control is well done, compared with other protocol, there is no large amount of bad debts. That might make WePiggy famous!
5. Option Description
Will set up options after in-depth discussion.