this is ore AKA trust underscore 90 on Twitter, and this is or being the top earner four times in a row on code for Arena's security audits. Landing him the number one spot in the past 90 days in the leaderboard and totaling over 67 thousand dollars. And actually before that also like a couple of other contests, a total about like 110 and 115k code free in this platform where instead of going to a traditional auditor to get your code reviewed, you actually open it up to Independent researchers to compete to find the most amount of vulnerabilities. And those who find the most and the most novel vulnerabilities get paid. And Trust has been killing it, and I wanted to find out how he was able to do this. So I invited him to an interview to learn more about his process in finding these bugs. So I started by understanding first of all the fundamentals before even starting to deal with security concept because security can only be built first on like good foundational understanding of the technology. Step one understand the

basics. Now, this is both the basics of EVM and Solidity and smart contracts, but also the basics of the whole space and the protocols that you're going to be working with. There were a lot, like obviously, there's a lot of knowledge gaps in terms of DeFi protocols and financial concepts that most people aren't aware of because eventually this is how the banking system works currently, but it's really abstracted away from us in the form of a bank account, which does all these things and institutional services. And in DeFi, everything happens transparently. There's a couple of weeks where you just learn about how collateral ratio works and how liquidations work, and I actually really enjoyed getting up to speed on all these concepts in Web 3. For Solidity, the best reference was the actual Solidity website. So then I asked, What's the first thing you do when you start auditing a project in code for Arena? To that, he gave us step two, which is understand the architecture of the protocol you're working with. Not

just the code but the actual project. I like to take a top-down approach, and through this approach, I will start by having a sound understanding of what the contract's external surface looks like. All right, so as a user, what are you allowed to do with this contract? And also, read all the docs because they may give you pretty cool understanding that you wouldn't have otherwise. So, the docs are basically preparation for diving into the code. I start from a zoom-out view and start digging into places where I think it could be more interesting to look at and encode Arena and audits in general. There's scope, so you want to make sure you spend your time on the code that isn't the code that is in scope in code for Arena and most security audits. There's this concept called scope. It's what you're allowed to look at and what you're not allowed to look at. If you submit a finding, a critical vulnerability for something that's out of scope, you don't get paid. Once you identify all these areas of code, you start filtering out

the trivial things, and you want to focus on the more complex stuff, like what sort of code is actually new or novel in this particular project, right? I like to spend my time focusing on the new stuff in each project, and also if they've changed something on top of another project, they need to ask yourself, like, why did they change it, and have they not fixed any issues that exist in the original? Like, in the fork project, there is basically no shortcut to understanding how the code actually works, and in order to find bugs, you need to find any assumptions that the developers are making which are not definitely true, because if there is no gap, there's no misunderstanding that the developer did, then there won't be bugs in the contract. There's always going to be some gap in a developer's understanding of the systems they're building. That's one way to focus. Another way to focus is on easy mistakes that keep on being made, re-entrances or precision loss errors, lots of these common mistakes that we keep happening.

keep seeing so you can have a pretty. You can take a wide view of all the projects, like what the product is doing, and see if there's any of the simple things going on wrong. But usually, these bugs will get reported by a lot of others. They're in the submissions that really make you the big bucks, are going to be like the special ones that require the most theological understanding of the project. And that's usually the ones that actually take you the longest time to find because on the surface level, they aren't even visible. And sometimes, these bugs aren't even to do with anything about solidity. It's only about the thought process. It's about what are you logically allowed to do and it's not. It could have been written in English and the bug would still be there. This is like some of the more elegant findings you can find, right? So if you read the docs, you say, Hey, this is an application for staking. You're saying once you get that, once you understand what staking is, locking up collateral, then you can go to

the docs and say okay where's the stake function okay it's here is it doing is it match up with what I conceptually think they're trying to do and then you just keep doing that for the whole contract yeah and eventually you want to go over the whole contract at least as a first pass and sometimes they even document the number of passes they do per Amtrak in order to increase my confidence that this part is legit you definitely want to go over everything separately and then after that you also want to have another pass where you try to understand the dependencies and the ways in which to the different contracts interact together because that may introduce lots of risks as well so what are the tools tools that you'd use to do this obviously it's important to have a setup where you can experiment and try out ideas PLC my setup is like a Windows machine with an Ubuntu WSL too and I use it to run all my hard hat and Foundry tests I usually try to do it as little

as possible on the Windows side, and because everything works a little more smoothly on Linux, a lot of my testing is on Remix because it's just really great to trace through and check out a lot of different tests quickly. And when I need to check specific events that take place in some blockchains, I'll use Tenderly. Tenderly.co was a really great tool for debugging specific transactions and trying to deploy your own contracts and see how they behave. I try to use the different tools as the most important and appropriate tools for the specific circumstances. It's important to know Foundry, Hardhat, and for Code Arena contests, we want to make use of the existing test suite that each project provides because it cuts down on the amount of prep time you need. And it's also great for developers as they're like to validate whatever finding you bring with their own tests, with their own tests. So, it's easy for them to get into it and understand exactly what you're doing. Or where can people find you? Find me on Twitter, on Trust for

90 also will be available. I hang around in the C4 Discord Channel a lot and on the unified channel, so you can find me over there and also on my website, trustindistrust.com. So, there it is. Understand the fundamentals, understand exactly what the protocol does from a conceptual level, and then number three, comb through the code, seeing if what it should do is what it is doing. Looking forward to seeing you all competing in Code for Arena. [Music] foreign foreign [Music]

How to become the #1 Auditor in Web3

How to become the #1 Auditor in Web3