Rhaydden retweeted
Replying to @jack__sanford
Jack, you are looking at only one side of the coin. Honest researchers submitted to contests, and their valid findings got downgraded or invalidated. Let's not say the judging is always perfect: I am a judge myself, and I know how it works from both sides. This happened to me many times as well.
I personally know strong researchers sitting below that threshold. The ratio is a signal you use for Audit Engine invites. Your 120-day window only helps them if they get a seat, and you decide who gets one. So, effectively, you are unilaterally forfeiting their rewards.
Coming back to the legal argument. These were the public conditions under which SRs have been doing their work: web.archive.org/web/20260612…
> 1. Until you've submitted 2 valid issues ...
> 2. Your "issues ratio" must be >=20% ...
> If you don't pass either of these criteria at any time, your USDC payouts will be withheld until you pass both criteria, at which point they'll be paid out in full.
That is a promise to pay in full once both criteria are met. You are cutting off the way to meet them. Contests in the previous format are gone. On Audit Engine, you decide who is invited.
You are sunsetting one platform, and bringing up a completely new one.
The honest approach is to stand by that promise: pay the calculated amounts for the accepted findings, or leave the condition open until those SRs actually have a chance to meet it.
I have nothing more to add here.
Replying to @sherlockdefi
@sherlockdefi announced yesterday that it will deprecate its Contents model and replace it with the Audit engine module, which they consider better.
The problem comes with the condition that Sherlock sets, which is that you need to have a validity score >= 20% as well as two valid issues to receive payouts.
In my opinion, this is unfair to SRs, and here is why I see it as unfair.
1- Sherlock in most of its contests, doesn't accept low issues, so the validity score itself is not accurate, valid Low issues are treated as invalid, even issues that was accepted as Medium/High and after long escalation war it gets downgraded to low.
2- A lot of contests end with invalidating an issue because of unclear docs, unclear scope and out-of-scope files. Issues get accepted, and then the Judger can make it out of scope; the Developer can mention that this is intended behaviour managed by off-chain systems. So new inputs coming after the contest finishes invalidate findings, which affects SRs validity threshold. I have examples for these situations.
3- A lot of recent contests were invite-only contests, picking only the top. So the new SRs didn't even have the chance to participate in these contests.
Because of these points, I see it is unfair to prevent paying SRs.
These are the points that make the system itself can't sustain this condition.
This is the decision compared to the system; I haven't talked about the morality of the decision itself, and how you dare to take another person's money.
- Some people may have left the space.
- Some can get into full-time positions and have no time.
- Others may need that money.
The 120-day period will not solve the problem; you don't know who still depends on contests and who does not, who left the space and who still, a lot of conditions, and this solution will not solve many of them.
I can't imagine how to have a clear conscience, and you are taking others' money.
Rhaydden retweeted
FYI: This is a North Korean approaching several SRs to do the classic "here's the link for the interview".
linkedin.com/in/oscarbankles…
So in case he approaches you on Telegram or LinkedIn, you already know. :)
Be careful out there, folks.
Rhaydden retweeted
The @Coinkite coldcard situation is really disappointing.
They are a smaller player in HW that did try hard.
I always had an interest in hacking hardware and at some point planned to do some research on their device, which might be easier than a Ledger for example.
Also I liked their idea of using physical dice for entropy.
Never got around to it (or any other HW for the matter).
Now I guess it doesn’t matter much?
A reminder that security requires many eyes and you cant get that without a large user base and serious budget.
Rhaydden retweeted
I used to think one of the barriers to entry in bug bounties was the ability or willingness to go long stretches of time without being paid.
But now we see so many people willing to go very long stretches of time burning money on tokens hunting for bugs, not getting paid, and when by any chance they get paid doubling down and burning money even faster.
I guess I have to thank Anthropic and OpenAI for making that obvious.
Rhaydden retweeted
If you're interested in catching chain halts, here are some ideas:
Consensus critical paths:
- Check consensus invariants and how to break them -> halt
- Check functions that should always succeed, but you find a way to make them fail or revert for everyone every time -> halt
- Check functions that should always return a response (success or failure), but you can make them panic -- unexpected side effect or missing recovery mechanism.
- Look for possible sources of non-determinism -- may lead to chain halt or fork
Risk profiles:
- Halt the production of blocks
- Halt the production of proposals
- Halt the processing of transactions
- Halt the p2p communications
- Halt the processing of txs
- Crash validators consistently
- Crash critical dependencies consistently
Attack Surface:
- Trace back the critical paths, and the components that could be broken
- It may be a malicious transaction by any user, or a malicious p2p message relayed to the nodes
- It could be a rogue validator with a malicious proposal
- The chain might read events from contracts. It could have a light client checking things happening on other chains.
- It could be time based, or something that happens on specific blocks, or during some special event.
- There might be issues in dependencies that aren't critical anywhere else, but they lead to a more severe impact in some specific flow
- The chain could have special roles that could be vulnerable to specific attacks
Resource exhaustion:
- CPU: make validators spend too much time computing transactions or blocks -- they won't make it in time for agreeing on the block
- Memory: crash validators with OOM errors
- Storage: bloat the disk space
- Invariants: bloat some resource invariant, like consistently surpassing the block size, or tx size, making proposals fail.
Caveats:
- Most bugs aren't vulnerabilities. Learn how to code an e2e PoC for a network.
- Not every panic leads to a crash. They're often gracefully caught.
- Not every crash leads to a chain halt. You may crash the RPC node, but not the validators
- A chain might have different clients, and the overall impact may not lead to a chain halt
- Permissionless attacks are more dangerous than ones that require a validator
- Panics in transactions are usually caught by the execution layer
- If the impact is that your tx reverts, there's no impact. If the impact is that your proposed block is rejected, there's no impact.
- Chains have different consensus mechanisms and caveats. The same vulnerability won't necessarily lead to the same impact.
There's a huge overlap with other impacts. The same core vulnerability could be exploited for a chain halt, or could be used to take down validators to gain consensus, or could be abused to lead to a chain fork, or other issues. It's also possible that it doesn't lead to any real impact too.
It's up to you to assess the most critical impact.
Hacking Google with A.I. for $500,000
brutecat.com/r/hacking-googl…
Rhaydden retweeted
I hope one day people realize that any project without a healthy bounty program is vulnerable to critical exploits.
Rhaydden retweeted
Balancer Hack Part 4: Breaking the protocol was the easy part. Escaping with the money was the hard part.
Every successful exploit needs three things:
1. The right state.
2. The exploit.
3. A way to get out with the profit.
Most researchers focus on #1 and #2.
But #3 is often what determines whether a bug is actually exploitable.
In Part 4 of my Balancer hack series, I break down how the attacker escaped after manipulating the invariant.
They had to overcome two major obstacles:
• Internal defences: Balancer reverting with errors
• External defences: MEV bots waiting to steal the opportunity
The result is a practical playbook for turning a theoretical vulnerability into a feasible exploit.
If you've ever found a bug and wondered, "Could this actually be exploited?" this article will change how you think.
Read it here: open.substack.com/pub/rehack…
Your next high-severity finding may not need a bigger bug.
It may just need a better escape route.
NEW: Balancer Hack, Part 3 is live.
Title: Turning Rounding Errors into Invariant Collapse.
This is where we stop theorising about the rounding bug and start weaponising it.
The article walks through the exact swaps that force Balancer to undervalue its own pool and repeatedly crush the invariant.
What makes this stage fascinating is that Balancer fights back hard:
• swap overflow errors
• Newton-Raphson quote failures
• repeated transaction reverts
The hacker still manages to bend the protocol into a stable exploit loop.
Full breakdown: open.substack.com/pub/rehack…
Rhaydden retweeted
What if RISC-V had 1024 registers instead of 32? Can that solve register spilling & improve zkVMs? Claude and I implemented this experiment in LLVM's RV32 backend and integrated it with OpenVM for e2e proofs.
Full results and write-up link below \/
Rhaydden retweeted
After months of work, I’ve published Part 1 of my Balancer Hack series.
This isn’t a post-mortem — it’s a guided walkthrough inside the attacker’s mind.
We follow the thinking: spotting a subtle bug, hitting dead ends, refining ideas… until it becomes a full exploit.
I wrote it to be experienced, not skimmed.
Would love your thoughts.
Huge thanks to @adeoluwami__ 🙏 for the review.
rehackt.substack.com/p/balan…
Rhaydden retweeted
I've created a site to share some ideas.
My first post is about being a professional whitehat, and how I evaluate potential rewards to decide where to hunt.
whitehatmage.github.io/posts…
Rhaydden retweeted
Your security goal as a project with live code is to get whitehats engaged with your code for the long run.
Incentivize hunters to check the code with a good bounty. Attract them with any other policies.
Make it easy for them to discover your assets, and to run experiments.
Rhaydden retweeted
Results and lessons from ~1yr (2025) of full-time BB on @immunefi
- 3 bugs marked as Crits and paid
- 2 Crits confirmed but not paid for >5-6 months
- spent ~3 months on this project
- the project has been unresponsive for months now
- just recently the BBP was paused
- I’m hoping they’ll pay eventually; it would be my biggest payout so far, but the chances are pretty slim
- the project even paid me for a different bug and has paid other people before, but decided to ghost here
- TVL, max bounty, and fees (from DefiLlama) show the project is an active medium-sized one with solid fee income, not some abandoned thing
- you never know if you’ll get paid or not and you have zero leverage
- 0 dups, so that’s probably good
- My income was lower than from contests in 2024, those 2 unpaid Crits would make a big difference
- If you check the immunefi leaderboard for 2025, you can see the number of paid reports is usually not that big, most often single digits
- compared to contests where you can find 10s or 100s of bugs per year, the variance in payouts is much higher
- it often comes down to 1–2 bugs per year that pay >50%, so if you don’t get paid on those you take a big hit
- It was motivating in the first months when I got several Crits
- But later I had much less motivation because
- long payment times
- long reply times (SLA is almost never respected)
- fewer bugs found, less feedback
- zero communication with the project before you submit the bug
- Strong upward and downward spirals: good results => learn more => get better, and the opposite
- What I like about BB
- you can go as deep as you want, as slow as you want, into so many projects and rabbit holes
- full freedom, no deadlines, no responsibilities, no schedule
- escalations on Immunefi work slowly (1–2 months+ usually) but they go deep into the issue
- feeling appreciated, even a simple “good find” after a month+ on a project makes you feel it wasn’t in vain
- What I didn’t like
- you are ignored all the time
- you never know when the project will reply, sometimes it’s month+
- you never know when Immunefi will reply on the issue, even if you ping in Discord you may just get something like “we are looking into it, will reply to your escalation asap” and then it can still take month+ to get a real answer
- no communication with the project, you need to learn everything on your own
- hard to navigate all the rules and define category and severity, and since you submit bugs so rarely the bureaucracy feels new every time
- issues can be closed with no explanation, you work for months and just get “Closed, out of scope”, then you ask and it turns out to be more like “no fix no pay, if this loss happens we will just top up the contract from treasury”
- you often feel low-balled, sometimes it might really not be a C but an M, but more often than not it feels like your effort is underappreciated
- overall it feels more lonely than contests
- you talk with the project or Immunefi maybe once a month or once every few months
- most of the time it feels like talking to the enemy, me against them, the project wants to pay less and pay later, you want to get more and get it faster (at least respect the SLA)
- it doesn’t feel like you are on the same side, more like you are in a fight
- no shared chat or common context like in big contests when all of X/Twitter is talking about a single project (see Maker contest), here you are hunting on your own
- Some thoughts on why the results are worse than I expected (and worse than last year in contests)
- Jump between platforms?
- each platform has its own rules, what gets paid in contests and is appreciated in private audits can be closed with no explanation in BB
- so it might be that I was looking in the wrong places and spent my time on leads that were never going to be paid anyway
- Didn’t learn enough?
- on BB you miss a lot of the learning aspects of contests, if you miss something in a contest you usually learn about it pretty soon, but in BB you don’t have that feedback loop
- you don’t really see how you compare to others (did they just get lucky, was I just unlucky, did I just choose the wrong project), without competition there is less motivation to learn and improve
- Bad pace?
- when you have so much freedom and almost no feedback, motivation slowly goes down, and your speed goes down with it
- No team? No social?
- I know this is my biggest leak overall, but in BB it’s an even bigger problem than in contests
- after a contest a lot of people want to discuss it, the issues, the mindset, the meta-game, etc
- less motivation to do X/Twitter, because it feels like if I share what I’m working on it might attract others to the same projects and I’ll start getting dups. And overall it feels like it’s me against the world, so why share (not necessary true)
- Going too deep into things that are not fruitful?
- with no deadlines and no pressure it’s very tempting to just explore how some tech works, just for fun
- hard to say if that will eventually pay, and it’s harder to stay focused on the most dangerous places
- I tend to spend months on one project, which is very risky if they don’t pay, and there are diminishing returns for most projects after 1–1.5 months
- if I didn’t go that deep into every area I don’t fully understand, maybe it would be more like 2–4 weeks per project
- I often feel like I need to check every idea I wrote down, but in reality the top ideas (marked as high probability by me) are the ones that pay, and 90% of other ideas are good for learning but probably not worth the time
- Maybe no talent? No skills?
- hard to judge myself
- overall there are some signals that I’m not that bad, 6 confirmed Crits in a year is probably ok
- Too inflexible?
- when I first came to audits I followed a very checklist-heavy approach
- now I’m more intuitive, I try to see what feels fishy, but I still rely on checklists and on going through the early ideas
- I lean heavily on AI, it’s a new thing I picked up that changed my approach a lot
- the projects I choose are mostly in my area of expertise and interest, maybe trying new languages or new types of protocols would help
- Bad mindset?
- many BB hunters jump quickly between projects, I still treat it more like a private audit and stay on one project until I feel there is nothing more I can do
- many people do something like a 1 week intuitive scan and then move on
- many work on several projects in parallel
I'm still thinking about what to focus on in 2026
Right now I'm pretty tired of BB, but that might change after a break
So probably some contests, maybe joining a team if I find one
I usually set my yearly goals in January, so there's still some time to think and decide on the direction
Thank you @immunefi and @FolksFinance for the opportunity 🙏🏻
🚀 The $30K @FolksFinance Wormhole NTT on Algorand Audit Competition is officially a wrap! 🎉
🔥 100% of the reward pool has been paid out!💰
🏆 Top Winners:
🥇 @0x_DyDx – $10,980
🥈 @_uhudo – $9,415
🥉 @rhaydden – $8,460
4️⃣ @yashar0x – $573
5️⃣ @Afriauditor – $573
Huge congratulations to all the winners and a big shoutout to every researcher who participated! Onward to the next hunt! 🚀
Rhaydden retweeted
Today, around 7:48 AM UTC, an exploit affected Balancer V2 Composable Stable Pools.
Our team is working with leading security researchers to understand the issue and will share additional findings and a full post-mortem as soon as possible.
Because these pools have been live onchain for several years, many were outside the pause window. Any pools that could be paused have been paused and are now in recovery mode.
All other Balancer pools are unaffected. This issue is isolated to V2 Composable Stable Pools and does not impact Balancer V3 or other Balancer pools.
Balancer is committed to operational security, has undergone extensive auditing by top firms, and had bug bounties running for a long time to incentivize independent auditors. We are working closely with our security and legal teams to ensure user safety and are conducting a swift & thorough investigation. We’re grateful to our partners and the broader DeFi community for their support.
Security notice: Fraudulent messages claiming to be from the Balancer Security Team are circulating. These are not from us. Do not interact with unsolicited communications or click unknown links.
Official updates will be posted only via:
- This official Balancer account on X (Twitter)
- Our official Discord server
Be careful with communications from other sources, they can be fraudulent.
We will provide a comprehensive update with more details as our investigation progresses.
The Balancer Team.






















