Why Security Audits Don’t Work for DeFi Anymore

DeFi has been experiencing a glorious period over the past year, and until last month, it’s growth could have been described as meteoric. Much of this boom can be attributed to the rise in the value of the underlying assets, including Ethereum, and the fact that investors were attracted to the generous returns provided through decentralized trading, lending and borrowing.

Ethereum’s increased usage is a great sign for its long-term prospects, and we’ve also seen a rise in popularity among other chains based on EVM (including the Binance Smart chain). But at the same time, this expansion is causing some significant growing pains, particularly when it comes to transaction fees. Layer-2 (L2) scaling solutions, and ultimately Ethereum 2.0, will be needed to bring about a true reduction in fees. Users should feel confident about the progress being made with L2 solutions such as Loopring, Immutable X and others.

With a surge in usage, DeFi’s security is of even greater concern than before. In this blog post, we want to address some of the prime security concerns, including the risks associated with forking, the problems caused by a failure to build holistic ecosystems, flaws in attempts to build decentralized economies, and why security audits are no longer sufficient.

The benefits of Decentralized Finance (DeFi)

Before we speak about the risks, let’s talk about some of the core benefits of DeFi in order to get a broader picture. For a start, DeFi applications don’t rely on any intermediaries. The code specifies the resolution of every possible dispute, which means that you - the user - can keep control over your funds at all times. This in turn lowers the cost associated with providing and using these products and results in a more seamless system.

There are also the multiple rewards that you can gain from Yield Farming and the many choices offered by pioneer DeFi protocols such as Bancor, UniSwap, MakerDAO and Compound, as well as so-called FoodFinance (including PancakeSwap).

But over the past few years, we’ve experienced an antipattern of increased forking of DeFi projects. Because DeFi, at its essence, has an open-source approach, it is relatively simple for developers to clone existing projects and deploy them quickly. Forks vary in their nature - some are 100% clones of the original protocols, others tweak the initial code.

For example the majority of swaps, AMM, liquidity pools and yield farms are based on the MasterChef contract code from SushiSwap (including projects such as PancakeSwap, PancakeBunny, PantherSwap, Cerberus, Thoreum and Polycat). In principle, reusing code isn’t a bad thing, as it was written to be battle-tested and proven. So how do things go wrong?

» We are 10Clouds: Introducing the DeFi Developer Roadmap

Failures and risks associated with DeFi

Below are some of the main risks associated with DeFi, which are often forgotten about until a major problem is revealed.

1. The security of the economy

Besides smart contract security (EVM flaws) another difficult factor in DeFi is the security of the economy. Even with on-chain security measures at place, and smart contracts audited for known bugs like reentrancy and obvious coding issues - it is still obvious that DeFi brings the risk of front-running and flash loan attacks that can exploit the economy mechanics themselves.

What are flash loan attacks? In these DeFi attacks, hackers take out loans from a lending protocol and use tricks to manipulate the market. These loans are uncollateralized meaning that the borrower can make and pay them back with a single transaction. The reason that they are used in these attacks is that they allow for easy access to capital.

PancakeBunny experienced a flash loan attack on 19th May. They responded with a compensation plan (which has now become the standard for many projects which get hacked). The plan offers to cover any losses from team pockets. But ultimately, as a result of this event, PancakeBunny have decided to develop their own platform for YieldFarming called QFI, which will be more than just a fork.

The irony was that not long after, the same thing happened to Autoshark, which is a fork of PancakeBunny. On 20th May (the day after the PancakeBunny attack), Autoshark explained on it’s official channel how it was prone to the flash loan attack that hit PancakeBunny, only to be hit by one 5 days later. Like PancakeBunny, their response also came in the form of a compensation plan, which involved issuing new tokens to victims based on a blockchain snapshot before the attack.

Another platform that was growing in popularity was BeltFinance, which was offering attractive yield farming for StableCoin-pegged assets. They also fell victim to a flash loan attack on 29th May which resulted in an overall $6.2 million loss for the platform. There are considerable similarities between this attack and the one used on Harvest Finance back in October 2020, and in which the hacker stole more than $25 million funds. Belt and Harvest were talking about their cooperation on Twitter just two days before this latest hack.

2. Incompatibility

Issues can occur when the creators of forks try to add their own ideas and mechanics to a piece of code which was originally not meant to work with them.

Here, it’s worth mentioning SafeMoon. After some initial success with its very opinionated mechanics, many projects began to copy them. PantherSwap, GarudaSwap, Cerberus and Thoreum are all mixtures of PancakeSwap and SafeMoon. GarudaSwap, Cerberus and Thoreum are even maintained by a single team and they keep adding features through each of them. Garuda came first, closely followed by Cerberus and finally Thoreum. They even came up with the idea of mixing them together, since they realised that the newer ones can enrich the older ecosystems with attractive features. An example is the auto-compound mechanism introduced with the launch of Thoreum, expanding the ecosystem of already present Cerberus and Garuda.

Unfortunately, it looks like SafeMoon’s mechanisms are not compatible out of the box, with yield farming systems that are also forked. This led to another instance of draining funds from liquidity pools. On 16th June 2021 Garuda, GoCerberus, KetchupSwap and Lokum all saw their native tokens drop to $0. This was due to a hacker exploiting these DeFi protocols, which are all built on SafeMoon transfer tax feature.

3. Lack of information how forked solutions should be operated

There are also issues which occur when the team developing the project has little experience in, or understanding of its code.

An example of this is PancakeSwap, which has a feature called IFO (Initial Farm Offering), which is a derivative of the IDO (Initial DEX Offering) from UniSwap. On Polygon, PancakeSwap has a fork called Polycat which also offers IFOs.

Unfortunately, a new problem arose as, as the team was not experienced in the product they had forked, which resulted in incorrect calculations of sent tokens during the end of the presale. Later, it became obvious that the problem was larger than initially thought and a new IFO contract didn’t fix all the issues. Due to insufficient checks made by Polycat’s dev team, users were able to claim 1 OMEN for 0.3 USDC instead of 3 USDC.

To solve the problem, the Augury Finance Team needed to adjust the whole economy for OMEN. In essence, they therefore printed 10x more OMEN and increased the overall supply, creating a whole new economy which made sense of the error.

4. Failure to build a risk-proof ecosystem

Last week, IronFinance’s Titan Token fell near to zero, due to DeFi panic selling. The token’s price went to $65 and then pulled back to $60 causing large investors, known as whales, to start selling. In doing so, they flooded the market with excess tokens, causing widespread panic. But what exactly went wrong?

Well, Iron is a partially collateralized stablecoin operating on the Polygon network and Binance Smart Chain. Stablecoins are usually pegged to fiat currency (1:1) in a bid to minimize price volatility. They can be seen as a bridge between regular finance and crypto.

In Iron Finance’s case, USDC and TITAN were used as collateral on Polygon, BUSD and STEEL on the Binance Smart Chain. This means that the price of TITAN goes up when new IRON tokens are minted, which means that the peg becomes less stable with the fall of TITAN’s price.

The dramatic crash was caused by a fault of economy design. In fact, Sam Kazemian, CEO of FRAX, said:

Iron forked the very basic V1 of FRAX with 0 of the safeguards we had built into the system to prevent a bank run. They tore out all the game theory code that would have blunted hyper growth so that they could pump $2TVL and advertise themselves as bigger+better than FRAX.

Lessons in security

It should be noted that forked projects need to pay for third party security audits and sometimes don’t take into account how the economics and mathematics of financial markets work. While most of these project owners know the value and importance of security, some may not fully understand the value of building a secure economy around their project.

The importance of system design for security

That’s why there should be more public encouragement to place more effort on system design, code development and the security of the solution. In such a diverse ecosystem, there’s real merit in not cutting corners, and not treating security as just an audit that should be paid for. Instead, it’s worth investing in a whole secure infrastructure and treating audits as an ongoing process that will be repeated with each upcoming update.

Why audits can be insufficient

It’s worth remembering that sometimes security audits are not even offered by the most reputable companies. And even in the cases where reputable providers such as OpenZeppelin produce an audit, problems might arise further down the line for different reasons. An example is the hacking of Opyn's smart contract, where the authors of the code updated it after the OpenZeppelin audit and introduced a bug. This is a good example of how an audit can often be insufficient because it doesn’t check the economy and operation of the system fully, particularly in relation to mechanics that might occur further in the future. This is why the audit of each code update should be essential.

Formal verification as the key to security success

In fact, this holistic approach to security, known as formal verification, is essential when it comes to creating DeFi ecosystems. Formal verification essentially means checking to ensure that the system meets every requirement that has been set for it, and at the same time does nothing that it has not been required to do. Formal verification engines can be used to mathematically prove that the solution will be successful in the long run.

Conclusion

The biggest lesson to learn here is that the code behind all of the above-mentioned networks and protocols was written by humans - programmers who were excited about their projects going out into the world and getting tested by users. Reusing this code can seem like an easy way to make millions in this market, but it’s much more difficult to build an effective, secure economy around it that will last for years.

Are you looking for expert advice about blockchain implementation at your company?

Get in touch with Dennis Van Der Vecht, our Interim Head of Sales, for a free blockchain consultation. You can contact him on dennis.vandervecht@10clouds.com or call on +48 793 200 141.