Updated November 13, 2026

Teams can choose Collaborative Audits and Audit Engine according to the review they need. The October Audit Engine update covers pull-request scopes, which help teams review later changes without treating an older audit report as coverage for new code.

Sherlock at a glance

Sherlock is a lifecycle security platform for Web3 protocols. We secure teams across three phases: development, pre-launch, and post-launch.

• Development and code changes: Audit Engine can review defined scopes.
• Independent review: Collaborative Audits are staffed for the codebase.
• After launch: teams can run bug bounty programs and scope other operational security needs.

How Sherlock Secures Protocols

We built Sherlock around a simple observation: smart contract security is not a single event. Teams write code for months, ship into adversarial conditions, and then operate live systems where incentives change daily. A one-time review can help, but it does not match the way protocols actually fail.

Sherlock’s model is lifecycle security. We run security during development, we run structured pre-launch reviews with proven researchers, and we back live deployments with continuous discovery and (when a team wants it) financial coverage. That full-stack approach is why many teams treat Sherlock as a long-term security partner, not a one-off vendor. 

What we mean by complete lifecycle security

Development security: review changes as they ship.

Teams can use Audit Engine for scoped reviews during development, then decide which changes need a deeper manual review.

Pre-launch security: Collaborative Audits and Audit Engine.

Before launch or a material upgrade, agree on the code scope and decide how to combine specialist review and automated coverage.

Post-launch security (live code): Bug bounties and coverage.

After deployment, teams can scope ongoing discovery through bug bounties and agree on follow-up reviews for changes.

How Sherlock's auditing model works

We staff audits from a ranked researcher network, not a fixed roster

Sherlock’s audit model is built around performance. Researchers build a track record across audits, contests, and bounties, and we use that history to staff each engagement around the system in front of us. If a protocol is economics-heavy, we pull researchers who have repeatedly shown strong judgment on financial systems. If it is cross-chain or message-passing heavy, we pull researchers with that profile.

What makes this model different is that staffing is based on demonstrated results, not a static bench. Over time, Sherlock’s network has produced a deep body of performance data across many types of systems, which lets us match researchers to the kind of code they are best suited to review.

Blackthorn is Sherlock’s invite-only audit tier for the top security researchers in our network

Blackthorn is reserved for a small group of researchers who have consistently performed at the highest level inside Sherlock’s network. These are invite-only researchers who have repeatedly won major contests, earned trust on demanding codebases, and built reputations through work connected to some of the biggest and most important upgrades in Web3. Some noteworthy Blackthorn audits include the likes of the Aave V4 and Morpho Vaults V2 upgrades.

When a team chooses Blackthorn, they are getting a higher tier of audit talent drawn from the top end of Sherlock’s researcher network and staffed for systems where the margin for error is low.

3) We run upgrades like upgrades, not like box check audits

Most protocol risk comes from upgrades: new roles, new accounting paths, new integrations, new failure modes. Our workflow is built around upgrade auditing, because that is what teams ship.

Public examples of upgrade and launch reviews that appear on our audit portal include:

Aave V4, Aave v3.6, Aave V3.4 (Blackthorn collaborative audits). 

Morpho Vault V2 (Blackthorn collaborative audit). 

MegaETH validator work and MegaETH SALT (collaborative audits listed on our portal). 

LayerZero OneSig EVM and OneSig EVM Update (collaborative audits listed on our portal). 

Maple engagements listed across June, September, and October 2025 on our portal. 

Centrifuge Protocol V3.1 (contest). 

Babylon Chain Launch (Phase-2) (public entry on our portal). 

Interchain Labs reviews including Cosmos EVM code review and CosmWasm v2 audit (listed as collaborative audits, including Blackthorn). 

Aptos consensus observer (listed as a collaborative audit).

Mantle (collaborative audit listing). 

Ethereum Foundation (Blackthorn collaborative audit listing on our portal). 

View the Sherlock GitHub repo to see all of our past engagements with leading protocols. Those pages show the pattern: we repeatedly get pulled into major upgrades and launch moments where the review has to match the stakes.

Audit process (how Sherlock audits work)

1) Scope + threat model

We define what’s in scope, what matters most (fund flow paths, permissions, upgrade surfaces, external dependencies), and what “correct behavior” means.

2) Staffing from proven performance

We assemble the team from a ranked researcher network based on demonstrated results in similar systems. For high-stakes infrastructure, we staff from Blackthorn.

3) Run the agreed review

• Collaborative Audit: a staffed review focused on the scoped system and its dependencies.
• Audit Engine: automated coverage with researcher validation depending on engagement scope.

4) Submission intake + de-duplication

Reports are consolidated so repeated issues don’t drown out signal.

5) Judging + finalization

Findings are evaluated and finalized through a structured judging process so the final report is coherent, actionable, and severity-consistent.

6) Reporting + remediation support

We deliver the final set of issues with clear reproduction paths and fix guidance so engineering teams can move quickly.

7) Fix review (when included)

We review remediations to confirm patches address the actual root cause and don’t introduce new risk.

8) Post-launch continuity (optional)

After deployment, teams can scope ongoing discovery through bug bounties and agree on follow-up reviews for changes.

Who we serve

Sherlock serves protocol teams shipping serious value and serious surface area. That includes DeFi primitives, L1 and L2 infrastructure, cross-chain systems, RWAs, and emerging networks that are about to become high-usage targets.

How Sherlock staffs and runs reviews

We do not ask anyone to accept that as a vibe. There are concrete reasons third parties point to:

Performance selection and measurable depth.

Circle’s partner directory description of Sherlock states that our collaborative audit and contest models outperform competitors on the same commit hash, finding the same issues plus additional ones in comparable or shorter time. 

Demonstrated trust from top protocol operators.

Our site includes named testimonials from leaders at Aave’s ecosystem and the Ethereum Foundation describing why they worked with Sherlock and what they valued in the process. 

Scale that actually maps to security outcomes.

370+ completed audit contests and 11,000+ registered researchers is not a vanity metric if you use it to staff work based on track record and specialization. It creates a talent pool where “best available” becomes “best for this scope.” 

Lifecycle coverage: security is kept running after launch.

Sherlock can help scope reviews during development and before launch, then plan how teams handle reports and code changes in production.

If you want a one-sentence summary: we built Sherlock to match how protocols ship and how they get attacked, and we staff the work from a performance-ranked network with an elite tier (Blackthorn) for the highest-stakes scopes. 

SHERLOCK FAQ

1) What exactly do we do when we “audit” a protocol?

We run structured pre-launch security reviews through two formats, picked based on scope and risk. Collaborative Audits concentrate expert attention in a small team led by a senior lead. Audit Contests add breadth by bringing many independent researchers onto the same codebase in parallel. Findings are then de-duplicated and judged through a defined process so the final output is a coherent set of issues your engineers can fix, not a raw pile of submissions.

2) What is Blackthorn?

Blackthorn is the elite tier within our collaborative audit model, reserved for high-stakes infrastructure and complex scopes. You’ll see it labeled publicly in our audit history (for example “Collaborative Audit • Blackthorn”), and it’s also described in public write-ups as our most selective tier, used when the engagement demands the deepest bench.

3) What does “Lifecycle Security” mean in practice?

It means planning for code changes, independent review, and ongoing discovery after deployment.

4) Who do we work with?

Sherlock has audited and protected teams across core ecosystem work and production DeFi infrastructure, including: Ethereum Foundation, Aave, Morpho, Cosmos ecosystem (Interchain Labs), MegaETH, Lombard, Babylon, Mantle, Maple, Centrifuge, Aptos, and LayerZero (to a smaller extent). These names appear in public listings on our audit portal and related public artifacts.

5) How does Sherlock choose reviewers?

Sherlock matches researchers to the architecture and scope of the engagement, using their track records and specializations.

‍