Sherlock

• Name: Sherlock
• URL: https://www.sherlock.xyz/
• Category: lifecycle security company / audit-bounty-and-coverage operator / claims-and-triage workflow shell
• Tags: ethereum-ecosystem
• Summary: Sherlock belongs in companies/, not only projects/, because the useful question is not just what audit or bounty format exists? but which named operator controls the staffed review loop, contest rules, severity and judging workflow, bug-bounty triage, Shield eligibility, and the payout-or-claims perimeter teams may start treating as part of their real security operating model? The practical leverage is not only brand or reviewer supply; it is who decides how development-time review, pre-launch pressure testing, post-launch reporting, and optional exploit-coverage workflow are tied together under one company shell.
• What it does:
  • Operates Sherlock as a complete lifecycle security company spanning development, pre-launch review, and post-launch security work rather than only a point-in-time audit marketplace
  • Packages multiple security programs under one operator boundary, including Sherlock AI, Collaborative Audits, Audit Contests, Bug Bounties, Sherlock Shield, and Blackthorn
  • Runs staffed review engagements where Sherlock assembles engagement-specific teams, coordinates fix verification, and keeps the security context attached to the codebase across iterations
  • Hosts public audit contests and post-launch bug-bounty programs with structured incentives, rules, and triage flow rather than leaving review pressure entirely ad hoc
  • Offers Sherlock Shield as an optional coverage layer for qualifying codebases, with Sherlock-controlled eligibility review, scoring, scope confirmation, and an onchain claims or payout process around covered events
• Key claims:
  • Sherlock’s own introduction says the company exists because onchain security can’t be treated as a one-time event or a single deliverable and instead must be an operating model that spans development, auditing, and post-launch operation
  • The docs say Sherlock offers six core services — Sherlock AI, Collaborative Auditing, Audit Contests, Bug Bounties, Sherlock Shield, and Blackthorn — which is strong first-party evidence that the meaningful boundary is one company-run lifecycle stack rather than one neutral protocol primitive
  • The FAQ describes Sherlock as a leading Web3 security company and says lifecycle security is meant to preserve a durable security memory of the system across releases, upgrades, and integration changes, which makes the operator workflow boundary more important than any one contest or report artifact
  • The Shield docs say coverage is available only for qualified codebases that complete a Sherlock audit and fix review, after which Sherlock evaluates eligibility, confirms scope and final terms, and then routes covered outcomes into the Shield process
  • The same Shield docs make the company policy surface unusually explicit by tying coverage amounts to Sherlock-found vulnerability points and audit-type multipliers, while also saying payouts are determined by the onchain claims process of the Sherlock protocol on Ethereum mainnet
• Whitepaper: No classic standalone company whitepaper is the important artifact here. The clearest current primary materials are Sherlock’s homepage, lifecycle-security introduction, FAQ, and Shield documentation; the older source bundle remains ../whitepapers/sherlock-primary-sources-2026-04-25.md.
• Sources:
  • https://www.sherlock.xyz/
  • https://docs.sherlock.xyz/readme.md
  • https://docs.sherlock.xyz/faq.md
  • https://docs.sherlock.xyz/coverage/sherlock-shield.md

Why this company note belongs in the corpus

• Analysts can talk about Sherlock audits, Sherlock contests, Sherlock Shield, or Sherlock AI as if those were separable products with neutral interfaces. The sharper question is who runs the combined review, triage, fix-verification, bounty, and coverage shell that downstream teams may start treating as part of live security operations.
• The entity boundary matters because Sherlock is trying to keep the whole security loop under one operator: architecture review, exploit-path analysis, severity framing, remediation verification, post-launch reporting pressure, and optional financial backstop.
• That means a customer can inherit Sherlock-authored workflow assumptions about what counts as sufficient review, when fixes are accepted, whether a codebase qualifies for coverage, and how claims or reimbursements are framed after an event.

Internal linkages

• Project-layer alias: sherlock.
• Best adjacent security-workflow comparison: immunefi.
• Security-platform company contrast: cantina.
• Security-review company contrast where the emphasis stays closer to validation tooling and audit-methodology workflow: chainsecurity.

Protocol / company boundary

• There is no especially useful standalone Sherlock protocol doing the main analytical work here.
• The meaningful surface is the company-run lifecycle-security shell: staffed audits, contest rules, bounty triage, fix verification, Shield eligibility, and the terms or claims machinery that connects review quality to post-launch coverage.
• That is why Sherlock belongs in companies/: the practical questions are about who operates the security workflow and coverage boundary, not about one immutable technical primitive.

Control surface

• Practical leverage sits in how Sherlock scopes reviews, staffs engagements, defines contest rules, adjudicates severity and valid findings, verifies fixes, determines Shield eligibility, and packages post-launch reporting or claims workflow.

• The sticky dependency is workflow authority: once a team routes pre-launch review, post-launch bounty intake, and optional exploit-coverage expectations through Sherlock, the company can become part of the effective security-management perimeter even without holding the protocol’s onchain admin keys.

• Read Sherlock as a company-run security workflow and coverage operator first, not as a neutral protocol primitive.

• Last reviewed: 2026-08-07 UTC