Top-1 Must-Have Skill for Security Researchers
This one is significant.
Play close attention.
Since it destroys 80% of auditors, including ones with a strong track record.
It’s simple:
You believe you’ve found all the bugs — and you stop early.
This is the most common self-inflicted mistake in Web3 security.
Not because you’re unskilled.
But because your brain wants comfort.
Auditing is mentally hard.
You stare at the same lines for hours.
You stretch your mind to generate new attack angles again and again.
And the moment you feel like you’ve “made progress,” your brain tries to convince you:
“Good job. Enough. You’re done.”
This is the trap.
And there is only one rule that breaks it:
Bugs always exist. Hunt until the last second.
Remember it.
Stick it into your audit identity.
This rule alone will change your entire progress curve — because it forces your brain to stay in attacker mode instead of comfort mode.
And 2025 proved this point brutally well.
Balancer — broken.
GMX — broken.
After years of operation.
After multiple audits.
After thousands of eyes.
And you still think a 3-4 week audit means “everything is covered”?
Let me show you the moment that permanently completely changed me.
Early 2025.
I was collaborating with very well known audit firm
This specific audit was conducted by use a 2x2 structure:
Two auditors vs two auditors, competing on the same repo.
It’s one of the most effective ways to boost curiosity, aggression, and pace during an audit.
But the strongest part isn’t the competition.
It’s the scoreboard.
You can’t see the issues themselves — but you can see how many H/M/L the other team has found.
Now picture this.
Last day of the audit.
I slowed down.
I thought the repo was empty. I convinced myself that the hard bugs were already found.
Then a message pops up:
“Other team is 1H ahead.”
- Instant adrenaline.
- Instant humiliation.
- Instant clarity.
I closed everything I was doing — restaurant, cinema, didn’t matter —
opened my laptop and hunted like an animal.
Example link
To understand this bug, you need just one idea:
Collateral and PnL are updated through different mechanisms.
- Collateral updates through:
modifyCollateral()or_settleOrder() - PnL updates only when you call:
_settleOrder()
Meaning:
Your collateral does NOT include PnL until you commit-settle.
But the vault’s redeem logic assumes the opposite.
Where Things Break
The redeem flow calls _valueToRedeem():
valueToRedeem = totalAssets() * (shares / totalSupply)
And here’s the problem:
totalAssets() includes PnL — even if it’s NOT settled yet.
So the vault uses unrealized, un-settled PnL as if it already exists as collateral.
Then, during actual withdrawal, the vault calls modifyCollateral:
modifyCollateralworks with real collateral tokens only- It cannot withdraw unrealized PnL (because it’s not collateral yet)
This creates a mismatch.
And every single time similar push, I found something I would’ve missed if I relaxed.
This is the truth nobody wants to admit:
If you want to grow, you must hunt actively — until the last second. Not until you're comfortable. Until the code is empty.
This is the difference between plateaus and breakthroughs.
Between $2k bugs and $200k bugs.
Between staying mid and becoming senior.