The analysis of Nerve Bridge Security Incident

By BlockSec

0x.1 Preface

On Nov 15th, 2021, our internal monitoring system caught suspicious flashloan transactions on BSC. After investigation, we found that it was an attack targeting Nerve Bridge, including the MetaPools of fUSDT and UST.

Figure 1: an example of attack transaction

As of this writing, the attacker has exhausted the liquidity of fUSDT and UST of Nerve’s staking pools, and gained 900 BNB profit.

Surprisingly, we found that the vulnerable code is forked from Saddle.Finance, which already led to 8M$ loss of Synapse Bridge on Nov 6th, 2021. Specifically, the root cause of the vulnerability comes from the inconsistent implementation of calculating exchange amount of tokens in different libraries.

However, there does NOT exist any public available report to analyze this security incident. As such, in this blog, we aim to provide a comprehensive analysis, including the mechanism of the project, the vulnerability and the attack.

0x2. Background

0x2.1 What is MetaPool?

Basically, Curve provides two kinds of stablecoin swap pools, i.e., Standard StableSwap Pool and MetaPool. The former is a fully AMM to create cross-markets between different stablecoins [1]. It is the most widely used type of pool, e.g., Curve.3pool, which consists of DAI, USDC and USDT. However, this pool cannot isolate the risk between stablecoins, which may lead to great losses for LP providers.

As such, MetaPool is proposed to address this problem. As stated by Curve [2], “it allows a single coin to be pooled with all the coins in another (base) pool without diluting its liquidity’’. It is essentially a swap pool between a stablecoin and a LP token of a Stand StableSwap Pool (which consists of several other stablecoins). In our context, we call these two types of stablecoins as pool stablecoin and underlying stablecoin, respectively.

For example, one victim of this incident is just the MetaPool of fUSDT and LP token of Nerve.3pool (including BUSD, USD and USDC), and the structure of this pool is essentially [fUSDT, LP token of (BUSD, USD, USDC)]. Thus fUSDT is the pool stablecoin, while BUSD, USD and USDC are the underlying stablecoins.

Figure 2: Neve.3pool

0x2.2 Source of the Vulnerable Code

Curve’s MetaPool is implemented in Vyper. To support the development of Solidity, Saddle.Finance’s dev team rewrite the code with Solidity. As the very beginning of this vulnerability, it has been forked and adopted by Synapse and Nerve, respectively. On Nov 6th, Synapse was attacked.

Figure 3: attack transactions targeting Synapse

Around $8.2M funds were drained from the MetaPool, while no funds were actually lost due to a ``silly’’ mistake made by the attacker [3].

After that, Saddle.Finance took an emergency action to guarantee the safety of their funds by pausing all the MetaPool contracts. However, Nerve Bridge did not take any action, which inevitably led to this security incident.

The relevant contract addresses are listed in the following:

  • MetaSwap: 0xd0fBF0A224563D5fFc8A57e4fdA6Ae080EbCf3D3
  • SwapUtils: 0x02338Ee742ddCDe44488640F4edf1Aa947E670E7
  • MetaSwapUtils: 0x91d1DBE983fBCbBAC198D5310f1d0C249bb54E65

0x3. Vulnerability Analysis

In MetaPool, there are two important functions, i.e., swap and swapUnderlying. Specifically, the former is used to swap the LP token and the pool stablecoin, while the latter is used to swap the pool stablecoin and the underlying stablecoins.

As to the victim MetaSwap contract of this incident, these two functions are implemented in two different libraries:

  • swap function in the SwapUtils contract
  • swapUnderlying in the MetaSwapUtils contract

To swap an underlying stablecoin for the pool stablecoin, the swapUnderlying function will use tokens provided by users to add liquidity to the underlying pool to get LP tokens. After that, it becomes a swap between the LP tokens and the pool stablecoins, i.e., the same logic as the swap function. Thus the corresponding key swapping parameters shall keep consistent with each other. One of such parameters is xp, which is used to normalize the token values when performing the swap. The normalized results will be used to conduct the further calculation.

Unfortunately, the implementation of xp in the two functions are different, as follows:

Figure4: xp in SwapUtils
Figure 5: xp in MetaSwapUtils

The above two figures demonstrate the inconsistency. The code snippet in the red rectangle is used to adjust the value of the LP token by measuring the “virtual price” of a LP token (which increases from a baseline value of 1 as more fees come). Meanwhile the swap function ignores the impact of the virtual price, which means the value of the LP token will be underestimated. In other words, more LP tokens could be swapped out.

As a result, it is possible to harvest more pool stablecoins by first fetching back the liquidity of the underlying stablecoins with the corresponding LP token, and then swapping pool stablecoins by invoking the swapUnderlying function.

0x4. Attack Analysis

We will take the sample transaction ( as an example to illustrate the attack.

Figure 6: the five attack steps

Figure 6 shows that the attacker took the following five steps to launch the attack:

  • Step 1: borrowing 50,000 BUSD using Flashloan from Fortube
  • Step 2: swapping 50,000 BUSD for 50,351 fUSDT from Ellipsis.
  • Step 3: invoking the swap function of MetaSwap to swap 50,351 fUSDT for 36,959 Nerve 3-LP with a relatively big slippage.
  • Step 4: invoking the removeLiquidityOneCoin function of Nerve.3pool with the LP tokens (received in the previous step) to remove the liquidity of BUSD, i.e., 37,071 BUSD.
  • Step 5: invoking the swapUnderlying function of MetaSwap to swap BUSD for fUSDT, and receiving 51,494 fUSDT.

The attacker repeatedly execute the above five steps (around 200+ transactions) to drain the liquidity of the MetaPool, and finally harvested 900 BNB.

Interestingly, the attacker just adopted the same approach used in the Synapse incident, which is not an optimized way to achieve the goal. Alternatively, it is possible launch attacks more efficiently, e.g., applying optimized parameters to drain the liquidity in one transaction. The result suggests that the attacker might NOT fully understand the root cause of this vulnerability.





Credits: Hailin Wang, Lei Wu, Yajin Zhou @BlockSec