📖WALL OF WISDOM

"Know When to Move On"

When reviewing a codebase, it's important to recognize when it's time to stop exploring and move on to the next one. If a certain amount of time passes without discovering any new leads or rabbit holes to jump into, it might be

"Go Hard or Go Home"

The more complex a project is, the greater the chances you'll find bugs in it. Don't spend too much time on simple codebases. Focus on protocols that implement intricate algorithms or have convoluted code flows—these are often closer to yielding your next Crit.

"Don't Be Afraid of the Unknown"

You don't need to be an expert in a language or technology to find bugs in it. Getting up to speed on something new might take less time than you expect. Explore niche technologies and emerging languages; sometimes, hidden gems can be found there.

"Think in properties"

Whenever you see any behavior in code, try to think what properties it is trying to enforce and what properties you'd imagine the code should have that it would break. For example, think in invariants: what should always be true about the contract?

"Ask yourself what's missing"

Checking that some code does what it should is usually relatively easy. It's easy to notice what's wrong, but it's difficult to notice what's missing. Always consider whether any other action should be executed or a check done.

"Audit restrictions"

In some reviews you'll do, you will find a lot of bugs and your client's fixes will be so huge, that it will require you to do a multiple of the work of the audit. Make sure you set the timeline for receiving fixes and that there is an upper limitation on how large the fix diff is. If any requirement is not fulfilled, the review requires a renegotiation. But don't be too strict about it.

"A-, Arch-, Architecture!"

Architecture is the most important thing about the codebase. If the developers thought about it enough, the codebase would be minimal. There will be few places to introduce bugs. If the contracts are large, it usually means that the architecture wasn't well done and it can pay off to look from the higher level: what is wrong with the current design?

"Keep pushing after thinking you have found everything"

After some time, you get a good gut feeling for when to stop. This is a reminder to keep pushing even after that feeling still, once in a while

"Get as many views of the code as possible"

(history, coverage, run tests), a contract is never unidimensional The goal of a security review is to get insights overlooked by the developer. Reading the code directly is the most obvious way to do it but is also the way the developer thinks about the code.

"Use the power of comparison, whether inside of a contract, or comparing a protocol design to a similar one"

Even without understanding the purpose of a piece of code, if we know that two different implementations are supposed to do the same thing, we can check for inconsistencies. Also as SRs we see a lot of different implementations for a similar projects so that is an advantage

"Go slow"

Slower than you feel you need. Slower is better, better is faster.

In auditing, slower also means you'll have observations, questions, and ideas that others reviewers didn't let themselves the time to have - and find missed bugs.

"Clusters of understanding first"

Understanding the code thoroughly is 90% of the work and the results.

The other 90% (the creative work) depends on the first part fully. Yes, 90-90 applies to auditing as well.

Clusters: try to find the natural division into logical components, or "clusters" of understanding.

"Go deep"

The better bugs are in the end of the review (or after), if limited in time, focus on fewer areas, but ensure depth.

"Most deals are bad deals"

Learn to say no to FOMO! Most bounties are marketing scams, most contests aren't worth the time and effort. Crypto has plenty of bad, greedy, scammy actors, and crypto-security is not an exception to this. Expect and adapt.

"Motivation is hard, learn yourself:"

Expect the first few days on a new codebase to be confused and struggle. Choose easier tasks to break the motivation barrier. Escalations and bounty negotiations are distracting and soul-draining, aim to have fewer by choosing better bounties, platforms, and projects.

"Choose Your Target Wisely"

It doesn't matter how fancy the bug is—if the project you chose doesn't pay you, nothing matters. Choose wisely where you want to put your effort.

"Don't get tempted by code that smells bad"

It's tempting to pick an easy target with "code smell" because it has a higher chance of being vulnerable. However, remember that such projects might not take security seriously.

"Checklist on picking BB targets"

• They project pays in stablecoin or hard assets (ETH, BTC)

• If they pay with their own token, make sure they have enough liquidity

• They are active—you're likely to be ghosted on inactive projects

  • Check their Discord, X (formerly Twitter), or other social platforms

  • Check their GitHub

"Don't Fear the Complexity"

Complexity goes both ways: if it's complex for you, it's also complex for developers. Complexity often leads to mistakes, and mistakes lead to bugs.

"Don't Skip the Fundamentals, Fill Your Knowledge Gaps"

While it's partly true that you can earn in this space knowing only Solidity, you might not be able to improve without understanding how blockchain works, how EVM operates, or even how Solidity is compiled to bytecodes. Expand your repertoire to other languages.

"Don't rely on luck"

Bridge your knowledge gaps. You can't expect to compete with knowledgeable security researchers if you couldn’t match their level of expertise. Luck plays a role in winning, but don't let it be your only factor of winning.

"Persistence is Key!"

What you see on the surface of this space is people's success—you don't see failed attempts. Stories of successful white hats often sound like they came from nothing, but that's unrealistic. Everyone faces hardships before becoming successful.

What they have in common though is persistence! They keep going, they keep doing, and that's what actually makes them distinctly successful.

"Persistence is key... but madness is not."

Don't forget to take a break.

What I also observe in this space is an excess of positivity. The value of your work is often equated with the time and effort you put into it.

It might sound cool to always be working on a target, spending countless nights looking for a bug. However, that's not healthy.

Don't fall into this trap and pressure. Everybody needs breaks. Remember, you'll only get the best results when you're well-rested.

"Go for the kill"

For time efficiency while hunting, concentrate on critical paths and assets, while leaving aside secondary assets. Understand the risk model of the project to decide where to focus. This will help you find the right attack vectors.

"Turn copper into gold:"

Often the impact of a bug is not immediately identified. Make sure to understand the project in detail before submitting a report. With the right context, or combining the bug found with another bug, the severity level could be raised. Always double check to make sure you are not underestimating a bug's impact, and tune the PoC for maximum impact.

"Multiply the effect of your efforts"

Sometimes you'll find a bug that is general enough that it could exist on other projects. Check all other similar projects where you could find it as well. Look through BBPs, repos, onchain contracts. While doing this, think of the possible variants of the bug as well. With some luck you could capitalize on the original bug and get some extra rewards.

"Smart contract is a state machine"

To understand it fully you need to master state variables and know the contract's state machine by heart

"Code on your computer is your playground"

Create branches, experiment with the code, modify it, write comments and see where it leads you.

"The best bugs are where no one looks"

Each time challenge your approach to auditing. Do you look where everyone looks? Do you skip hard parts that others will likely skip? What is that you can do differently that will set you apart from others?

"Productivity is about energy management rather than time management"

As knowledge workers, our most important resource is focus.

There is no point putting in more hours when your brain is tired. That time is better spent resting.

Productivity shoots up after resting. It’s easier to parse code and learn new concepts than when your brain is tired

"The larger the audit scope and the more complicated the protocol, the more critical your notes will be."

Note-taking is a skill that also needs to be developed to be great at auditing.

Personally, I prefer handwritten notes as my “compressed knowledge” of the codebase.

It is written as a quick reference for me. There are no huge blocks of text. It is a collection of terms, concepts, flows, and their relationships.

"There are always more bugs"

No such thing as “safe code”, no matter how many auditors looked at it

"Debug"

Don’t underestimate the importance of a working debug setup

"Connect the dots"

Remember all the little oddities and issues that weren’t bugs, eventually they’ll be useful for something larger

"Choose what is interesting to you"

In competitions, choose protocols that seem fun or interesting to you for the best results.

"Complexity is your ally"

Generally, the more complex the project or language, the less competition you'll face.

"Understand code deeply"

The best way to succeed is to understand a codebase deeply. Focus on comprehension first; bugs will reveal themselves naturally as you go.

"Push until the end"

Most interesting or unique bugs are usually found in the final days of an audit, so stay focused and keep trying until the end.

"Look one more time"

Some of my most interesting bugs have come from times where I've exhausted all my hypotheses and am about to give up.

But I decide to look at something one more time and a bug jumps out at me.

"Diversify but also play to your strengths"

Some people are just going to be better than you at finding certain types of bugs.

Understand your weaknesses and try to improve, but equally don't discard what you're good at, sometimes it pays to play to your strengths.

"Focus on the important bugs"

Don't waste time on low/informational severity bugs.

There are bigger fish to fry, taking the time to write up reports for low severity bugs isn't a good use of your time when you could instead be finding the more impactful bugs.

"Understand well what the code is supposed to do"

For me, one key aspect of finding tricky bugs is getting a very good understanding of what the code is supposed to do on a higher level by reading the documentation. Once I have that, I can start at an important part of the code and jump through the codebase following the flow of logic instead of going over a single file line by line.

"Analyze reports of code you have context about"

The best way to continue learning is to look at all the confirmed findings I missed, after a contest.

I don't like going over old reports where I did not compete since I don't have the context of that codebase.

If I review findings from codebases I spent a lot of time on, I can more easily identify why I missed a certain issue and learn from that.

"Take care of yourself"

What I also realized, is that treating myself as well as possible in life translates to better results in contests.

When I am not stressed and feel good physically, that directly impacts my auditing performance. Working out also helps a lot with mental clarity

"Audited codebases"

Regarding bug bounties, almost all codebases have been previously audited, often by leading security firms.

Don’t let that fool you into thinking they are bug-free. Some of my biggest bounties have been in projects that have been audited extensively and yet still were vulnerable.

Approach each codebase as if it came fresh from the developers.

"Be prepared to negotiate"

Identifying a bug, writing up a PoC, and reporting it is only the first half.

The second half commonly involves quite a bit of discussion and negotiation.

Learn how to express complex technical situations, how to present a well-founded case, and how to professionally negotiate.

"When to stop searching"

At which point do you stop searching a codebase for bugs?

Try to understand the system to the point where you could reimplement it from scratch without looking at the original codebase. Not from remembering the code, but from having understood what the application is supposed to do.

If you have examined a project that far and have not found a bug, the chances of finding one by continuing is low. On the other hand, if there was a bug in there, you would have most likely found it.

"How to improve your skills"

Theoretical knowledge is important, but nothing trumps practical experience.

Develop your own projects and observe areas of security concern, participate in CTFs, and build PoCs for past exploits.

"Focus is your best ally. Make sure you know how to work well with it"

What sets the best researchers apart from the average ones is their ability to focus and the time they spend in a deeply concentrated state.

Human focus is like a car's fuel tank—you need to know when it needs refilling and how to use it efficiently when it's full.

Self-reflection can help you understand the conditions under which you perform at your best. Use that understanding to improve consistently and effectively.

"Don't stop until you have achieved your goal"

If your goal is to uncover a high-severity bug in the X codebase and you're committed to it, your focus will naturally guide you toward success.

Approach it with the mindset of a warrior—relentless and determined—and don't give up until you're certain you've explored every possible angle to achieve your goal.

"Breaking Versus Understanding"

Focus on breaking the codebase rather than understanding it. Many bugs are slight logical inconsistencies that don’t even require understanding the whole picture.

Many times focusing too much on the bigger picture will yield some high-level, economical attacks but might miss out on function-specific edge cases.

"Don't Run in Circles"

It’s very common for auditors to keep on checking the same scenarios.

If you're doing this, just remind yourself that this is a form of procrastination, and the only added value is in checking those 1% complex scenarios that are hard to grasp.

"Inspire Yourself"

Go over all the bugs that are found in similar protocols on Solodit to direct your thinking and get ideas flowing.

It is the hardest to find any bugs when you don't know what you're looking for.

"Use AI"

Use AI tools to speed up the understanding of the codebase and to generate ideas.

If you don’t have a co-auditor on a project AI can be extremely useful. Just don’t expect it to give you accurate answers every time, it’s only a tool and it’s up to you to make sense of its suggestions.

"Have faith that you’ll find bugs"

The number one thing you need to succeed at hunting bugs, for bounties or contests, is having faith that you’ll find bugs.

Statistically every code base will have bugs, but that’s not how it feels when you haven’t found one in a long time.

Find out what gets you excited and hopeful, and nurture it. Consistent effort beats pretty much everything else in predicting success.

"Try to learn hard things"

Try to learn hard things. Don’t limit yourself to the low-hanging fruit. If you learn something that most people don’t know you’ll find bugs most people miss. That can be a weird detail of the EVM or an entire field like ZK proofs. Keep pushing the boundaries of your knowledge, and collecting information on different things.

"Expect unexpected results"

After a certain skill level pretty much anyone could find most bugs — but how do you know what targets to focus on? And for how long?

That’s the hardest part of hunting bugs, and more art than science. You might find a gold mine of bugs and report 10 in a single week, then not find any in multiple targets for months.

That’s normal. It sucks, but is normal. Try to learn with your hits and misses but don’t stress over it — it’s always unpredictable to some extent.

"Learn to negotiate"

Bounty negotiations are hard — and often heartbreaking. Don’t just let projects lowball your bounties, but also keep your focus on the next one. Don’t let the anxiety of the process take your time and energy away from your bug hunting.

"Know everything about your target"

I like to start with code, others focus first on documentation: use both resources extensively. But that is still just the basics, you should go the extra mile.

Pro tip: watch the target’s GitHub activity.

"Look twice before looking again"

Even if you have high confidence on a certain function/part of the code, give it one more look, it always pays off

"The most complicated bugs are the simplest"

Sometimes we have the urge to try to come up with very complicated/weird edge-cases forgetting to approach everyone from first principle approach

"Do not overdo your issues"

I've seen an urge on various occasions where researchers like to overwork their issues which might cause the client to lose the meaning of the issue.

Keep it simple, do not forget, your goal is to help the client secure their code

"web3 is a world of white box testing"

This changes a lot - not only about the approach to searching things, but also about what can be considered a vulnerability. For HTTP API you will need to prove that you can access admin dashboard. In web3, you need to explicitly show what you can do when you are this admin - because if worst thing you can do is start a proposal without paying fees, it will not be a high impact bug. White box gives observability, and simulation gives ability to prove things - and this means that meaning of “bug” changes from “something risky” to “something really harmful”

"Stop following the known path"

There is a certain moment when you should stop following the known path.

“Hacking” is about thinking differently, looking from different perspective - at least not thinking like the developer of this contract, at most thinking not like anyone else at all.

This does not mean you should not study findings of others or read new things - but you should grow your own unique approach.

Try different ideas, mix them, combine, experiment with new things. Only way to find something everyone else didn’t notice is look at it like no one else did before

"Do not limit yourself"

Do not limit yourself with severity or specific area.

Sometimes it is easier to find a crit than low.

Just don’t limit yourself

"You can just do things"

No matter how much you want to read docs or listen to somebody else teach, fucking around and finding out is always best.

"Do what seems most fun to you"

Burnout is real, if you have to force yourself to a path, it's not going to be sustainable.

"Time is your most valuable resource"

Spend it well. Observe the meta. Having a decent understanding of your skills compared to others allows you to spend your time where it's least -ev for you.

"Consider Sources and Sinks"

Source: a point in code where an attacker supplied input enters the execution flow. Sink: a point in code where malicious state change can occur. Map the program for all Sources and trace the execution flow to determine which of them provide a path where a Sink can be reached. What safeguards are present and what would be required to bypass them? Respectively, map the program for all Sinks and retrace the steps required to reach them to identify relevant Sources. Is it possible to craft a valid transaction to reach the Sink from the Source?

"Collaboration"

Joining forces has been one of my best decisions since I started auditing. The benefits of collaboration are significant:

• Enhanced Findings: Working with partners has raised the quality and quantity of our findings. We combine our ideas, transforming them into a fully developed issue. One sophisticated discovery resulted from merging two ideas:

  • My partner’s insight: "If we disrupt the list order, we could then employ strategy Y to potentially cause users to lose funds."

  • My idea: "Implementing strategy X might let us break the list order."

"Learn by sharing"

By sharing ideas, I also get the chance to understand different perspectives, which is one of the most valuable aspects of working with a partner.

"Taking Breaks"

Taking breaks during audits is essential for me. A quick reset in the middle of a project refreshes the mind, making it easier to approach the contract from a new angle and often sparking ideas that weren’t apparent before.

"Using a Checklist"

A critical lesson I learned in auditing is to maintain a personal checklist for each category. Until every box on the checklist is ticked, the audit isn’t complete. In the past, missing a simple access control check cost me a critical finding and, ultimately, the top spot.

"The Programming Language is Not a Blocker"

Understanding the application logic and being able to read a bit of the specific programming language is sufficient for finding bugs;

Expertise in that language is not mandatory.

You don’t need to stick exclusively to Solidity to hunt for bugs.

Although I lack expertise outside of Solidity, I've successfully reported bugs in Vyper, Rust, Cairo, Move, and other languages.

"Consider the Dilution Effect When Describing Bug Impact"

When evaluating the impact of a bug, keep the Dilution Effect in mind.

Suppose you identify two possible impacts of an exploit: one with high impact and the other with low.

As a bounty hunter, you may feel inclined to mention both, but this can backfire.

The weaker impact can dilute the stronger one, as people tend to average the effects rather than summing them up. You're better off emphasizing the higher impact alone. Source: The Counterintuitive Way to Be More Persuasive by Niro Sivanathan (TED Talk)

"Thoroughly review related third-party codebases first"

When auditing an unfamiliar codebase, it's essential to thoroughly review related third-party codebases first. For instance, when auditing a new chain based on Cosmos SDK and Geth, you should:

• Study key APIs like Cosmos SDK's PrepareProposal/ProcessProposal/FinalizeBlock/ExtendVote/VerifyVoteExtension functions.

• Understand Geth's block generation/verification/processing steps.

• Research known vulnerabilities discovered by other security experts.

This approach helps you understand both the complete code flow and potential security risks, providing valuable insights for your audit

"When identifying a potential vulnerability:"

• Thoroughly review the attack path firstly.

• Take a break, then review it again with fresh eyes.

• If the vulnerability still holds after double review, develop a Proof of Concept (PoC).

Remember that ideas often rely on assumptions that may be incorrect, especially in complex codebases. Following this systematic approach helps build experience and reduces errors in future audits.

"Focus on understanding 100% of the system"

It is compulsory to know how everything should behave.

Once you get that kind of understanding of the protocol, you'll be able to understand how tweaking certain values or pushing the system to unexpected states might lead to vulnerabilities.

"Put on the developer's shoes"

This has worked like a charm to me.

The idea here is to be able to think how everything should behave prior to actually diving in the implementation. This will allow you to identify things missing in the protocol, or to check unexpected behaviors that might lead to bugs.

"Have patience and learn from each contest"

Although it might seem that the auditing part of the contest brings you the most learnings, it is in the escalations and results phase where you'll actually grow.

See what you missed and incorporate that knowledge.

"Learn to reverse engineer"

You must learn to reverse engineer exploits, you should not need to wait for someone else to write a thread explaining what happened.

There's tons of old exploits you can start with and Phalcon is free to use

"Understand the code deeply enough that you could implement it yourself."

Once you understand a system so well, you can explain it back and write it from scratch, you will most likely find all the bugs, barring some gotchas

"Become really good"

There is no competition once you are good enough, focus on your own progress and ignore the noise

"Never accept protocol design decisions without question"

Always ask why they were designed and implemented that way.

I have seen unique findings that aren't immediately apparent in the codebase but only become clear after digging deep into the design and questioning it.

"Don't try to be the jack of all trades"

Currently, there are far more opportunities in Web3 security than anyone could have imagined even a year ago.

Pick one niche and excel at it, capitalize on it as much as possible. Then, you can expand your knowledge afterward. Don't try to chase and master everything early in your journey

"Don't lose situational awareness"

It's one of the worst things that can happen. It can occur especially in very large codebases.

Once it made us lose the only spotted High vulnerability in a public C4 contest which awarded the solo spotter a 6 figure prize.

I had the risk in my notes, I highlighted the code snippet with the audit tag before, and failed to validate it as I lost the code logic at the end of the contest.

"Don't force yourself to find the bugs"

It creates unnecessary pressure and a burden when you do it.

I’ve realized that whenever I approach code with this mindset, I often come up empty-handed. However, when I explore codebases out of curiosity and simply for the joy of understanding them, that’s when I find success.

"Don't lose time on codebases you don't like"

While this could be subjective - as many people suggest that it leverages Game Theory by not doing so - I observe that I don't see any flaws in the codebases that I disliked.

This often leads to simply passing time without purpose and can deepen feelings of imposter syndrome once those flaws become apparent.

"You can earn big payouts from contests by simply doing manual analysis."

You don't need to set up tools to run complex tests during a contest as there's barely any time for that. Taking your time to manually review the code is enough.

"Mitigations are a good place to start looking for bugs."

A mitigation can fix a bug, partially fix a bug, not fix a bug or expose another vulnerability in the code. It can also do a combination of these. You can always check if a mitigation does any of these.

I've seen a mitigation to a problem I reported partially fix a problem and allow me still exploit the vulnerability.

"Leverage previous reports"

Reading former audit report also gives you deeper insight about the protocol, allowing you to reason about the code in multiple ways to find bugs somewhat related to the old finding.

"Understand the code deeply before actively searching for bugs"

This might not always be possible, but try to understand the code deeply before trying to exploit it for bugs. In the process of understanding the protocol, you may find bugs, you can filter out genuine findings, and you can transfer your new-found knowledge to other competitions.

"Always review all the valid findings in a competition you participated in"

Reviewing the findings will allow you know how and why you missed these findings during the competitions. This will equip you with the needed knowledge and mindset to ensure you don't miss similar bugs in the future.

"Focus on difficult codes"

While reviewing many auditors leave the difficult part of codes. That is someplace most of the bug lies

"Read what you missed"

After completing the audit, read other auditor finding to know what you missed

"Time and Focus"

This is a common tip, but it's one of the truest: the time and focus you invest directly influence the number of bugs you uncover.

Like they say, the 10,000 hours themselves are more important than the actual strategies used in that time.

"One Detail at a Time"

Once you understand the structure and flow of a system, narrow your focus to a single variable. Identify all the changes it undergoes and assess whether these changes are intended. Tools like "Ctrl+F" are key for tracking variables efficiently. I’ve seen 0xSimao mention this strategy on X.

"Bug Variations"

When you identify a bug, consider possible variations that might lead to other impacts or scenarios. These variations can often spark insights into additional, unrelated bugs. A single complex bug might open the door to a host of new issues.

"If it's hard, you're on the right path"

It's hard for everyone, and those who persevere through the struggle will reap the rewards later... it's your choice.

"If you're just starting, curiosity is your fuel"

Keep going down the rabbit hole so you don't run out of fuel. And that's the only motivation you really need.

"Don't chase money; chase knowledge"

It will pay off—don't worry.

"Auditing is about answering three questions"

• How should it work?

• How does it work?

• What if (x)?

"Transact with the protocol in different ways"

A great way to understand a live protocol at a high level is to just transact with it in different ways (via the frontend), and then analyse the transaction trace on tenderly, or the blocksec explorer.

"Auditing skill > technical knowledge (generally)"

The vast majority of vulnerabilities are due to logical flaws or a lack of constraints and don't require a deep understanding of the EVM's inner workings. These are found by training your auditing skill through deliberate practice.

So in terms of technical knowledge, you can achieve great results if you just learn the basics thoroughly (e.g as much as @CyfrinUpdraft teaches).

"Fail fast"

The fastest way you’re going to progress is by making mistakes early and learning from them. Have the humility to fail!

"Become the Product of Your Efforts, Not the Sum of Your Earnings"

Avoid evaluating and comparing your progress/skill level based on earnings. You are the product of your efforts, not the sum of your earnings.

"Depth over breadth"

Pick depth over breadth most of the times. Focusing on one codebase at a time provides higher ROI than performing multiple reviews at the same time.

"Maintain physical and mental energy"

It’s better to do less work on 100% than double the work on 50%. My belief is that if you do a 100% job, you get 100% result.

But if you do a 50% job, you get 25% result. You work with code every day, you use your brain to uncover sophisticated attacks. You need 100% focus. You need good sleep, good diet and a lot of energy. Take a break sometimes, work out / walk daily, go on a hike

"Embrace the failure"

This applies especially to audit contests. You work your ass off on an audit just to find out that you made a few cents in the end. That is the best thing that can happen to you!

First you can learn from the findings you did not find and make sure that you will never miss those again.

Second you can retrospect on your process and see what should be improved, maybe based on the reasons why you missed some findings.

Third this should make you want to compete more and more fiercely with the new knowledge to beat everyone the next time.

My biggest achievements started when I changed my approach after I realised I have not reported vulnerabilities worth ~$40k that I saw during the competitions:)

"Learn constantly"

There is a new attack vector everyday. There is a new technology or concept every week. You must still be ahead of the market.

"Hunt in blue oceans🌊"

There is some good in financial success that might be a good driver forward, that’s why you should hunt in blue oceans - focus where the least focus is to maximise your profit.

Why compete with thousands when you can compete with tens?:) Compete does not necessarily means audit competitions, businesses are competing for customers etc.

"Do not audit"

This means that audit to me signals some guy in suit checking if something is correct. You are not a unit test, you should not check if it is working correctly.

You should check how to exploit it for your financial gain! Or how to exploit it to hurt the users, or the protocol itself. You are the attacker!

Of course, you are the good guy, so once you uncover the bug, you responsibly report it:)

"Improve"

I changed my process several times, in the beginning after almost every audit, until I found what suits me the best.

Key insights from my process is analyse what you are doing (drawings, use case diagrams, flow charts, state machine), identify attack vectors and create threat models, and then just break the code.

"There's always (and I mean always) another bug"

Most of my decisions regarding an audit are based on this one-liner, for instance I never quit before the time is over and I rarely fool myself into thinking I found everything

"Have fun"

Staying motivated is easier when you enjoy what you do. It also helps prevent burnout

"Build solid routines"

• ~4 hours of deep work (like reading code, analyzing the project) each day.

• 1–2 hours of shallow work.

• Stick to a 5-day work week.

• Exercise at the gym 3+ times a week.

• Prioritize rest to stay sharp.

"Results improve with experience"

Over time, you’ll recognize problem areas and know where to dive in first

"Keep learning and use checklists"

Helps to spark new ideas during audits.

"Work harder"

A wise person once said: work, work, work, work, work, work

It was Rihanna.

"Idk man, you just need to put in the work" is like the most generic thing you could tell someone who wants advice on how to get gud (at anything), but sadly the answer is as true as it is unsexy.

I like to consider myself fairly smart. I had an easy time in school and university, I could half-ass most of it and still get very good grades. I had to learn the hard way that this mentality does not transfer to the security research space.

This place is filled with giga-brains, and the only option for most people to get anywhere close in terms of skill is to outwork them.

"Focus on one thing at a time and do it properly"

I am a massive sucker for FOMO. I can not count the times where I tried to do contests in parallel or when I was planning to do a contest in the final third of the time available just so I could do another one before that, for which I also only allocated a fraction of the time I should have. Needless to say I did not perform well doing this, ever. Remember how I said earlier that I consider myself smart? It's moments like these that make me question if I don't have a learning disability instead (like in the Simpsons episode where Lisa tests if her brother is dumber than a hamster) Learn from my mistakes and dedicate yourself to one codebase at a time for as much time as necessary until you understand how everything works.

"Just read the code"

This is a funny meme, but it's just that.

If you are you are far enough to the right of the intelligence curve you may be able to get away with it, but for most people I don't believe its an efficient way to go. Obviously reading code is the majority of the job, but for those who are not blessed with extraordinay mental RAM, there is no shame in:

• reading the docs to get a high-level understanding first

• taking notes and drawing diagrams

• using an IDE and learning to use it properly

• (especially in regards to navigating and searching code)

"Focus on Complex Areas"

Complex code often presents roadblocks, but these are precisely where many vulnerabilities reside.

Instead of avoiding these challenges, dive deeper. These areas often yield high-value findings that others might miss or skip over.

"Revisit Previous Sections"

After gaining a clearer understanding of a code section, revisit earlier parts you’ve examined.

Analyze the connections between these sections and any potential edge cases; often, unique bugs are buried beneath multiple layers.

"Previous Findings as Opportunities"

Previous findings can present valuable opportunities. Always review past audits and analyze the fixes; often, less time is spent auditing these corrections.

Remember that fixes can create new problems or may not be implemented correctly, leading to potential vulnerabilities.

"Use contests as a method to improve"

Don't be afraid to work on contests that has new concepts you are unfamiliar with. Instead, use the contest to push yourself to learn new things (e.g. Protocol heavily uses UniV3 but you didn't know UniV3 before).

"Prioritize contests with larger codebases"

Bigger than 3k+ loc, rather than small ones. Two reasons:

1. The ability to work on large codebases with complicated logic is a must for going deeper in this space

2. Smaller contests tend to have more noise, which may be distracting.

"Spent time reading aside from auditing"

Aside from normal audit work, leave some time for reading articles/write-ups and researching every once in a while. New tech and new issues are popping out every day, it is important to keep track, especially in such a fast evolving space.

"Understand the flow"

Imagine how each party interacts with the protocol, and try hard to break

"Pay attention to details"

Keep record of every little weak points and try to combine them

"Select larger and harder codebase"

Keep learning new things

"Critical thinking"

Don't read other's reports without independent thinking first.

"Speed is crucial in the initial audit phase"

Build a mental model of the code base quickly by speed-reading the contracts and avoid deep-diving at this point.

You can note down the low hanging bugs and put TODO tags for complex logic to review at the subsequent passes.

"Maintain the momentum"

Maintain momentum and save time by working on the easy tasks first and not be slowed down by the complex issues that require deep thoughts.

At the same time, you will gain confidence on the code base and not be overwhelmed by the details.

"Spend bulk of the time on reasoning complex attack vectors"

Allocate as much time as possible to review the complex logic (math, multi-contracts interactions, novel design, etc). You need creativity, knowledge and a good mental model to find the most complex bugs. These are the ones that are not obvious and typically involves multiple step or specific edge case to exploit. With the saved time from the initial phase, you increase your odds of spotting the more complicated issues.

"How to tackle a codebase?"

• Explore the entire codebase before diving into the details of each contract.

• Once exploring in-depth the codebase, leave no path unexplored. Explore every path that comes to your mind, and think of sequences that could cause the state of the contracts to fall into an unexpected state.

"Leverage the test suite"

Leverage the test suite to explore edge cases not considered on the tests.

"Document everything, even your thoughts"

Take notes about everything, from how a tricky function works, to all the attack vectors I’ve already thought about while exploring the contracts.

Write all the doubts and ideas of potential attack vectors/bugs and always return to them once you’ve understood every detail of the codebase.

Save all the articles (EIPs, deep downs of X protocol) you consulted for future reference.

"Attacker’s mindset first"

While auditing, focus your attention on exploring paths that would allow an attacker to steal assets from the contracts. More often than not you’ll get false positives/dead-ends, but, in the process of exploring these paths you’ll end up understanding the codebase from top to bottom and the non-critical bugs will pop up right in front of you.

"If your wind blows, seize it."

If you make a great achievement like winning a contest or a bug bounty, you should seize this hype and make the most benefits from it, such as joining invitational audits or marketing to yourself to get more opportunities such as private audits and build your experience. Do not stop or take a rest after making good results.

"Be organized in your approach"

I like to keep track of contracts I have reviewed, so that I don't miss out on anything and it is easier for me to do a systematic review of all the contracts. This is especially helpful if there is alot of stuff to review.

"Don't be afraid to tackle hard codebases"

The harder the contest, the lesser number of people and the greater chance of winning.

"Choose a niche and focus on it"

With the huge number of contests lately, there is enough to go around for everbody. As for me I chose cross-chain and L2s but some rockstars like A2Security specialize in lending.

"You don't know a lot"

You reach a point where you fully understand the codebase, but the results come with a lot of bugs you miss.

"Time Management"

Studying, doing contests besides escalations, and learning new concepts. Each task should take its time without neglecting the other task.

"Patience"

You can spend weeks working hard without any progress, but you should keep working to reach your goals.

"Do not be afraid to take on a new challenge"

That’s from trying to audit a new language or trying the 5000+nsloc contest or even going for a Blockchain/DLT level contest from classic solidity Defi.

"Security research is a mindset"

As some people say security research is a mindset, so regardless of the size of the protocol or the language, there are always bug cases that apply to it, and if you don’t find any during that audit, you’d definitely learn from the report and apply it on your next audit.

"Stay consistent"

Just show up everyday and do something.

"Stay away from the crowd"

I always try to do the most unattractive contest currently offered. It's usually either a very complex codebase, or a language no one wants to learn.

This way I always keep myself challenged (avoiding fatigue) and get the minimum of competition which leads to a way less diluted pot.

"Check for 3 signs that will tell you that this is a good contest to do:"

• New language / protocol type

• Complex Math

• Gigantic codebase

"Predict highs"

When deciding on what contest to look at, nowadays its becoming more and more important to know if a contest will contain highs, due to scaled pots. You can usually predict the chances of this pretty well by looking at 3 metrics:

• Prior audits -> Who audited it before? In case of no one or a low quality company we can be pretty sure to find stuff

• Code quality -> If there is almost no testcases or documentation, we can usually expect highs

• Size -> The bigger the codebase is the better as the chance of highs increases exponentially

"Favor big codebases"

So if I do a scaled pot, in the best case I want those 3 to align.

A big codebase, that is badly documented / tested and had no or only low quality audits before. In that case you can be almost sure that the pot is unlocked, but competition will still be a lot lower due to the pot being scaled.

"Meet Everyone"

I always try to meet as many people in the industry as possible.

First of all you will find a lot of friends that have a similar mindset to you which is awesome.

Second of all these friends can be helpful all along the way. I have gotten many opportunities or clients referred to me by friends I met along the way.

"Don't be a leech 🐛"

If you just want others to help you but not do anything for them no one will want to be your friend. Try to help and support each of your friends whenever you can. It might be referring a client to them, it might be putting a good word in for them with someone you know etc. This way you can build lasting friendships out of which both sides profit.

"Prepare well before your first contest"

If you're just starting out and planning to participate in your first contest, make sure to properly equip yourself before stepping into the battlefield. One of the main reasons many newcomers give up early is that they jump straight into a contest without preparation. Often, they struggle to find anything, feel overwhelmed, and conclude that success is impossible- leading them to quit. On the other hand, auditors who spend a few weeks preparing by conducting shadow audits, reading reports, and actively practicing finding bugs, tend to perform reasonably well in their first contest. This initial success is what you need to ignite the motivation needed to persevere and continue until you truly "make it."

"Go deeeeep"

This is where unique and less duplicated findings hide. If you stay on the surface, where everyone else is, you'll uncover the same issues as everyone else. But if you're bold enough to dive deeper, you can win Big. The deeper you go, the less competition you'll face. Going deep means that once you understand how a protocol works, you focus on its most critical flows, break them down into smaller components, and start exploring:

• are there any external integrations -> study the external integration code

• check tests for a particular flow -> are there any spots left untested -> explore them

• are there any exotic scenarios to this flow -> try to think of them and see if they brake the logic

"Focus"

Remaining focused is one of the most essential principles to grasp in this industry, and it applies on multiple levels:

• Commit to one contest at a time and give it your all - It's far better to win a single contest than to perform moderately well in several.

• Dedicate yourself to one goal - Whether it's becoming an LSR/LSW, building a business, or excelling at bug bounties, choose a single goal and channel all your efforts into achieving meaningful results.

"Knowledge is power"

Once you’ve built some initial recognition (achieving a few milestones helps break the ice quickly), start connecting with other auditors.

Share your opinions, expectations, and experiences with them—this can help you identify false assumptions and recalibrate your approach to make more informed and effective decisions

This is one of the best ways to stay updated on real trends and opportunities in the industry—those that lie behind the glossy marketing facade.

"Pure curiosity and discipline is everything in Security Research"

"For newbies: Learn the basics"

• Learn the basics of blockchain, ethereum and solidity. You should have a basic idea of how these things work under the hood.

• Learn about basic smart contract/blochchain bugs

• Do some CTFs and other available challenges

"For newbies: Do shadow audits "

Do shadow audits. Choose any past audit with small codebase and try to find bugs in it, then compare your found bugs with the actual audit contest result.

Pay special attention to the bugs you missed as that's the key for improvement.

"For newbies: Compete in a live contest "

Compete in a live contest - preferably a smaller codebase one. Analyze your findings against the contest top rankers.

"For the experienced: Choose less crowded contests"

To maximize payouts choose less crowded contests (complex codebases, new languages, new platforms, heavy math codebase, etc).

"For the experienced: Ask"

Question every business logic. Asking what if ...? is the way to go.

"For the experienced: Go deep"

Go deep into the codebase that you audit.

Understand the protocol flow & all its state transitions. Diagrams/charts can be helpful here.

"For the experienced: Understand your top competitors"

Try to understand the mindset of your fellow top competitors in the contest.

Read all their findings to understand how they were seeing and approaching the codebase.

"< 2k nSLoC contests are to learn basics of Security Research where you just train skills. Real work starts later on big complex projects"

"Learn by doing"

Stop wasting time trying to learn some concepts up-front.

Learn as you do, especially in security reviews.

"Setup that feedback loop"

• Failing by missing vulnerabilities is normal. You can’t do without it.

• But failing multiple times on the same issues is not acceptable.

• Get that feedback loop up, be sure to never miss this issue again.

"Question everything"

Question, question, question. Don’t take assumptions, or if you do you should question them too! Then look for the answer, you may be surprised!

"Cut the abstraction down"

“This should work like this, I’m not checking it!”

Are you sure about that anon?

"Interpret that small line of code"

What does this line of code means on the whole protocol? What consequences does it have on other workflows?

Interpret the small lines within the project’s big picture!

"Have fun!"

It’s OK to not enjoy a codebase. With competitions, you can just wrap-up and go with another you enjoy!

I’ve done it in the past, I will do it in the future. Because competitions allow it!

"Be unwavering in your conviction"

Never believe there are no vulnerabilities left to find, or that you will not be able to find them.

If you catch yourself thinking that, you are not competing to win. There is always a way for you to discover the next vulnerability - you just have to find it.

"Dive deep, when needed"

Always welcome the opportunity to dive one step deeper, to understand the code at an even lower level, to develop an even more precise understanding of the whole stack.

But do it with a purpose - also accept that it is simply infeasible to learn and retain all there is to know about any single blockchain. So pick your battles, and fight.

"Skill comes with practice"

Good auditing skills come from auditing. You need some reference material to get started, but after that, learning by doing is how you improve.

Contest platforms provide a feedback loop, community, scheduling, the right incentives and most importantly, a payout. Make use of the structures available to you.

"Just do it"

The difference between doers and dreamers is that doers started DOING one day. Today is a great day to be your day one.

"Set your goals high"

When your goals are set too low, it's so easy to quit or lose interest after some success.

Your goals should be so high that reaching them will truly change your life. There are so many memes about BJJ people leaving training after getting their blue belt, but when your goal is to be the most badass grappler in the world, no belt will make you quit the game.

"Give before you take"

As I strongly believe that we’re put here to give more to this earth than to receive, hoping to get everything we’re dreaming of without giving back at least equally, it won’t happen. If your dreams are high, you need to be ready to pay more.

And the right way to be able to give more is by working on YOU every day, being a greater version of YOU!

"Consistency is key"

When someone's performance seems unreachable, it doesn't mean it is. All you need to reach that level is consistency. You'll level up without even realizing how much you've grown with just consistent work. For example, when I started jiu-jitsu, blue belts seemed so powerful and untouchable. I felt unprotected and thought I'd never reach their level. But now, I can play with newcomers and submit them easily. All it took was 8-9 months of consistent training

"Do Not Avoid the Cracks While Looking for the Entrance"

A bit controversial, but also include informational and low issues when possible. The act of putting into writing a potential low issue both solidifies your understanding of the codebase and provides a slight benefit for the protocol. Countless times, while thinking about how to report an informational issue on a part of the code, I realized there were more issues there.

"The Hunter Should Not Be Jealous of the Builder's Hammer, and the Builder Should Not Envy the Hunter's Bow"

What works when hunting on bug bounties may not be as relevant when doing private engagements or contests.

Although similar, different applications of auditing require different approaches. Remember this and do not try to apply a bug bounty hunter mindset to a private engagement, or vice-versa.

"Balance Focus With Flow"

Your resource is your brain, but it has its quirks. You may focus for hours on a codebase only to find an issue later while showering. Why? Because you entered a diffuse thinking mode.

Relax your thinking intentionally to allow the pieces to fall into place and the issue to reveal itself to you. Plan walks, long baths, or other such activities in between focus sessions.

"Look in places that you know better than the devs"

The devs don't know all the edge cases of the protocol that they are built on top of or forked from.

A lot of bugs that I found on Immunefi were bugs where you needed to do something in these deeper layers first to achieve the bad end state.

"Have fun and follow your curiosity"

It's a completely different focus when you're doing it out of your curiosity instead of forcing yourself to work.

There is a lot to choose from so choose whatever interests you and have fun.