🏴‍☠️ Deep dive

The real problem comes not from knowing how to hunt for bugs, but from knowing where to hunt for them.

Bugs are hiding everywhere, but those who find the most sophisticated ones win the pot.

However, what does “sophisticated” mean?

Sometimes, it’s the attack vectors that consist of multiple steps, for example like in the Abracadabra hack.

But most of the time, sophisticated bugs are usually where people don’t dare to look.

Real truth that you must accept is that you can’t find sophisticated bugs if you don’t constantly

• analyse
• miss
• aim to find

such bugs…

That’s why I really like to study bug bounties rather than individual findings from Solodit.

Because most of the time, bounties are the product of very crazy and complex ideas, which have birthed real bugs.

Now, you have a question? OK… All seems clear.

But how can I train to find sophisticated bugs?

• Should I dedicate 10k hours into Web3 Security?
• Should I constantly study complex exploits?
• Should I develop the attacker mindset?

Let’s distill it based on an interesting and very exciting example.

When you audit the system, yes, you need to distill it to the core 15%. Yes, you need to properly time-manage the process.

But most importantly – and it’s the hardest part so far – is to think of everything as “layers” and understand that each layer has its own respective vulnerabilities, constraints, and protections.

You may audit a simple staking contract on Solana and be sure that it has no bugs…

But….

Are you sure you understand the core layers of the system you audit?

If it’s a simple contract built on Solana, which layers do we have?

We have:

1. Contract layer
2. System layer (*native Solana)

Ok. Now you see, you may understand the Contract layer, the actual staking logic precisely, but the system layer you can lack specific knowledge.

Let’s take a look at a small example from a staking contract.

What do we see??

It’s a simple transfer…

We transfer from the source PDA to the destination account a specific amount.

What could go wrong?

Yes, we lack a bit of context about what the system does, but it doesn’t matter in such a case, what matters is the simple transfer.

Let’s play around with the system layer of solana, and what constraints it can introduce that can lead to the bugs…

If you are coming from EVM, you know that when we execute the transfer of native tokens via .call, we know

• the difference between .call and .transfer
• 63/64 gas rule
• return bomb attack case

So, if you look on the function that executes the call, you intuitively think about following cases and how they can fit.

Solana is different, and each chain is different.

The future is multichain.

The future of being a solid auditor is the ability to audit many chains and have deep knowledge of each chain's behaviour.

When it comes to Solana, we may ask.

How does the native behavior of transferring native tokens work on Solana?

Once we pose such question, we will search articles, read X and watch youtube videos.

Or we will go to the native solana code and see how it works.

And what we will discover there?

We will discover that simple transfer of sol isn’t as simple as it seems and there are 3 cases where the transfer of sol can be stuck.

Bug #1 - Solana account state

Every Solana account must have enough SOL to be rent exempt

Here is what it means:

So, there are 3 states:

1. Uninitialised = no SOL at all
2. RentPaying = sol_balance < rent_exempt_min(data_len) , but sol_balance > 0
3. RentExempt = sol_balance > rent_exempt_min(data_len)

And if we take a look at the Solana run time logic, we observe that we can’t transition:

• go from rent-exempt → rent-paying
• credit lamports into a non-rent-exempt account
• go from 0 → small amount

It means, that we can leverage it, and potentially achieve a DoS scenario if it isn’t taken into an account.

Bug #2 - We can’t send SOL to an executable account.

On Solana, every account has a structure, and there’s a parameter called “executable.”

The executable flag is an old marker that tells Solana: “this account is program code.”

Because code doesn’t change, Solana treats it as read-only and runs it faster instead of handling it like a normal account.

And it means,

even if the executable is rent exempt, it will reject the direct transfer

Here’s the actual code piece from the native Solana code:

• You can create an executable account
• You can make it rent-exempt at creation time
• You can fund it as part of the same transaction (during creation / deployment)

But you can’t send the funds to it directly.

Now imagine a contract where you can store any address, and potentially achieve DoS…

This was a basic example on how solana transfers might fail.

But it teaches us more than it seems.

It teaches us that every time you audit any system you must think about the underlying systems too, that make possible to code logic to run.

Everything is a state transition.

Every state transition has rules. You must understand these rules.

• Where do the rules come from? → From native chain behavior.
• You must check native chain behavior first to understand how transitions work.

All of these bugs proceed from Solana's core.

Next time you work, you need to deeply research the native layer.

That's what "research" actually means—

Not just how the code works,

But how the underlying tech works that makes the code work.

And if you go deeper, if you look at things no one dares to look at,

You will find bugs.

For most auditors, a simple transfer would be straightforward.

But for seniors, it will be a playground for bugs.