Coinbase Security Series How to Prepare for a Smart Contract Audit

Hey everyone, my name is Opel. Matt and I are blockchain security engineers at Coinbase. We work on the protocol security team with Alexis and Emra who you met in the last talk. Our team is responsible for securing onchain protocols here at Coinbase. This is the second talk of our Coinbase security series where every two weeks a security engineer will present on a topic of onchain security.

The topic for today is how you as a member of your team building a decentralized application can successfully prepare for a smart contract audit. As is the case for everyone on these talks, please note our disclaimer at the bottom of the screen. And with that, I'll let Matt take the floor.

Good afternoon everyone. Thank you for joining us today. My name is Matt Pillsbury and I'm excited to talk to you about a topic that's critical for anyone working in the blockchain space and that is how to prepare for a smart contract audit. Smart contract audits are a vital step in ensuring the security and reliability of your codebase. They're not just about finding bugs.

They're about building trust, protecting user funds, and ensuring your project is ready for deployment. But here's the thing. The success of an audit depends heavily on how well you prepare for it. So, in this presentation, I'll walk you through the key steps you can take to make the audit process as smooth and effective as possible. Whether you're a developer, a project manager, or just someone interested in blockchain security, you should leave here today with actionable insights to help you get the most out of your next audit.

Before we dive in, I'll provide a road map for today's presentation. We'll begin with an introduction into the importance of smart contract audits, why they matter, what auditors are looking for, and how you can maximize the value you get from the process. Next, we'll dive into the preliminary review of your codebase where we'll discuss the importance of clean, organized, and well doumented code, as well as tools that you can use to check for test coverage and find early security issues. From there, we'll talk about the importance of writing detailed documentation for your smart contracts. This is a key step in ensuring that auditors understand the intended behavior of your project, the known risks, and any security trade-offs you've made in the project's design.

After that, we'll discuss the importance of test scripts, deployment scripts, and monitors. And I'll share with you how you can get free monitoring for your project. Then, we'll go over common pitfalls and how to avoid them by leaving enough time for fixes after the audit and setting clear expectations around communication and deadlock. Finally, we'll wrap up with the key takeaways from today's presentation and then I'll take a few questions from the audience. Okay, so let's start by talking about smart contract audits.

Smart contract audits are a critical step in the development process and they're becoming increasingly important as the blockchain ecosystem grows both in volume and in value. So, first let's talk about the value of audits. At their core, audits are about preventing catastrophic financial losses. On the right side of the screen here, we can see a number of recent projects that have been exploited. Audits are critical to keep your project secure and off of this list.

A single vulnerability in a smart contract can lead to millions or even billions of dollars being stolen. Beyond that, audits help you build trust with your users, investors, and other stakeholders. A well- audited contract signals that you take security seriously. Finally, audits help to ensure that your code is safe prior to deployment, which is especially important as in the overwhelming majority of cases, smart contracts are immutable and cannot be changed after deployment. Now, let's take a look at the auditor's perspective.

Auditors aren't only looking for bugs. They're assessing the overall security posture of your project. They want to understand how your system is designed, what assumptions you've made, and how you've mitigated any risks. The more details you can provide around your business logic, assumptions, and design, the more effective the audit will be. So, how do you maximize your return from an audit?

The key is preparation. A well-prepared codebase and detailed documentation enables the auditors to focus on finding bugs rather than spending time trying to understand the intentions of your protocols design. It also minimizes the back and forth between you and the auditors, which means you may be able to get your audit results faster and ultimately deploy faster. In short, audits are not just a checkbox on your launch checklist. They are an investment into the security and long-term success of your project.

Next, let's talk about the preliminary review of your codebase, which is one of the most important steps in preparing for a smart contract audit. First, your code should be clean, organized, and well doumented. Auditors need to understand your code to evaluate its security, and messy or poorly documented code makes their jobs harder. One of the best ways to document your code is to use NATSE.NATSE is built into Solidity.

It's the built-in documentation format for Solidity. Um, and it allows you to add comments that explain the purpose, inputs, outputs, and assumptions of each function. For example, you can specify what a function is supposed to do, what constraints it has, and how it may handle certain edge cases. If you're short on time, AI tools can help you write these, though it works best when you have some documentation to feed into the AI first. And always make sure to double check the output when using AI as well.

Second, let's talk about testing. When developing a protocol, you should be writing function tests for ideally every function in your smart contracts. When you are spending time writing these tests, you should also focus first and foremost upon the critical logic of your protocol, meaning the functions that modify the storage or state of the smart contract or that move value in some way. If you want to take an advanced approach to testing, you can also write fuzzing tests in Foundry, which will automatically test a variety of scenarios instead of one predefined one. Ideally, you want to aim for 100% test code coverage by the time your code is handed over to the auditors.

This will help the auditor see which scenarios have been accounted for and will help them identify any gaps or edge cases they may want to test to try and break or hack your contracts. Third, you should be leveraging security tooling whenever you can. Static analysis tools are very simple to set up and run against your codebase and they provide extremely valuable results. Slither analyzer, soulhint, and aderine are popular open-source uh smart contract static analysis tools which are commonly used for detecting both vulnerabilities and best practice violations within smart contracts. These tools combined and or together provide hundreds and hundreds of issue detectors that you can use on your smart contracts today and completely for free.

Over the years, I've seen a lot of audit reports where many of the findings could have been discovered early by using these tools. So, if you run these tools and clean up your codebase prior to conducting an audit, your audit will go much more smoothly. the auditors will spend more of their time looking for other critical issues and your final audit report will come across much cleaner. Then finally, I want to call out uh some additional resources. So, if you're interested in reading more about smart contract security, Siphon Siphon has a lot of useful blog posts and other articles where you can learn a lot more about securing your codebase and those are all free as well.

Now, let's move on to writing detailed documentation. While NATS spec comments are great, they're not enough. Having formal documentation that explains your entire protocol is also a necessity. Now, your documentation should go over all of your most critical functions, explaining how you intend them to work, and how they should be used. This means specifying for each function what type of address or user is going to call the function, what the expected input parameters are, what is the logic of the function, and what are the state changes made as a result of that function being used.

You should also discuss the intended business logic for your protocol. This means that for all functions, even those that don't change the state of the contract, you should strive to provide documentation explaining the purpose of the function and the thought process behind the critical logic within that function. The auditors will use this when reviewing your code to compare it against your business logic and ultimately ensure ultimately ensure that the protocol will work as you've intended it to. It's also very important to document any edge cases, known risks, or security trade-offs you made in developing your smart contracts. You should aim to explain your justification for accepting any risks or making any trade-offs because the auditors will use this information to try and test edge cases that may exploit an accepted risk or security trade-off.

It is critical that you disclose any assumptions your protocol relies upon. For example, you may assume that a certain source will always provide the fair price of an asset, but the auditors may not be so trusting and they will likely want to investigate these assumptions further. And this is important because it helps the auditors look for again edge cases that can break the developer assumptions and ultimately have an unexpected result, also known as a bug. Ultimately, these steps are important because they reduce the ambiguity for the auditors and help them focus on the most critical areas of your code. Detailed documentation also demonstrates to auditors that you've put significant thought into your design and risk mitigation strategies.

Overall, providing this detailed documentation is essential for ensuring a smooth and effective audit process. Moving on, I want to talk about the importance of test scripts, deployment scripts, and monitors. Now, I touched on writing tests earlier, but sharing both your test and your deployment scripts is essential for ensuring that your smart contracts are thoroughly tested and easy for the auditors to evaluate. Again, aim for 100% coverage for your functionality testing, ensuring that you account for all probable scenarios. Employ fuzz testing to proactively uncover and address unexpected edge cases if possible.

And then by providing a robust test suite, auditors can identify any remaining gaps or additional scenarios to test overall enhancing the protocol security. Now let's move on to deployment scripts. These scripts are important because they allow the auditors to deploy your contract in a controlled environment and they allow them to do so in the exact same way that you intend to deploy it. This makes it easier for them to accurately test your contract and evaluate its behavior in a in a controlled environment most alike to mainet. Regarding monitors, you should share any existing monitor configurations you've developed with your auditors.

Just like with the test suite, auditors may be able to identify gaps and recommend additional monitors to enhance your protocol security posture. And as a bonus, I want to remind everyone of the base hexagate monitoring program, which provides free onchain monitoring for base builders. We've partnered with Hexagate to offer this service to you at no cost, and it will enable you to monitor up to 10 contracts on base completely for free. This is a great resource to leverage, and I would strongly encourage anyone who's looking to deploy smart contracts on base to enroll in that program. Now, let's talk about some of the common pitfalls to avoid when going through a smart contract audit.

These are mistakes that can delay the audit process, reduce its effectiveness, and just cause general frustration. So, avoiding these can save you a lot of time while also ensuring that you get the most value for the money you paid for the audit. Now, the first and and most common pitfall is poor time management. It is critical that you leave enough time after the audit to implement fixes and to have those fixes subsequently re-reviewed by the auditors. Audits can uncover issues that require significant changes to your codebase to resolve.

And rushing to deploy without fully addressing and having these issues re having these resolutions re-reviewed can lead to vulnerabilities being exploited after you deploy. So always plan for a post audit phase where you can make improvements and fixes and then have those changes be re-reviewed by the auditors. You know, think back to last week's session on the secured development life cycle and remember that smart contract development is an iterative process and as such you should be planning for multiple iterations of development and auditing. Finally, if your project can afford it, you should budget time for a second audit. Remember that audits are not security guarantees, but best effort reviews to find as many security issues as possible.

Having multiple audits means more eyes on your code, more issues found. ultimately higher confidence in the safety and security of your protocol. The second most common pitfall is communication issues. When obtaining an audit, it's important to set clear expectations with your auditors around communication, time zones, and deadlines. For example, if your team is in another time zone than the auditors, make sure you've accounted for that in your timelines and your communication plan.

Also, be realistic about deadlines. Rushing the audit process to in order to meet a launch deadline can lead to missed vulnerabilities. In almost all cases, it is better to delay a launch by a couple of days in order to ensure your codebase is secure. Third, avoid documentation gaps. Incomplete or outdated documentation can slow down the audit process and lead to misunderstandings.

Make sure your documentation is thorough, up-to-date, and easy for the auditors to understand. Then finally, after the audit is complete, you're not done. There is still more to do. Ideally, you should have set up a bug bounty program so that independent security researchers have both a motivation and a path to find and report any security vulnerabilities in your deployed smart contracts. You should also plan how your team will respond to any incidents should they arise.

And finally, you should be leveraging a monitoring solution like Hexagate to alert your team of any issues or unexpected actions that are occurring on chain. By avoiding these common pitfalls, you can ensure that your audit process is smooth, efficient, and effective. Now, let's wrap up with some key takeaways from today's presentation. Referencing these images on the right, which came from last week's presentation on the secure development life cycle, we can see that the cost to secure your codebase drastically increases after deployment. This just emphasizes the importance of performing audits and being well prepared for those audits in order to ensure you get the maximum value for your audit before you deploy.

So, first preparation is key. A clean, well- tested codebase and detailed documentation are essential for a successful audit. The more effort you put into preparation, the more effective the audit will be. Second, leverage tools. Use static analysis tools, testing frameworks, and other resources to catch issues early.

These tools can help you identify vulnerabilities before the auditors even see your code, saving time and possibly reducing costs. Third, communicate effectively. Set clear expectations with your auditors around communication, time zone, and deadlines. Good communication ensures that well that the audit process will run smoothly. And then finally, leave time for fixes.

Audits are not the end of the process. They're just one step in ensuring the security of your contract. Always plan for a post audit phase where you can address any security issues that are uncovered and have them re-reviewed. By following these steps, you can maximize the value of your smart contract audit and ultimately ensure that your codebase is secure, reliable, and ready for deployment. So that concludes my present tastation today.

Thank you so much for your time and attention and best of luck on launching your project. Now I'll open the floor for questions. So, if there's anything you'd like me to expand on or clarify, feel free to ask.

Thanks, Matt. Great presentation. Yeah. So, like you said, this is the audience's time now to ask any questions that may have come up during the talk. And while we wait, I do have a question of my own.

So, what can it look like when one of these smart contract prep tips are overlooked? Do you have like a real life example of something that can happen as a result? Yeah, I mean the easiest way to explain what happens is delays, confusion, and wasted time and money. So, I mean, I can think back to an example. I I won't name any names, but I did a review on a certain project of their version three, but they hadn't updated their documentation.

Their documentation was still for their version two, and that wasn't made clear to us. So, you know, we started the audit. We're a day or two in. We're reading the documentation, looking at the code, and we're thinking this isn't lining up. There's there's something missing here.

And so, you know, we got in touch with the team, eventually learned they had to write a bunch of do new documentation. And so, that delayed the audit process because we essentially had to put the process on pause while they wrote the new documentation. And then in addition to that, they lost two days of auditing. So, for multiple reasons, this was not an ideal scenario. And again, this just emphasizes the importance of having that documentation fully up to date before you start them.

Yeah, that makes a lot of sense. That really emphasizes the pitfalls that you mentioned earlier. Another question I have is for those trying to factor in enough time in planning their launch, how long does an audit usually take and what factors are used in determining this?

Yeah, so the the time it takes to complete an audit can vary drastically and ultimately it's going to depend on how large and how complex your codebase is. So, you know, if you have a very large collect code base like like a lending market, you know, that may take a while. That may take about a month or so. Um, but you know, if you're working on a token or like a staking contract where it's a standalone smaller product, you know, then I think an audit could take as little as a week even. Um, so ultimately it really comes down to the size and complexity of your codebase.

But then, you know, this also brings up another thing I'd like to share, which is the time before you start the audit. So, you know, you may budget four weeks for your audit, but the auditors are often very busy. So, just because the audit will take four weeks, you may also need to wait four weeks just to get in the auditor's door. So, definitely keep that in mind when you're going to conduct an audit, try and reach out to the auditors early and set that audit start date, you know, well ahead of time. Ideally, a couple weeks to even months ahead of time.

Yeah, that makes sense. What about like post audit audit fix time? Is it usually quick? So yeah, I mean again that that really depends on the the size and scope of the fixes. So you know if it's um if it's just implementing a lot of small fixes that aren't really touching core critical logic, the re-review period can only be a couple of days just to ensure those fixes were done right and didn't introduce any new security issues.

However, there's also times where the auditors will essentially say, "Hey, this large chunk, this conceptual idea you have in your codebase just doesn't work. It's vulnerable on its face." And as a result, you know, the development team may need to rewrite more substantial parts of your codebase. And in that case, you know, the fix period may be longer. I would say the most common fix period is about two weeks, but again, it can vary a lot.

And and of course, that's always up for negotiation with your auditors as well. Yeah.

Yeah. Um, another question that comes to mind is, can the tools previously mentioned such as Analyzer, Slither, and even AI currently completely replace manual audits done by humans? What do you get with one that you may not get with the other?

Well, I'll say AI is definitely not coming for our jobs anytime soon. And and and similarly with these tools. So, these these tools, they're very good at finding programmatic issues. You know, they're largely pattern recognition tools. So, they'll help you find the more common issues in smart contracts, ranging from a lot offormational and best practice issues these tools will flag to you, but they'll also call out things like re-entry, which is of course probably the most common vulnerability in smart contracts.

What these tools won't find, however, is flaws related to your business logic. So, let's say you have a lending platform and um you know, there's certain logic around calculating liquidation ratios or something. A static analysis tool doesn't have the context. It doesn't know enough to be able to catch like a bug in that logic. Really, there's there's no replacing humans.

I will say we've tried with AI having it find those logic bugs and it hasn't been uh doing the best job either. You know, maybe give AI a couple years, but for now, humans are absolutely essential to making sure an audit is done well. Yeah, it kind of sounds like anything that makes your project the unique project that it is kind of requires humans to look at. Yeah. Uh like one final question I have to wrap up here is are there any other further open source resources available on the web for uh a developer that wants to become more security-minded that you would want to mention?

Yeah, I would definitely point people to the siphon resources. They have a lot of articles, maybe even I think like a course. I'm not sure if it's formerly a course, but um they have a lot a lot of resources on how to secure your smart contracts. Um how to like learn to be an auditor essentially, which is probably good for any developer to know how an auditor thinks. So I would definitely look at the cipher resources.

Lots of articles there. Um and then like we were saying, these open-source tools, these static analysis tools, very very easy to use and very very high impact. So I I can't recommend them enough to everyone on the call here today.

Yeah, thank you so much for sharing your perspective, Matt. I think that wraps up the questions for today's talk. To everyone me watching, keep an eye out for our next session July 25th where Eli will discuss best practices for key management and wallet security. Definitely don't want to miss that one. Thanks for to everyone for attending.

Have a great day.