Blockchain Security: How to Understand Blockchain Audits to Stay Safe in DeFi

This past year has been a pretty dark time in crypto. Not only have we seen the catastrophic collapse of Luna, the degeneracy of 3 Arrows Capital, insolvency and bankruptcy woes with BlockFi, Celsius, Voyager, VAULD and more, macro-economic conditions that have plunged us into the depths of a crypto winter, but it has also been a monumentally disastrous year for blockchain and DeFi hacks and exploits, which has resulted in people running away from DeFi faster than swimmers fleeing shark-infested waters.

Now you are probably thinking to yourself, “wow, thanks for the depressing intro. Crypto sounds like a minefield!”

And you aren’t wrong there, crypto certainly has its fair share of risks. But before letting all this doom and gloom make you want to ditch crypto forever and go hide under your bed, fear not, because this article is going to help teach you how to navigate the DeFi waters in the safest possible manner and show you what you need to know about blockchain security audits.

While this won’t help protect against every risk in crypto, there is no protecting someone who decides to “YOLO” their life savings into the next memecoin, the information in this article will at least help equip you with one more arrow in your quiver that you can deploy to greatly enhance your overall safe navigation of the DeFi space.

Just to allay some fears early on, don’t worry about this article being too technical. This helpful guide will be so easy to understand that even my dad who refers to the entire crypto industry as “That Bitcoin Stuff” will be able to understand it.

And because I am about as well versed in the skills of blockchain developing as a rock is at cutting hair, I decided to get some professional help and insider advice for this article. I reached out to our friends over at Ackee Blockchain to help teach myself, and the average Joe just what the heck these blockchain audits are all about.

I want to give a big shout-out to the Ackee team for taking the time to help us and our community out by teaching us the fundamentals of blockchain audits, and for collaborating with us on this article. Blockchain and DeFi audit reports are such a critically important aspect of crypto and are something that very few of us really understand.

When doing our due diligence in determining the safety and security of a DApp or DeFi protocol, many of us will look for something that says the platform has been audited and may think, “okay, good enough.” I know I have been guilty of that in the past, but what does it actually mean to have been audited? How can we verify this? And as you will learn in this article, just because something has been audited, that doesn’t mean it should automatically get the green light.

To start, let's look at what blockchain auditing companies actually do.

What do Blockchain Auditing Companies Do?

When we hear the term “audit,” many of us automatically imagine a stuffy old dude in a suit that works for the government who is going to come knocking and go through all of our financials and bank statements with a fine-toothed comb. In the traditional financial industry, you’d be right, but blockchain auditors could not be further from that.

Blockchain auditors are not accountants by any stretch of the imagination, they are experts in coding and developer skills who look for bugs, errors, and malicious code in the source code of a blockchain project, smart contract, or crypto token.

Different auditing companies may specialize in different areas as well, which is why it is always good to see a platform that has been audited by more than one company.  Every audit conducted reduces risk and one company may pick up on something that the other company missed.

1inch is a great example of this. 1inch is a DEX aggregator that has been audited by multiple different companies, which enhances user confidence in the platform, and highlights that the 1inch team have a strong commitment to ensuring the safety of its community.

Blockchain auditing companies will have a team of engineers that can conduct tasks such as:

• Security Audit
• Tool Analysis
• Manual Code Review
• Run and Write Automated Tests
• Conduct Bug Bounty Contests

While other auditing companies like Ackee Blockchain can also meet more “full-service” requirements and help in additional areas such as:

• Creating Secure Smart Contracts on Solidity or Rust
• Assist in Building a full ecosystem, handling UX, design, frontends, backends and DevOps

Ackee Blockchain also contributes to the blockchain industry as a whole, which is great to see. They have developed open-source security tools that anyone can use and are passionate about teaching and providing opportunities for aspiring blockchain developers. In the past, they have hosted online courses for developers who want to work in blockchain and even received a grant from the Solana Foundation to run a summer school for Solana.

The team offers summer schools online where they teach Solidity, and in the fall of 2022, Ackee Blockchain CEO and Co-founder Josef Gattermayer, Ph.D. will be teaching topics around blockchain development at the Czech Technical University in Prague. It is definitely worth reaching out to the Ackee team, registering for the courses on their site, and following them if you are interested in a future in blockchain development and security.

As you can see, blockchain auditing can be about more than just nerding out in a dark room and scouring through code, there is an entire ecosystem encapsulated within the niche.

Why is Blockchain Auditing Important?

If humans were perfect, there would be no need for blockchain auditing companies as every line of code would be written flawlessly and completely impervious to exploits, faults, and attacks.

What is even worse than humans making mistakes, is that people can be corrupt and malicious. A fairly frequent occurrence is that bad actors will intentionally enter malicious code into their protocol that will allow them to exploit a platform that they created in order to steal users’ funds.

Between human error and malicious intent, smart contracts and blockchain applications/DApps are susceptible to the following risks:

• Denial of service attacks that render the protocol unusable.
• Rug pulls/back door theft where the founders enter malicious code that allows them to withdraw funds placed into a smart contract.
• Exploiting the code in ways that benefits the hacker and hurts users such as minting new tokens outside of the intended methods or draining customer funds from smart contracts.
• Some hackers simply want to “watch the world burn” and will exploit any fault they can find to damage a platform.

Many DeFi users consider one of the most important things to look for in a DeFi platform is whether or not the code is open-source. This is a great first step as many projects will publish the code on a public site like Github, where anyone can go in and check/verify the code for themselves.

When looking at a project’s GitHub page, this is often one of the things that users who are considering using a DApp look for, using 1inch again as an example:

This is a good initial approach to take when verifying the authenticity of a protocol as this is where community members or anyone can go in and verify there is no malicious code hidden in there.

It is also helpful to know that anyone can post anything on GitHub. The code posted in GitHub doesn't automatically confirm that that is the same code running the smart contract. Luckily, users can verify this by going into a block explorer like Etherscan and checking to see that the code in GitHub is actually deployed and used. Here is the 1inch Token in Etherscan, for example. I tend to agree with the sentiment that open-source publishing to GitHub is a good sign, but to me, when I click into GitHub to take a look, all I see is:

So instead of my brain frying like an egg on a hot sidewalk trying to figure this out, I like to see that a team of professionals from a blockchain auditing company has scoured through all this and have given it the thumbs up.

It is important to clear one thing up, and that is that just because a protocol has been audited, that does not mean that it is 100% safe. No code can ever be considered completely impervious to hack attempts as hackers’ tools and skills are getting more sophisticated all the time. Just as white-hat (good) hackers and blockchain devs are getting better and evolving all the time, so are the bad guys.

You can think of it sort of like a game of cat and mouse, writing code is essentially like building a creative puzzle and problem solving, and hackers are looking for ways to solve or attack the puzzle in increasingly clever and sophisticated ways, so there will always remain an element of risk.

Why 2022 Has Been Especially Bad for Crypto Exploits

When we see headlines like this:

It can be quite heartbreaking. The crypto industry has been given a serious black eye as every week there seems to be another massive hack or exploit resulting in millions in lost funds.

This is not only sad as these are average folks losing their money, but also worrying as these attacks are subjecting the entire crypto industry to increasingly harsh criticisms, slowing adoption, keeping investors away, and providing governments with the excuses they need to increase their authoritative control to “protect” investors, often imposing draconian measures that many of us turned to crypto to escape.

The primary reason for this comes down to sloppy developer engineering.

When I sat down with Josef from Ackee, I asked for his take on why there have been record numbers of exploits, his explanation made sense.

Heavily paraphrasing, Josef went on to explain to me that the crypto industry is growing rapidly and there is a fierce race for teams to launch their products. There is a lack of skilled and experienced blockchain developers able to meet the demand, resulting in many projects hiring novice developers and having a “good enough” attitude, launching DApps without the proper checks and audits being done.

Josef also went on to explain that the need for blockchain auditing services is skyrocketing, and there are not enough blockchain auditing companies to meet the demand from projects. This has been resulting in project teams not wanting to wait for an auditing team to become available, so they go ahead and launch or release an upgrade, either without an audit, or relying on an out-of-date audit that doesn’t cover the new version or iteration of a platform.

This theme was especially present during the 2021 bull run, but things are much more relaxed now that we are in a bear market. Projects aren't in a big rush to launch and there are fewer projects in the auditing bottleneck. It is true that bear markets are the time for building, and teams tend to take a more diligent approach during slower market times.

We went over two specific successful attacks that happened to investigate exactly what went down, to help put all this into perspective.

The Ethereum DAO Hack of 2016

Essentially, what happened here was something known as a re-entrancy bug. To put it simply, the code executes two instructions:

1. Withdraw
2. Update Balance

If performed chronologically, it works as it should. But as Ethereum is a distributed system (unlike web2 programs), the contract can be called from another contract which brings an option to implement a custom callback function that is called from the withdraw instruction.

And this callback function implemented by the hacker calls the contract again then again multiple times before the update balance instruction is finally executed. This allows the attacker to withdraw multiple times.

This is a frequent mistake made by novice web3 developers. Even 5 years after this attack, the issue still arises from developers not taking the time to learn from this case. The solution is quite simple in this case, and that is to just put those two lines of code in the opposite order. First update, then withdrawal.

Auditors look for known issues like this when auditing a protocol.

Solana Wormhole Attack 2022

2022 did not get off to a good start with the first major attack happening on Solana in early February. The attacker bypassed a signature verification in a Rust program so it looked like the guardians had signed off on a 120k ETH deposit into Wormhole on Solana, even though they hadn't. The attacker then minted 120k worth of wrapped ETH on Solana.

Before this wormhole attack, many in the crypto community assumed that Solana and Rust development was too hard to learn to attract amateur developers. This led to the belief that only the best developers worked on Solana, meaning that there wasn’t as strong of a need for audits. After this attack, Josef mentioned that he and his team saw a significant increase in audit requests for Solana DApps and protocols.

After all this, you may be thinking that if humans are the source of error and harmful intent, wouldn’t it make sense to just have computers and Artificial Intelligence machines who are unlikely to make mistakes and incapable of malicious intent just write all this code for us?

That is a great question, and because of articles like the one above, this is something that has crossed my mind as well. We will cover that in the next section.

The Future of Blockchain Security

It is evident that we are moving towards a future where many of our jobs are going to be outsourced to computers and AI programs that can do the jobs of humans far better than we can.

We already see this with automated cashiers and car manufacturing factories that have more robots than humans. Computers are even taking over highly specialized jobs like doctors and pharmacists, as a robot can be more precise with a scalpel and a computer program can scour the entire database of medicine and within seconds populate reports on what medicines can and cannot mix with other chemicals and medicines, a task impossible for a human.

I thought for sure that programming and developing would be one of the first jobs replaced by computers. If it is all letters and numbers on a screen constructed in a way to complete certain tasks, then surely a computer could do that better than a human, with fewer errors right?

I thought blockchain auditing companies would be going the way of the Dodo bird (extinct), as once computers start developing autonomously, there will be no errors to find. This highlighted how little I knew about developing as the Ackee team explained some concepts that I hadn’t appreciated.

A large part of blockchain development is problem-solving and looking at a 360-degree view of an issue. It takes a large amount of creativity and “outside of the box” thinking that computers are unable to do. It isn’t just as simple as “when ‘X’ happens, execute ‘Y’.”

We also need to consider that many of these DApps and applications are trying to solve “human” problems and how we interact with systems, protocols and procedures. Sorry little Butter Bot, but you aren’t cut out to understand human problems and provide human solutions.

Not only are jobs in blockchain development and security skyrocketing, but it looks like there will be a need for these roles for years to come.

That isn’t to say that there is no automation happening in the web3 development space though. There are plenty of free tools for developers that provide them with some security feedback and help to offload some of the work so devs can focus on other tasks.

For example, on Ethereum, there is a good static code analyser named Slither that is very popular and Ackee Blockchain is working on their own open-sourced static analyser called Woke, which detects things differently than Slither, reducing the burden of having to manually analyze the code.

The Ackee team also uncovered a trend on Solana regarding a problem with tests. Developers were not writing enough of them as it is quite labour intensive, with the need to write a lot of boilerplate code. So, Ackee Blockchain spearheaded a project where they wrote an open-source testing framework for Solana called Trdelnik that will allow developers to write tests easier. The team received an honourable mention and won a Marinade prize during a hackathon in Prague for Trdelnik.

In November 2023, Ackee Blockchain also released Wake, a suite of open-source tools on Ethereum to stop bugs.  Wake is a Python-based Solidity development and testing framework with built-in vulnerability detectors and printers. The basic feature is it allows developers to write tests for their Solidity code. But Wake is more like a Swiss Army knife, so it's packed with more features, not common for testing frameworks. 

Featured in the tool are detectors - automatic code scans, that pop up in case of a discovery of code vulnerability. It can be used either as a command line tool or Wake has also a visual-fronted - Visual Studio Code extension. The extension shows all outputs from Wake to developers in their development environment.

All this shows us that it is likely that automation and computers will play an increasingly important role in assisting blockchain developers and security auditors, but is unlikely to be replacing them anytime soon.

The general sentiment among blockchain developers is that many of these hacks and exploits are a result of this still being a young and inexperienced industry. As the blockchain industry continues to evolve and mature, there should be fewer and fewer exploits, resulting in the overall crypto space becoming more secure and user-friendly.

Alright, now let’s get into the good stuff, the major takeaway from this article.

How to Verify a Platform Has Been Audited

The very first step is to actually make sure there is an audit to be found. These can be found in the project’s GitHub repository, and any conducted audits should be clearly mentioned in the project’s docs, or on the platform website itself. If you cannot find any mention of an audit, I’d stay away.

There are also some great tools available for free at your disposal to help you streamline your due diligence and research efforts. One such tool is De.Fi

De.Fi labels itself as the “Web3 Super App & Antivirus.” It not only helps with portfolio tracking, but my favourite features are the Sheild, Scanner, and the Audit database. The Audit Database highlights the type of audits that we are discussing in this article and De.Fi boasts the largest audit database available. This is a great first step to check if your favourite DeFi protocols have been audited.

No publicly available audit likely means that:

• There has been no audit conducted
• There has been a failed audit that the project doesn’t want to be known
• The audit discovered issues that the team did not address
• The code contains malicious backdoor routes that could lead to theft

As mentioned earlier, it is also nice to see that the code is open-source by being labelled “public” on GitHub. This is not a requirement, but it is still a bonus. There are reasons to not open-source code though, so that isn’t always a deal breaker. Reasons not to open-source code can be things like:

• Companies wishing to retain a competitive advantage. As soon as a company open-sources their code, anyone can create the same protocol and compete. This is why Coca-Cola keeps their recipe a secret and KFC famously has their “Top secret 11 herbs and spices.”
• Once a code is public, hackers can use the information to look for exploits. Though good practice does the opposite, if a project is confident in its code, they'll publish it.
• Early projects may not want to open-source their code right away until they have built up a large community and enough users, creating a hurdle for potential competitors.

I recently met with a project team who regretted open sourcing their platform right away, as a competing company simply copied their code and business model, and had more funding to pay influencers and pay for followers. This made it appear that the competing firm was the better platform right from launch as it gave the impression of more users and a larger following. The competing company is now significantly ahead of the original founding team who chose to grow more organically and ethically.

Here is a great visual from Bridge Global that summarizes some of the generalized differences between open-source and closed-source software:

Two interesting approaches to open vs closed source code can be found by comparing popular hardware wallets Trezor and Ledger. Trezor chose to publish 100% of its source code to the public for anyone to verify, while Ledger chose to play its cards closer to its chest and open-sourced some code, but keep its firmware closed source.

This led to many blockchain elitists choosing Trezor over Ledger as they felt that Ledger should open-source their code, wondering what they are trying to hide. I personally don’t see this as a cause for concern as Ledger has proven their track record and dedication to the space, and has grown to become one of the largest hardware wallet providers in the world, creating some of the highest grade secure crypto storage devices.

Once an audit has been conducted and located, as long as it has been made public, anyone can open the document and find the results of the audit. Instead of scrolling through the entire audit document, for our simple purpose, all we need to look for is the “Executive Summary” page, which often looks something like this:

This page will either be located at the very beginning or end of the report. It is a page that shows the results of the audit in a simple format that the average person can understand. Let’s dive into what information this is showing us.

Is the audit recent? Audits should be a continuous service and there should definitely be a new audit being done for EVERY update, version, or new feature/function introduced. If there has been a new feature or version launched, the previous audit results are no longer valid as the codebase has probably changed.

This can be verified by looking at the project version and/or commit hash. The version is something like when you see Uniswap "V2" (version 2), and the commit hash identifies a revision in the source code repository. When looking at the version or commit hash shown in the audit, which can be seen in the image above in the table with the heading "repository," users can check to ensure that it coincides with the version or commit hash shown in GitHub.

That will look something like this:

Here is another look from one of Ackee Blockchain Audits:

Though if the commit hash doesn’t match, that doesn’t necessarily mean there is a red flag. The commit hash on the project's GitHub will change any time a new adjustment or iteration is made. Every adjustment will change the commit hash and shouldn’t be a cause for concern if there was just a minor adjustment.

If you do not see the commit hash from the audit on the main GitHub page, you can go into the “Commit History” and search for the commit hash and see for yourself how much has changed since the audit was conducted.

That can be done by clicking here:

Then doing a search here:

As a new commit hash is populated for each change, each with a date and time stamp, if there have been a significant number of new commits between the time the audit was conducted, and the commit hash that the project is currently on, you may want to consider waiting until another audit is conducted before getting involved.

If you have an analytical eye and want to dive in deeper, you can click into each new commit hash and compare the old code shown in red with the new code shown in green and verify for yourself what exactly has changed:

If you notice a new commit hash that is different to when the audit was conducted and see something like this:

That is one of those insignificant changes I mentioned, and though it populated a new commit hash, it isn’t anything to be concerned about as this was a simple renaming of a file. The GitHub image above shows 0 additions and 0 deletions.

Now onto the next thing to look for in the Executive Summary:

Issues - The executive summary shows all the issues that were uncovered during the audit, and more importantly, if the team resolved the issues. This section can be seen near the bottom where it shows “Total Issues,” then goes to break them down into severity and whether or not they were resolved. The auditing company first identifies issues, flags them to the dev team, and then checks the code again once the developers address the issues before the auditing team will mark the issue as “resolved.”

Clearly, any issues that are marked as “Critical,” or “High Risk,” should be resolved. Even if the report shows that all the critical or high-risk issues have been resolved, this should still be noted with some scepticism about the project. If the auditing team found a high number of critical issues to begin with, that can highlight that the developer team behind the project may be quite novice, leading to further and additional problems down the road.

Medium or low-risk issues are common and not normally a cause for concern. The auditing team may even mark something as a low-risk issue if they are simply suggesting an alternative or have a difference of opinion on how to approach something.

Here is a summary of what each of the categories means:

Critical - Anything marked as critical means that something is exploitable right now.

The team at Ackee Blockchain told me a story about an audit they were conducting where they found a critical issue on a protocol that had already launched. They woke the project’s Dev team up at 5 am in an “all hands on deck” emergency to repair the code ASAP. Fortunately, they caught the issue in time before hackers were able to identify the vulnerability.

High Severity - Issues that are not exploitable now, but could be if some specific sequences are fulfilled.

Medium to Low - These are often minor tweaks that are needed or recommendations and not necessarily security threats.

Different auditing companies will write up executive summaries in different formats as well. The executive summary shown above was done by auditing firm Quantstamp. Ackee Blockchain provides the PDF with the audit and a web summary that combines initial and follow-up results in more of an essay format that is easier to read. You can find an example of that in their Audit Summary.

Additional things to look for:

• Has an audit been completed by more than one company? The more eyes looking for issues, the less chance there is of a flaw existing in the code.
• Is the blockchain auditing company professional and respected in the community? If you have never heard of the auditing company before, take a look at their website and look for other projects that they have worked on. Are any of the platforms they have audited reputable? Check to see if any of the platforms were exploited after the company performed an audit, this could highlight a track record of poor auditing skills. Look for things like won hackathons and support/grants from layer 1 network foundations.

A good example of this is Ackee Blockchain, which has been assigned official development/community grants by four key foundations: Coinbase Giving, the Ethereum Foundation, the Solana Foundation, and the Tezos Foundation.

If you are someone who has become understandably untrusting in this age of misinformation, if you see a claim such as the image above taken from the Ackee Blockchain website, instead of taking their word for it, you can always navigate to the websites of the foundations mentioned and verify the claims for yourself.

The reason I say this is because, in my years of writing reviews, the number of websites that claim, “Featured in Forbes or Yahoo Finance,” when they never were is overwhelming. I wish there was some form of internet police that could haul companies off to internet jail for lying and misleading statements like that. That is why in crypto there is a saying, “don’t trust, verify.” Don’t worry, Ackee checks out and actually is trusted by the above foundations, I checked 😉

Closing Thoughts

Well, there you have it. Some information about blockchain security that I hope you found useful. I hope this article helps you feel more confident venturing out into the world of crypto with one more layer of armour and being able to navigate the crypto waters safer than before. I know that I will be diligent in verifying this information the next time I am selecting what DApps and protocols I choose to trust with my crypto assets.

As the saying goes, “in crypto, it’s not about how much you earn, it’s about how much you keep,” as unfortunately, many of us old crusty crypto veterans have lost more than our fair share of Satoshis in a myriad of hacks, scams, rug-pulls, bankruptcies etc. The more knowledge we have, the better we can protect ourselves from many of the harsh risks that exist in this new and budding wacky world of crypto.