The quality of a smart contract audit is decided by the people who read the code. That is why Kann Audits sets a clear, verifiable bar for every researcher it works with, and why that bar is built on results from bug bounties and competitive audits rather than titles.
The Researcher Is the Audit
A firm's name appears on the report cover, but the findings come from the specific people who read the code. Two audits with the same scope and the same logo can produce very different results depending on who is assigned, how much relevant experience they bring, and how carefully they test the protocol's assumptions.
For a protocol team, the most useful question is therefore not which brand performed the review, but who did the work and what evidence shows they can find serious bugs. That is the question Kann Audits answers with its researcher bar.
Our Bar: 50+ Valid Bugs and $50,000+ Earned
Kann Audits only works with security researchers who meet two public, verifiable thresholds: at least 50 valid bugs found and more than $50,000 earned from bug bounties and competitive audit contests.
Both numbers matter. The finding count shows that a researcher has repeatedly identified real issues across many codebases rather than getting lucky once. The earnings show that those issues were significant enough for protocol teams and independent judges to pay for them. Together they filter for people who consistently find what others miss.
Valid findings and bounty earnings are awarded by protocol teams and independent judges. They are evidence produced outside of Kann Audits, which is what makes them a useful bar.
Why Bug Bounty and Contest Results Are Strong Evidence
Competitive audit contests and bug bounty programs are adversarial by design. Researchers only get paid for findings that are accepted as valid, duplicates are shared or discounted, and invalid submissions earn nothing. Many contests attract a large number of experienced participants looking at the same code at the same time, so earning consistently means finding issues that a crowd of other researchers did not.
That makes these results a better signal than self-reported experience. They are tied to real code, judged by someone other than the researcher, and often public. They also reward the skills a private audit needs most: understanding a new codebase quickly, reasoning about business logic and economics, and writing a clear, reproducible report.
| Signal | What it shows | What it does not show on its own |
|---|---|---|
| Valid findings count | Repeated success finding real issues across many codebases | Experience in a specific language or protocol type |
| Bounty and contest earnings | Findings were significant enough to be paid for by teams and judges | Ability to communicate during a private engagement |
| Judged severity | Independent validation of impact | Familiarity with the exact architecture being audited |
| Published reports | Writing quality, rigor, and remediation follow-through | Performance on code the researcher has not seen |
What We Look for Beyond the Numbers
Thresholds keep the bar high, but they do not decide who fits a particular engagement. Kann Audits also looks at how a researcher thinks and works with a protocol team, because an audit is a collaboration as much as a hunt.
Technical depth
- Solidity and the EVM
- Rust and Move
- Go and DAML
- Zero-knowledge circuits
Adversarial reasoning
- Business logic and invariants
- Economic and oracle attacks
- Cross-contract and cross-chain paths
- Access control and upgrades
Evidence
- Proofs of concept
- Precise reproduction paths
- Accurate severity
- Root-cause remediation advice
Communication
- Clear written findings
- Fast clarification with developers
- Constructive fix reviews
- Respect for confidentiality
How Researchers Are Matched to an Engagement
Every engagement starts with the scope: the languages, ecosystems, protocol category, integrations, and risk profile of the code. Researchers are then selected whose track records match it, for example lending and liquidation experience for a money market, or privacy and cryptography experience for a confidential DeFi system.
Engagements are typically staffed with 2 to 4 assigned researchers. Each researcher reviews the codebase independently at the start, which avoids anchoring everyone on the same first impression. The team then holds collaborative review sessions to share findings and explore additional attack vectors in the highest-risk areas.
What This Means for Your Audit
A high researcher bar shows up in the report. Findings come with evidence, severities reflect real impact, and recommendations address root causes rather than symptoms. Fewer unvalidated warnings reach the protocol team, so engineering time goes into fixing real problems.
It also shows up in continuity. Teams often return to the same researchers for upgrades and new features, which is part of why Kann Audits reports a 99% client return rate. You can review the results of this approach directly in our published audit reports.
If you are still comparing providers, our comparison of smart contract auditing companies explains how different firms staff and run their reviews.
“The strongest audit firms are built from researchers who have already proven they can find what others miss.”
Questions About Kann Audits Researchers
Short answers about how Kann Audits selects, matches, and credits its security researchers.
How does Kann Audits select its security researchers?
Kann Audits only works with security researchers who have a proven public track record: at least 50 valid bugs found and more than $50,000 earned from bug bounties and competitive audit contests. Beyond those thresholds, researchers are assessed on technical depth in the relevant stack, the quality of their written findings, and how they communicate with development teams.
Why use bug bounty and contest results as a hiring signal?
Bug bounty programs and audit contests only pay for findings that an independent judge or the protocol team accepts as valid. Earnings and accepted findings are therefore evidence that a researcher repeatedly found real issues in production-grade code while competing with many other security researchers.
How many researchers work on a Kann Audits engagement?
Engagements are typically staffed with 2 to 4 assigned researchers, adjusted to the size, complexity, and stack of the codebase. Researchers review the code independently first and then collaborate on high-risk areas.
Can we see who audited a published report?
Yes, in most cases. Published Kann Audits reports list the researchers who worked on the engagement where the engagement terms allow it, and the full reports are available in the Kann Audits audit library.
Are researchers matched to the protocol type?
Yes. Researchers are matched by language, ecosystem, and protocol category, for example Solidity lending markets, Rust or Move programs, zero-knowledge circuits, DAML and Canton applications, or Go infrastructure, so the people reading the code have relevant experience.
Primary references