Understanding Security Risks in DeFi

Originally published
May 26, 2021

This article recaps a live-streaming event hosted by Binance Smart Chain (BSC) with a guest speaker from CertiK, the leading blockchain security company. To watch a recording of the event, please visit: https://www.pscp.tv/w/1BdGYYeYVREGX.

DeFi has been growing exponentially with BSC emerging as one of the leading DeFi platforms since it launched 9 months ago. Today, there are more than 600 projects generating tens of millions of daily transactions on BSC.

(pic from https://twitter.com/BinanceChain/status/1395060714390315008)

However, with great success comes great risks. Exploits are happening more frequently by hackers who take advantage of vulnerabilities exposed at different levels. These vulnerabilities fall into 4 general categories that we will go over to provide readers with a better understanding of the security risks associated with DeFi.

Admin Key Compromise

With smart contracts, modifiers restrict who is allowed to invoke certain functions. Such functions are typically privileged functions used to modify the contract configuration or manage funds held in the smart contract. If an attacker compromises an admin key, they can have complete control over the smart contract and steal user funds.

How can a key be compromised?

The first possibility is through a computer trojan. An attacker can use a trojan to steal private keys stored on a computer. An attacker can also conduct a phishing attack to trick the users into sending their private keys to the attacker. For DeFi projects, sometimes several project stakeholders will share one private key. This allows a malicious insider to use the key to call admin functions and transfer the project’s tokens to their own wallet address.

For example, on March 5th, 2021, PAID Network suffered from a “mint” attack caused by the mismanagement of their private keys. The PAID token contract sits behind an upgradeable proxy, meaning that the contract can be modified and replaced. The proxy owner’s private keys were used to swap the code deployed behind the proxy with a malicious one containing the burn and mint functions used during the attack. The attacker burned 60M in existing PAID tokens and then minted 59M tokens for themselves. The token price dropped from $2.80 to $0.30 as 2,501,203 PAID tokens were sold on Uniswap for a total of 2,040 ETH. The attacker likely compromised an admin’s machine through a phishing attack.

On April 19, 2021, 2.98M EASY tokens were transferred out of the official EasyFi wallet to several unknown wallets, the value of these tokens was $75 million at the time. The EasyFi founder claimed the hack resulted from a “targeted attack on the founder’s machine/Metamask to access admin keys.”

Projects should store their private keys securely. They should not store admin keys in plain text on PC devices or rely on a MetaMask hot wallet. We recommend creating a Multisig(account) using hardware wallets. For example, for a five-person team, each team member should have their own hardware wallet. When they attempt to send privileged transactions, it should require at least three out of the five team members to sign the transaction. This prevents an attacker from being able to call any privileged functions should they gain access to one of the keys.

For a token contract, avoid allowing the minting of new tokens, if possible. If that is not a possibility, try to use a DAO contract or timelock contract as the owner instead of an EOA account.

Coding Mistakes

Some vulnerabilities in DeFi are complex, but that is not always the case. Sometimes a small coding mistake in smart contracts can turn into a major disaster that causes assets worth millions to be compromised.

Some common coding mistakes include:

  • Function permission(modifier)
  • Typos
  • Incorrect number of digits
  • Missing/incorrect variable value assignment

A notable example is the Uranium Finance hack that took place on an unaudited contract, which resulted in a loss of 57 million dollars. It was caused by an inconsistent multiplier used when comparing the product of two token balances in the pool before and after the swap. This allowed the attacker to swap out most of the tokens from the pool costing only 1 Wei.

Uranium Finance code:

Correct code:

Another example is from the Value DeFi hack, which led to 10 million dollars being lost. The initialize function in the contract missed “initialized = true” meaning anyone could re-initialize the pool and set themselves as the operator. On May 5th, 2021, the attacker re-initialized the pool, set the operator role to themselves, and then used the “governanceRecoverUnsupported()” function to drain the staked tokens.

The vulnerable code from Value DeFi:

The fix:

The two examples mentioned above were caused by simple coding mistakes, which led to significant losses. These types of mistakes can be easily eliminated with proper peer reviews, unit testing, and security audits.

Flash Loans and Price Manipulation

Flash loans are a way to borrow large amounts of money from a protocol like Aave or DyDx for a certain fee. The requirement is that the loans need to be returned within the same transaction. If not, the transaction will be reverted. The general exploit of these loans are as follows:

  1. Borrow a large amount of token A using flash loans
  2. Swap token A for token B on a DEX (lowering price of token A and increasing price of token B drastically)
  3. Exploit a DeFi project that relies on the price of A/B
  4. Repay the flash loan

Recently, PancakeBunny suffered from a flash loan attack, and the attacker received 114K BNB and 697K Bunny ($40M at the time). The attacker used a flash loan to manipulate the price of the PancakeSwap USDT-BNB V1 pool, causing a huge amount of BNB to flow into the BNB-Bunny pool, which enabled the contract to mint Bunny with an inflated BNB to Bunny price. PancakeBunny uses the following function to calculate the Bunny price:

Since there is a large amount of BNB flowing into the BNB-Bunny pool, the variable “reserve0” became significantly larger. Because of the flawed price calculation, the attacker was able to receive 697K Bunny.

There are many flash loan attack victims, including some big names in the DeFi space: PancakeBunny(40M), Harvest Finance(25M), Yearn(11M), Value DeFi(7M), AKROPOLIS(2M), Cheese Bank, XToken, bZx and so on.

If a project requires price references, it needs to be careful, as flash loans might manipulate the price. To prevent this from happening, we recommend using Time-Weighted Average Price (TWAP). The TWAP represents the average price of a token over a specified time frame. If an attacker manipulates the price in one block, it will not affect the average price. The other suggestion is to use a reliable on-chain price oracle, such as Chainlink.

Misuse of Third-Party Protocols and Business Logic Errors

Many projects, such as PancakeSwap and UniSwap, run independently. In PancakeSwap, users can provide liquidity to farm tokens or swap one token for another. Users do not interact with other third-party protocols.

Other projects, such as Yearn Finance, operate differently. Yearn Finance collects user funds and puts them into third-party contracts. It invests user tokens in order to gain yields. Another case is that some projects “borrow” code from other projects. For example, PancakeSwap references code from UniSwap. In both situations, if the source of the third-party code is vulnerable, the project that uses the code is also vulnerable. If the developers of a project are not familiar with the third-party code they are using, this may turn into a major issue once a vulnerability is exploited.

On May 8, 2021, the Value DeFi vSwap AMM’s non 50/50 pools were exploited and lost approximately $11 million in total. To implement the non 50/50 pools, Value DeFi copied the “power()” function from “BancorFormula.sol”, which belongs to the Bancor protocol. In the power() function description, it is written that this function does not support the case when “_baseN <_baseD.” Unfortunately, this is how Value DeFi uses this function. The attacker was able to swap a small amount of token A to token B by sending a crafted payload to the function.

Value DeFi Code:

There are many other similar cases in the DeFi space. On May 8th, 2021, an attacker was able to drain approximately 2600 ETH from the Rari Capital Ethereum Pool by leveraging the functions of the ibETH pool (Bank contract) of Alpha Homora V1, which is integrated into Rari Capital V2. Bearn Finance uses the withdrawal amounts for BUSD to withdraw ibBUSD in their “BvaultsStrategy” contract, allowing an attacker to removed 10,859,319 BUSD from the pool.

These kinds of issues are harder to detect and you should proceed cautiously when using a project that communicates with any third-party protocol. We do not recommend blindly copying and deploying code that a developer doesn’t understand. We advise developers to fully understand third-party protocols and how a forked project works before integrating them and deploying them into production. We also recommend developers deploy their projects on a testnet first and do test runs to check for abnormalities in transaction records.

As end users, it is sometimes difficult to find out detailed information on projects before interacting with them using your personal assets. To democratize access to security, we at CertiK built the world’s first security leaderboard for blockchain and smart contract projects where you can find extensive and real-time security-centric insights that can help fulfill your due diligence requirements. Check out here today at https://www.certik.org!

Preparing for a Security Audit

To get the most out of a security audit, we recommend that the project owners make some preparations. Here are some tips:

  • Define the scope and set a goal
  • Make comprehensive documentation
  • Ensure good code quality
  • Test the code before an audit
  • Freeze the code and specify the commit hash before an audit.

For more details on preparing for an audit, please visit


In summary, building DeFi projects can be fun, being hacked is not. It is difficult to make a project 100% secure, but there are certain things we can do to protect as much as possible:

  • Keep admin keys safe
  • Avoid simple coding mistakes
  • Use reliable on-chain price feeds
  • Undergo security audits and prepare for them

Let’s #BUIDL and be #SAFU!