There is no way to recover, and the YAM voting rescue operation is doomed to fail from the beginning

Within 36 hours, he saw his building rise, and within a few minutes, his building collapsed.

At 03:00 on August 13th, Beijing time, the high-profile DeFi project YAM Finance announced the launch of liquidity mining. In just one day, the value of locked assets exceeded 600 million U.S. dollars, and the increment and growth rate of locked assets reached Almost in a state of madness. And according to this development, the annual interest rate of some wool parties who injected liquidity into the pool in the early stage can even approach 200 times, which shows the degree of madness.

However, just as everyone was falling into the mining carnival, an accident happened.

secondary title

How to save our YAM little sweet potato?

After discovering the vulnerability, the YAM team launched a "rescue operation", saying that they needed 160,000 delegated votes to submit a governance proposal, so they launched a call to the community to vote. Soon, this vigorous community voting operation will be completed.

However, just when everyone thought it was just a false alarm, at 16:01 pm on August 13, Beijing time, YAM founder Brock Elmore tweeted, sorry everyone, I failed. HH?

After the PeckShield security personnel intervened in the analysis, they quickly located the essence of the problem: there was a code formula error in the elastic supply mechanism (rebase), which caused the system to automatically issue 10 ^ 18 new tokens when the second rebase was triggered. If it is kept at a high level, then each subsequent rebase will trigger an exponential increase, which will turn the number of Little Sweet Potato YAM into a terrible astronomical number. This means that no matter how the community entrusts votes in the later stage, it will not be able to obtain enough votes to control the system, and the entire system will fall into a state of loss of control and no master.

Originally, the YAM official called on all YAM holders to complete the voting "rescue operation" through proxy voting to fix this existing loophole. However, further analysis by PeckShield security personnel found that when YAM officials began to appeal, the rescue operation was actually doomed to fail.

There are two reasons:

1）Time is too late: YAM officials may have overlooked one point. It will take at least 12.5 hours for the proposal to be implemented after the completion of the preparations for the voting rescue operation. According to the current time rhythm, when the implementation takes effect, the second rebase has already been completed. trigger.

2）The newly-deployed governance contract cannot be effectively executed: due to the second rebase trigger, the official expected to execute the new governance contract after the execution time, but found that the total amount of votes was far from reaching 4% of the total amount agreed in the contract. Therefore, it cannot be effectively implemented.

secondary title

First, let’s introduce the flexible supply mechanism (rebase) of the YAM smart contract:

1) The system will dynamically adjust the supply of tokens according to market price fluctuations. When the market price rises, additional tokens will be issued proportionally to reduce the value of unit tokens until it drops to $1.

2) Rebase is performed twice a day, and each rebase will change the supply of tokens, and a certain amount of tokens will be issued or destroyed according to the current market price.

Let me talk about a key factor in the implementation of the proposal: the holders entrust voting, and the number of votes exceeds 1% of the total, the proposal can be executed and arranged, and the execution of the arrangement according to the contract needs to wait for 12.5 hours, and when the proposal is executed, then Voting needs to exceed 4% of the total. Only in this way can the new governance contract be implemented and take effect, and the project can continue to operate normally.

With the foreshadowing of the above technical points, let’s take a look at YAM’s official follow-up timetable to understand why this rescue operation is doomed to fail.

As shown in the timeline below:

②It is the time when the first rebase is triggered. Due to a bug in the contract, the assets of totalsupply have skyrocketed abnormally. The official found that the bug existed and disclosed it.

But things backfired. It was too late for the officials to discover the loopholes and disclose the call for voting, missing the only golden emergency period that could succeed. What's worse, according to the official time rhythm, when the new governance contract reaches the execution time of ⑦, the number of votes must exceed 4% of the total amount, and the total amount at this moment has expanded by 10^18*10^18 , the number of votes accumulated before is already a drop in the bucket, and it will not help at all.

Therefore, this rescue operation was doomed to fail from the very beginning.

Below we will make a detailed analysis of this incident: (the project party github addresshttps://github.com/yam-finance/yam-protocol）

image description

Figure 1. Asset changes for the first rebase

As the information on the chain above (https://oko.palkeo.com/) shows that after the first rebase, totalSupply skyrockets from 3,500,000* 10^18 to a maximum value.

Let's further analyze the code to see what happened in the code: First, from the information on the chain, we can see that the rebase operation calls the YAMRebaser::rebase() function of the YAMRebaser contract (we will skip this function first and talk about it later) , we finally found that it recalculates totalSupply by calling the rebase() function of the YAM contract (0xa923af6d05993495257a872ec69dbbf01501eb0e) (the code logic is shown in Figure 2 below). In the totalSupply assignment operation on line 340, we can see that this line of code has an obvious Error - did not divide BASE, which caused the value of totalSupply to increase by 10^18 times.

image description

Figure 2. YAMToken::rebase() gets an unusually large totalSupply value

And after 12 hours, YAM triggered the second rebase (https://oko.palkeo.com/image description

Figure 3. Second rebase asset changes

image description

Figure 4. YAMRebaser::rebase() calculates initSupply with wrong totalSupply

secondary title

Why is it said that the project party completed the preparation work too late?

image description

Figure 5. The GovernorAlpha::queue() function sets eta (effective time)

And why do you say that the rescue actions that have been taken are of no avail at all?

image description

Figure 6. GovernorAlpha::execute() checks proposal status

image description

Figure 7. GovernorAlpha::state() execution returns Defeated error

image description

Figure 8. GovernorAlpha::quorumVotes() returns a wrong outlier

image description

image description

Summarize

This YAM vulnerability event eventually caused 750,000 yCRV in the governance contract to be permanently locked, and the situation of rapid plunge and inability to recover in a short period of time, I don’t know how many people were buried at the high price point, and the degree of madness became This is the truest portrayal of DeFi liquidity mining today, isn't it cruel and magical? If the project party has tested the rebase process once before deploying the contract, it will definitely be able to catch the existence of loopholes. It is enough to see the importance of security audits for DeFi projects.

To sum up, PeckShield wants to use this to advise you,In the blockchain world, it is important to be in awe of every line of contract code, because any slight omission may cause an irreparable situation. After all, the code is written by humans, and it is difficult to completely avoid loopholes. Therefore, it is necessary for the project party to do sufficient testing and third-party security audit work before the contract is deployed online, which will help it discover and troubleshoot potential contract codes earlier. It is too late to fix the security breach after the breach occurs