Flash Loans: The “Zero-Cost Strategy” of the DeFi World

Flash Loan Attack Incidents

1. February 16, 2020:

The margin trading platform bZx suffered a flash loan attack, resulting in a loss of $360,000. Just two days later, a similar attack occurred, causing another $600,000 in losses.

2. February 22, 2020:

Concerned about flash loan risks, the Maker governance team passed an emergency proposal to increase the Governance Security Module delay time from 0 seconds to 24 hours.

3. June 29, 2020:

Two liquidity pools on Balancer were exploited in a flash loan attack, leading to losses of $500,000.

What Are Flash Loans?

Flash loans are designed for developers, allowing them to borrow funds instantly without any collateral. However, the entire loan process must be completed within a single Ethereum transaction.

Key Points:

• Only developers familiar with Ethereum programming can utilize flash loans.

• They require no collateral or credit history.

• A single Ethereum transaction can perform multiple operations, such as transferring funds and calling multiple smart contract functions.

Flash loans must complete three steps—borrowing, using, and repaying the loan—within the same transaction. If any step fails, the network rejects the transaction entirely, as if nothing ever happened.

Why Are Flash Loans Needed?

The primary purpose of flash loans is profit generation, often through arbitrage across different decentralized exchanges (DEXs), commonly referred to as “brick-moving.”

A Simple Example:

1. Use a flash loan on the AAVE platform to borrow $10,000.

2. Buy tokens at a lower price on DEX A.

3. Sell the tokens at a higher price on DEX B.

4. Repay the loan (plus any interest).

5. Keep the profit.

Case 1: The First Flash Loan Attack

1. The attacker first borrowed 10,000 ETH through a flash loan from the dYdX platform.

2. They transferred 5,500 ETH to Compound as collateral and borrowed 112 WBTC.

3. Next, 1,300 ETH was transferred to bZx’s margin trading platform. Using 5x leverage, the attacker borrowed 5,637 ETH, which they exchanged for 51 WBTC on Uniswap. This step was critical to the attack, as the attacker exploited a vulnerability in bZx’s smart contract, enabling them to sell the borrowed ETH at a low price. This triggered a liquidation event where the attacker’s bZx account lost all its funds and even incurred a negative balance.

4. The attacker then used the 112 WBTC borrowed from Compound to buy underpriced ETH on Uniswap, acquiring 6,871 ETH and completing the “wash trade.”

5. The attacker repaid the 10,000 ETH loan, leaving a balance of ETH. Additionally, the attacker redeemed the collateral from Compound at the normal market price, exchanging 4,300 ETH for the 112 WBTC, yielding a profit of ETH.

6. Summary: The attacker gained ETH, worth approximately $300,000.

Root Cause Analysis:

This was a sophisticated attack executed in a single transaction lasting only a few seconds. By using a flash loan to gain substantial capital, the attacker manipulated market prices to create significant slippage. The core issue lay in a vulnerability in bZx’s code, which failed to account for extreme price slippage, resulting in insolvency and enabling asset siphoning.

Case 2: Another bZx Exploit

1. The attacker borrowed 7,500 ETH from bZx via a flash loan.

2. They exchanged 900 ETH on Kyber for 156,000 sUSD, artificially inflating the price of sUSD to 2.5 times the average market price (approximately $2.50 per sUSD).

3. Using Synthetic, they deposited 3,518 ETH to mint 943,000 sUSD at the normal sUSD price. At this point, the attacker held a total of 1.1 million sUSD, equivalent to 20% of the total sUSD supply.

4. The attacker transferred the 1.1 million sUSD to bZx. Since bZx relied solely on Kyber for price feeds, they successfully borrowed 6,796 ETH, whereas under normal conditions, 1.1 million sUSD could only collateralize 4,000 ETH. This created another under-collateralized loan, allowing the attacker to profit.

5. The attacker repaid the flash loan, retaining ETH.

Root Cause Analysis:

Unlike the first case, this attack exploited bZx’s reliance on a single price feed (Kyber) for valuation. By manipulating Kyber’s market prices, the attacker secured an excessively large loan. Following the incident, bZx announced the addition of ChainLink as an additional price oracle.

Case 3: Balancer Exploit Using Deflationary Token (STA)

1. The attacker borrowed 100,000 WETH from dYdX via a flash loan.

2. Balancer, an AMM DEX similar to Uniswap, contained a liquidity pool with assets like WETH, WBTC, LINK, and STA. The attacker used the borrowed WETH to buy STA tokens from the Balancer pool, reducing the STA supply in the pool to 1 wei STA (0.000000000000000001 STA). Due to the AMM pricing formula, the STA price skyrocketed, with 1 STA valued at 30,000 ETH.

3. The attacker then sold minimal amounts of STA back to the Balancer pool. Normally, when a token’s supply increases, its price decreases. However, STA is a deflationary token, deducting 1% of each transaction as a burn fee. By repeatedly selling 1 wei STA, the attacker exploited a vulnerability in Balancer’s gulp() function, locking the STA balance at 1 wei STA and maintaining its inflated price.

4. Using this method, the attacker drained other assets like WBTC, LINK, and SNX from the Balancer pool.

5. Finally, the attacker repaid the flash loan and exited with profits. Balancer suffered a loss of approximately $500,000.

Root Cause Analysis:

The composability of DeFi protocols also introduces compatibility risks. In this case, Balancer’s failure to properly handle deflationary tokens led to the exploit. Following the attack, Balancer blacklisted deflationary tokens to prevent future incidents.

Case 4: Potential Governance Attack

By leveraging flash loans, an attacker could acquire enough MKR to initiate a vote to replace MakerDAO’s governance contract with a malicious one, allowing them to steal the system’s ETH collateral and mint new DAI to repay the flash loan. To mitigate this risk, on February 22, the Maker governance team passed an emergency proposal, increasing the Governance Security Module delay time from 0 seconds to 24 hours.

On October 27, it was reported that a DeFi protocol team used a flash loan to manipulate a MakerDAO governance vote:

1. The team borrowed 50,000 ETH via a flash loan from dYdX, valued at $20 million.

2. They deposited the ETH into AAVE and borrowed 13,000 MKR, worth $7 million.

3. The borrowed MKR was used to participate in a MakerDAO governance vote, ensuring the proposal’s approval.

4. The MKR and ETH were repaid after the vote.

Case 5: Harvest Finance Suffers Oracle Manipulation – The Largest Loss to Date

1. The attacker first obtained ETH through a private Ethereum transaction platform to deploy the attack contract.

2. Using a flash loan, the attacker borrowed $18.3 million USDT and $50 million USDC from Uniswap.

3. The attacker swapped $17.22 million USDT for $17.21 million USDC in Curve’s Y pool, increasing the USDC price in the pool by approximately 1%.

4. They then deposited nearly $50 million USDC into Harvest’s USDC vault. Since Harvest’s exchange rates were directly linked to Curve’s Y pool, the inflated USDC price from Step 3 allowed the attacker to receive $51.46 million fUSDC.

5. The attacker swapped $17.23 million USDC back into $17.23 million USDT in the Y pool, returning USDC’s price to normal.

6. Finally, the attacker redeemed the $51.46 million fUSDC in Harvest for USDC at the now-normal price, receiving $50.59 million USDC. This resulted in a profit of $59,000 USDC for this cycle.

7. The attacker repeated this process several times over the next few minutes, causing Harvest to lose more than $34 million USDC.

Root Cause Analysis:

Similar to the second bZx attack, the root cause was oracle manipulation. By inflating the price of assets in Curve’s Y pool, the attacker exploited Harvest’s reliance on the manipulated price feed. Due to Harvest’s total value locked (TVL) exceeding $1 billion, the resulting losses were particularly severe.

How to Prevent Flash Loan Attacks

While there is no definitive way to completely prevent flash loan attacks, several measures can help reduce the risk:

1. Oracle Selection:

Many flash loan attacks have shown that market prices are easily manipulated and cannot be used directly as price feeds. Weighted averages or multiple oracle sources should be considered to avoid reliance on a single price feed.

2. Governance Voting Lock Period:

On-chain governance votes should include a lock period to allow time for potential vulnerabilities or malicious activities to be identified and mitigated.

3. Robust Business Logic:

Product and protocol design must account for extreme scenarios. Under such conditions, regular business logic may fail and expose vulnerabilities. Planning for these edge cases can help mitigate risks.