How I Did a Shadow Audit (Start to Finish)

What is a shadow audit? One of my goals is to understand as many vulnerabilities as possible. To do that, we can do many things like reading reports, watching courses, participating in contests, and reading articles. One great method is picking already finished contests, getting familiar with the codebase, finding some issues, and analyzing the report to understand the issues you missed. It's a good practical way of studying not only vulnerabilities, but also you will be better at analyzing the code, learning Solidity, DeFi, and many other skills that a smart contract auditor needs to be good at. How to do a shadow audit? To get the most out of it, I tried to imitate some aspects of real contests. This plan was heavily inspired by suggestions I received from Bloqarl on how to approach shadow auditing. Preparation First, book yourself a ~week — this should help with training yourself to work under pressure and stick to deadlines. Choose a protocol that will be in the topic you want to learn — in my case, it was BeedleFi, because of the staking module. After some trouble with finding the right versions of the libs, I went to the next step. Get familiar with the codebase After preparations, I started to analyze the code line by line, which was a really slow process, because each line was at least one side quest to research — but man, it was a really great opportunity to learn Solidity. To understand why the code was written this way, I used Claude in my IDE to explain things. Also, one good thing I did was to create mermaid graphs of flows in that protocol. Try to understand the protocol to the point where you know why the dev wanted to write a particular part of the code in that way. Here, knowledge about DeFi and protocol docs would be great to have. I didn't do good research before, so I was learning how some things like integration with Uniswap work on the go. Next time, I will prepare myself better before diving into the codebase. While getting familiar with a codebase, try to find flaws in logic. I found reentrancy vulnerability possibilities, a lack of appropriate checks that were actually the cause of a couple of high and medium findings. One of the things that I need to do next time is to go through the code with a checklist of common vulnerabilities — like this one from Solodit. Time for the report When you have a total understanding of the protocol, it's time to go into the report. Go through each issue deeply, trace every bug in the codebase, and reflect on how the auditor found it and why you missed it. On every issue, I made a little explanation on my own to see if I understood it. What are the pros of shadow auditing? When you audit in a live contest, you submit your findings and then wait at least a couple of days to see all findings. So when you have a chance to analyze these things, you are already a couple of days out of that codebase — so not every mid and high will be easy to understand. You need to sit and try to remind yourself of the codebase, from the protocol, which doubles the work. While performing a shadow audit, going through all reports is one of the next things you do after getting familiar with the protocol. You see what I mean — there is no gap between these steps, so your understanding of these issues can be a lot better and sharper. Maybe you will even find something on your own? Definitely try it! Doing shadow audits is way better than just reading reports, because it's a whole process that includes going through reports, but it's just a small part of it. And cons… One serious problem when I was shadow auditing was not having a real deadline and incentives. Because of that, it can get a little bit tricky to stay motivated. After a couple of days, I already started thinking about participating in a real contest or building the next project, which was distracting. I think that one way to help myself create some pressure on myself is to learn in public, so write what you're gonna audit, and what the deadline will be. Was the shadow audit worth my time? Yes, absolutely. I learned so much during the process. I discovered what my flaws are in the code analysis process, how to perform better, and how to organize and understand the code. Also, seeing the codebase of real big protocols is advancing my understanding of Solidity and DeFi architecture. I already have ideas for improving my process, so I can't wait to start the next one. This reflects my current thinking as someone still early in the journey

Apr 27, 2025 - 18:07

How I Did a Shadow Audit (Start to Finish)

What is a shadow audit?

One of my goals is to understand as many vulnerabilities as possible.

To do that, we can do many things like reading reports, watching courses, participating in contests, and reading articles.

One great method is picking already finished contests, getting familiar with the codebase, finding some issues, and analyzing the report to understand the issues you missed.

It's a good practical way of studying not only vulnerabilities, but also you will be better at analyzing the code, learning Solidity, DeFi, and many other skills that a smart contract auditor needs to be good at.

How to do a shadow audit?

To get the most out of it, I tried to imitate some aspects of real contests.

This plan was heavily inspired by suggestions I received from Bloqarl on how to approach shadow auditing.

Preparation

First, book yourself a ~week — this should help with training yourself to work under pressure and stick to deadlines.

Choose a protocol that will be in the topic you want to learn — in my case, it was BeedleFi, because of the staking module.

After some trouble with finding the right versions of the libs, I went to the next step.

Get familiar with the codebase

After preparations, I started to analyze the code line by line, which was a really slow process, because each line was at least one side quest to research — but man, it was a really great opportunity to learn Solidity.

To understand why the code was written this way, I used Claude in my IDE to explain things.

Also, one good thing I did was to create mermaid graphs of flows in that protocol.

Try to understand the protocol to the point where you know why the dev wanted to write a particular part of the code in that way.

Here, knowledge about DeFi and protocol docs would be great to have.

I didn't do good research before, so I was learning how some things like integration with Uniswap work on the go.

Next time, I will prepare myself better before diving into the codebase.

While getting familiar with a codebase, try to find flaws in logic.

I found reentrancy vulnerability possibilities, a lack of appropriate checks that were actually the cause of a couple of high and medium findings.

One of the things that I need to do next time is to go through the code with a checklist of common vulnerabilities — like this one from Solodit.

Time for the report

When you have a total understanding of the protocol, it's time to go into the report.

Go through each issue deeply, trace every bug in the codebase, and reflect on how the auditor found it and why you missed it.

On every issue, I made a little explanation on my own to see if I understood it.

What are the pros of shadow auditing?

When you audit in a live contest, you submit your findings and then wait at least a couple of days to see all findings.

So when you have a chance to analyze these things, you are already a couple of days out of that codebase — so not every mid and high will be easy to understand.

You need to sit and try to remind yourself of the codebase, from the protocol, which doubles the work.

While performing a shadow audit, going through all reports is one of the next things you do after getting familiar with the protocol.

You see what I mean — there is no gap between these steps,

so your understanding of these issues can be a lot better and sharper.

Maybe you will even find something on your own? Definitely try it!

Doing shadow audits is way better than just reading reports,

because it's a whole process that includes going through reports,

but it's just a small part of it.

And cons…

One serious problem when I was shadow auditing was not having a real deadline and incentives.

Because of that, it can get a little bit tricky to stay motivated.

After a couple of days, I already started thinking about participating in a real contest or building the next project, which was distracting.

I think that one way to help myself create some pressure on myself is to learn in public, so write what you're gonna audit, and what the deadline will be.

Was the shadow audit worth my time?

Yes, absolutely.

I learned so much during the process.

I discovered what my flaws are in the code analysis process, how to perform better, and how to organize and understand the code.

Also, seeing the codebase of real big protocols is advancing my understanding of Solidity and DeFi architecture.

I already have ideas for improving my process, so I can't wait to start the next one.

This reflects my current thinking as someone still early in the journey