How Does One Audit DeFi Platforms?

The safety of users' funds in DeFi isn't guaranteed by monetary authorities. Huge vaults and armed security personnel also don't jump in to assist you. It all comes down to the soundness of the code. Bad Practices. Bad Practices Everywhere. It’s quite common for the DeFi space to launch products in a rush and then try to patch and adjust them once they're out. We have seen, and continue to see, projects that go down this route get hacked or exploited. In the crypto world, users rely on platforms and code, not human beings making decisions. Air-tight code is a must. Going through many audits needs to be the default, not a nice-to-have for Web3 protocols. Regardless of the expense. In this piece, I’ll highlight the importance of DeFi audits. We’ll also explore what ideal scenarios look like, and reflect on Fringe Finance’s first-hand experience of performing a double audit. Audits 101: You WILL suffer, but it’s Worth it! An audit involves dozens of people with proven expertise in cybersecurity. Their job is to scrutinize every line of code to identify: critical vulnerabilities, potential points of failure, excess centralization, and even the simplicity of your interface. Audits are a great way to: Avoid tunnel vision. Get a fresh perspective. Set the foundations of a project that can then scale faster. They are a must for any project or platform that cares about the safety of users' funds and their long-term success. You only need to get hacked once to lose the trust of the public forever. One must not underestimate the importance of staying alive for longer than your DeFi competitors. For Fringe, launching trouble-free with the Primary Lending Platform is essential to meet our goal of attracting high-net-worth individuals, financial institutions, and the communities surrounding hundreds of DeFi projects. So, we promised ourselves that we’d go under as many auditing rounds as necessary. Speaking of Rounds… The phrase “ ”, implies that every single vulnerability fixed needs to get re-tested to oblivion. go through as many rounds as necessary Here’s how it works: When you start an audit, you need to set the scope of the process. You decide which contracts the auditing firm scrutinizes and to what degree. Ideally, you would have your whole protocol audited, not a few contracts. Each contract that's included in an audit makes it increasingly time-consuming and expensive. Some projects take as an incentive to cut corners. We opted to find solutions for the protocol that minimized the usage of contracts and made the most out of them. Strategy is the name of the game! The audit firm's experts study your codebase. They run automatic testing tools, apply a wide range of known exploits, and manually check for vulnerabilities. This process generates a report that the team will act upon, fixing vulnerabilities. From most to least critical. Once patched, you should re-submit your code to the auditing firm. They re-test all previously identified vulnerabilities while looking for newly introduced ones. The project should repeat this back-and-forth process until the auditors can no longer find any standing vulnerabilities. Double Auditing in War Times I have stressed the importance of re-checks. "Auditing," should be taken with nuance in all cases. Going through a single check does not count as an audit, and neither does fixing vulnerabilities without repeated tests. One could even say, "going for multi-firm consensus could be the only way to achieve true security". Since every auditing firm has an internal culture and fixed procedures that could impede a true audit. Hello From the Other Side Having an audit certificate looks good on paper, but you don’t get there unless you’re diligent, which is certainly hard work. Overall, the unexpected takeaway is how much one learns from being scrutinized by the very best in the business. Everyone involved can now proudly say that we’ve become more skilled in our jobs and know things we didn’t before. Auditing, unexpectedly, allowed us to discover multiple opportunities for tweaks and possible implementations. In short, it made us stronger. We learned a lot about our own protocol, biases, and ideas. We came up with some great concepts that will help make the protocol more attractive to users looking for both innovation and security. DeFi and Web3 are young. And, if I had to come up with just one takeaway from this process, it would be that we, as an ecosystem, can only improve by collaborating. DeFi is for everyone, but, it is also for everyone.