Why We Only Put Proven Auditors on Your Code

Every audit firm's website says they have top auditors. Ours does too. So the phrase on its own tells you nothing. What matters is what a firm means by it, and whether you can check.

Our rule at Valves is simple: nobody touches client code unless they have public, verifiable results, and a nice CV doesn't count as one.

Below is why we're strict about it, plus a list of questions you can ask any audit firm before you sign. Including us.

Three against a thousand

Picture a race. Two teams get the same codebase and the same deadline. On one side, three proven security researchers. On the other, a thousand juniors and researchers who haven't proven themselves yet.

Who finds more critical bugs?

Common sense says the thousand. More eyes, more bugs. In our experience the three win, and it isn't close once you only count the findings that could actually drain the protocol. The big team will find plenty, but mostly the same things. Expect the same missing zero-address check four hundred times, each with a slightly different title.

The small team wins because experience changes how you read code.

An experienced researcher has seen the same root causes in dozens of disguises: a rounding error in a vault, a stale price in a liquidation, a signature that can be replayed on another chain. They don't read your code cold. They read it asking “where does this break?”, because they've already watched protocols like yours break.

They can also tell a bug from a quirk. Spotting a weird line is easy. Knowing whether it's exploitable, how bad it is and what the right fix is, that's the actual job. Experience is what tells you the weird line on 212 is a critical and the weird line on 87 is just how your dev likes to write loops. For you, that means a report you can act on: a real attack path, a proof of concept for the serious issues, and a fix that doesn't introduce two new bugs.

And they go deep. The fix for a critical bug is often a single line. Finding it is another story. It can mean holding three contracts, two external integrations and an assumption buried in a code comment in your head at the same time, for days.

Private audits also have their own rhythm. There's a fixed scope, a deadline, your developers in a shared channel and a report that has to make sense to people who didn't write the code. Our researchers have done many private audits. They scope properly, ask the awkward questions early, spend their time where the risk is and deliver when they said they would. That only comes from doing it.

What “proven” means to us

You can't call someone proven without a scoreboard. In web3 security, the most honest scoreboard is public audit contests on platforms like Code4rena and Sherlock. Hundreds of researchers look at the same code, every valid finding is public, and the judges don't care what's on your LinkedIn.

That's where we come from. Our founders have top-3 finishes in multiple contests with more than 3,500 participants combined, including:

Contest	Platform	Result
Panoptic	Code4rena	#1
SukukFi	Code4rena	#3
Monolith Stablecoin Factory	Sherlock	#3

Those results are public, so you don't have to take our word for it. Everyone who audits with us is held to the same bar: a public history of valid, high-severity findings on real protocols.

We care about auditor skill enough that we built the Valves Security Auditor Training Hub, where people train on challenges built from tens of thousands of real audit findings. Training is how the next generation of auditors gets good, and plenty of them will be on those leaderboards soon. Deciding who reads your code today is a different question, and for that we only look at results.

Contest or private audit?

Since we keep bringing up contests, you might wonder whether to skip the firm and run one yourself. They're good at different things.

A contest puts a lot of researchers on your code at once for a fixed prize pool, and some of the best people in the space compete. But you don't choose who shows up. One contest draws a dozen top names, the next draws mostly newcomers, and you only find out which one you got when the results come in. In a public contest your code is public too, communication with researchers is limited, and fix review isn't always included.

A private audit is the opposite trade. You choose exactly who reads your code, it stays private until launch, your developers talk to the researchers every day, and fix review is part of the deal. You're paying for a known team instead of whoever the prize pool attracts.

	Public contest	Private audit
Who reads your code	Whoever the prize pool attracts	Researchers you chose
Number of eyes	Many	A few, all proven
Code confidentiality	Public	Private until launch
Talking to researchers	Limited	Shared channel, daily
Fix review	Not always included	Included
Predictability	You find out when results come in	Known team, known timeline

Plenty of teams do both: a private audit first to catch most of the issues, then a contest or a bug bounty for extra eyes. If the budget only covers one before mainnet, pick the one where you know who's looking.

Questions to ask any audit firm (us included)

Before you sign with anyone, ask:

1. Who exactly will audit my code? Names or handles, not “our team.” If they can't or won't tell you, that's an answer too.
2. Where can I see their results? Public contest profiles and leaderboards (Code4rena, Sherlock, Cantina, CodeHawks), or public reports with their names on them.
3. Have they audited something like mine? Someone brilliant at AMMs isn't automatically brilliant at bridges, lending or Cosmos chains.
4. Can I read a past report? Look at the highs and criticals, not the page count. Sixty informational notes and zero real bugs is padding.
5. Is fix review included? A finding isn't fixed until someone checks the fix.
6. How many researchers, and for how long? One person for three days on a 5,000-line lending protocol is a skim.

And watch for these red flags:

Red flag	What it usually means
Any kind of guarantee	“100% secure” doesn't exist, and anyone who promises it either doesn't understand security or hopes you don't.
Half the price and a week faster than everyone else	Something is being cut, and it's usually the reviewing.
Senior names on the proposal, different people on the code	Put the auditors' names in the contract.

What a useful finding looks like

When you read a sample report, pay attention to how the findings are written. Here's the same bug written up twice. (It's the reward griefing bug from our article on AI and audits.)

The first one tells you something looks off. The second tells you how bad it is, proves it and gives you a fix you can ship.

What you get with Valves

• Every researcher on your audit has a public track record you can look up.
• Several researchers per audit, each with their own tools and approach (here's why that matters).
• Manual review first. AI helps us get through code faster, and people decide what's a bug.
• Clear findings: what's wrong, how bad it is, how it can be exploited and how to fix it.
• Fix review included.