smart contract audit is a time-boxed security-based code review on your smart contract system. An auditor's goal is to find as many vulnerabilities as possible and educate the protocol on best security practices and coding best practices moving forward. Auditors use a combination of manual review and automated tools to find these vulnerabilities. Now, why are they so important? Why is it critical that you get an audit before deploying your code base to a live blockchain? For starters, there are entire websites dedicated to how many hacks happen. Last year, we saw the most value ever stolen from smart contracts, with almost 4 billion dollars stolen. Due to the immutability of the blockchain, once a smart contract is deployed, you can't change it, so you better get it right. The blockchain is a permissionless adversarial environment, and your protocol needs to be prepared for malicious users. But even more so than that, an audit can improve your developers' team's understanding of code, improving their speed and effectiveness in implementing features moving forward.

and it can teach your team the latest and greatest tooling in the space. Often, just one smart contract audit isn't even enough, and protocols go on a security journey that includes many audits and many different services like formal verification, competitive audits, and bug bounty programs. We'll break these down in a future video. There are a lot of companies that offer smart contract auditing services like Parallel Bits, Consensus Diligence, Open Zeppelin, Sigma Prime, Spirit Dao, Mixed Bytes, WatchPug, Trust, and of course, Ciphon. Additionally, there's a lot of independent auditors that do great work as well. A typical audit looks like this: price and timeline. First, a protocol needs to reach out, and they can reach out before or after their code is actually finished. Ideally, they reach out sometime before their code is finished so the auditors can have time to slot them in. Once they reach out, the protocol and auditors will discuss how long the audit will take based off of scope and code complexity. The scope of the audit is going to be the exact files

and commit hash that's going to be audited. How long the audit usually depends on how many lines of code/complexity. You can see a very, very rough approximation of how long an audit takes on your screen. Now, of course, this depends from The Firm audit to audit and tool to Tool, so take these with a very large grain of salt. Additionally, it's this duration that sets the price and same thing at the time of recording. Prices range wildly depending on who's doing the audit, how many people are doing the audit, how complex the code is, and more. And these initial conversations are really just to get a ballpark estimate and Slot you in to the auditor schedule commit hash down payment start date. Once you have a commit hash, you can finalize the start date and final price. The commit hash is the unique ID of the code base that you're working with, so the Auditors can know exactly what code they're going to be looking at. Some Auditors will ask for a down payment in order to schedule you in. Audit Begins. The Auditors will use every tool in

their Arsenal to find as many vulnerabilities in your code as possible. We'll give you some tricks in a minute to make this a successful step. Initial report after the time period ends. The Auditors will give you an initial report that looks something like this, with all their findings listed by severity, usually categorized into highs, mediums, lows, informational/non-critical, and gas efficiencies. Highs, mediums, and lows represent the severity of impact and likelihood of each vulnerability. Informational, gas, and non-critical are findings to improve the efficiency of our code, code structure, readability, and best practice improvements that are not necessarily vulnerabilities but more ways to improve your code. Mitigation Begins. The protocol's team will then have an agreed-upon time to fix the vulnerabilities found in the initial Auto report. Sometimes, depending on the severity of the findings, this might mean you have to start from scratch, but more times than not, you can just implement the recommendations the Auditors give you. This is usually much shorter than the audit itself. Final report after the protocol makes these changes. The auto

team will do a final audit report exclusively on the fixes made to address the issues brought up in the initial report. Then, hopefully, the protocol and Auditors have a great experience together and will work together in the future to keep web 3 secure. Now, there are a few key things that you can do to make sure your audit is as successful as possible. To get the most out of your audit, you should have clear documentation, a robust test suite, ideally including fuzz or invariant tests, code should be commented and readable, modern best practices are followed, there should be an established communication channel between developers and Auditors during the audit, and an initial video walkthrough of the code should be done before the audit starts. The most important part of the process is going to be during the audit. To get the best results, you want to think of you and your Auditors working together as a team. One of the best ways to do this is to have a dedicated channel where Auditors can ask questions to developers. The developers will always and forever have more context over the

code base than the Auditors ever will because they have spent so much more time working on the code base. The more documentation, context, and information that you can give to the Auditors, the better. This way, it can be easy for anybody to walk through the code and understand what it's supposed to do. In fact, 80 percent of all bugs are actually business logic implementation bugs. This means that these are bugs that have nothing to do with some weird coding error and are just somebody not knowing what the protocol should be doing. So, it's vitally important that the Auditors understand what the code should be doing. Having a modern test suite and tooling can also make Auditors spend less time fidgeting with your tooling and more time finding issues. Post-audit, we highly encourage you to take the recommendations your Auditors give you seriously. Additionally, after an audit, if you make a change to your code base, that new code is now unaudited code. It doesn't matter how small the changes; we've seen a ton of protocols saying, Oh

I'll just slip in one line of code, and sure enough, that's the line of code that gets exploited. And often, depending on the seriousness of your protocol and how many users you want to use it, one audit might not even be enough. Working with multiple auditors and getting more eyes on your code will give you a better chance of finding more vulnerabilities. What an audit isn't. Now, here's the thing: an audit doesn't mean that your code is bug-free. An audit is a security journey between the protocol and the auditor to find as many bugs as possible and teach the protocol different methodologies to stay more secure in the future. Security is a continuous process that is always evolving. No matter how much experience someone has, people at all levels have missed vulnerabilities. On the unfortunate day that that happens, be sure that you and your auditor can jump on a call quickly to try to remedy the situation, and maybe consider getting insurance for your protocol as well. So now, with that being said, now you have a good idea of what a smart contract audit.

entails and what to expect. To end a smart contract audit is a security journey, end-to-end, leveling up your protocol so that you can have all the best practices and security know-how to deploy your code to a live blockchain forever. And of course, if you're looking for an audit, be sure to reach out to the Cyphron team. Link in the description. And as always, stay safe out there, and we'll see you next time.

What is a smart contract audit? How to prepare for a smart contract audit?

Book a smart contract audit here 👇
https://www.cyfrin.io/
