ValueDeFi Incident: Incorrect Weighted Constant Product Invariant Calculation

[Disclaimer] This analysis is based on the initial finding by @FrankResearcher!

Started at 07:41:39 PM +UTC, May 7, 2021, ValueDeFi’s vSwap contract was exploited to drain a number of pools at the loss of about $11M. The incident was due to the improper use of a complex exponentiation power() function behind the calculation and enforcement of the weighted constant product invariant. It is worthwhile to mention that vSwap uses the weighted constant product invariant formula for non 50-50 ratio pools. In the following, we elaborate the technical details.

Summary

This incident was due to the mis-calculation by the protocol on the adopted weighted constant product invariant for non 50–50 ratio pools. There is no flashloan or price manipulation involved. The consequence of mis-calculated invariant allows for draining of affected pool funds. Currently, the bug has been exploited to attack 9 non 50–50 ratio pools with the estimated loss of $11M.

Details

Incorrect Weighted Constant Product Invariant Calculation

The vSwap pool is initially forked from UniswapV2 but with the support of non 50-50 ratio pools. The non 50-50 ratio pools require a different approach to calculate the weighted constant product, i.e., reserve0^(weight0/50) * reserve1^(weight1/50) <= balance0Adjusted^(weight0/50) * balance1Adjusted^(weight1/50). Because of the required exponentiation function, ValueDeFi makes use of the Bancor formula to calculate the above constant product as shown below.

Note the power() routine takes four arguments (baseN, baseD, expN, and expD) and is used to calculate an integer approximation of (baseN/baseD)^(expN/expD)*(2^precision) where precision is used for the calculated result. However, there is a caveat in how this power() function should be used. It makes an explicit assumption that baseN must be no less than baseD, i.e., baseN >= baseD. In this attack, the pool’s swap() function are called with a crafted input that intentionally violates the above assumption. As a result, the weighted constant product enforcement is passed while the pool funds are being drained.

We started the analysis from the transaction behind one specific hack: 2fd0…c2de. This transaction has a number of operations against the non 50–50 ratio vBSWAP-WBNB pool and our elaboration only focuses on the first swap() operation operation. Specifically, this swap() operation in essence trades in 0.05 WBNB and trades out 1 WEI vBSWAP and 3,543.083896847545353949 WBNB! The purpose of trade-out of 1 WEI leads to balance0Adjusted = reserve0 - 1 WEI, which causes the execution to take the else-branch in the above figure. And the violated assumption on
balance1Adjusted >= reserve1 corrupts the power() execution, hence passing the constant product enforcement.

If we examine the root cause behind this attack, the vulnerability stems from the improper use of a complex exponentiation power() function, which unfortunately lies in the critical path for invariant calcuation and enforcement. In the meantime, we also strongly suggest to make the assumption explicit in the power() function by adding the following requirement: require(baseN >= baseD)!

The Funds

This attack leads to more than $11M loss from the affected 9 pools. And most of the attacker’s funds from the above exploitations are currently held in this wallet: b88a. We are actively monitoring this wallet for any movement.

About Us

PeckShield Inc. is an industry leading blockchain security company with the goal of elevating the security, privacy, and usability of the current blockchain ecosystem. For any business or media inquiries (including the need for smart contract auditing), please contact us at telegram, twitter, or email.