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