State of security of new DeFi projects

This will be a continuation of a rant on how clients should prepare for an audit. Opinions and views are my own if you haven’t catch that 😉

I’ve been auditing smart contracts for 8 months now. I’ve seen my fair share of well-written projects, well documented, and also a fair bit of project which code I would like to see burnt to the ground. In all fairness, if a client shows a vast interest in fixing all the issues and problems I mentioned in the report, the client can only get praise from me. It shows they came for an audit not to get a stamp of approval (wishes), but to improve their codebase and make a better product.

I’ve recently seen more often projects that are already deployed, not willing to change the deployed code. Usually, the project is a clone of another project with some altered mechanics at best or 1:1 fork of original code.

DeFi is composable of different moving parts, and if one government module is working is not needed to reinvent the wheel, especially when the code is open source. I get that. But I’m talking about straight forks of projects that make too many changes to the codebase that break a lot of functionality or introduce some way of rug pulling its users.

It’s been a while since I saw an original solidity code and idea. Everything is a mix of everything. I’m not saying every project should be an original one. Iterations of an idea are welcomed, but make sure changes are introduced in all places. We don’t want another Uranium Finance hack to happen. The issue in question was trivial.

When you copy a code, make sure it doesn’t introduce re-entrancy. Simple checks-effect-pattern or nonReantrant modifier will be fine. And for the love of God, do not introduce the “Emergency Exit” function that can take all of the user's funds. Allow users to make their own withdrawals. Even if your intentions are pure, someone could steal your private key or mnemonic and can rug pull all of your users.

I saw ☝️ the exact issue more than I should.

Lastly: Do not change the parts of the code you don’t understand while forking from respectable projects! Some decisions were taken for a reason, and without a deep understanding of the inner workings of the protocol, don’t make your own decision on what you think should be changed.

Phew, that is it. It feels good to say this thing out loud, not only to my colleagues.

From time to time, I will write similar rants to give you a perspective of how I see things like this and what my opinion is on all of this. We’re in a bull run; everybody wants a piece of that $80B TVL cake, thus the influx of crappy designed / copy-pasted projects. It’s my duty to warn about any daring issues and Vulnerabilities of a project, but still, the decision is up to you to take if you want to risk your own money to ape on a project.

No audit will make your product 100% secure, and audits are no silver bullets. Blockchain Security is an ever-changing landscape, and new threats are emerging. 2 years ago, projects didn’t think about flash-loan protections as it wasn’t a thing yet. Remember, audits only helps the project make a comprehensive sanity check of the quality and security of its code.