YAM投票拯救注定失败的人从一开始！

36小时内，我看着他站起来，几分钟内他就倒下了。

北京时间3时，德福旗下备受关注的项目YAM金融宣布启动流动性挖矿。资产在一天之内就超过了600万美元的增长速度。根据这一发展趋势，一些前期向池中注入流动性的羊毛党的年利率甚至接近200倍，这从疯狂中可见一斑。

然而，就在大家都参与挖矿狂欢节的时候，事故发生了。

北京时间8月13日早间消息，YAM金融发现其智能合约的弹性供应机制（返基）存在漏洞，导致第二次触发合约时出现大量额外代币。这意味着社区将无法获得足够的代币来执行任何治理操作，yam将成为一台失控的机器，并最终失去社区用户的信任。

如何拯救我们的YAM红薯？

在发现漏洞后，YAM团队发起了一场“拯救行动”，称他们需要16万张代理投票才能提交治理方案，因此他们呼吁社会投票。很快，充满活力的社区投票活动结束了。

然而，就在所有人都认为这只是虚惊一场的时候，北京时间8月13日下午16:01，YAM创始人布洛克·埃尔莫尔在微博上写道：“对不起，我失败了。”这是怎么回事？

peckshield的安全人员参与分析后，很快发现问题的实质是返基机制的代码公式有错误，导致系统在触发第二个回基时自动发出10^18个新代币。如果市场价格一直居高不下，指数级增发会在每次回基触发时进行，这将使红薯YAM的数量成为一个可怕的天文数字。这意味着无论社区在后期如何委托投票，都无法获得足够的选票来控制制度，整个制度将陷入失控、无主的状态。

原来，YAM官员呼吁广大YAM持有人完成投票“救市行动”，通过代理投票修复现有漏洞。不过，派克希尔德安全人员进一步分析发现，当亚姆官员开始上诉时，救援行动注定要失败。

有两个原因

1） 时间太晚了：yam的官员可能忽略了一个要点，即它的提案至少需要12.5小时才能投票支持救援行动的实施和生效。根据当前的时间节奏，当它的实现生效时，已经触发了第二个回扣。

2） 新部署治理合同无法有效执行：由于第二次返基触发，原预计由政府执行的新治理合同到了执行时间，但发现总票数达不到合同约定总金额的4%，因此，它无法得到有效实施。

为什么？其次，技术干货：

技术概述

本文首先介绍了yam智能合约的柔性供应机制（rebase）

1） 系统会根据市场价格波动动态调整代币供应。当市场价格上涨时，将按比例发行额外代币，以降低单位代币的价值，直至其降至1美元。

2） 每笔回扣将改变代币供应，并根据当前市场价格发行或销毁一定数量的代币。

实施提案的另一个关键因素是：如果得票数超过总票数的1%，则可以将提案付诸执行安排。根据合同，安排时间需要等待12.5小时。提案实施时，投票数需超过总票数的4%。这样，新的治理契约才能得以实施和生效，项目才能继续正常运行。

有了以上技术要点的铺垫，让我们看看YAM官方的后续日程安排，来了解救援行动为何注定要失败。

如下图所示：

② 这是第一次触发rebase的时间。由于合同中的一个缺陷，供应资产总额异常增加。这位官员发现了这个窃听器并将其公布了出来。

③ 现在是正式宣布部署新治理合同的时候了，之后社区开始投票。

④ 这是投票目标的初始完成时间，也是新的治理契约进入执行安排的时间。从那以后，合同的执行就等了12.5个小时。

⑤ 是第二个回基的触发时间。

⑦ 这是投票通过后新的治理合同正式实施的时候。

⑥ 在第二次回扣触发后31分钟，也许项目方发现它无法回到今天。方案被成功取消，项目方正式宣布YAM失败。

① 之后，绿色区域是“黄金紧急时期”，投票和提议救援行动可以成功。整个救援行动的准备工作需要在第一次回基触发前半小时内完成。（即蓝色虚线应提前移至绿色区域）。

这意味着yam官员应该在第一次回扣（北京时间8月13日凌晨4:08）之前发现这个漏洞，并留出足够的时间来完成新治理合同的部署和投票。

然而，与我们的愿望相反，这位官员发现漏洞并公布投票呼吁已经太晚了，错过了唯一可以成功的黄金紧急时期。更糟糕的是，根据官方的时间节奏，当新的治理合同到了执行时间时，票数将超过总票数的4%。目前，总金额扩大了10^18*10^18。以前累积的票数只是九牛一毛。

因此，救援行动从一开始就注定要失败。

下面我们将对这一事件进行详细分析：（项目方GitHub地址）https://github.com/yam-finance/yam-protocol)

详细过程分析

首先，让我们来看看我们第一次回基时发生了什么：

图1。第一次返利资产变动

比如上面链上的信息（https://oko.palkeo.com/0x7b9017ec92b200455e5269380195fbecff91c8acda30985cc1dc413d215076/)第一次返利后，总供应量从3500000*10^18飙升至最高点。

我们进一步分析代码，看看代码中发生了什么：首先，从链上的信息可以看出，yamrebaser契约的函数yamrebase:：rebase（）是由rebase操作调用的（我们跳过这个函数，稍后再讨论）。最后，我们发现它调用了yam契约的rebase（）（0xa923af6d0599345257a872ec69dbbf01501eb0e）；该函数重新计算totalsupply（代码逻辑如下图2所示）。在340行totalsupply的赋值操作中，我们可以看到这行代码有一个明显的错误——没有基数的划分，导致totalsupply的值增加了10^18倍。

任正非在第一次发现这个问题后，便公开了退基窃听事件，并展开了救市行动。

图2。Yamtoken:：rebase（）获取异常大的总供应值

12小时后，YAM引发了第二次回扣（https://oko.palkeo.com/0x32735e9ae9aac51739b5725a225be6c7a3851f422be986d0f44bc0ec475ee286/)此数据基于错误的total supply计算，这将导致initsupply的值出现异常。

图3。第二次返利资产变动

我们继续分析initsupply异常的原因。关键是上面提到了yamrebase:：rebase（）函数。此功能实现的主要逻辑是：首先，基于总供应量（）计算此折扣中要发行的yam数量，并在多次调用mint（）函数后输入yam的after rebase（）函数，该函数根据异常的minthamount为initsupply赋值。由于在第一个rebase中，totalsupply已成为一个最大值，基于此异常值的后续操作（如图4中的红色箭头所示）最终导致initsupply的计算错误，这将成为一个天文值。

图4。Yamrebaser:：rebase（）使用错误的totalsupply计算initsupply

当出现第一个rebase异常时，项目方已发现问题并决定提出修复系统的建议，希望将该建议放入执行队列并通过投票方式执行。当收到足够数量的投票时，治理契约允许任何人通过调用governoralpha:：queue（）函数对问题进行排队。然而，由于治理契约代码逻辑的实现，无论是在第二次回基之前还是之后，救援行动都不能正确执行。

为什么说项目方的准备工作完成得太晚了？

让我们看看下图中的governoralpha:：queue（）代码，我们注意到在queueorrevert函数之前的第224行中，设置变量ETA=current timestamp+延时锁定（12.5小时），这使得有效时间必须是加入队列后的12.5小时，而第二次回基时间与第一次回基时间相差12小时，这意味着救援行动需要提前到第一次回基至少半小时才能成功，否则永远无法执行。

图5。调控器alpha:：queue（）函数设置eta（有效时间）

为什么已经采取的救援行动毫无帮助？

当触发contract governoralpha:：execute（）时，首先执行state函数以获取当前的建议状态。

图6。Governoralpha:：execute（）检测建议状态

在state（）的第330行，如果投票提案Lt；=againstvotes（），建议状态设置为失败。

图7。Governoralpha:：state（）执行返回失败的错误

从规范中可以看出，项目方设计系统时，票数必须大于initsupply总金额的4%，才能使方案合法，如下图所示。但是，在第二次重设基之后，initsupply已达到最大值。这就导致了这样一个事实：票数（for votes）永远不能gt；=quorumVoices（），它总是返回违例的。

图8。Governoralpha:：quorumvotes（）返回错误异常

除了提案状态异常的问题外，如图9和图10所示，在第二次转基之后，由于governoralpha:：propose（）检查的票数必须小于proposalthreshold（initsupply的1%），因此不能再提出新的提案，更不用说投票赞成实施了。

图9。Governoralpha:：provide（）检测投票数是否大于initsupply的1%；

图10。Governoralpha:：proposalthreshold（）返回1%initsupply

总结

YAM漏洞事件最终导致治理合同中75万ycrv永久锁定，并出现快速下滑、短时间内无法恢复的局面。我不知道有多少人被埋在了价格高点。疯狂的程度已经成为当前非流动性挖矿最真实的写照，而其残酷的神奇程度是不是？如果项目方在部署契约之前测试了一次rebase过程，那么它将能够发现漏洞的存在。由此可见，安全审计对DeFi项目的重要性。

总而言之，peckshield希望提醒您，在区块链世界中，您必须敬畏每一行合同代码，因为任何微小的遗漏都可能造成无法弥补的局面。毕竟，代码是由人编写的，漏洞很难完全避免。因此，在合同部署上线前，项目方有必要做好测试和第三方安全审计工作。这将帮助他们尽早发现并检查合同代码的潜在安全漏洞。漏洞一旦出现，修补为时不晚