“How do I pick my first shadow audit target?”
A shadow audit is an audit nobody pays you for.
You pick a live protocol and audit it like a paid job.
You open a big repo.
No idea how it actually works.
No idea where to start looking for bugs.
Next week you switch repos and start from zero again.
Today I’m sharing the 4 steps to pick that target, and make it pay off even with zero bugs.
Pick one lane on a chain that needs auditors
Pick a lane and stay in it.
A lane is one protocol type: lending, CLMM, perps or cross-chain.
Every switch to a new type resets you to zero.
When I grinded random contests, every context switch cost me a lot.
Then I went deep on cross-chain:
A cross-chain contest: $10K
The next cross-chain contest, with a teammate: Top 10, $3K
Every project after that: smoother ramp-up, more ideas, more patterns to hunt
Same lane. Each codebase got easier to read.
Now the chain.
EVM: more projects, more auditors, patterns mature enough to push into AI
Solana and Move chains: fewer auditors, real demand, and they pay more
EVM is still a good place to learn.
But depth on Solana or Move gets noticed faster.
Coming from EVM?
The business logic bugs look the same.
The hard part is the chain’s own concepts, not the language.
Do this now:
Open a blank note
Write one lane: lending, CLMM, perps or cross-chain
Write one chain: Solana, or a Move chain like Sui or Aptos
Commit your next three shadow audits to that pair
Shadow the mature protocol everyone builds on
Inside your lane, go to the top.
The biggest lending market. The biggest CLMM.
The one other protocols call into.
One word you’ll need:
Integration: another app calling into a protocol. Step 4 runs on it
Pick the one that actually interests you.
Go deep on that one, not all three.
You’ll live in it for the next 1-2 months.
“Isn’t the top protocol already audited to death?”
Many times.
Go deep enough and you can still find bugs in the top ones.
So you get two outcomes:
You find a bug. Good
You find nothing. You still learned the base layer
Either way, you studied code that a lot of your future private audits build on
That last line is the real reason.
The projects that pay you later integrate with this one.
Zero bugs here still means you know the code your next client calls.
Before you close this tab:
List the three biggest lending or CLMM protocols on Solana
Next to each, note which other apps integrate with it
Circle the one most apps call into. That’s your target
Read every past report on that protocol
Past reports show you the problem places.
Before you read a single line of code.
Then you widen it to the whole lane.
Early on, I prepared for a ZK rollup contest.
Here’s what I did:
Took every past report on that codebase
Took every issue too
Read all of it before the start
A private audit took the slot, so I never entered.
But I knew where the problem places were.
And where the bugs could be.
The bug that shows up in three reports is the one to hunt.
Now go wider.
Take popular projects of the same type. Other chains count too.
Ask yourself:
Why is it built this way?
Why this design and not the obvious alternative?
How does a rival build the same mechanism?
Why is one of them more efficient?
Which bug patterns repeat across all of them?
One protocol shows you its design.
Its rivals show you the choices behind it.
Ten minutes:
Make one folder named after your target
Save every past audit report on it
Add the reports of two rivals of the same type
Skim the finding titles of the newest report
Write the checklist of integration mistakes
Every time a mechanism clicks, ask one more question.
How could an app that calls this get it wrong?
Write the answer down.
Later a private client integrates this protocol.
You already know where integrators slip.
That list is your leverage.
My 1st place came from exactly this.
$8K. One unique High.
The bug sat in the contract the staking pool called into, outside the contest scope.
Everyone else stopped at the scope line.
I read the out-of-scope docs anyway.
Here’s what that contract did on a manual recover:
The caller picked the gas limit
It deleted the pool’s balance entry first
Then it sent the funds back as a message
If handling the return failed, the message bounced
It ignored bounced messages, so the entry never came back
Retry: refused
The funds sat there with no record pointing at them.
The pool assumed the return always lands.
That’s not a bug in the big contract.
That’s a mistake in how the caller used it.
The base protocol is solid. The apps calling it are where you hunt.
Start the list today:
Open a doc named after your target
Write five ways an app calling it could lose money
Add one line every time a mechanism clicks
Your first shadow audit doesn’t have to find a bug.
It has to leave you with a list nobody else has.
You can run this alone, or run your first one with me.
Two weeks. Seven people. A real codebase.
You commit your leads first. Then I open the answer, and we go through every bug you missed.
LINK
