Report It Anyway

01Why report it anyway

If you find a bug and sit on it, you're choosing to let users carry the risk. "They don't have a bounty program" doesn't change that. The code is deployed, the money in it is real, and if my pipeline found the bug, someone else's can too.

So the first email always says the same thing: I'm not asking for anything. No bounty, no pitch. It's a responsible disclosure. Here's the bug and here's how to reproduce it.

It's the right thing to do, and that's reason enough. What I didn't expect was everything that came back.

02The teams I remember most

I'm not a bounty hunter or an auditor, and I haven't found a six-figure or million-dollar bug (yet). Still, 25+ teams have paid something, and people surprise you. My biggest bounty came from a team with no bounty program at all. But the ones I think about most are the small ones.

Some teams paid a little, not because they're cheap but because they genuinely don't make much money. A co-founder of a DeFi infra project wrote to me about exactly that:

Exhibit A

“Although we don't currently have any active bounty program, due to financial constraints and market conditions in general, we still must thank you for such a contribution.”

A tiny team sent $100 with a kind note. Another rated my report informational and paid about $50 anyway. They could've just not, and I'd never have known.

I really appreciate the gesture. They're not paying because they have to. They're paying because they respect the work and want researchers to keep showing up. It's not much, but it's honest work.

And a lot of the time there's no money at all, and that's completely fine. A liquid staking protocol that was winding down couldn't pay, but they shut deposits the same day. This one made my week.

Exhibit B

“It is the most complete and careful report our program has received”

One maintainer's whole reply was this:

Exhibit C

“Thank you! Fixed :)”

That's honestly the best version of this job. The bug's gone before someone else finds it.

03What I found

My favourite find is also the scariest. A large DeFi protocol, live and audited many times over, had a bug that let tokens be minted with nothing backing them. Millions of dollars' worth, across multiple chains, enough to drain the liquidity behind them. They patched it and paid a bounty. No bounty program, it all started from a cold email.

Most reports weren't that dramatic. Here's how the ones I rated broke down, and what kind of bugs kept coming up:

I'm not a great bug hunter, and the chart shows it. Most of what I find is Medium or Low, and plenty of it would be out of scope for a bounty program. I send it anyway. I don't want their money. If there's even a small chance a team doesn't know about it, they should get to fix it.

So if you're a security researcher reading this, you're probably way better at finding crits than I am. All the more reason to send yours.

Not everything needs to be a crit, but here's some of what I found. A DEX where outsiders could walk off with other users' order proceeds. A permission bug that could send a user's approved token transfer to someone else's wallet. A lending protocol undercharging interest and quietly losing revenue. One bad peer response that could freeze a blockchain node. Six bugs in a zero-knowledge cryptography library, all fixed within a month. And a forum misconfiguration a colleague found, which we reported to about 40 DeFi governance forums at once.

Most recently I've been looking at account takeover risk in crypto npm packages. You always hear about npm worms and hijacked packages hitting wallets and frontends, so I started checking which maintainer accounts were exposed and warning the maintainers before anyone else noticed. Within a day of the first emails, plenty of them had already locked their accounts down. More on that one when it's wrapped up.

04How the pipeline got here

The prompt really is that simple. What comes out of it isn't. Even the Anthropic researcher from the talk said they had hundreds of kernel crashes they wouldn't send to anyone until they'd checked them. Finding something that looks like a bug is easy. Finding a real one, in deployed code, that nobody's reported yet, is the hard part.

Big models, few targets. I started with swarms of the most expensive models I could get. They were good, but slow and pricey, so I could only point them at a handful of targets. And I made the classic mistake: I kept iterating without a benchmark. Every change felt like progress and I had no idea if it actually was. The systems turned into spaghetti.

One simple prompt. So I went the other way: one simple prompt, run wide. It worked, sort of. It found real bugs. But the duplicates were insane. Everyone's pointing the same models at the same code, so everyone finds the same things.

Small agents, obsessive validation. What actually works is swarms of smaller agents and a ridiculous amount of care on validation. Every time the AI fooled me I added a check, and over months those checks built up like calluses. These days a candidate only survives if a proof of concept runs on a fork against the real deployed contracts. No storage edits, no mocked calls, real addresses. Then I read it myself, cut anything the PoC doesn't actually prove, and send it.

The other thing I learned the slow way is benchmarking. Running on live targets is a terrible feedback signal, because "found nothing this week" tells you almost nothing. You need a good internal benchmark, iterate until you fit it, then check on cases you didn't tune on so you know you're not just overfitting. It costs a lot to run the same cases again and again. It's still cheaper than flying blind.

Most of those calluses came from the same handful of mistakes:

05What I'd do differently

When I trusted the pipeline too much, it showed. Some reports came back wrong, duplicate or intended design, and one team told me they'd stopped taking emailed reports entirely because of AI-generated noise. Fair enough, some of that noise was mine. Now I challenge every verdict before it goes anywhere.

Early on the AI wrote my emails, and sometimes sent them too. They read like it. Now I use a humanizer skill I tuned to how I actually talk, so they sound more natural. If a person is going to read it, it should sound like a person wrote it.

06If you're on either end of this

If you run a protocol and get one of these: sorry about the slop. A lot of what lands in security inboxes now is AI-generated. But you're the best-placed person to triage it, because you know your own threat model. Use AI on your side too. Keep your past reports, the real ones and the false positives, and use them to teach your triage what matters for your protocol so it gets better over time. And reply, even if you can't pay. "Thanks, fixed" goes a long way.

If you're a researcher and nervous about cold-emailing a team: just send it. Have the AI draft it if you want, read it over so it sounds like you, and press send. Worst case, nobody replies.

07Report it anyway

Most teams can't pay and a lot won't reply. I'd still send it, every time. If I found it, someone else can too. If you run a protocol and want a second pair of eyes, or you're working on something similar, my DMs are open.

08Receipts

Real emails, names and individual amounts blacked out.

Exhibit D

“We would like to offer you a [amount redacted] bounty for your responsible disclosure.”

Exhibit E

“Cannot believe we all missed this, me, all the AI audit and the human auditor.”

Exhibit F

“The issues are resolved:”

Exhibit G

“You were precise about both what the finding *is* and what it *isn't*”

Exhibit H

“None of that is a comment on the work itself, which was accurate, reproducible and correctly rated.”

Exhibit I

“We reviewed your report and implemented a fix because of it.”

Exhibit J

“We have addressed the issue.”