Flash Loans & Defi Attacks

As we work on flash loan attack debriefs we can gather a lot of information about what could have been taken as preventative measures. It’s important to understand how these flash loans work before diving into root causes and analytics.

Flash loans are loans given out without collateral and returned in the same block that they were lent out. This is possible in the world of smart contracts, because the code can verify whether or not it will be able to return the loan at the end of the block. If yes, it’s able to lend as much as the user needs. This is where the attack vectors come in.

We can draw from a study done by academics at the Imperial College London that looks at two notorious attacks in particular. Their main finding is as follows:

Flash loan attacks are typically Price Oracle Attacks / Oracle Manipulation

This seems to be the #1 cause of attacks at the moment, by far. What is important to note, is that decentralized exchanges are not decentralized oracles. Using Uniswap, Sushiswap, or Curve to get pricing information to execute trades is pulling data from potocols whose price depends soley on liquidity. Looking at the infamous ground zero bZx attack that sparked this wave of attacks, we can see exactly what happens. These flash loans are used to crash and manipulate the price of these decentralized exchanges, which most projects deemed safe to use. The issue here relies in the fact that these protocols prices depend entirely on liquidity. Here’s basically how it works:

  1. User takes a massive loan out
  2. User uses that loan, to buy out all the liquidity on one side of a liquidity pool, causing a massive drop in price
  3. This price is being used by another protocol to determine or execute some code, ie, they peg the price of their asset to the protocols asset. So the user swaps for next to nothing for a massive profit.
  4. Then pays back the original loan, and leaves with massive gains

What auditors and software engineers need to do, is make sure they don’t get pricing or data that rely on DEXes. Uniswap is a decentralized exchange NOT a decentralized pricing oracle, they are each a centralized data point, and using them as such is dangerous to a point where in the last 2 months, ~5 protocols have been hacked for over $30M combined.


This all being said, to prevent these attacks from happening, you need to make sure that when you’re getting pricing information, or any data at all, it needs to come from decentralized oracles and get the data from decentralized Chainlink Price Feeds, if it’s price data. For any other data you need to get your data from a decentralized network of Chainlink Oracles. And as an engineer, anyone can customize their oracle network to make it as wide or narrow as they like.

This all being said, at this point, there is enough information out there that if a protocol gets hacked and that protocol paid an auditor, that auditor needs to be held accountable as well, as missing centralized price oracles in audit reviews is going to make this keep happening. Many projects who have been hacked have integrated Chainlink price feeds as there backbone for data reliability and have since stabilized.

The second most popular attack is reentrancy attacks

To quote:

A reentrancy attack can occur when you create a function that makes an
external call to another untrusted contract before it resolves any
effects. If the attacker can control the untrusted contract, they can
make a recursive call back to the original function, repeating
interactions that would have otherwise not run after the effects were

Luckily, we know that fallback functions have been patched to use only 2300 gas, so this can be helpful here. Consensys recommends using call instead of transfer or send to protect yourself against these.

However, I’ve also seen the exact opposite suggested. I think using transfer is actually better. Just as long as you set the balance to 0 before you make an external call. Always try to make the external contract call after all the other important pieces are in-tact.

Other notes

It should be mentioned that there are some “hacks” that will also fix this issue. Making all your important transactions happen over the course of 2 or more blocks can be a hacky way to get around some of this. Also you will always want to use safeMath when working with massive integers, and need to make sure your overflows don’t break your protocol.

What other security pieces should we look at?

I want to make a preventdefiattacks.com instead to make it more general, since we’ve seen a lot of attacks not using flash loans.


@patrickalphac Thanks for your post and welcome to the forum. Based on your post and own knowledge, what research directions would you outline?


@patrickalphac I wanted to follow-up on one of the topics you brought up regarding the prevention of these attacks. Recently the team at ValueDeFi made the decision to implement Chainlink Price Feeds (CPF) after they encountered an attack in Nov/2020.

The ValueDeFi team stated “…protocols using on-chain generated price oracles like LP Pools or Dexes are at great risk of succumbing to the same flash loan exploits experienced by ValueDeFi” and “On-chain generated price oracles are fundamentally unable to provide a sufficient level of market coverage and security guarantees for DeFi.

If we assume integrating CPFs can help defend against these types of attacks for the time being, do you think more research should be invested in integrating solutions like CPF or would you suggest research be dedicated to ensuring the safety/validity of on-chain oracles (especially those regarding lower liquidity assets)?


I’m not sure, to be honest. The research sector is a little new to me. It feels like it would be great if we had some more information on where this breakdown is occurring. It seems clear where the issue is, but why it’s still not being caught is strange to me.

Auditors not catching? Not caring?

1 Like

Typically, I’d suggest more research go into ensuring the safety of oracles, but at this point we know CPF work. So my thought there would be to research integrating CPF more.

Getting my setup right here, it appears I don’t have notifications on…

1 Like