DEV Community

holistis
holistis

Posted on

What actually gets paid in smart contract audit contests

I run a smart contract audit pipeline, and I keep a labeled record of what judges actually reward. I pulled 20,720 findings across 81 Sherlock contests and counted only the ones that carried a real Reward label. The thing that turned out to matter most was not the one I expected, and it corrected something I believed going in.

Most valid findings do get paid. The rate just swings wildly.

Across all 81 contests, 66 percent of submissions were rewarded. But that average hides the real story. Per contest, the paid rate ran from near 0 percent to near 99 percent, with a median of 60 percent. Twenty-three of the contests paid less than a quarter of submissions. Thirty-eight paid more than three quarters.

So the single biggest lever on your odds is not your skill or the bug you find. It is which contest you enter. Same researcher, same ability, wildly different outcome depending on the codebase, the field of competitors, and how strict the judging was.

The bug type barely matters. This was the surprise.

I expected the prestigious bugs, reentrancy and oracle manipulation, to separate cleanly from the boring ones. At 20,000 findings, they do not. Every major pattern pays inside a narrow band.

Pattern Paid rate Paid / submitted
liquidation 77% 1624 / 2118
fee miscalculation 76% 1601 / 2105
oracle manipulation 75% 1949 / 2586
mev / slippage 75% 1053 / 1410
flash loan 71% 330 / 465
rounding 70% 1480 / 2104
dos / griefing 70% 1828 / 2610
access control 68% 1241 / 1812
reentrancy 67% 548 / 820
overflow 66% 656 / 990
trusted actor 65% 4547 / 6948
staleness 65% 2983 / 4585

The whole spread from top to bottom is twelve points. The pattern you find is close to a rounding error next to the contest you picked. If you are choosing what to hunt based on which bug class feels most valuable, you are optimizing the wrong variable.

One category is worth a note for a different reason. Trusted actor is by far the largest, 6,948 submissions, nearly a third of everything. Most of it is people arguing that an owner or admin could misbehave. It pays about the same as the rest here, but in my own pipeline it is the category I reject most often, because when the only attacker is an already-trusted role, most programs do not treat it as a finding. High volume, ordinary hit rate.

Claiming High barely helps, and it rarely survives.

Findings submitted as High got paid 74 percent of the time. Findings submitted as Medium got paid 65 percent. A real but modest gap.

The bigger tell is what happens to the label. Only 10 percent of findings submitted as High actually ended up rated High. The other 90 percent were downgraded or dropped. The market over claims severity by a wide margin, and the judges cut most of it back down.

Even when you win, sometimes you split the pot.

17 percent of the findings that got paid were duplicates. Real bugs, but someone else reported the same thing, so the reward was shared. It is not the majority, but it is common enough that finding a bug others will also find is worth less than finding one they will miss.

What this is, and what it is not

The sample is 20,720 findings across 81 fully crawled Sherlock contests from 2024. Every one of these contests has its complete finding list, not a partial crawl. It is one platform and one year, so treat it as a large slice, not the whole market.

I count a finding as paid only if it carries the Reward label in the public judging result. That counts each individual submission, including duplicate submitters who shared a payout. Confirmed but unrewarded, disputed, and rejected all count as not paid.

Each finding is tagged by bug class from its title and judge notes. Reasonable people would tag a few differently. The direction of the numbers is what matters, not the second decimal.

One honest note on method, because it is the whole point. I first ran this on a small set of 10 contests and got a very different picture, a low overall pay rate and reentrancy on top. When I widened it to 81 contests, both of those flipped. The small sample happened to be full of low paying contests. That is exactly why the contest you pick matters more than the pattern, and it is a good reminder that a clean looking number from a small sample can point the wrong way.

Try it

The skill all of this rewards is judgment: before you spend a submission on a finding, knowing whether it will actually be rewarded, or whether it is a dup, a known issue, or an argument the judges will wave away. I built the judge I use for exactly that, and it is live and free to run:

npx al-mizaan-judge

It runs your finding through a strict 7-gate validity check and tells you where it would fail and why, before you spend the submission. Package: https://www.npmjs.com/package/al-mizaan-judge

If the verdict surprises you, or you just want the full data behind this, leave a comment or reach out. I read everything.

Top comments (0)