I get this kind of DM every week.

Some start with “I can do nothing, help me.”

Others end with “I can do something, but I’m still stuck.”

Some of these people have done security for 1-2 years.

Still no deep bug. Still no private audit.

Today I’m sharing the 3 reasons you’re still stuck in 2026, and what to do instead.

But first, what changed:

• AI reads code top to bottom, and it does it well

• Contests get thousands of AI-generated reports

• A lot of bug bounty teams just don’t pay

The old path was simple.

Join a contest, find a bug, hit the top 10, post it on X, wait for the DMs.

That path is closed.

1. Stop reading code top to bottom. Hunt the 5% that moves money.

Most auditors still read a codebase from top to bottom.

Deposit, then withdraw, then the next file.

They hope a High shows up on the first pass.

Maybe the second.

AI already does that pass.

Some AI workflows do it very well.

So the bugs left for you sit where AI is still weak: the complex, math-heavy parts that need many steps of reasoning.

You don’t need to read everything better than AI. You need to know where to look.

Here’s the order I use:

1. Understand the codebase: actors, assets, roles, state transitions, assumptions

2. Do one manual pass, line by line, only to know what sits where

3. Run an AI workflow for the easy bugs, if you want

4. Pick the 1 to 5 critical parts: the code that moves funds or runs the core formula

5. Learn that part deeply, then go backwards from the worst impact

Step 2 is not hunting yet.

And understanding the whole project is not the same as understanding its hardest part.

You need both.

Going backwards means you start at the damage.

“What if this formula is wrong?” “What if someone gets this flow stuck?”

Then you walk left, right and up from that line until you find what can cause it.

While you sit there, you research the bug types this kind of code has.

You chat with AI about it. You write heavy notes.

I did exactly this in a cross-chain messaging contest.

The project had other parts.

I knew they didn’t matter.

One flow was critical. If a message got stuck there, the whole protocol stopped.

So I spent a whole week on about 100 lines of code.

The attack needed many steps: the code, the chain it ran on, and how that chain works.

That kind of multi-step research is where AI still fails.

I found the bug, a denial of service on the messaging.

It paid $10K.

Do this on the codebase you’re on now:

1. List every function that moves funds or runs a core formula

2. Pick one

3. Write its worst impact at the top of a new note

4. Read backwards from that line for one hour

2. Stop waiting for contests. Hunt live projects.

Contests used to be the fast way in.

One good result, and firms knew your name.

Now your real bug sits in thousands of AI reports.

So don’t wait for the next contest.

Go to projects that are already live. New ones, or ones that ran for a couple of months.

Here’s what one live project gives you:

• Real experience finding bugs, with or without AI

• Findings for your portfolio

• A team that can give you a testimonial

• Sometimes, money

The money is the smallest part.

You post the work on X.

You write up the bug, if the team allows it.

Then, when you DM a firm for a private audit, you send the portfolio.

Every week researchers DM me: “Can I work with you? Can I do a private audit?”

Of course you can. But show me what you can do.

Show me your results. Show me your stats.

If there are no stats, what’s the point of working with you?

Prove it to yourself first. Then DM me.

This week:

1. Pick one project in your domain that has been live for 2+ months

2. Read its core flow, the 5% from part 1

3. Test every idea on a local fork, never on mainnet

4. Report what you find to the team privately, and ask for a testimonial

3. Stop going wide. Take one domain for 90 days.

Early in my journey I jumped between domains:

• Lending

• AMMs

• Liquid staking

• Cross-chain

Each one has its own bug types, its own knowledge and its own way of thinking.

Switch all the time, and you’re confident in none.

So take one domain and stay there for at least 90 days.

Say perpetual futures.

Open DefiLlama, take the top 3 perps projects, and study them.

Every feature. Every bug type. How each team built it differently.

After that, you can hunt perps on any chain: Solana, Sui, Ethereum.

The design is mostly the same everywhere.

Only the chain-specific bugs change.

Lending works the same way.

On Solana, take Kamino and learn it by heart.

Then audit the projects that integrate with Kamino.

You find bugs there because you know the main project by heart.

Get known for one thing first.

Later, when you do private audits, you can move between domains.

At the start, you can’t.

Today:

1. Pick one domain

2. Open DefiLlama and write down its top 3 projects

3. Block 90 days in your calendar for those 3 only

None of this is fast.

It’s hard work, and the results come late.

But if you do it with a strategy, your chances are much higher than doing it at random.

If you want to find that 5% in a real Solana codebase, with me next to you, start here:

arsen.ac/solana-audits-bootcamp

— Arsen

• 200+ High and Medium bugs found

• $1.6B+ TVL secured

• 100+ audits done

It taught me one thing:

Becoming a skilled Web3 auditor is extremely hard.

Auditors often ask me:

“Is it still possible to become an auditor in 2026?”

It’s much harder now.

But even with AI, the private audit market is booming. The demand is crazy.

So here’s how I’d become an auditor in 2026:

• Why you should pick a niche

• Which protocols to learn

• How to get private audits

Let’s go.

1. Why I’m pushing Solana

Early in my career, I was scared of Rust.

It felt like the next level.

Then one request changed everything:

My first Rust audit. A Bitcoin light client.

• 3 weeks to finish it

• I learned Rust and C++ on the job

• I hunted bugs across Bitcoin, Zcash and Dogecoin

I understood that Rust, and most of this tech, isn’t that complex.

You just need to get your hands dirty ASAP.

Today, 90% of my work is Solana and Rust.

It’s the future of DeFi

When I started, most audits, contests and bounties were on EVM.

Times have changed. EVM is still the biggest market.

It’s also the most crowded:

• Thousands of auditors

• Hundreds of AI audit bots

• Tons of EVM audit resources

That makes the barrier high. Entering EVM isn’t the same as it was 2 years ago.

Few people look at the niche, where there are fewer resources and fewer auditors.

Solana is one of the most promising directions.

Solana made $143M in app revenue in August.

Ethereum did $47M in the same month.

That’s 3 times less. DefiLlama numbers.

Auditors who can work on Solana earn more by default.

Why?

Not many people know Solana, but the demand keeps growing.

Demand is booming

Private audits are cooking.

More and more really strong projects are building on Solana:

• Projects & institutions are coming into play

• The Solana dev community is very solid

• Cheap tx and gas

We even saw an L1 on Cosmos close and move to Solana.

This makes Solana the ideal next Top-1 blockchain.

If I were starting out today, I’d go to Solana.

It’s where the next level is.

How to learn Solana the right way

1 core rule to understand.

You shouldn’t spend too much time in theory.

You shouldn’t learn all of Rust or do a Rust course.

What you should do instead is very simple:

1. Open the RareSkills book

2. Open Blueshift

3. Spend 2-3 days reading Rust & Solana

At this step, you need the bare minimum.

Don’t learn it by heart. Just get a strong 1st overview.

Make sure you understand the following concepts:

• How the account model works

• What a PDA is

• What a CPI is

• What rent is

• What an instruction is

• What Anchor is

That’s enough to start reading the code.

Afterwards, we move to the more complex part.

2. Which protocols to learn

You know Solana now. You think you did a lot already.

But the hardest part is about to begin.

Soon you’ll audit projects that hold billions in TVL.

You need to work like a real professional. But how?

Learn 1 domain by heart

By domain, I mean one type of DeFi protocol:

• CLMM, propAMM

• Lending & borrowing

• Perpetual futures

• Virtual machines / nodes

Early in my journey, I jumped from contest to contest.

I didn’t stick to any domain.

One week I audited cross-chain. The next week, lending.

Nothing stuck.

Results appeared only when I went 1 domain at a time.

Only then did I understand the real game of audits.

Finding creative bugs by knowing the system well.

Just go to DefiLlama and check the top projects out there

Those are your 1st targets to audit.

Here's the top of that list:

Repeat for 90 days & save the knowledge

Pick one domain. Then:

1. Hunt only that domain for 90 days

2. Read the code

3. Study past exploits / reports

4. Record observations

5. Make the right notes

After you read this 1st project, you’ll gain valuable knowledge: how the core protocol works & what bugs it has

Then, make sure you save all notes in your DB, and tune your AI with this knowledge

That gives you an assistant that knows:

• Major bugs you found or missed

• Patterns that repeat across codebases

• Implementations the devs made

• Every structured note

30 retros later, you see patterns nobody else sees.

Wide gets you nowhere. Depth gets you paid.

3. How can I earn?

No one knows you

When you enter Web3 Security, no one knows you.

Bounties are harsh. Not everyone pays it.

So how can you earn?

By building yourself as a professional auditor.

• Public portfolio

• Strong X account

• Proven record / Bugs found

It takes a lot of work to build those 3, but it’s exciting.

Eventually, if you stick to these 3, you will make it.

Are you a real professional?

Show that you can find bugs.

With and without AI, doesn’t matter.

It should be a real skill.

In 2026 it’s harder, due to the lack of dedicated contests.

That’s why I advise the following:

1. Find live projects and bounties

2. Hunt the bugs there by heart

3. Submit them to the team

4. Build your portfolio from these findings

5. Hopefully get paid (it’s not the main goal)

6. Repeat

Once you have a public record of 10-20 H/M findings in live projects, you’ll know the game, and you’ll be ready for private audits.

Pitch yourself

You should be a known professional in your own niche.

Once that’s set up, share your experience:

• Write post-mortems

• Write technical articles

• Write tweets with your advice

Share the knowledge, inspire others, pitch yourself.

Afterwards, DM firms for private engagements.

Hunt the opportunities wildly.

And your first $3K private deal will be done.

If you want to do this with me, my Solana Audits Bootcamp starts Nov 23. Four weeks on real code, with a live call every week.

Live bonus: join before Sunday, Nov 8 and you get a 30-min 1:1 call with me. We plan your 4 weeks.

https://www.arsen.ac/web3-auditor-course

— Arsen

“During an audit, I forget everything quickly. I get confused when I take notes.”

I know this feeling.

Day 3 of an audit.

You see something weird in a function.

“I’ll come back to it.”

You never do.

Today I’m sharing the 3 rules I use so a lead survives until the last day of the audit.

Stop reasoning in your head

After a week of line-by-line review, you forget things.

That’s normal. It’s how the brain works.

The problem is where you do the thinking.

Reason in your head, and leads fall out.

Keeping the whole codebase in your head is a disaster.

Your notes have one job: hold everything your head drops.

• Every thought, cut to one line

• Every open question, parked

• Every lead, kept until it’s closed

I tried a lot of setups before I got there:

• Diagrams

• Code pasted into Miro

• Raw notes in VSCode

Miro got the closest.

The whole codebase fit on one screen.

It showed me the code.

My questions about the code had nowhere to go.

Now I use Notion, in 4 layers:

1. The system

2. Each flow

3. Each function

4. The line

A question goes into the layer it belongs to.

Do this now:

1. Open your current audit

2. Write down every “I’ll come back to it” from this week, one line each

3. Put each line under the flow it belongs to

Give every lead one row

A lead in your head is gone by Friday.

Write it down the moment you see it.

Every lead gets one row, with 3 parts:

• Where: the function and the line

• Why: what looks wrong

• What breaks: who loses money if it’s real

Here’s the difference.

In your head: “something off with the fees”

As a row:

• Where: withdraw, the fee line

• Why: the fee rounds down to zero on small amounts

• What breaks: the protocol, if a user splits one withdraw into many small ones

The first one is gone tomorrow.

The second one you can test.

Then I mark the line in the code itself with //@audit.

So I land on it again in one second.

The row tells you what to check. The marker tells you where.

Before you close this tab:

1. Pick the last 3 leads you parked

2. Give each one a row: Where, Why, What breaks

3. Put //@audit on each of those lines in the code

Let one row grow into a chapter

Sometimes one row keeps pulling you back.

Don’t close it. Grow it.

In one audit, I had a row that said “leverage update and its behavior”.

For me it wasn’t one lead.

It was a whole chapter.

I covered it in every flow:

• Open

• Withdraw

• Liquidate

Backwards, actor by actor.

It ended in a critical bug, and $11K.

You only see that when the row is written down.

Tonight:

1. Open your notes

2. Find the row you keep coming back to

3. Walk it through every flow that touches it

4. Write one line on what it does in each

Write the lead down on day 3.

You won’t remember it on day 10.

In my private Audit Program, your notes and your leads are what you submit for review, every phase, by the deadline.

Then a live call at the end. We go through every bug you missed, and the step that would have caught it.

https://www.arsen.ac/web3-guided-audit

— Arsen

I got this in my DMs.

Another one asked me to simplify the “bad state” idea.

So today I’ll show you exactly how I study a hack.

Here’s what most people do:

• open the write-up

• read the attack steps

• think they got it

• forget it in a week

Then the same bug sits in their audit, and they walk right past it.

When I started, I spent hours on Solodit issues and old reports.

It helps, but only up to a point.

My example today is the $42M GMX hack. You need 4 facts about it:

• GMX V1 is a perps exchange: traders trade against one shared pool

• GLP is the pool token: its price comes from AUM (what the pool says it’s worth)

• AUM depends on two values: the total short size and the average short price

• The size lives in the Vault: the average price lives in another contract, ShortsTracker

That’s all. Now the 3 steps.

1. Find the bad state before you read the attack

I start every hack with context.

Same list, every time:

• Which state matters?

• What does the good state look like?

• What is the bad state?

• What does the bad state allow?

For GMX:

• state: short size and average short price

• good state: they move together, every time

• bad state: size goes up, the average price stays old

• it allows: AUM looks bigger, GLP looks more expensive, you redeem for more than you put in

Write these 4 lines before you read a single attack step.

Once you know the bad state, the attack is just one question.

How do I get there?

Try it today: take one hack you’ve already read, close the write-up, and write these 4 lines from the code.

2. Ask what stops you, then when it’s off

Here’s how an attacker thinks.

He starts from what he wants: the bad state.

Then he runs the same loop, again and again:

1. What do I want?

2. What stops me?

3. When is that check off, or who can skip it?

Every “no” becomes the next question.

He stops when he reaches a function anyone can call.

Here’s the loop on GMX, from my notes:

• I want size up and the average price old

• What stops me? A normal order updates both, through ShortsTracker

• Can I skip it? Yes, call the Vault directly

• What stops me now? The Vault works only while a leverage flag is on

• When is it on? Only while the keeper bot executes an order

• So I need my own code to run during the keeper’s order

One more question finishes it.

What do I control?

In that sequence, the attacker controls one thing: _account, the address that gets the ETH back.

He made it a contract.

The ETH lands, his code runs, and the flag is still on.

Everything that is user-supplied is a tricky place.

The rest is the cash out: redeem GLP at the fake price.

The extra money comes from every other GLP holder.

“But I’ll never audit GMX.”

Doesn’t matter. The loop works on any code.

Your homework:

1. Pick one function in your current audit

2. Write the bad state you want

3. Run the loop: what stops me, when is it off, what do I control

4. Keep going until you hit a function anyone can call, or a check you can’t get around

3. Forget the scope. The attacker does.

A Whitehat reads the bounty page first.

The attacker uses everything that touches the protocol: bots, keepers, oracles, other contracts.

On GMX, the keeper did half the work for him:

• it turned the leverage flag on

• it sent the ETH to his contract

• nobody hacked it, it just did its job

Now look at it as a Whitehat.

The keeper is off-chain, so it’s out of scope.

Submit this, and the project answers:

“Off-chain entity validates it, it’s ok!”

You’d beg for a small bounty.

The attacker drained $42M and kept about $5M after returning the rest.

Before your next audit:

1. List every actor that calls the protocol: users, keepers, admins, oracles, other protocols

2. For each one, ask: what does it do for me if I’m the attacker?

3. Check the scope only after you have the answer

Here’s the full template I fill in for every hack:

HACK: <name> · <date> · <loss>
LINKS: 2-3 write-ups, never one

BEFORE I START
- What are the most important parts to focus on?
- What don't I understand yet? *define it clearly
- What is my final goal?

CONTEXT
- Which state matters?
- Good state:
- Bad state:
- What the bad state allows:

THE LOOP
- What do I want? What stops me? When is it off?
- What do I control?
- //@audit on every line the bad value touches, until the payout
- Where did the extra money come from?

OUTSIDE THE SCOPE
- Who else calls this code?
- What does each one do for the attacker?

SOLIDIFY
- Explain it to yourself in simple words
- Re-read the notes and look for a hole
- Move the questions into your checklist, without names

Pick one hack this week and fill it in.

That’s how you train your hacker mindset without a contest.

My GMX notes came from 3 write-ups: the Neodyme thread, the GMX post-mortem, and the SolidityScan analysis.

If you want to run the full attacker method on a real codebase with me, join the guided audit: a real audit we run together, not a course you watch.

Link

— Arsen

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:

1. Open a blank note

2. Write one lane: lending, CLMM, perps or cross-chain

3. Write one chain: Solana, or a Move chain like Sui or Aptos

4. 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:

1. List the three biggest lending or CLMM protocols on Solana

2. Next to each, note which other apps integrate with it

3. 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:

1. Make one folder named after your target

2. Save every past audit report on it

3. Add the reports of two rivals of the same type

4. 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:

1. Open a doc named after your target

2. Write five ways an app calling it could lose money

3. 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

“How do I get audit experience if nobody will hire me?”

You keep studying.

Reports, docs, random threads.

But nothing tells you whether you can actually find a real bug.

You’re not short on information.

You’re short on a codebase with your name on the work.

Today I’m sharing the 4 ways to get audit experience with no clients.

Shadow audit one big protocol nobody pays you for

A live protocol doesn’t care whether someone hired you.

It gives you everything a paid engagement does:

• the same flows

• the same money

• the same code you’d read for a client

The only difference is that nobody told you to open it.

So pick one lane and go deep on that, not on five:

• lending

• CLMM

• a launchpad

• whatever actually pulls you

While you read it, study the past public reports on the same protocol.

Then check whether the same pattern lives somewhere else in the program.

You come out with something you own: a checklist of the integration bugs that hit every team plugging into it.

Integrators repeat the same mistakes. That checklist is your edge.

My first place came from exactly this kind of reading:

• a new chain

• a new language

• the last days of the contest, out of ideas

• docs read, every line in scope read

So I went into the integrations sitting outside the scope.

That’s where the High was. $8K, one unique finding.

Everyone read the same in-scope files.

Nobody opened the other side of the integration.

Out-of-scope code has nobody else in it. That’s the whole reason to read it.

Your move today:

1. Open one live Solana lending or CLMM program.

2. Write down its three core flows: deposit, withdraw, and the one the protocol earns on.

3. That list is your scope for the week.

Take whatever opens and keep every submission public

Stop waiting for the right contest to appear.

Contests are thin right now. So take what opens:

• a bounty

• a CTF

• a one-off opening

All of it carries your name.

All of it counts as a portfolio before a client pays you.

Here’s what that looked like for me:

• Contest 1: a High, duplicated. Paid $2.

• Months 2-6: zero results. Same hours every month.

• Month 7: $400.

• Month 9: $10K for one Medium in a cross-chain codebase, the only Medium anyone found in the whole scope.

• Later: a CTF, around 500 USDC and a job offer I turned down.

No client. No permission.

Every submission stayed public, and that’s the part that compounds.

The payout is not the point yet. The public record is.

Your move today:

1. Open one live bounty or CTF page.

2. Make two columns: flows in scope, flows outside it.

3. Start reading in the right column.

Ask teams directly for a free audit

Nobody is going to invite you.

An unpaid finding sits in a portfolio the same way a paid one does.

The team reading your report never asks what you charged.

I did free audits early. I just asked for them.

Some teams ignored me. Some said yes.

You’re not asking for a favor. You’re asking for a codebase.

It’s still what I tell people who DM me. Build a portfolio with solid bugs in it first:

• free audits

• unpaid bounty reports

• a CTF writeup

Then message the firms.

The door opens on the portfolio, never on the message.

Your move today: write a five-line message, not a pitch deck.

1. Who you are

2. What you’ll read

3. What you send back, and when

4. That it costs them nothing

5. One line of proof, even a public CTF writeup

Send it to one team before you close the laptop.

Pair with one auditor stronger than you

You can’t learn what you never see.

No course shows you what a strong auditor opens first.

Or what he refuses to read at all.

I DMed a guy who had won the same $10K in the same contest.

I asked him to audit the next one together. He said yes.

We went full time, contest after contest:

• we split the flows

• we argued about the leads

• we ran brainstorms and validated each other’s leads

• we hunted one attack vector on purpose

I watched what he opened first, and what he skipped completely.

On a cross-chain bridge we placed Top 10: one High, five Mediums, $3K.

Then we split. Both of us had taken what we needed.

The method was never the missing part.

I had the method for six months while earning nothing.

Watching someone stronger work is what moved it.

Nobody audits alone. Not the firms, not the teams, not the people making six figures a contest.

Your move today:

1. List three auditors ahead of you.

2. Message one of them about splitting the next contest.

3. Say which flow you’ll take. That’s the part that gets a yes.

Nobody hands you the first audit.

You take it from public code, a free offer, and one person ahead of you.

Surface to deep

I run this as a real audit, not a course:

• two weeks

• seven people

• one live codebase with known bugs in it

Seven seats in this first run, at $299. Fewer than seven people and I refund everyone.

https://app.notion.com/p/Stop-finding-surface-bugs-3e8b025761248078af4dfbb0c5bfa7da?source=copy_link

That proof is correct.

The value it then goes looking for is one the submitter computed himself.

And it goes looking for it with a text search.

Quick refresh so we’re on the same page.

Some chains don’t mine their own blocks.

Dogecoin is one.

Miners point their hardware at Litecoin, and the same work counts for both chains at once.

That’s merged mining, and it’s a good deal.

One machine, two rewards, no extra electricity.

The proof has to live somewhere, and it lives on the parent chain:

• Every block starts with a coinbase, the transaction that pays the miner.

• The coinbase has a field with no consensus meaning at all. Free space.

• The child chain’s commitment gets written into that free space.

• Whoever mines the parent block writes that field. By hand. Anything they want.

Three words you’ll need:

• Coinbase - the first transaction in a block. Pays the miner.

• script_sig - the free-space field inside it.

• chain_root - the commitment that says which child block this work belongs to.

Now the light client.

You review the aux path and it looks like the strongest code in the file.

Merkle tooling everywhere.

Four steps, one after another.

Step one: this parent block hasn’t been used before.

Step two: the coinbase transaction is proven into the parent block’s merkle root. That one is real.

Step three: a chain_root is computed. Not verified. Computed, out of the child block hash, a chain id, and a merkle proof.

All three of those come from whoever is submitting.

“It’s covered in merkle proofs. What could go wrong?”

Read step four.

.contains().

Step two proves structure. Step three derives a number out of attacker input. Step four searches for that number.

Only one of the four is a check.

It renders the script to a hex string and asks whether the derived root appears somewhere inside it.

Somewhere.

Not at the offset the format specifies. Not once. Not after the marker bytes that say the merged mining section starts here.

Anywhere in the string is a pass.

And the field it searches is the one field on the parent chain that a miner fills in freely.

The attack is not complicated:

• miner writes their own chain_root into script_sig

• writes the honest one in after it

• both are present in the hex

• .contains() finds whichever it is asked about

• the same parent block now attests to two different child blocks

• the light client accepts the one it was handed

The merged mining format exists to stop exactly this.

There are marker bytes, a position rule, a size and a nonce, and a requirement that the commitment appear once.

None of that is checked here.

The format was replaced by a substring search.

There’s a second problem in the same line, pointing at the same cause.

.to_hex_string() and .to_string() are two renderings by two different types.

Bitcoin stores hashes little endian.

Display prints them the other way round.

So an honest submitter, handing over correct data in the byte order the chain actually uses, fails this check.

The search is wrong in both directions. It admits what it shouldn’t, and it rejects what it should take.

When you audit a commitment check, ask:

• Is this comparing bytes, or comparing strings that describe bytes?

• Does the format specify a position, and is the position enforced?

• Can the field appear twice? What happens if it does?

• Who writes the field being searched? If the answer is a miner, it is attacker input.

• Are the two sides of the comparison the same type, rendered the same way?

Most reviews check whether the value is there.

Finding a value is not the same as validating where it sits.

The usual version of this finding is a missing check.

Something absent, you grep for it, you find the gap.

Here the check is present, and it runs, and it passes for the honest case in every test.

It is the wrong kind of check, and the wrong kind of check looks exactly like the right kind until someone writes a second value into the same field.

Root cause: a structural commitment verified by substring search.

Two fixes.

1. Parse the script instead of searching it. Find the marker, read the commitment at the offset the format defines, reject the block if it appears more than once.

2. Compare bytes to bytes. The hex round trip is what let two different orderings look comparable in the first place.

The fix that shipped was neither. Access control, so only the relayer can submit blocks.

That closes the door. It doesn’t fix the lock.

Arsen

The service needs to know how an account was created.

The account is real.

Its history is real.

It still reads the wrong transaction out of it.

Quick refresh so we’re on the same page.

On Solana an account stores state.

Current state, nothing else.

It doesn’t store how it got there.

No created_at, no origin field, nothing that says which transaction made it.

That’s a good design. Accounts stay small and cheap.

But if you want the creation transaction, you ask an RPC node for the address history.

The tradeoff this bug lives on:

Three words you’ll need:

• PDA - the account the program creates for each request.

• Signature - the ID of a transaction.

• Backfill - the catch-up path. Service was down, now it re-reads what it missed.

Now the service.

The on-chain program was clean.

Zero findings there.

So you’re in the off-chain part. Rust, RPC calls, plumbing.

First pass: does it parse the account correctly? It does.

Second pass: retries, error handling, deserialization. All fine.

You never ask: what does this RPC actually promise about order?

And who else can write into what it returns?

.first(). That’s the whole bug.

And it runs once per account, inside the sweep.

Here’s the interesting part.

There are two ways this service learns about a request.

Live path: a websocket event arrives and the signature is inside it.

The service parses that one transaction, and it’s correct by construction.

Nobody picked the signature. It was handed over.

Backfill path: no event.

So the service asks for every account the program owns, then asks each account for its signatures, then takes the first one, then calls the same parsing function as the live path.

“Same function at the end. What could go wrong?”

The live path never had to choose.

The backfill path invented a lookup, and it identifies the creation transaction by position in a list.

Position in a list that strangers can push to.

The attack is not complicated:

Who pays for it: the catch-up path itself.

It’s a denial of service on backfill, not one stuck request.

Everything that was waiting to be caught up keeps waiting.

The attacker spends one lamport for that.

When you audit any off-chain service that reads chain state, check:

The model worth keeping:

The account tells you its state. It never tells you its story.

And the story is a list strangers can write to.

Everyone knows not to trust user input.

Almost nobody counts a transaction history as user input.

But that’s what it is.

It’s not the account’s own data. It’s a list a node keeps about an address, and the address is public, so the list is open.

Root cause, one line:

Off-chain identity taken from position in a list anyone can append to.

Two fixes.

1. Use .last() instead of .first(). Fixes the order, and it holds until someone spams the address - getSignaturesForAddress returns 1000 signatures max, so .last() is the oldest of that page, not the oldest ever.

2. Stop reading history at all. Put the access mode directly in the PDA, so the state answers the question and there is no signature scan left to attack.

The team went with the second one. Design review, program changed, the whole traversal deleted.

Arsen

He had $250 left to pay them with.

The protocol took the $250, marked the bill settled, then paid him $450 on top.

He should have walked away with $100.

He walked away with $450.

Quick refresh so we’re on the same page.

A perp lets you hold a leveraged long or short with no expiry date.

You post collateral, the protocol marks profit and loss against it, and you sit there forever.

Forever is the problem.

Nothing drags a perp’s price back to spot the way an expiry does.

So perps use funding, a steady payment between the two sides:

• Longs crowded → longs pay shorts.

• Shorts crowded → shorts pay longs.

• It flips whenever the crowd flips.

So funding is sometimes money you owe, and sometimes money you’re owed.

Four words you’ll need:

• Margin - the collateral you posted. Fees come out of it.

• PnL - profit and loss, applied to margin before anything else.

• Funding income - funding owed to you, when you’re on the paid side.

• Liquidation check - the function that decides if you can stay open.

Now the close path.

First pass: you read the settlement code. Every line does what it says.

Second pass: you read the liquidation check.

Also fine. Deliberate, correct, even commented.

Both files pass review. Separately.

You never ask whether the two of them are counting the same money.

“It’s a fee deduction. What could go wrong?”

Read it in order.

The clamp on line 2 is the whole thing.

Fees can only take what’s there.

A $600 bill against $250 collects $250, and the other $350 is never written down anywhere.

Nothing carries it forward. Nothing nets it against what comes next.

And what comes next is that last line. The full funding payment, landing after the books already closed.

Now the liquidation check, same protocol.

Look at that middle branch.

Fees exceed margin, the trader is receiving funding, and the check subtracts the shortfall from funding income and keeps going.

There’s even a comment on it.

Somebody sat down, thought about exactly the case where fees run past collateral while funding is owed to the trader, decided funding should absorb it, and wrote that down.

Then the settlement path was written as if that conversation never happened.

Walk the numbers.

Margin after PnL is $250.

Fees owed are $600.

Funding owed to the trader is $450.

Settlement clamps to $250, takes it, moves on.

The $350 remainder isn’t deferred. It isn’t netted. It’s gone.

Then funding credits on its own line. The full $450.

$450 out, where $100 was correct.

The gap is whichever is smaller: the funding they’re owed, or the fees that went uncollected.

A clamp that stops an underflow also forgives the difference.

The clamp itself is correct. Without it the split runs past the balance and the transaction aborts.

The solvency branch is correct too.

If someone owes you $450, you’re not insolvent over a $350 gap.

And the same ordering repeats across every exit path the protocol has.

Three call sites agreeing reads like a decision.

Consistency isn’t correctness.

Here is the whole thing as one close:

No flash loan. No oracle. No reentrancy.

You close a position at the moment funding is paying you and your fees have already eaten your collateral.

And it repeats. Every close that meets those two conditions.

The money comes out of the LP pool.

Depositors pay the funding, and they eat the fees the protocol never collected.

When you audit a settlement path, check:

Most auditors check that each function is correct on its own.

Few check that two functions share the same model of what money is.

This isn’t a missing check, and that’s exactly why it survives.

The usual version of this finding is “fee not charged” or “wrong account authorised”.

Something is absent, you grep for it, you find it.

Here nothing is absent.

Fees are charged. The cap is deliberate.

The solvency model is deliberate, correct, and commented.

The bug lives between two files that were each reviewed on a different day.

Root cause: settlement clamps then credits, solvency sums then compares.

Two fixes.

1. Do the arithmetic once. Margin, funding, fees, one number at the end, and clamp that number instead of the fee line.

2. Make the liquidation check call that same function, so the two can’t drift apart again.

The second one is what stops it coming back.

Arsen

Easy to drown in files, lines, and edge cases.

You try to read everything and end up understanding nothing deeply.

So the real questions are:

• How do I find the most critical flows?

• How do I focus most of my time there?

Senior auditors ask the same thing in one line:

How do I find the 5% of code that can kill the protocol?

You don’t always need to audit the whole codebase.
Most of the time, you need to spot a few key flows and attack them hard.

This email shows you how I do that.

The real truth

This is a skill, not a magic.

It comes from practice and from understanding how a system works.

There’s no magic tool that tags “critical flow” for you.

But you can train a simple model in your head:

1. Find the core flows.

2. Think like an attacker around those flows only.

Step 1 — Build a simple mental map

First, answer one question:

“What are the 2–3 main things this protocol lets users do?”

In contests or private audits, that often happens on a short kick-off call.
Devs walk you through:

• What the system does

• Who the main actors are

• How “normal” behavior looks like

• Which invariants must always hold

You won’t get deep understanding here.
But you’ll understand where value and trust move. That’s enough for the Initial Discovery Phase.

If there’s no call, recreate it yourself:

1. Read the docs

2. Feed them into AI

3. Scan the codebase

4. Ask AI targeted questions and verify answers against code

You’re not hunting bugs yet.
You’re just mapping the territory.

Step 2 — Abstract the critical flows

Once you know what the system does, move to logic flow abstraction.

List out:

• Main actors (user, admin, LP, liquidator, relayer, etc.)

• Where real money or sensitive state moves

• The few public functions everything depends on

Pick one/two main flows:

• Deposit

• Withdrawal

• Swap

• Position update

• Bridge transfer

Follow that flow end-to-end in code.

Ask:

• Who can call this?

• What can they control?

• What state does it touch?

• What must never happen here?

Step 3 — Mark the files that matter

At this point, you don’t need the whole repo.
You need the subset that touches your chosen flows.

Mark those files. Ignore the rest.

Here’s the tool I use to mark files and jump between them fast:

When I return the next day, I jump straight back into the same “slice” of the system.

Step 4 — Set up a thinking workspace

Your IDE is for code.
You still need a place for thinking.

Somewhere to:

• Draw flows

• Write invariants

• List attack ideas

• Capture “I don’t understand this yet” questions

I use:

Miro — for drawings and state diagrams:

Notion — for text notes:

• What each actor can do

• What must always hold true

• Where value enters and leaves

• Which assumptions I haven’t tested yet

I revisit these notes often.
Bugs usually hide where my notes are vague.

Here’s my own notes structure:

Better and clear notes = better bugs.

Case study — Raydium CLMM

Here’s how all this plays out in a real protocol.

Raydium’s CLMM uses a default tick range for its pools.
Storing all ticks is too expensive, so it limits the active range.

If you want to deposit outside that range, you pass an extension account with extra ticks.

That idea is fine.
The problem was validation.

The program didn’t verify that the “extra ticks” account belonged to the correct pool.

That one oversight let an attacker:

1. Create their own pool

2. Forge an “extra ticks” account for it

3. Pass it to a victim pool

By doing that, they could flip tick state in the victim pool.
And that state persisted.

Later swaps used the tampered tick, so liquidity accounting broke.

With a specific sequence of swaps + tick flips, the attacker inflated liquidity and withdrew more tokens than they should have.

Attacker didn’t brute-force the whole repo.

Attacker picked one flow — ticks handling

The real lesson

Complex bugs rarely show up when you first look.

You might follow one flow for weeks.
And sometimes you find nothing.

But this process scales:

• Build a simple map

• Abstract a few critical flows

• Mark the contracts that matter

• Go deep there and ignore everything else

That’s how you move from:

“I’m lost in this repo.”

to:

“I know exactly which flows can kill this thing.”