Debunking Smart Contract Audit Myths

Smart contracts are immutable once deployed on the blockchain. As smart contracts are programmed and written by humans, they may contain bugs or errors that have been unintentionally overlooked during the development process. To top it all off, the inherent transparency of blockchain technology gives everyone access to the code. Including hackers, who can take all the time they need to figure out ways to exploit them.

In the course of our work as white hats, together with our partners and market makers Enflux, we’ve met and partnered with many founders and their development teams, and encountered differing views and preferences on how to go about securing their creations.

To our surprise, not a small number of them were ready to make compromises in certain areas, compromises which could turn detrimental to their good intentions and long term efforts. Perceived safety of forked smart contracts, partial audits and narrow timelines are some security myths we will focus on in this article. 

Our team is committed to clarity and accuracy in the auditing process. We believe a thorough audit is not supposed to last 2 days, and careful attention should be paid to the entirety of the system, rather than only on certain parts deemed most important. 

With the growing amount of funds lost to hacks in the past few years and already a whopping $1.2B having been stolen in the first half of 2024, debunking these common beliefs can lead to better security practices and more reliable smart contracts for the future of Web3. 

Forked Smart Contracts: A Forked Protocol is a Safe Protocol

Many teams believe since they have a what they claim to be “1:1 fork” of another protocol’s contracts (which have been audited god knows how long ago and by whom), that means their codebase is safeguarded against exploits. 

History shows this is not the case. It’s important to note that each chain has its own specific calculations and settling mechanisms, which can have an impact on its security. Secondly, most times the dev team has implemented “minor” custom functionalities to accommodate the differentiation aspects of their protocol. As we all know, each protocol stands out in its own way, and has come to life to satisfy specific needs.

Custom smart contract functionality includes proxies, different oracle mechanisms, verifications, admin controls and more. Funny enough, these are precisely the places where the most common attack vectors are hidden. 

Protocols can showcase their long-term vision and commitment to security by undergoing an audit and making it public, regardless of whether what they forked was audited or not. Taking action will show their dedication to security and deep care for their community. 

Amount of Audits: Is One Security Review Conclusive?

Would you trust only one doctor’s opinion on your health if there is an issue? No, perhaps you’d ask two or three professionals and put their opinions to the test. Most likely you will probably go for periodic checks every 2-3 years to make sure everything is alright. The only constant is change, and web3 is known to be one of the fastest changing industries. 

The clock is ticking and hackers really do have a lot of free time on their hands. White hats are on the lookout, but are less likely to spot a bug in your protocol if they are already busy working for clients. Hire your own dedicated security team, and ensure peace of mind for yourself and your team going forward.

Cutting Costs with Partial Smart Contract Audits

We love bootstrapped projects and fully support bold moves! 

However, we’ve experienced some founders/product managers asking for a quote for the whole codebase, together with a quote for “only this and this contract”. Here it’s worth reverting back to the doctor reference. Just like the human body, codebases are interconnected parts of a whole. Contracts usually call each other and have distinct dependencies. 

As auditors, we cannot vouch for the security of the entire system by only auditing a part of it. To be completely honest, this makes us feel quite uncomfortable as an auditing team. The vulnerability might be hidden in the place you least suspect. Perhaps the way one of these interdependencies is designed has a flaw which puts funds at a risk. Even if no funds are in danger, losing control over the protocol, or randomly activating the fallback mechanism is never fun for the protocol’s team or the community. FUD is spread quickly and people run to Twitter and Discord to share their own experience of the mishap.

Security is probably the worst choice for cutting costs. If you want your efforts to not be in vain and to keep users happy with a robust and safe product, set aside a sufficient audit budget. If you have a robust product, it will work for you in the long run, and you wouldn’t need to worry about its revenue! 

Wrapping It Up: Security Isn't a Checkbox

Look, we get it. The world of Web3 moves fast, and there's always pressure to launch quickly and keep costs down. But when it comes to security, taking such shortcuts is like playing with fire – eventually, you'll get burned.

Remember, your smart contracts are the backbone of your project. They hold your users' funds and trust. Treating security as an afterthought or trying to cut corners isn't just risky – it's downright irresponsible.

So, what's the takeaway here? First, don't assume that forked code is safe code. Second, one audit isn't a lifetime guarantee – regular check-ups are crucial. And finally, partial audits might not be the best decision going forward. Job done halfway is not really a job well done.

At the end of the day, investing in thorough, regular security audits is about protecting your users, your reputation, and the future of your project. In Web3, solid security is your best shot at long-term success.

Once that's out of the way, you can start debunking more pleasurable myths such as offsite company fun for your team!

Let's build a safer Web3 together, one properly audited protocol at a time.

After all, in this space, your security is only as strong as your weakest link. Don't let that weak link be a security myth you could have busted.

STAY SAFU

Audita's Team