WIP33:WePiggy 协议事故解决方案 / WePiggy Protocol Incident Resolution

1 、前言

提案编号:WIP33
提案名称:WePiggy 协议事故解决方案
提案作者:DeFi.Panda
有关提案:无
替换提案:无

2 、摘要

本提案中,我,@DeFi.Panda,作为 WPC 的持有者,也作为 WePiggy 社区的一员,呼吁所有社区成员对此次 WePiggy 协议的 CHE 异常清算事故的解决方案进行深入讨论,重新制定方案。我也在本提案中给出了我认为合理的标准和流程。

3 、动机

尽管,开发团队积极处理问题,尽职尽责是值得称赞的——这也是目前一边倒的意见。但是,不同于中心化产品,我认为去中心化借贷协议的决策者应该是社区。这才符合 WPC 的治理定位和 DAO 的精神。

团队在这次事故上的处理态度是趋向于息事宁人的,甚至是希望尽快处理掉,跳过了必要的社区讨论和投票环节。这样可能会导致将来 WePiggy 协议支出不合理的赔偿,导致受损的用户向 WePiggy 协议和 WPC 追求无限的赔偿责任。这也违反了 DeFi 和 DAO 的原则。

所以,我希望由社区来决定对什么样的事件进行赔偿,赔偿的资金来源,赔偿的上限,赔偿的流程以及具体的执行标准。之后对核心开发团队提出的事故解决方案做出改正,替换现有方案,以维护 WPC 作为治理代币的地位和 WPC 持币者的长期权益。

4 、正文

4.1 背景

“2021 年 12 月 15 日 5 时 21 分(UTC+08:00),WePiggy-OEC 由于预言机报价出现短暂错误,CHE 报价远高于市场价格,导致借取 CHE 的用户遭到了异常清算。根据事发时的价格统计,用户资产总损失约为 40 万美元。”

随后, WePiggy 开发团队启用协议资金(包括:准备金收入,其它收入,WPC 风险准备金)对事故中受损用户进行100%预先赔付。

详情: https://www.yuque.com/zgryhn/fg3t76/lylhsl#CPr0Q

4.2 参考案例:Compound DAI 市场 8500万美金异常清算事故

为了更好地阐述我的建议,这里我们以 Compound 8500万美金的 DAI 异常清算事故作为切入点进行观察,因为该事故与此次事故的重合性非常之高。

具体来说:

Compound 社区提出了讨论:https://www.comp.xyz/t/dai-liquidation-compensation/684

文中的问题,对 WePiggy 社区的此次事故处理来说同样适用:

  • Coinbase Pro 上 DAI 的市场价格是否公平?是故意操纵,还是市场错位?

  • 受影响的用户是否意识到风险?

  • 受影响的用户是否应该得到补偿?为什么?

  • 如果是,应如何计算赔偿?

  • 如果是这样,补偿应该来自储备金,还是通过分配 COMP?

  • 补偿用户是否会创建一个尚不存在的社会契约?社会契约是否已经存在?补偿将如何改变用户的未来活动?

最后,Compound 社区经过讨论,否决了使用 COMP 作为赔偿金的方案,并最终通过了使用 DAI 准备金作为赔偿的方案。赔偿金额等于清算罚金,即:85,222,475 DAI x 8% = 6,817,798 DAI 。

赔偿提案1(补偿COMP,被否决):

赔偿提案2(补偿DAI,通过):

4.3 一些基础思考以及改进方案

COMP 社区采取的处理方式,结果上来看,与 WePiggy 开发团队的处理方式类似。但是我认为,WePiggy 社区应该有自己的赔偿标准和流程,而且是需要经过社区达成一致意见的方案。

具体来说,主要有以下几个方面:

4.3.1 定性

到底什么样的事故,属于应该获赔的范畴?

以此次事故为例,是第三方提供的预言机出现了严重的异常报价,进而导致了 WePiggy 协议的用户出现了异常清算损失。

也许很多人认为:这明显是 OEC 的预言机采用了单一报价源所导致的问题。所以,这个事故最根本的问题应该是 WePiggy 错误地选择了本不该相信的预言机,只要选择“正确的”预言机就没有问题了。

但是,我认为,即使这个报价错误来自预言机的业界一哥 Chainlink,也是有可能的。把时间拉长来看,Chainlink 发生报价异常依然是一个高概率事件。

1998 年,俄罗斯债务违约直接导致了美国长期资本管理公司的倒闭。在事情没有发生之前,谁能想到一个堂堂大国主权也可以发生如此大规模的违约?我认为,Chainlink 发生报价异常的概率并不会比大国主权发生债务违约的概率更低了。

甚至,在 WePiggy 的此次事故过程中,Chainlink 也有少量节点出现了严重偏离市场的价格(大约20%的偏差)。我认为,这些节点应该与 OEC 预言机一样,都是受到了 Coinmarketcap 报价异常的影响。

在 DeFi 赛道,协议和基础设施之间的整合是不可避免的。可组合性也是 DeFi 的优势和魅力所在。那么,在团队已经公示了预言机信息,用户完全知情的前提下,像这样的预言机事故是否应该归罪于协议本身,并且让协议所在的社区承担全部责任呢?

除了第三方提供的服务出现问题所造成的用户损失之外,还有很多其他的可能,例如:

a. 上线的某资产市场价格被恶意操纵,但是价格在所有交易市场都是相同的
b. 协议合约层面的 Bug 带来的损失
c. 应用前端 Bug 带来的损失
d. 协议的合约部署地址私钥管理不当所带来的损失
e. 某资产出现了增发漏洞所带来的协议损失
f. 某资产流动性枯竭,部分债务无法清算,造成了协议的坏账
g. 其它可能

以上,大家可以多多补充,但是,我想表达的问题其实是:以什么样的标准来认定协议应该进行赔偿?

对此我的回答是:

a. 不应该由 WePiggy 协议赔偿
b. 应该由 WePiggy 协议赔偿
c. 应该由 WePiggy 协议赔偿
d. 应该由 WePiggy 协议赔偿
e. 不应该由 WePiggy 协议赔偿
f. 不应该由 WePiggy 协议赔偿

引入第三方服务的时候,团队应该进行充分的公示,确保社区对这一风险是知情的。社区用户应该在公示期间,提出其对引入风险的不同意见。

总之,我的立场是:

属于第三方责任,原则上不应该由协议来负责。若社区成员认为协议确实有赔偿的必要,也可以发起讨论并提交正式提案由社区的 WPC 持有者共同投票表决。

4.3.2 定损

受损用户、社区、第三方和开发团队都能通过链上行为分析,对损失进行清楚的认定,不在此赘述。

4.3.3 补偿来源和上限

这部分,我认为主要有以下三个方面需要考虑:

1、有哪些资产可以用来补偿用户

2、由于 WePiggy 是一个多链部署的协议,每一条链是否应该有止损线,具体多少为宜?

3、如果发生了重大安全事故,即使动用了所有的可用资产,也无法弥补损失的情况下,应该怎么办?

对此我的回答是:

1、目前可以考虑使用的资产就是报告中提到的:协议早期的质押挖矿盈余,借贷协议中的准备金,WPC 代币分配中的风险准备金部分。

2、风险不应该无限扩大,某条链上的用户损失,应该主要由该链上的所有准备金作为赔偿;如果不够的话,可以使用协议早期的质押挖矿盈余(这部分我认为是各个链共享的资金,虽然不多);如果还是不够,根据事故发生时该链的 WPC 分配比例,来计算可以用来赔偿的 WPC 风险准备金数量,并按照事故之前 14 天的 WPC 市场均价进行结算。

3、协议不宜承担超过止损线的债务。否则,即便承诺赔偿,也会因为受到事故影响,导致其偿债能力大幅度下降,使得偿还债务变成空谈。这里应该做的,其实是提示该链的赔偿上限值,让用户明确了解风险存在。

4.3.4 补偿的流程

这部分,我认为可以在开发团队的“72 小时应急预案”基础上改进:

1、事件调查取证(链上数据搜集,协议紧急风控,多方联合调查)

2、社区投票决策(根据事件调查报告,对事故定性,定损,讨论垫付方案,并发起正式提案)

3、用户损失垫付(提案获得社区投票支持以后,由社区监督开发团队执行)

4、事件损失追讨(若明确存在黑客攻击行为)

4.3.5 其它

除了主流程之外,还有一些其它的事情也应该做出一些规定,例如:

1、垫付之后,若发现黑客“良心发现”退还了部分资金到团队地址或用户地址(业内常见现象),团队或用户应该与社区主动沟通,将这部分资金返还给 WePiggy 协议。否则,应由社区采取一切必要之手段,使其返还。

2、协议应该定期做资产风险分析报告,定期对资产的风险参数进行再调整。市场不是一成不变的,风险过大的资产应该予以下架,这比开发新功能都更重要。作为一个借贷协议,也就是去中心化的银行,有必要将协议的资产安全放在第一位考虑,而不是引入新风险的各种长尾资产或者叠加新风险的借贷功能。我相信,这也是为什么 Compound 上线新资产如此克制的原因。相对的,Aave 更为激进。但我个人更希望 WePiggy 向 Compound 学习,甚至比 Compound 更为保守,将长尾资产所引入的风险尽可能剔除。

最后,我也呼吁 WePiggy 开发团队能以此为鉴,以史为鉴,多花时间把借贷协议的安全方案做的比其他借贷协议更好。

一家银行不需要功能很多很复杂。功能越多越复杂,引入的风险越多,发生事故的可能性越高。

追求极致的资金利用率,在刀口上舔血的项目很多很多,特别是海外项目,很多都是金融“套娃”和“杠杆”高手,不缺 WePiggy 一个。

作为在项目上线第一天就参与进来,看着团队和社区逐步成长壮大的用户,WePiggy 寄托了我对国产项目的一些期待和情怀。

我更希望 WePiggy 是一个长期、稳健、可靠的银行,甚至可以只支持主流资产,让我的资金无比安全,睡得着觉。

甚至,当类似 312 的黑天鹅行情(一天之内,以太坊下跌 50%,其他山寨币下跌 80%)出现时,WePiggy 可以因为支持的都是主流资产,而且安全风控做得好,反而没有出现大面积的坏账。那样也许可以一战成名!

5、选项

待讨论出一个更为清晰的版本之后,再来制定选项、发起投票

--------In English----------

有点长,有必要的话,哪位大佬帮忙翻译一下 ORZ

1 Like

感谢批评!

非常棒的提案!WePiggy 的成长非常需要具有反思能力的社区成员,WePiggy 很荣幸能有你这样的社区成员。

已经初步读完一遍,会和开发团队的其他小伙伴一起反思一下,并尽快给出回复。

英文版本不用担心,我们的小伙伴已经在同步翻译了。

很好的提议,社区的声音非常重要。合理的监督才能够保证走的远和不偏航。

感谢!市场还没熊,但是天有不测风云,早做准备,大家都放心一点。最近看到多数DeFi币大幅度的回调,再看看我的小CRV的表现,都在不断地提醒我,有远期代币释放模型,并提供合理地锁仓机制是长期项目的一种非常有必要的做法。

一直以来,CRV在资金利用率来看都是很差的,但是它站住了核心应用之一,稳定币兑换,然后就是他属于那种不会出黑天鹅的项目,相反,都是他帮着制造了黑天鹅,肥了自己。

他山之石,可以攻玉。我觉得吧,现在先防住风险,下一步,合理的锁仓机制,在下一步,生态扩展,few…

1 Like

希望大家多多出谋划策啊,熊猫这个提案至多算是抛砖引玉,利益所致,必须站出来献丑一番,其实社区里面厉害的大佬很多,比如之前的白特幂老哥,都是很棒的 :+1:

我们又不是compound,没必要什么都要学人家,原因确实在第三方预言机造成的没有错,但也因为是借贷协议使用它造成了受害者的损失,所以受害者追责对象是借贷协议是没有问题的,对于第三方应该有借贷协议去追责。就像消费者因为车辆质量问题造成安全事故找的肯定是车企,不能因为最后查出是某一个零件造成的原因就把责任推给零件制造商。

熊猫大佬NB!

我说说我的想法,我们把小猪看成是银行。从一个客户的角度,那从一个客户的角度,他是不知道预言机的原理和错误的。他只想知道自己的资金是安全的。也就是说,不管任何情形发生的时候,他都不希望自己亏损,虽然这可能对小猪很不公平甚至不合理。但是我们也应该见过很多很合理、很公平的产品,在慢慢丧失自己客户之后死亡、消失。
这里我觉得大家可以参考包商银行的案例,我认为设置一个赔付的底线额度是我们社区需要讨论的。说的绝对一点,就是不论什么情况导致的损失(除用户自己行为导致的),只要单个用户在这个限额以下的损失,就一定能获得对应的WPC的赔付。这个限额可以随着社区、WPC的发展来变化。
另外,国外的银行其实是很差异化的,但是使用底线赔付保险其实也是很多银行拉拢新客户的手段。我觉得小猪也可以考虑。

所以我的提议是,对于小额的损失,应该赔付。对于超过某个额度的单个客户的亏损,我们就应该考虑熊猫大佬对于导致损失的原因来分析了。

原因认定只是一方面,至多,告诉我们一个朴素得真理,没有任何第三方可以提供100%无误的服务,即便如此,使用第三方的服务也是必然,因为术业有专攻,自己造轮子成本太大了。

事实上,协议也没有声讨第三方承担后果,出了事还是得自己想办法。

我也希望用户的损失都可以获得赔偿,皆大欢喜。

现实层面,我们必须意识到,去中心化不存在兜底机制,团队也兜不了底,协议也都不行,最多就是在收入的基础上做补偿,其它的资金也都是用户的,WPC的补偿在发生巨额亏损的时候也是不够的。

所以,这里大家要讨论的应该是一个可以执行的方案,发生问题的止损线在哪里,各个链是不是都应该有一个,不然风险就难以隔离了。。

如compound社区提到的,这是一种新型的社会契约,说句难听的,要定一个认亏的方式。

我觉传统银行的逻辑可以借鉴,用来我们这里讨论出一个规则,老哥可以详细说说。

我这里强调一下,传统金融跟DeFi还是有很大不同。

其实所有的DeFi用户都应该有一种意识就是,在一个公平的机制下大家存款,获取收益,或者利用协议借钱,赚取收益。正常来说,这个市场运行正常,大家相安无事。

我们制定好事故处理规则之后,一旦出了问题也不怕,按照既定的规则获得赔偿,或者不被赔偿。

只要,这些原则都是透明的,大家一开始就是知情的情况下,选择使用协议,不存在被骗,或者扯不清的事情。

补充一下,其实各国银行,连政府都不兜底的,破产就是清算,还是不够,那就没有办法了。所以,传统金融其实也不是无风险的,同样是概率问题,就好像大家觉得chainlink 99.999%不出问题,但不还有0.001%出问题么。人要是倒霉,喝凉水都塞牙缝。

--------In English----------

WIP33: WePiggy Protocol Incident Resolution

1. Preamble

Proposal Number: WIP33
Proposal Title: WePiggy Protocol Incident Resolution
Proposal Author(s): Core Devs
Related Proposals / Dependencies: N/A
Replacement Proposal / Replaces: N/A

2. Abstract

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.

3. Motivation

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. Specification

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.

Details: https://www.yuque.com/zgryhn/fg3t76/lylhsl#CPr0Q

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.

Specifically:

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:

4.3.1 Characterization

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.

1 Like

Thank you so much for your amazing work, and I can also discuss this proposal with you guys in English.

3 Likes

This is a very well written article, thanks to DeFi Panda for producing it. I mostly agree with what is written, especially for the community to vote on the compensation. I think it was right at this beginning stage for the victims to be compensated as we are an early project and need to avoid bad publicity, but it would be good in true DeFi fashion for the community to have voted it through instead.

Going forward, i would recommend seeking a partnership with someone like https://nexusmutual.io which offers insurance for DeFi issues like this (hackers, contract failures, etc…). Users would feel more assured of the safety of their funds.

A compensation policy is a good idea, and perhaps removing higher risk assets that rely on single source price feeds. Great work DeFi.Panda, i look forward to reading other community opinions

1 Like

DeFi.Panda 的提案是第一份由除了核心开发团队之外,WePiggy 社区成员所产生的提案,而且质量之高,在中文项目的圈子里,都是罕见的。

CHE 异常清算是我们作为开发团队第一次参与处理的链上资金事件(当然,真心希望也是最后一次,我们文末会给出解决方案)。因为看过不少同行屡屡出现状况,我们事先拟定了一份“72 小时应急预案”。然而,谁也没有想到会如此之快就派上用场了。该预案一直处于草案状态,并没有经过社区的正式讨论和投票。

作为协议开发团队的我们,在事件发生后,也来不及多想,就像抓住救命稻草一样,第一时间就开始按照这个预案跟进和处理事件。期间也没有引导社区积极参与进来,只是希望能够尽早把事件处理好,对用户和社区也都有所交代,毕竟这确实是受损用户和社区当时所关注的。而且我们当时也正在紧张地准备 WPC 开放领取的相关开发工作(跨链桥、空投池、DAO 网站的开发和测试,以及各种合约的撰写和审计等)。

现在回想起来,确实是不够成熟的做法。一方面,可能引起一些用户错误地认为日后协议和社区需要对此类事件承担无限责任,另一方面,也违背了协议治理的基本流程和 DAO 的精神。

我在这里谨代表 WePiggy 核心开发团队,向社区表示歉意,也向 DeFi.Panda 表示感谢。感谢他为我们和社区都敲响了警钟,并给出了切实可行的改进建议。

经过几次讨论之后,我们作为开发团队赞同 DeFi.Panda 的大部分意见,整理如下:

属于第三方责任,原则上不应该由 WePiggy 协议和社区来负责垫付损失。

若社区成员认为协议确实有必要垫付损失,事件发生时可以发起讨论并提交正式提案,由社区的 WPC 持有者共同投票表决。

垫付损失的来源应限定在:

1、协议早期的质押挖矿盈余;

2、借贷协议中的准备金部分;

3、WPC 代币分配中的风险准备金部分。

垫付损失的上限是:

1、某个网络上的用户损失以该网络的所有准备金优先垫付;

2、如果该网络准备金不够,使用协议早期质押挖矿的盈余垫付;

3、如果还是不够,根据事故发生时该网络分配到的 WPC 比例,计算相应的 WPC 风险准备金数量。并以事故之前 14 天的 WPC 市场均价为准,在受损用户中按资产损失的比例进行分配。

垫付损失的流程,基于原有的“72 小时应急预案”改进为:

1、事件调查取证(链上数据搜集,协议紧急风控,多方联合调查)

2、社区投票决策(根据事件调查报告,对事故定性,定损,讨论垫付方案,并发起正式提案)

3、用户损失垫付(提案获得社区投票支持以后,由社区监督开发团队执行)

4、事件损失追讨(若明确存在黑客攻击行为)

未来我们将采取以下方案,显著提示由第三方引入的风险,进一步降低协议面临的风险,提升协议安全水平:

1、在所有网络中,明确标识所有币种价格的预言机来源(已完成),并增加风险提示,声明由此所产生的第三方风险,WePiggy 协议和社区有权不进行赔付(开发中);

说明:考虑到未来 WePiggy 协议还将入驻其他新兴公链,这些公链上可能会存在类似 OEC 的情况:尚未与 Chainlink 这类权威可靠的预言机来源进行整合,但存在由社区开发,公链团队孵化或引入的其他第三方主流预言机。因此,必须让这些网络中的用户对此风险有明确的意识。在此基础上,由用户决定是否继续使用特定网络的借贷协议。

2、排期开发 WPC 财库页面。在页面中详细展示 所有网络中的协议准备金,以及 WPC 风险准备金情况;

说明:WPC 开放领取后,WPC 财库透明化即可提上开发日程。这有助于所有用户明确了解协议在各个网络的准备金情况,以及补偿上限。

3、优先开发预言机风控模块,当备用预言机与主预言机之间发生巨大价格偏差时,协议的借款功能将自动关闭,但不影响存款、取款和还款功能;

说明:不是所有的预言机都是 Chainlink。这些预言机有可能向协议推送某个币种严重偏离市场的价格信息。预言机风控模块将会在监测到这类报价异常时,主动关闭协议的借款功能,避免更多的债务产生。由于模块本身也可能存在报价异常情况,因此它不会去主动关闭协议的其他功能,不会影响用户任何的存款、取款、还款和清算行为。该模块只是在监测到主预言机有可能出错的前提下,为用户的资产安全提供最后一道“防火墙”。我们不敢说自己比 Chainlink 在预言机方面更专业、更可靠,但站在巨人的肩膀上,做一些微小的补充,尽己所能守护协议用户的资产安全,还是可以努力的。

4、定期对所有网络上的 WePiggy 协议资产进行风险再评估,根据实际市场情况,积极发起提案对资产的风险参数进行再调整;

说明:正如 DeFi.Panda 所说——市场不是一成不变的。协议应该定期对上架资产进行风险再评估,及时调整风险参数,以免发生因为流动性不足,导致无法及时清算,或者是资产的对手方风险显著增大,可能抽干协议资金池等问题。

5、优化开发团队的自研清算机器人,极力避免被第三方机器人抢跑;

说明:清算始终是公开的。但是如果我们的机器人能够争取到更多的清算订单(尽管这个难度不小),特别是在新公链上,那么就可以争取在极端行情之下,也能为遭遇异常清算的用户挽回一些损失。

6、建议社区逐步降低各种长尾资产的存款上限,直至完全消除长尾资产对 WePiggy 协议所造成的潜在风险;

7、开发面向长尾资产的专门借贷产品,与主流资产的资金池风险隔离,避免暴跌的黑天鹅行情下产生大量无法清算的坏账;

说明:正如 DeFi.Panda 所说——作为一个借贷协议,也就是去中心化的银行,有必要将协议的资产安全放在第一位考虑,而不是不断引入更多长尾资产,将他们与主流资产的风险杂揉到一起,这样最终走向 Cream 的老路。

通过这次 CHE 异常清算事件,以及 DeFi.Panda 的提案,促使我们整个开发团队都进行了深刻的反思。无论协议如何反复提示风险,大部分用户其实都还是很难正视和承受本金湮灭的风险。第三方服务也很难对这个损失负责(当然,幸运的是,这次 CHE 异常清算事件我们遇到了 OEC 节点团队,他们愿意提供一定的财务支持,再次表示感谢),要求黑客还钱更是痴人说梦的事情。最终对损失买单的,还是协议自身的准备金和 WPC 的持有者。作为 WePiggy 的开发团队和社区,也无法承受来自受损用户要求承担无限责任的压力(这也是不合理的)。

因此,相比 Aave 这样略显激进的上币策略,WePiggy 应该更在乎安全,在各个网络上主打主流资产的借贷,成为资产品类最为纯净,风控最为严格和安全标准顶尖的借贷协议。

我预测,未来借贷赛道的产品将会越来越多。每一家都会有不同的市场定位,不同的特色功能,不同的风控标准,不同的团队实力。作为这几百家中的一家,我们希望 WePiggy 是其中最安全稳健的那一家——英雄比气长。只有这样才能在长久的市场竞争中存活下来。我们的社区也才能发展壮大。,WPC 也才会有长久可期的价值。

最后,我们建议对借贷协议有使用需求的用户,在充分了解和评估每家“银行”的产品特性后,尽可能将资产分散存储在你认为值得信赖的不同网络上的不同“银行”,以此分散风险,提升反脆弱性,避免单点风险为自己造成不可挽回的巨大损失。

1 Like

Thank you so much, dude.
But, as far as I know, the DeFi insurance does not work well for the DeFi incident, of course, it is an option.
If someone knows that very well, can give us some suggestion.

1 Like

3、优先开发预言机风控模块,当备用预言机与主预言机之间发生巨大价格偏差时,协议的借款功能将自动关闭,但不影响存款、取款和还款功能;
这个不错

4、定期对所有网络上的 WePiggy 协议资产进行风险再评估,根据实际市场情况,积极发起提案对资产的风险参数进行再调整;
是的,这个希望团队能给一个动态调整的办法,看看是不是至少一个月一次

5、优化开发团队的自研清算机器人,极力避免被第三方机器人抢跑;
这个真的做的到么,哈哈哈,链上科学家太多了

6、建议社区逐步降低各种长尾资产的存款上限,直至完全消除长尾资产对 WePiggy 协议所造成的潜在风险;
这个非常重要,今天我在电报群里面看到有个老哥应该就是一个别的项目的苦主,我们社区一定要避免重蹈覆辙。建议下架一些风险大的资产,只保留硬通货。我稍微研究了一下,各个链的情况,比如这些:
xLON - 这个我主要是担心发生cream遇到的那种事故
YFII - 项目已经没有人推动了,基本上是一个庄币了,没有未来

CHE - 一开始还行,现在对社区帮助不大了,成交量不大,dex流动性一般,项目表现欠佳,说不定哪天团队不做了

NULS - 一开始还行,现在对社区帮助不大了,dex流动性弱的离谱,遇到爆仓估计都不好清算
MASK - 一开始还行,现在对社区帮助不大了,dex流动性不佳

dQUICK - 跟xLON差不多原因,除此之外,这是一个毫无存在感的资产

7、开发面向长尾资产的专门借贷产品,与主流资产的资金池风险隔离,避免暴跌的黑天鹅行情下产生大量无法清算的坏账;
感觉没太大必要,SUSHI做的KASHI就感觉没什么用,如果跟大资本合作另外搞个市场还行,反正不要影响小猪的品牌。

小猪要继续保持稳健,DeFi世界风险无处不在,我希望当别人都发生问题陆续倒下,我们社区还能站稳脚跟。日拱一卒,迟早TOP3,加油啊!

2 Likes

嗯,达成共识!没有问题的话,我们这两天整合下意见,形成一份新的提案吧,让社区的大伙儿正式投票。一起把 WePiggy 塑造成最安全,最纯粹的借贷协议。

----------- In English------
( Translation is slow because there is a lot of content)

DeFi.Panda’s proposal is the first proposal produced by members of the WePiggy community in addition to the core development team, and it is of high quality, which is rare in Chinese crypto community.

CHE abnormal liquidation is the first on-chain incident that we have participated in as a development team (of course, sincerely hope it will be the last time, we will give a solution at the end of this article). As we have seen many incidents happen before, so we have drawn up a “72-hour emergency plan” in advance. However, no one thought it would come in handy so quickly. The plan has been in a draft state and has not been discussed in governance forum and voting by the community.

As the protocol development team, after the incident, we didn’t have time to think about it. Just follow up and deal with the incident in accordance with this plan as soon as possible. During this period, we did not guide the community to actively participate in it. We just hope that the incident can be handled as soon as possible, so that we can give a quick result to the community. After all, this is indeed the concern of the affected users and the community at that time. And we were busy for WPC token official launch related work (cross-chain bridge, airdrop pool, DAO website development and testing, as well as various smart contracts writing and auditing, etc.) .

In retrospect, it is indeed immature. On the one hand, it may cause some users to mistakenly believe that the protocol and the community need to bear unlimited responsibility for such incidents in the future. On the other hand, it also violates the basic process of governance and the spirit of DAO.

On behalf of WePiggy’s core development team, I would like to apologize to the community and thank DeFi.Panda. Thank you so much for sounding the alarm for us and the community, and for giving practical suggestions for improvement.


After several discussions, we, as the development team, agree with most of DeFi.Panda’s opinions, which are summarized as follows:

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.


Compensation source should be limited to:

1 The mining pool extra rewards in the early days of the protocol;

2 Reserves in WePiggy lending protocol;

3 the risk reserve part of WPC token distribution.


The upper limit of advance losses is:

1 The loss of users on a certain chain should be mainly compensated by all the reserves on that chain;

2 If it is not enough, should use the mining pool extra rewards in the early days of the protocol;

3 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.


The process of advancing losses, based on the original “72-hour emergency plan”, is improved as follows:

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)


In the future, we will adopt the following plans to highlight the risks introduced by third parties, further reduce the risks faced by the protocol, and improve the security level of the protocol:

1. In all networks, clearly identify the price source for all token prices (completed), add a risk warning stating that the WePiggy protocol and the community have the right not to pay out for any third party risks arising from this (under development);
Considering that the WePiggy protocol will launch on other emerging public chains in the future, there may be OEC-like situations on these public chains: no authoritative and reliable oracles such as Chainlink, but there are some other third-party oracles, which are developed by the community or the public chain team.

Therefore, users in these networks must be clearly aware of this risk. On this basis, it is up to the user to decide whether to continue to use the lending protocol on this network.

2. Start the development of WPC treasury page to show users the details of all reserves and WPC risk reserves for all networks;
After the WPC is open for claim, the transparency of the WPC treasury can be put on the development schedule. This helps all users have a clear understanding of the agreement’s reserves in each network and the upper limit of compensation.

3. Give priority to the development of the oracle risk control module. When there is a huge price deviation between the backup oracle and the primary oracle, the borrowing function will be automatically closed, but it will not affect the deposit, withdrawal and repayment functions;
Not all oracles are Chainlink. Sometimes, other third-party oracles may feed abnormal prices to the protocol. The oralce risk control module will actively shut down the borrowing function when it detects such an abnormal quotation to avoid more debts. Since the module itself may also have abnormal quotations, it will not actively close other functions of the protocol, and will not affect any deposit, withdrawal, repayment and liquidation operations of users. This module only provides the a “firewall” for the user’s asset security on the premise that the primary oracle may be faulty. It’s a small addition, to protect the security of the protocol users’ assets.

4. Regularly evaluate the risks of all listed assets on all different networks, and actively initiate proposals to re-adjust the risk parameters of assets based on actual market conditions;
As DeFi.Panda said, the market is not static. The protocol should periodically reassess the risks of listed assets and adjust risk parameters to avoid problems such as insufficient liquidation liquidity, greater counterparty risk.

5. Optimize the self-developed liquidation robot to beat the third party.
The liquidation is always open to all parties in crypto world. But if our robot can win more liquidation orders (although it is not easy), especially on the new public chains, then we can save some losses for users who have encountered abnormal liquidation under extreme market conditions. .

6. It is recommended that the community gradually lower the deposit upper limit of various long-tail assets until the potential risks caused by long-tail assets to the WePiggy protocol are completely eliminated;

7. Develop special lending products for long-tail assets, isolate them from the capital pool risks of mainstream assets, and avoid a large number of bad debts due to extreme market conditions.
As DeFi.Panda said, 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. To avoid repeating CREAM’s mistakes.


Through this CHE abnormal liquidation incident and DeFi.Panda’s proposal, our entire development team has been deeply introspected. No matter how the protocol repeatedly prompts risks, most users are still difficult to face and bear the risk of principal loss. It is also difficult for third-party services to be responsible for this loss (of course, fortunately, in this abnormal CHE liquidation incident, the OEC node team is willing to provide some financial support, highly appreciated their help), and asking hackers to return the funds is totally impossible. In the end, only funds belong to the protocol can be used for compensation, as a result, WPC holders suffer the losses. It is also not possible for development team and community of WePiggy to withstand the pressure from affeacted users to assume unlimited responsibility (this is also unreasonable).

Therefore, compared to Aave’s slightly aggressive listing strategy, WePiggy should care more about security, focusing on the lending of mainstream assets on various networks, becoming a lending protocol with the simplest listed assets, the most stringent risk control, and the highest security.

I believe that there will be more and more products on the loan track in the future. Each company will have different market positioning, different features, different risk control standards, and different team strengths. As one of these hundreds of families, we hope that WePiggy will be the safest and most stable of them-a hero is better than an angry one. Only in this way can we survive the long-term market competition. Only our communities can develop and grow. , WPC will also have long-term value.

I believe that there will be more and more lending products in the future. Each will have different market positioning, different features, different risk control standards, and different team strengths. As one of them, we hope that WePiggy will be the safest and stablest among them-he who laughs last, laughs best. Only in this way can we survive the long-term market competition, our community can develop and grow, and WPC can have long-term value.

Finally, we recommend that all users, after fully understanding and evaluating the product characteristics of each “bank”, store assets as much as possible in different “banks” on different networks that you think are trustworthy, so as to spread risks and improve Anti-fragility, avoid a single point of risk to cause irreparable huge losses for yourself.

3 Likes