DeFi Security 101 2025 - Smart Contract Auditing 101

Transcript

organizing it. It's an event that's supposed to be before the DeFi Security Summit to help you understand the concepts which are there. We started in Stanford 4 years ago. We had four people, so now we have slightly more. Uh I think it's a wonderful opportunity for you to learn about the space. We It's a commitment from our side and from your side. From our side, our commitment is to bring the best people and I think we have done it this year. From your side, your commitment is to ask questions and to be active in this thing. So, maybe I can just quickly ask how many of you have written at least one smart contract?

Okay, that's good. How many of you have had your smart contract with a bug? Okay, that's nice. Okay. So, we going to start. We are recording. It means that if you have questions, we prefer to actually and I going to help and other people will help with the mic so that people get the recording. A lot of people and in the previous time that we did, we didn't record and there were a lot of complaints. So, we want the recording to come up and this is also a commitment to the to the speakers. If somebody ask you a question, either you see that you get the mic or repeat the question.

So, people that listen, unfortunately, we cannot broadcast, but we will upload it. So, the first line of speakers, we have amazing line of speaker. We have Rajiv, Jocelyn, and Alex which are leaders in this space. So, please welcome them. >> [applause] >> Okay, so I'm just going to sit.

Okay. Hi everyone. Hi Hi everyone. Good morning. So, we are going to start with one-on-one number of tips for smart contract auditing with Rajiv, Alex, and myself. So, I'm going to start with a lot to cover. So, stay focused. So, my first tips for you and for this presentation is that you should not trust us and you should build your own path. What I mean by that is that through this hour, you are going to learn a lot of advice, you are going to learn a lot of strategy to do code auditing and to do like security. But in reality, there is no one way to do code reviews, there is no one way to be a security researcher. And really, what I would recommend you to do is to experiment, see what stick for you, what doesn't stick for you,

and you know, build your own expertise. I have split my first 30 tips into categories. So, first I'm going to go over learning. Um Something I've seen happening a lot is that people try to learn everything at once. What I would recommend if you're starting is to first start to build a depth of expertise before a breadth of expertise. What I mean by that is really to go deep dive into a specific topic, one or two topic until you reach a point where you're not progressing and then move to something different. For example, it might be lending protocol, you really want to be really good at that and then you focus on that for like some month instead of trying to switch every, you know, now and then the topic.

Um You are lucky. These days, there are a lot of really, really good content out there. I would recommend to go on War Skill, I've Drive I've Drive from Cyfrin, and subscribe to Black Friday News is going to give you a lot of information about what's happening in the space. Um At the same time, don't just read tutorial, learn to read code. Your job as a security researcher is going to stare at code all day, so you you have to become really, really familiar with that, you have to become really, really confident reading code. So, don't just read tutorial and postmortem, go on the source code. If you want to learn about EVM, go on the node implementation, geth, web, you know, whatever implementation you want to learn about, and really become familiar with reading code.

You are what you review. This might be a bit weird, but basically, what it means is that as a security researcher, you are going to be as good as the project that you are reviewing. If you spend your time reviewing project that don't push you, for which you are not learning, you are not going to progress. So, really, you know, start and to think about being strategic about where you spend your time. If you review, you know, the copy of a copy of a copy of a NFT, you are not going to progress. Your goal is to find project that challenge you, but are still kind of within reach. So, this is really important. Learn to focus.

Code auditing is hard. It requires to, you know, really, really being focused. It It requires to not being distracted with everything can happen on your social media or on Discord or whatever. So, really, learn as a practice to know how to focus. Be strategic when reading report. So, that's something I've seen a lot of people doing. They read a lot of report and they don't necessarily accumulate knowledge out of them because they just go through the report. So, be strategic meaning identify what type of vulnerability are in the report. Usually, you will find surface level bugs, you will find common bugs, and you will find novel attack. So, when you read a report, what you want is to build up your own kind of like mental model for

the common bug and the surface level bug, and you want to spend more time on everything which is a bit more novel to kind of understand more what they are about. Don't use AI to replace what you are doing, in particular within your learning. I have seen that happening a lot, in particular these days. AI is great, you have to use it, but when you learn, you have to be careful to not replace your learning with AI because you do need to build up the mental muscle to do code review and to explore code base. At the same time, you do have to use AI, so it's a bit of a trade-off. So, you are going to use AI in your career to speed up your process.

So, that's good, but you have to be careful to not replace it when you are learning. Have the right expectation. That's something I have seen happening a lot where newcomer believe that after a few months, you are going to be an expert. You are not. For the first year, you are going to be a beginner, that's okay. For the first one or two years, you are going to be junior, and that's okay. Don't expect to become like a top researcher in two months, it's just not going to happen. Which goes along with compare against yourself, not other. That's something we see a lot on Twitter and on other different social media where you see people being really, really successful and that can create like FOMO for yourself, that can create some some difficult comparison. The reality is

that most of the people you compare against and you see like some successful story, they have more experience, they have spent like a lot of time doing that, they might not share that they have this experience. So, you know, be be careful when you see like a successful story, and really focus on what you are learning, what you know, how you are progressing. Um so, the next tips are related to how to do an audit. Learn to switch between understanding and breaking. And what I mean by that is that I see a lot of people spending a lot of time understanding a code base and not enough time trying to break it.

It's really like a different mindset where you want to understand what the code is supposed to do, but you want to kind of switch also and be able to switch to understand how to break it. So, it's about thinking as an attacker, thinking about how the code base can go wrong. One way to to think about breaking a code base is to ask yourself what if question. That should be even like a kind of a second mode for yourself. What if that happen, what if this is going to, you know, be a case and and so on. Being driven by this what if is going to help you to uncover edge cases. Prioritization over completeness.

So, a lot of time, I see people trying to understand everything in a code base. They try to understand every single line, they try to really have like a complete review of the code base. That might not be possible in all the setups. Sometimes, you don't have the time, sometimes you have to prioritize. So, learning how to prioritize, learning where to focus is really important. Which goes along with learn how to have a review plan. For example, if I'm going to review for 3 weeks, after the first day, I will have some plan. What I'm going to cover, how am I going to cover, and with whom if I am within a team.

This is really important because it helps you to think about the code base, it helps you to kind of structure your work. It doesn't mean that you have to strictly follow the plan because, you know, you are going to explore code base and you are going to learn along the way, but it gives you guideline into what to explore. Um it goes along with building along the path of having a review plan to build a lightweight model. So, think about attack vector, think about actor, think about like the different things happening in the code base, and use that to drive your exploration of the code. So, the next tips kind of personal strategy that works well for me. I know they don't work for everyone, so it goes back to my first tips where, you know, I would recommend to experiment, see what stick for you, what doesn't stick for

you. I think I'm a decent security researcher, but I think I'm an average developer. And as a result, one thing I used to drive my exploration of code base is that I ask myself, where would I make mistake if I were to develop this protocol? And usually, if I make a if I would have make a mistake somewhere, other people might make the same mistakes. So, it's a kind of mentality that helps me to kind of drive where I'm going to look at. Use visual aids. I do that a lot. I have a whiteboard at home where I play to draw things like architectural design, like formula, and things like that.

I really I really kind of it helps me to have like visual representation of what I'm thinking and and what I'm doing. So, try it, you know, you see if if it's help you. A common question I I receive is how to start in a code base. From my perspective, I usually have like two approach. I either start with a what I call like the orchestrator, which is basically there's always like a core component like one one component which is in the middle of like the full architecture. And if that's the case, if I can identify it, I will start with that. I will make abstraction of everything outside and I really focus my understanding first on this kind of core and orchestrator component. So, that's one way I might approach the code base.

A second one, depending on the code base, might be for me to start with an isolated component. Uh for example, a library. Mathematical library is a good place for me to start because I know I can understand the math without necessarily understanding how it's used in the code base, at least for the first step of the exploration. Uh I always follow the money and Oh, thank you. I always follow the money and the user flow. Um That's pretty standard. You know, DeFi is all about money, so you want to understand where the money is going. And user flow is basically what are like the input, what are like the entry point, and you know, how the user are going to interact with the protocol.

I always start with the really surface level bugs first and then I focus on complexity. Basically, after the first day of the review, I want to be able to, you know, go over every checklist, every like simple bug, every like kind of like surface level issue, and be done with that so that I can focus on complexity. You are providing most of the value when you focus on complexity, so you don't want to, you know, go back and forth with like simple bug. Over time, you really want to get that done directly. So, the next tips are really relevant if you want to be a security researcher in a company and do audits.

They will be less relevant if you do bug bounty and bug contest, but I think as a something to keep in mind as you're progressing within your security career, they will still I think be relevant. Soft skills are important. Communication is important, the way you present in front of a client, the way you communicate with your teammate. This is really important. I have seen a lot of engineer just focusing on the technical side and for and forgetting that, you know, we are human and the way you convey information is is really important. Which go along with learn to write because part of your job is going to write report. AI is going to help you to do that, but at the same time, if you don't have like the baseline and the fundamental on how to write clear and concise report, you are really going to

struggle struggle along. It's also true if you do bug report in bug bounty and bug contest. If no one can understand you know what you are talking about, if no one can understand your bug, no one will care about. So, really learn to be clear and concise when you you write vulnerability. Adapt to your client's needs. So, that's something which is really important from the moment you do consulting work. It's not just about, you know, trying to do everything and so on, but it's really about understanding what are your need for your client. Sometimes your client will need complete review in the sense that they want the coverage of all the components. Sometimes they want like more focus on critical issue. For example, if they are going to go live you know in two days, maybe they don't care about like long-term

recommendation. Maybe they just want to to know about the critical issue. Sometimes you're going to work with team that have work in progress code. Um you know, some components are not fully written, some components are going to change, and you need to adapt your strategy to that to be efficient and to really answer the client's need. If you work in a company, if you work in a team, don't hesitate to ask your teammate for help. You know, people are here for for, to help you. So, if there are things that you don't know about, if there are like you know, things you want to brainstorm, don't hesitate to do that. Collaboration helps a lot doing security review.

Thinking idea, doing brainstorming, this is something I can really kind of like help you to uncover new things. So, the next tips are are related to trait behavior that I think are really important as a security researcher and I would recommend you to foster, you know, as you go along in your career. Um the first one, limit time spent on social media. I have seen a lot of people like spending hours and hours on Twitter, Discord, and everything. And when you do that, you are going to lose focus. Your brain is not going to be you're going to have trouble with context switching and everything. So, really limit time. One good strategy to do that, for example, you know, start your day with 1 hour where you might go on social media, you know, check the news and

everything, and then you don't do it for the full day. You do it at the end of the day or whatever works for you, but really really learn to to spend less time on that. Have a growth mindset or learn from failure. You are not going to be able to find everything on your first audit. You are not going to be able to, you know, have all the knowledge knowledge directly. If you see findings in a bug contest that, you know, you did not find, that's okay. It's actually a good thing. It's a way for you to learn and to grow. So, learn from your failure and, you know, have this mindset. Uh passion passion beats greeting every time. I I've seen a lot of people saying, you know, if you want to be a security researcher, you have to grind grind grind grind grind and you will

become good. That's not true. Like security research, it's difficult. It requires a lot of motivation. It requires a lot of inner motivation. So, it's it's really a kind of a field where you need to be passionate. If you spend six months in the field and after six months you don't really enjoy what you are doing, it's not something you have, you know, motivation for it, maybe it's not for you. And you know, that's fine. That can be also a learning. So, really identify if it's something for which you are passionate or not because this is going to be important in the long term. If you stop learning, you are out of the game. And this is particularly true for blockchain security. The space is moving really really fast. What we know today is going to be different from what we know in a year from now. So, if you if

you kind of identify for yourself that you are not making progress anymore, that you are not learning, that you are not growing, probably, you know, you should think about different strategy and you should think about how you can continue to progress because this space moves fast. It's highly competitive and you need to be constantly progressing. Everything I said might be stressful because there is a lot to consider. There is a lot of energy to spend to do code review. But at the same time, you need also to learn on how to take care of your mental health.

Burnout is a real thing in our space. Doing code review is stressful. It takes a lot of energy. It takes a lot of kind of like, you know, it takes a lot out of you. So, you also have to learn how to, you know, maybe take a break from time to time, make sure you have good sleep, you know, do exercise, do physical exercise, you know, eat well because this is going to be important in the long term. You will be able in your career to have rush for, you know, couple of months. You can really do like a You can really push yourself for a couple of months. You cannot do that for a year. So, you have to learn how to manage that.

When you have opportunity in companies, in like different position, don't just focus on money. Especially at the beginning of your career, you want to focus on what are you going to learn with respect to the opportunity you are given. What are the growth opportunity? Meaning, what are like the different responsibility you are going to be given? What are the different steps and and and position you can get within the company or other team you are going to to get. And think about the teams that you are you are you are joining also because if you are in a toxic environment, that can be like a kind of a can even ending your career if you are in a place where you don't have support and you don't have, you know, people helping you. So, don't just focus on the money. Focus on, you know, how you are going to progress,

especially at the beginning of your career. Um this one I studied from Andrej Karpathy. Agency beats intelligence. That's something that took me took me a while to understand, but agency basically means being proactive, getting things done. If you have the smartest people in the room, but you know, you don't have like a mentality that you want to get things done and you want to be proactive, you are not going to be that successful. So, really, you know, be proactive, get things done. Be be be your own driver because that's going to be a trait that is going to make a difference between someone who is successful and not from my experience.

Okay, my last tip, but not least, think about ethics. What we do have an impact. You know, as a security researcher, we want to help the industry. We want to to be in a place where we provide value to to our customer. It's really important to think about ethics, to think that what you are doing doesn't have doesn't cause harm. The way you kind of communicate with your peers doesn't create toxic environment. The way you kind of like share your knowledge is helping other. You know, when you report a bug, when you you think about the vulnerability you can find, this kind of like a real world impact and you need to think about ethics. If you want to be a white hat, this is really important.

And next is Alex. Thank you. >> That's

what I have strong opinions that is being held. Because fundamentally you don't know where the bugs are. Your time is limited, your attention is limited, and as such you want to prioritize based on either a maximum impact or a maximum gain or a maximum benefit to your customer. And at the same time you also want to establish or or remind yourself how confident you are on certain areas of the code base. And therefore, this idea of thinking in bats applies both in prioritizing what you're going to what code you're going to look at and then it's also about self-assessing how confident you are that a piece of

code is safe or how confident you are that you should go and take a second look. In a similar fashion as you expand your understanding of the code base while you effectively ignore selective ignore parts of the code because again prioritize and ignore, you also want to constrain behavior which is the idea that you don't you don't necessarily want to look at all possibilities that the code can have. You want instead as you look at each line as you look at each component, you want to effectively simplify it down to the most logical combinations as well as the most

interesting edge cases. And this is something that I'm going to talk about at the main event as well on Thursday. So definitely be there. But it's really the idea that as humans we are particularly good at finding heuristics or simplifications that allow us not to have to focus on the entirety of the code base. And so that's something you want to keep in mind is once you're done with some piece of code, you literally express the constraint in some way and now you just ignore it. And that way you don't have to think about it anymore. You just think about the combinations that you'll have off of the code that you reviewed.

This is a really good advice that keeps popping up on Twitter. It applies especially to contest and it's that most people find the same piece of code hard. And so it's like if it's hard for you, it's hard for everybody else. I'm doing a small mastermind group with a bunch of white hats and it's always funny to me that like half of those people, they always choose the same contest. Like I'm sure you know there's like 10 to 15 contest running at all times. And yet half of the people always choose the same one. And I think it's really because of this idea that if it's easy for you, if you're more likely to do it.

And if it's hard for everyone, then it's for you it's probably hard for everybody else. So nobody does it. So keep that in mind that you you really want to have to kind of fight your own biases. And you want to effectively understand that more opportunity is where is in the path least traveled effectively. And another great advice is to seek truth. So fundamentally when you're performing a security review or you're understanding what the developers are trying to do, you you want you you you want to understand that you're biased towards for example trusting the developer or trusting your

own biases. But fundamentally as you perform a review, you're just seeking the actual truth of what the code does. And so the closer you are to objective reality, which is effective math, the closer you are to to the math and and the the truth of it, the better you're going to be at your job. In in a similar line, you want to understand a system first and then break it. I like to call it a smash and grab versus kind of the systematic attack. Smash and grab is the idea that there's a bunch of low-hanging fruits in the code, rounding error, Oracle staleness, that type of stuff. Everybody can find it and it's really not particularly unique. And hopefully we'll get rid of all those bugs one day through

automation. But most interesting bugs and most important bugs are found by first understanding the system then having kind of a detached perspective, kind of a thinking just just yourself. You want to basically think about the system and then you you're going to kind of find these new paths. It's like you kind of unlock the those bugs because you understand the system first. And something I want to emphasize is that building is harder than breaking.

It's it's very crucial that you keep that in mind because a common mental pattern especially for red side hacking so basically steal money is fundamentally that you you don't want to have respect for the developer. And I think it's a good mindset to have in practice to to believe that developer can make mistakes and you can you know kind of beat them in a sense. But you also want to keep in mind that if the developers are all unsuccessful, you will never have a job. So fundamentally you want to make sure the developers are successful and you want to understand that it takes not only a ton of courage but also a ton of resource and a ton of work to actually build something. And this is also why most great D5 protocols tend to

be very elegant and tend to be very simple. And it's really because it's so much like it's so easy to write crappy code, but it's very difficult to write something that will actually last. So keep that kind of respect in mind as you fundamentally disrespect their work and you do your job. But keep it in mind that these people are putting themselves out there and they deserve a lot of respect for doing that. So this is kind of a hot top hot take. But I like to think of tools as a substitute for thinking. And so the key idea is that when you're dealing with some sort of a math heavy piece of code or you're

dealing with something you don't fully understand, you actually can use tools to do the thinking for you. A good example that I have is whenever I'm looking at a function, I like to just build like a quick Python script to build me a graph. And that's because even if I don't fully understand the math, now I can quickly see it. And that can help me think about what the code is actually doing without having to be bogged down by the details. So I don't advocate for using tools at all times, but I believe that a smart researcher knows when something is above their pay grade or something is above their skill level. And tools can help you kind of get up kind of cheat a bit

and get up to that level. And possibly find bugs that you can't find through reasoning or math alone due to your skills. Something else that I want to uh I mean this this piece of advice comes from the Rari Capital hack where a low severity fix caused 80 million dollars being stolen. And so a fully understood low severity bug is always better than an untested than an untested fix. This is something that I have really advocate and it's the key idea that once you understand a system and its limitations, then you can work around it. Whereas if you try to forcefully fix

those limitations and another great example is the dust balances on Euler V1, you end up introducing critical bugs because the amount of effort that it takes to constrain behavior, to do the audit, to reduce the risk is completely thrown away when you introduce a fix that doesn't go through that same process. So fully understood to the low severity is always better than an untested fix. And this should lead us to the next insight which is if it's not tested, it's always broken. I have yet to see and you know I've worked with extremely smart people and I would consider myself a somewhat productive developer. But I've yet to see anybody in in D5 ever be able to ship a safe

project with zero tests. I've never seen that. I tried myself, but I wasn't able to. And so this is a key insight that tests can reveal the maturity of the code base. And test or yourself writing tests can also help you understand the system better. And so this is like a maxim. Whenever you're working with a set of developers, if they don't even speak the lingo of tests in the sense they don't even think about coverage and obviously there's more to that. There's modified decision and condition coverage. There's other more advanced ideas we can talk about. But

fundamentally if they if you or your developers didn't put in enough effort to know that the system works properly, it doesn't work properly. There is 0% chance. So keep this in mind. Another interesting idea that that I keep changing my my thoughts on but currently is to think of AI as a brainstorming tool. AI is an incredibly good tool for the end user because it does all the work. And if the bug is valid, it's done. So it's beautiful when it works. But if when it when it doesn't work, it's basically you know worse than slither. And I hope some of you resonate with that because it's basically just a pile of stuff that was looked at that contains mistakes and that is not

particularly actionable. And so the way I like to use AI is very different. Is when I'm done in my review, when I have no thoughts left, when when I like all the options are explored, that's when I need the insane hallucinations of the AI to give me new ideas because that's a great way for you to just be a bit more imaginative. Something I learned, I think it's a interview question from a hedge fund or maybe it was Einstein. I don't remember exactly, but basically there was this interview question where they would give you a theorem like some math and then they will tell you what if this constraint of like of physics was no longer there and you would actually

find that the smartest people would start to kind of think of new ways and that's the same thing you can do with code where you can basically eliminate a constraint and from there you can you you will basically find new bugs and then your only problem is to find a bypass to that one constraint which is a pretty cool way to find very unique bugs. Another key concept tied to thinking in bats is working with progressive escalation which is the idea that you you should do the least work that is necessary to break a system. So if you can do it by reading the code and you find a bug, great. Write the POC, be

done with it. If you need to write it on paper, talk to Claude to figure out the math, go ahead and do that. If you need to fuzz it, go ahead and do that. If you need to formally verify the entire system before you can find the bug, do that. However, we have we have limited in our time and we have to think in bats. As such, we want to work with progressive escalation. So you if you're if you have more tools, you want to create your own internal ranking of complexity and effort and you want to decide when to apply each with the full understanding that the only way to be 100% certain or at least to be 100% done in your process will be to actually do

everything in all cases, but that's obviously impossible. So keep in mind that you don't have to do all of the work. You can find the easiest way to get to a bug and then be done. Um And a a really cool idea of on being average is that if you are an average security researcher your life and your pay like your pay I guess your income is going to be much higher than if you are the average I don't know bricklayer or taxi driver.

And so understanding the meaning of being average really means that you want to look at your peers. You want to find peers that inspire you or peers that have let's say the lifestyle that you want and you can be an average researcher at that level and you're still going to have a really successful life. So don't worry if you're not you know, the number one on the leaderboard. I know I wish I was. Obviously everybody wishes they were you know, winning everything, but understand that being average doesn't mean it doesn't actually suck that much. So try to get to average, then find your base and hopefully one day we'll see you at the top of the leaderboard as well.

So another really cool insight from from this year is that you can very cheaply and very quickly formally verify stateless libraries and extract constraints. So this is very technical, but it fundamentally means that you can write a couple of tests. You can use the Certora prover. You can use Alma or control. We use them all and we like them all, but basically you can take some logic from a system, put it in a library that has zero state and that basically means that these tools will very quickly prove a bunch of stuff. They will prove whether the math is sound and you can likely also quickly optimize the bounds and basically gets a bunch of maximum and minimums from it

which means that once you're done with that, you can simplify the system in your head and you no longer have to even look at all of that code. So this is something we advise to all developers we work with is just put all of the nasty logic in a stateless library, remove the state so that we can formally verify it even if it's massively complex and it's really easy to do. Um but at the same time there are no easy paths, I guess. You just have to get better. This is something that I learned and you can look at my audit report from Liquity V2 from Bold, but something that I learned is um you you have to rise to the type of challenges that you're faced.

And so if you for example are unable to exploit I don't know rounding errors, you're unable to work with certain codebases, it's an indicator that you that there's no easy path. You just have to improve on that. And most of the times that comes from an extended amount of time in which you focus and then it comes from putting a lot of effort into it. So what I can say from my experience though is that anytime I do something intellectually hard, I think my brain permanently permanently changes. So I think that type of learning is something that you want to give to yourself and it's something that sticks there. So my advice is really when you're faced with something difficult

keep at it because it it's not going to get easier, but you're going to get better and that those benefits stay forever. So understanding when to clamp and when not to is that an idea that sometimes you can just simplify the system, just quickly put some numbers in the system and it's likely going to represent all the all the cases. So there are many many times in which you can be very greedy with simplifying code or simplifying the system as you think about it and you basically explore all the meaningful combinations anyway. So most of the times you don't have to overcomplicate your thinking on on on some code.

Another idea to instead create a ton of work for you is to rewrite the code and compare notes. So you would read let's say a vault you would read like some sort of system and then you read all the documentation. You're like, okay, I fully understand it and then from there you would basically rewrite it and in rewriting it you would identify issues in thinking that the developer may have and the other thing you'll find is if you could have written in a much cleaner much more elegant way. Both of these it lead you to bugs and lead you to also being a better researcher in general.

And a pretty pretty interesting idea is that peak experiences are like a wave. So you will likely find some amazing bug, but it will come at a price and so you don't want to ask yourself to always be at the top. You can't always be on the top of your game. You want instead prepare for the peak experience. You want to enjoy. You want to ride the wave, but then you also want to take time to rest. And you you really want to embrace this idea. If you look at great entrepreneurs, they have a bunch of money. They rest until they find a great idea and that's when they go all in. There's really no point in being all in all the time if you if it's not worth it. So instead try and find the the wave that you want to ride and then hold on to that for dear life.

Um Similar idea, most contest winners have a brutal track record. I really respect Zik Tour, but at the same time if you look at his Cantina page, you will see that there's the valley of death of $0, $100, $1,000 results and that's where most people quit. And so keep in mind that to get to that peak experience, there was a lot of effort and there was a lot of it basically created his own opportunity to have those peak experiences and it's easy to just look at that but to forget what what it actually took which is I think it was extremely brutal track record. There's totally random, but there's really no

rushing writing a report or a POC. Just write it slowly over time and make sure it's simple and it's clear. Don't use you know, any tricks there. Just write it slowly until somebody else can understand it. In a similar note, it's always a serious deal or just don't bother. Don't half ass your reports. Don't half ass your bounties. Don't send the low quality low low effort bug because you don't want to put in more work. Either do it really well or don't bother because people will find a way not to pay you. So you may as well you may as well just do it well.

And start with the end in mind which is really the idea that if you're finding bugs and you're writing reports start early in in doing that in setting yourself up for success. You don't have to have this separate phase etc. You can instead think about what your end goal is and you progressively get to it instead of separating into very harsh steps. I'm going to very quickly finish my points. Try always read code and when you can't read the code anymore, that's when you try something else. That's when I would start developing only when I'm really tired. And you really don't understand how hard it is to actually review code at the highest level. Find the best person you can, work with them for a day. It will change your life.

I know it works from experience. If you're done before an audit, it means you're not even trying. Nobody's ever done in an audit. If you're done, it means you're literally not even playing the same game. Understand your edge and use it to your advantage is the idea that you want to over time build a deep set of knowledge on a specific set of protocols and you want to push that as much as you can. Or if you have a unique bug or if you have any unique technique, push really hard. There really is no overnight success. It's really the work catching up to you because of the efforts.

And you just want to really repeat those basic foundational steps consistently. Uh my favorite thing is to find people I really respect and learn from them whether by hanging out or just looking at the research. There's a ton of very very brilliant people here, really inspiring people, and you just have to find them and uh model them. Uh and then forge your own path. Um fundamentally um there is no right or wrong way. You have to live with the consequences of your decision, so just forge your own path.

Learn from reading common bugs, but then create your own category-defining bugs. Resting is work, which means that as I said, you want to give time to yourself to grow, and the growth happens in resting, just like in the gym. Uh be careful about your own biases because you will eventually start missing the same type of bug, so you have to self-correct, and the only constant is you. So, believe in yourself, uh keep going, and let me give it up for uh Rajeev next.

>> [applause] >> Thank you, Alex. Uh it's really good to be hard to you know, be the last one, especially after my distinguished colleagues. So, um yeah, I mean these are if you notice, you see the tip numbers at the bottom. So, we really tried to squeeze in 101 tips for 101. Um so, it's going to be really really fast. I think each of these steps we could probably talk you know, we can have like a 30-minute chat about it. And uh like both of them have said, these are subjective opinions. You'll see that some of them overlap, some of them may contradict. So, that's part of the fun.

So, anyway, so I'm I'm Rajeev. Um Um I'm a security researcher. Uh these days I do uh mostly collaborative reviews at Cantina, which is one of the smart contract auditing platforms. So, the first one, right? I mean here we are talking about the basics. This is as simple as it looks. We have said it in many different ways, all these various things, but ultimately auditing is about reading code. Developers write code, we read code. And I mean you you see these takes on Twitter that oh yeah, reading code, it's just so simple. So, that's not how it is, it's so much more complicated, obviously, right? I mean this is a meme, right? But behind this, it's about how

do you efficiently understand the code? How do you understand the logic? You know, first you understand it, and then you break it, you do it iteratively, all that good stuff. But ultimately, auditing smart contract security auditing is really about reading code, right? Again, basics. Um Everything that we are talking about really boils down to three things. Assets, without which we won't have, you know, actors or actions. And because we have assets, we have actors. Actors we we may call them as users or anything else, but it's really actors.

And then actors decide to do something with the assets, which is really the actions, right? So, you go back to the beginning of computer science, uh you see various access control matrices. It's really about subject and objects, and you know, can you read it? Can you write it? Can you execute it? That's really what we are talking about. So, again, we are oversimplifying things, but that's the point of this. And uh how do you start doing all this, right? So, we uh when we say read code, that's great, but then we uh also I mean, code is let's say in this case, for example, written in Solidity or some of the other um smart contract languages.

You can read some documentation, and most protocol well, most protocols have documentation right? But ultimately, we want to be able to have a spec, a specification, a formal specification. I think some of the leading protocols have it today. Um but that's sort of the end goal we want to get to, right? That every protocol really has a spec, starts with a spec, has the documentation, and then really starts uh coding, right? So, if you have all these three, then that's like a fantastic start for uh for smart contract auditing.

This is uh I think this is a critical thing that's been brought up multiple times. As auditors, we tend to see things well, we we read code, right? So, we see the things that are present, but ultimately, we need to see the things that are absent. Right? So, these could be absent checks, these could be absent uh uh conditions. So, that is the tricky part, right? What is missing here? The what if that Jocelyn talked about, right? So, that is really critical. So, obviously when you start out, you're seeing you're looking at the code, so you know, our head our brains tend to work in certain ways, so you start spotting mistakes, but then we need to zoom out, and then think about

okay, this is all there, but what's missing? What should be there, right? So, that that's critical. And if there is um yeah, one thing again, similar to what if, challenge everything, right? As auditors. Uh I had I I missed uh having a a meme diagram here, but if if they say 1 + 1 is 2, you need to challenge that, right? That that's just a meme, but really question everything that you see, and and when I say when we say question, it doesn't mean that you need to ask them ask the developers, question it in your head, right? Does it make sense? What are the assumptions being made in this line of code or in this module or in

this contract? Uh is it correct? Is it not? So, that is uh that is really the adversarial mindset we are talking about, right? So, challenge everything. >> [snorts] >> Um so, as many of the tips that we are talking about, they sort of uh cross between contest smart contract, you know, auditing contests, uh collaborative audits, and bug bounties. Um That's that's good. Um so, when it comes to auditing, specifically the way we understand auditing today, these days, there are uh competitive audits or contests, different names these days, which is a great place for uh beginners

to start, right? Um well, it's it's brutal, as Alex put it, it's tough, but it it's compared to the rest of the world, I mean, let's say web two, here you actually get paid to learn, right? It's time-bound, you do a contest, you submit your findings, and then very soon, you know, hopefully in a in a in a week or so, uh you see the results, you see what you missed, you see well, if you didn't miss it, you get rewarded for it, you see what you missed, you learn from it. I mean, this is really the fastest feedback loop that I have seen in my 25 years of security research, right? So,

there's no better way today uh to start with um uh to start learning than uh contest. But obviously, to to I mean, you I can't just wake up tomorrow and say I'm going to start doing contest, right? So, you need to understand the language, you need to understand what the protocol is about, so there is definitely a bit of learning. So, the various resources that Jocelyn shared, great places to start. Collaborative audits are different, and if you're not familiar with the term, what it means is that you have a bunch of researchers, maybe two or three, some senior, some junior, they're put together by uh the platform, let's say Cantina or Sherlock or anyone else or Tora, right? So, a team gets formed, or

even in you know, of uh private audit firms as well, right? Um team gets formed, they get assigned on a particular protocol for a particular duration, and the idea is for that team to collaborate. Right? And what we mean by that is that it's not like if there are two people assigned, that they need to work in silos, right? Uh there are there are some platforms that also do that, but in general, the idea is that the sum should be greater than the parts, right? So, if you're two people, then in a collaborative audit, the output should be better than me and Alex working separately. So, if we we the three of us

are on a collaborative audit, then hopefully it'll be much better than having just each one of us do it separately right? And how do we do that? So, I think I'm going to focus a lot of my next uh top uh tips on the collaborative part. And what we mean by collaborate here is collaborate with between among the security researchers, and also collaborate with the project. And what what do we mean by that, right? So, in many platforms, uh auditing platforms, you can actually have there's there's like a comms channel with the project, right? So, you have uh Discord or Slack or whatever it is where the

developers are also there, and this is really a collaborative thing that they're also part of. It's not like they say, "Hey, here's here's the code, two weeks, and then at the end of two weeks, uh the researchers have discussed among themselves, and then they present uh all the findings, right? I mean, that that happens, there is value in that, but I think there's much greater value if the protocol if the developers can also engage or also deeply engaged during the audit because um not everything is documented, We may have questions. We may have like "Hey, this looks like an issue. Is it really a bug or is it a vulnerability and so on,

right?" So, collaboration is really, really key. And how do we make that happen? Really communication. I mean, if there is one thing so we've they've shared a lot of technical tips. If there is a non-technical tip that I strongly believe that we need to do better as a community, I think it's communication. Right? There's just so much lost in communication before the audit, during the audit, after the audit, all these gaps, which leads to a lot of issues.

So communicate with yourself, right? Think, challenge, do all that. Communicate with the other security researchers on your team. Discuss, share [snorts] the resources. Don't just you know, we shouldn't just go away, lock ourselves, and sort of think, and only communicate when we have a real valid issue, right? That's good. But I think there's much more that can be achieved by constant frequent communication. Obviously, there is a line to be drawn. You don't want to be annoying and sort of keep pinging all the time. You want to have that focus that uh Alex talked about.

But figure out where that line is and keep communicating. And the other one is really communicating with the protocol, right? Ask because we are far from the time when everything is specked out and everything is super obvious. If we do not understand something, something critical, think, ask your colleagues, and if we can't agree, then ask the protocol. And that, I mean, personally for me, we have found so many issues or non-issues because of that communication channel. So, comms super critical.

Just to sort of summarize, right? So, discover, and this is really sort of in in my head when I'm looking at stuff, trying to discover issues, potential issues. Discuss with your colleagues and challenge everything, right? So, debate. Have a respectful debate amongst your security amongst your team, and definitely with the protocol. And depending on the protocol, they may you know, they may challenge some of the findings or the severity of the findings, which is good. Healthy debate is really good. I mean, that's what security is about.

Right? So, challenge everything, and this is really sort of part of the discovery process. And why should we do this? This is uh really what builds trust. Right? For the protocol, if we communicate with them with potential issues, potential concerns, then they one, they see the sort of our thinking process. And it gives them more confidence that okay, they're going in the right direction.

And if not, they can sort of help us go in the right directions. Um And yeah, same thing among the security researchers as well, right? And this is sort of uh a challenge in the web3 security space. Um unfortunately, I think we are stuck with the term bug in this space. I mean, if you look at the history of bugs in computer science right? The the first moth that was there on I forget uh um the mark processor, whatever, 50 years ago. So, that's when it got termed a bug. I mean, bug is generally synonymous with something that is annoying, right? Like, "Don't bug me," right? But in this case, we are talking

about bugs. Uh we well, we're really talking about vulnerabilities that uh cost us cost the space hundreds of millions of dollars, the reputation. I mean, the whole of crypto, if you look at somebody outside the space who's not aware of crypto, the first thing that they are aware of is how much money, you know, can somebody make in crypto or all the scams going on, right? And which includes the hacks. So, I think we have a responsibility to be really serious about this and not sort of treat everything as a quote-unquote bug.

But as security researchers, we need to understand the difference between these three things, right? Anomaly, something that is not normal is anomalous in the code in the good behavior. Um and some of those can be issues, right? Some of those can be bugs in the sense that they are um you know, they they they deviate from the normal, they're not expected, they're unexpected behavior. But does that really lead to a loss of funds or lock of funds, right?

So, that that kind of you know, if you want to say serious issue or a serious bug is a vulnerability. So, if you go back to the web2 space, most references there are to vulnerabilities, right? In in the technical literature. So, we need to get more rigorous about sort of terminology in this space. For the last 5-10 years, we've been sort of loosely using these terms. Um the other one is impact likelihood severity, right? So, for those of you in this space, this is very common. Every issue you know, becomes an issue because there is an impact of loss or lock of funds and other related things.

Um likelihood. I think this is the trickiest part, which plays a big role in at least bug bounties, is what is the probability of this vulnerability being exploited to cause this impact, right? Is it a very low probability, medium, high? I mean, we don't have a good way to quantify this yet. So, we sort of have taken the easy path and said low, medium, high, and then we have a severity matrix based on that. I think there can be a lot of lot of work that we can do better with likelihood.

>> [snorts] >> Uh this is an interesting thing, right? I forget who came up with this, but hunting and gathering. Um Hunting for bugs and gathering for bugs. So, the notion is that hunting is really finding that deep, complex, maybe high severity vulnerabilities, right? And gathering is sort of maybe at a shallower level, looking for let's say the lows and mediums just to make it easier for discuss, right?

So, there is this notion that oh, hunting is really as you get more senior as a security researcher, I should just be focusing on hunting, only finding the criticals, and not really bother about anything else because you know, that's that's sort of below my whatever, right? Um but I I disagree. I think both are important because when you look at the attack it's called surface area, right? And surface area, if you let's say it's a two-dimensional thing, it's a depth and breadth.

So, if you think of this rectangle as the attack surface area, and if I focus only on this particular depth, and I'm going to miss out on all these, you know, all the other part of the attack surface area, which I would not have gotten into if I know if I do not focus on the breadth, right? So, breadth or the gathering part is equally important. And what we may think of as something that is shallow may actually be you know, not as shallow if it is combined with other things, if you're wrong about the probabilities and so many other things. So, coverage is critical.

Um the other thing that I've seen with the security researchers is competency is fantastic. I mean, we need to we need to be super competent. Um but where I do not see that happening is with consistency right? I mean, this we are dealing with really mission-critical code here. We should be treating it with that respect. Right? And we are trying to build sort of the next financial internet and you know, civilizational infrastructure, whatever, future of finance, whatever your thing is.

So, you we need to be super consistent. Right? Every day, every audit has to have the same level of rigor, same level of um attention, and there is no room literally no room for error, right? I mean, that's that's how critical it is. Um this I won't go I mean, this is I talked about this breadth first. So, okay, now talking about how do we how do we start doing this in that rigorous way, right? So, some people like to do it in a breadth first way.

Jocelyn talked about sort of looking at all the low things first and then going deeper into the complex things. Some people like to sort of do it in more modular way. They like to sort of focus on certain components, maybe the central orchestrator as Jocelyn called it. Want to look at that really well, and then look at other things. Um one way to do it again, another way of thinking about it is to do it in a very definitive way and then move on to other things, or do it in a iterative way, right? So, do it once and then come back again. I think our brains really work iteratively, although we may not um, fully understand it yet.

So, there is, uh, capability which is, uh, table stakes. I mean, all of us have to be super capable to be, uh, to be reviewing and sort of, uh, uh, bearing the responsibility for this, uh, uh, code base, for all the protocols. So, responsibility is a huge deal. Goes back to the ethics thing that, uh, Jocelyn talks about. This is an interesting thing. When you do collaborative there is this notion of diffused responsibility, right? So, if I'm a single researcher, I know that, oh my god, if something goes wrong, I'm the one to blame. But, if you have multiple people in the group, what I have noticed is that, you know, people may tend to think that, hey,

okay, so, we are three of us, so, uh, even if I miss something, maybe the other person will catch, or if I don't see this, maybe the other person will, uh, look at it. So, that is, that is, uh, a challenge, right? Uh, that that has to be taken seriously. So, diffuse responsibility, um, is is not good. So, we need to be super careful about it. The other thing that, um, want to bring up is clarity, right? Uh, Jocelyn talked about it in terms of, uh, the soft skills.

Clarity in comms, in communications is super critical, but even clarity in understanding the code base and being able to reason with it is really, really important. And obviously the criticality part, right? That if you're not clear, then if it just means that we really didn't understand, uh, what the protocol is doing, so you can't really, um, uh, get into sort of the critical parts of where things may break. I'm going to speed up. I think, uh, yeah. So, um, let's see. Checking, validating, um, basically pace pace yourself between reading, reviewing, and reporting.

Because it's a time-bound process. Uh, bugs can be found, but, you know, ultimately it is a time-bound thing. Fixed reviews have to be, uh, we're talking about audit reviews, but fixed reviews are super critical. Uh, Alex brought this up. Uh, I think we can do a much better job here because, uh, there could be some cracks in this. Context switching, not a good, uh, happens, but not really good. Uh, focus, like others have talked about it.

This is, this seems to keep coming up, right? Whether should we combine the issues or should we not combine the issues? I think it is sort of synthetic, um but um it has some implications for, uh, the protocol, for reporting, for other things as well. So, a lot of guidelines, but it's a time-bound thing. There are fine lines that we need to sort of make a subjective call. For protocols, code freeze is critical before an audit. Be very clear what the scope of the audit is, what is out of scope. And if that keeps changing, it's it's not a good sign. Uh, so, we need to be super careful about it. Lot of, uh, exploits uh, have happened because of this.

Um, let's see. Yeah, comms very critical. Fix. Uh, this is for the protocols, right? Correct. Correct us if it is not an issue, confirm an issue, fix it, acknowledge it, and we need to make sure we capture all the right things. Ultimately uh again, this is worth repeating. Audits are not a silver bullet, right? This, I mean, this unfortunately comes up. Anything, any exploit, they're like, oh, but it had an audit. It has five audits.

It has 10 audits, right? They are not a silver bullet. We need to really move safely. We are building a lot of critical infrastructure. There's a lot of trust being placed on, uh, on this. We need to make sure that we break nothing. Ultimately, ignore all these 101 tips, tools, and techniques. Figure out what works for you best. Figure out how you want to, you know, how you want to read the code and make it safer. Thank you. >> [applause] >> Okay.

Hello. Yeah, thank you very much, Rajiv, and, Alex, and Jocelyn. We don't have time for question, but, uh, we will try to prepare uh uh um, a media where you can ask questions. Uh, the next speakers that we have is, uh, uh, where's Pablo, actually? He's somewhere here. Okay, he's coming. Pablo and Luis. So, we started this morning and we