# Introduction to Sherlock An overview of Sherlock, our security programs, and how these docs are organized so that teams can quickly find the right guidance for AI, audits, contests, bounties, & coverage. Updated January 2026. Sherlock is a security organization built to protect onchain systems where software directly controls capital. We exist because security for these systems can’t be treated as a one-time event or a single deliverable. Protocols ship continuously, assumptions change, integrations shift, and incentives attract real adversaries. Security has to be an operating model. ### **Complete Lifecycle Security** Sherlock’s model is complete lifecycle security: coverage across development, auditing, and post-launch operation. **Development:** teams identify issues early and tighten assumptions while code is still changing fast. **Auditing:** structured review programs pressure test architecture and code under adversarial conditions, then verify fixes before release. **Post-launch**: ongoing incentives keep pressure on production systems as upgrades, integrations, and market conditions change.
We built this model because one-off reviews don’t match how onchain systems are actually built and maintained. Protocols ship continuously, trust assumptions shift with upgrades and integrations, and many real failures come from changes made after a point-in-time review. Lifecycle security keeps the work connected across phases so teams don’t restart from zero each release.
Compounding context is the practical benefit: a durable “security memory” of the system (intent, assumptions, known risk areas, prior findings, and the outcomes of fixes) that carries forward into the next change. That continuity reduces repeat findings, shortens remediation cycles, and makes upgrades safer because the starting point is an informed baseline, not a cold start.
### **How teams work with Sherlock** Each program is designed to solve a different part of the security problem, and most teams combine them based on architecture complexity, timeline, and risk tolerance. The sections below explain what each program is, when to use it, and what to expect from the process and outputs. #### **Sherlock offers six core services:** 1. **Sherlock AI** An auditor-grade AI security tool used during development and pre-launch review. It reads your codebase in context, models protocol intent and trust assumptions, and routes analysis through specialist checks. The output is fix-ready findings tied to real exploit paths, so teams can remediate as they build and ship.
2. **Collaborative Auditing** A staffed audit engagement. Sherlock assembles an engagement-specific team from our elite researcher network based on your architecture and attack surface. The review is coordinated end-to-end, with fix verification through to release.
3. **Audit Contests** A time-boxed public audit program. Many independent, vetted researchers review the same scope under clear rules and incentives. The result is high-throughput issue discovery with structured judging, consistent severity calibration, and a clean paper trail teams can remediate against. 4. **Bug Bounties** A post-launch security program that keeps pressure on production systems. Independent researchers are paid for valid live findings. Triage and remediation workflows are defined up front so teams can receive, validate, patch, and communicate issues without chaos. 5. **Sherlock Shield** An optional post-launch coverage program with defined terms. It can reimburse eligible losses or payouts tied to covered security events. It is designed to sit alongside bounties and ongoing security work as a financial backstop, not a substitute for fixing root causes. 6. **Blackthorn** A premium collaborative audit tier for the highest-stakes scopes. It’s staffed by a small group of top-tier reviewers and run with deeper architecture scrutiny. Teams get tighter iteration loops and hands-on fix verification when uncertainty isn’t acceptable. # FAQ High-level information on Sherlock’s lifecycle security model, how our programs work, and how teams choose the right path from development through post-launch. **What is Sherlock?** Sherlock is a leading Web3 security company for onchain systems where software directly controls capital. We provide complete lifecycle security across development, pre-launch review, and post-launch operation through Sherlock AI, Collaborative Audits, Audit Contests, Bug Bounties, and Sherlock Shield. **What does “complete lifecycle security” mean in practice?** It means security work that matches how protocols actually fail in production: invariants drift as features ship, upgrade paths introduce new trust assumptions, integrations change, and adversaries adapt. Lifecycle security applies pressure at three points: * During development (before patterns harden), * Before launch/upgrade (when risk concentrates), * After launch (when incentives and integrations keep moving).
**What types of vulnerabilities does Sherlock focus on?** The work is designed to catch issues that commonly lead to loss of funds or broken protocol guarantees, including: access control and privilege paths, accounting/invariant breaks, reentrancy and callback risk, oracle and price-manipulation surfaces, MEV and sequencing risk, upgrade and admin-key assumptions, cross-contract and cross-chain integration failures, and unsafe external dependency trust boundaries. Coverage depends on scope and program type. **How is Sherlock AI used across the lifecycle?** Sherlock AI is used across the lifecycle, with the highest leverage during development when code is changing fast. Teams run it continuously as they build, refactor, and ship—using it to surface exploitable patterns, clarify assumptions, and prioritize fixes. It also stays useful before launches or upgrades and after deployment to re-check changes, new integrations, and evolving attack surfaces as the system evolves. **What is a Collaborative Audit?** A Collaborative Audit is a staffed engagement where Sherlock assembles an engagement-specific team and runs a coordinated review for high-stakes scopes. The team builds an architecture-level understanding of the protocol, maps trust boundaries and attack surfaces, tests exploit paths, and verifies fixes through iteration. It’s the right fit when complexity, upgradeability, or integration risk calls for tight feedback loops and hands-on fix validation. **What is Blackthorn?** Blackthorn is Sherlock’s elite collaborative audit program for the highest-stakes scopes. It’s a staffed engagement led by a small group of top-tier reviewers who go deep on architecture, threat modeling, and exploit-path analysis, then stay engaged through iteration to verify fixes. Teams use Blackthorn when a standard review cadence isn’t enough: new primitives, complex integrations, large TVL, or launch timelines where uncertainty is the real risk. **What is an Audit Contest?** An Audit Contest is a public review program where many independent security researchers analyze the scope concurrently under clear incentives. The focus is breadth and throughput: multiple independent perspectives, many parallel lines of inquiry, and fast coverage of attack surfaces that can be missed by a small team. **How should we choose between a Collaborative Audit and an Audit Contest?** Teams typically choose a Collaborative Audit when they need coordinated depth on architecture, invariants, roles, and integrations, plus an iterative fix-and-verify loop with a staffed team. Choose an Audit Contest when you want maximum parallel coverage from independent researchers and high throughput on a clearly defined scope. Many teams combine them: Collaborative Audit first to pressure test the design and verify fixes, then a Contest to add breadth on the hardened release candidate. **What does “fix verification” mean?** Fix verification is the step where proposed remediations are reviewed against the reported exploit path and the protocol’s intended invariants. The goal is to confirm the fix closes the specific failure mode without introducing regressions or new trust assumptions. **What do we get as outputs from a review?** Outputs vary by program, but generally include written findings and severity assessments, proof-of-concept or exploit reasoning where applicable, reproduction context, and guidance on remediation. For pre-launch programs, the emphasis is on actionable results: what breaks, why it breaks, and what changes are required to restore intended guarantees. **How does Sherlock handle post-launch security?** Post-launch security is driven by incentive programs like bug bounties, which keep ongoing pressure on production systems. This is meant to match reality: upgrades, parameter changes, new integrations, and market conditions change the effective threat model over time, so scrutiny has to persist after deployment. **What is Sherlock Shield?** Sherlock Shield is optional financial coverage that can sit alongside post-launch programs under defined terms. Coverage availability, eligibility, scope, and limits depend on the program terms and the details of the reviewed system. **Does Sherlock guarantee the protocol won’t be exploited?** No. The goal is to materially reduce risk by identifying and fixing vulnerabilities, clarifying trust assumptions, validating invariants, and maintaining scrutiny as the system evolves. Outcomes depend on scope definition, code maturity, change cadence, operational controls, and integration complexity. **What chains and codebases can Sherlock support?** Sherlock supports smart contract security work across major onchain environments, and the recommended program depends on your stack and architecture (for example EVM Solidity vs Solana Rust), the deployment model (upgradeable vs immutable), and how much integration surface area exists. If you share your target chain, repo, and timeline, the right program mix becomes straightforward to recommend.
# Glossary Definitions for Sherlock programs, people and roles, and core security terms used across these docs: from scope and severity to contests, bounties, judging, and Shield. ### People and roles **Protocol team:** The builders and operators of the system in scope. Typically includes engineering, security, and operations roles responsible for scoping, remediation, and deployment decisions. **Security researcher:** An independent researcher who analyzes code and systems to find vulnerabilities and reports them through a contest or bounty under the program rules. **Watson:** A security researcher participating in Sherlock programs. Watsons submit findings in contests and bounties and are incentivized to surface real exploit paths and concrete impact. **Judge:** The party responsible for evaluating contest submissions under the published rules. Judges validate issues, assign severity, group duplicates, and determine the final results. **Judging:** The end-to-end evaluation process for contest submissions: validation, impact and exploitability assessment, severity assignment, duplicate grouping, and final outcome determination based on contest rules. *** ### Core concepts **Finding (Issue):** A security-relevant problem identified in code, configuration, or system design. A finding typically includes an impact statement, an attack path (or failure mode), and remediation guidance. **Severity:** A classification of a finding based on impact and exploitability. Severity reflects what can break (loss of funds, unauthorized control, insolvency, denial of service, invariant violation) and how realistically an attacker can reach that state given prerequisites and constraints. **Impact:** What a finding enables if exploited: fund loss, permission escalation, governance/control takeover, bad debt, broken accounting, state corruption, or other defined adverse outcomes. **Exploitability:** How feasible it is to turn a finding into a real attack path. Exploitability depends on prerequisites (roles/keys), reachable call paths, external dependencies (oracles, integrations), economic conditions, and timing/sequencing constraints. **Proof of Concept (PoC) / Reproduction:** Evidence that a finding is real and reachable. This can be a test case, transaction sequence, minimal exploit script, or a clear set of steps that reproduces the behavior. **Scope:** The exact system boundary covered by a program: repositories, commit hashes/tags, deployed addresses, specific contracts/programs, and explicitly included integrations. Scope defines what is reviewed and what results are expected to apply to. **In scope / Out of scope:** In scope means the issue affects components and versions included in the defined boundary. Out of scope means the issue involves excluded components, unsupported versions, or threat models the program explicitly does not cover. **Release candidate (Scope freeze):** A pinned version of the code intended for deployment (or already deployed) that the review applies to. This is usually a commit hash, tag, or set of deployed addresses. Changes after the freeze are not automatically covered unless explicitly re-reviewed. **Fix verification (Retest):** A follow-up review that checks whether a remediation closes the reported failure mode and does not introduce regressions or new trust assumptions. Verification may include reviewing the patch and re-evaluating exploit paths against the updated code. **Disclosure:** The process of reporting a vulnerability through an agreed channel so it can be validated and fixed before details are shared publicly. Disclosure expectations are defined by the rules of the program (contest or bounty) and any safe-harbor terms. *** ### Development **Sherlock AI:** Auditor-grade analysis used across the lifecycle, with the highest leverage while code is still changing. Teams use it during development to surface likely vulnerabilities, clarify trust assumptions, and prioritize fixes as they build and refactor. **AI finding:** A potential issue flagged during development-time analysis. AI findings still require engineering validation; teams confirm reachability, impact, and whether the behavior matches protocol intent. **Assumptions:** Explicit or implicit statements the system relies on to be safe (roles cannot be compromised, oracle inputs behave within bounds, integrations meet certain guarantees, invariants hold under all user actions). Many high-severity failures come from assumptions that were never written down or drifted over time. *** ### Auditing (Pre-launch review) **Collaborative Audit:** A staffed, coordinated review for high-stakes scopes. The emphasis is depth: architecture understanding, adversarial reasoning, and fix verification with a tight feedback loop. **Audit report:** A written artifact that documents findings, severity, reproduction context, and remediation guidance for an agreed scope and version. **Audit Contest:** A structured public review program where many independent researchers analyze a defined scope concurrently under clear incentives, rules, and timelines. The emphasis is breadth and throughput. **Contest submission:** A report submitted by a Watson during a contest. Submissions are evaluated for validity, severity, and scope alignment. **Duplicate:** A submission that describes the same underlying issue as another submission. Contest rules determine how duplicates are handled and how credit is assigned. **Contest rules:** The published constraints and evaluation criteria for a contest, including scope definition, submission requirements, severity definitions, duplicate handling, and payout methodology. **Contest results:** The finalized set of validated findings after judging, including severity assignments, duplicate groupings, and any final notes required by the rules. *** ### Post-Launch protection **Bug bounty:** An ongoing post-launch program that rewards responsible disclosure of vulnerabilities in a live system. Bounties exist to keep pressure on production deployments as upgrades, integrations, and market conditions change. **Bounty submission:** A report describing a vulnerability or exploit path in a live system under an active bounty program. Submissions are triaged for validity, severity, and scope alignment. **Triage:** The process of validating a report, reproducing the behavior, assessing impact and exploitability, assigning severity, and coordinating remediation. **Safe harbor:** Terms that define permitted testing behavior and disclosure expectations for researchers acting in good faith. Safe-harbor language is typically program-specific. *** ### Sherlock Shield **Sherlock Shield:** Optional financial coverage that can sit alongside post-launch programs under defined terms. **Coverage:** A defined limit and set of terms describing what reimbursements may be available under Shield. Coverage is bounded by scope, eligibility requirements, and exclusions. **Claim:** A formal request submitted under Shield terms when an event occurs that may be eligible for reimbursement. Claims are evaluated against scope, evidence, and exclusions. **Premium:** The amount paid for Shield coverage over a defined time period, based on the agreed limits, scope, and risk profile. **Exclusions:** Events, failure modes, or components explicitly not covered under Shield terms. Exclusions define boundaries and prevent ambiguity around eligibility.
# Disclaimers This page summarizes important limitations and risk considerations for protocol teams and other parties who interact with Sherlock programs. ### **What Sherlock is** Sherlock provides security review programs and related services designed to help teams identify and remediate vulnerabilities in onchain systems. These services can materially reduce risk, but they do not eliminate it. Web3 code and smart contract systems operate in adversarial environments, and failures can still occur even after review. #### What Sherlock is not No guarantees. Sherlock does not and cannot guarantee that a smart contract will be free of vulnerabilities, that an exploit will not occur, or that any particular finding will be identified during a review. Not insurance. Sherlock is not an insurance company and does not offer insurance products as defined by applicable laws or regulations. Any financial coverage or reimbursement-style program offered by Sherlock (if applicable to your engagement) is governed solely by its written terms and may be subject to eligibility requirements, limits, and exclusions. #### What protocol teams are paying for Security review outcomes are probabilistic. Protocol teams engaging Sherlock programs are paying for access to a structured security process (including participation from independent researchers in certain programs) and for the outputs of that process (findings, severity assessments, and remediation guidance). Security research is not deterministic: reviewers may miss issues, severity may be debated, and outcomes depend on scope, code maturity, time constraints, and the protocol’s architecture and integrations. Scope matters. Results apply only to the defined scope and version(s) reviewed. Code changes, new deployments, upgrades, integrations, configuration changes, and operational decisions after the review can materially change the effective risk profile. #### Financial coverage and reimbursements (if applicable) Some engagements may include an optional financial coverage component governed by program-specific terms. If your engagement includes such a component: * Availability is not guaranteed. The existence of a stated limit does not guarantee funds will be available at the time of an event. Availability can be affected by program limits, other obligations, smart contract risk, governance or operational issues, or other factors described in the governing terms. * Eligibility is determined by the terms. Whether an event qualifies depends on the written terms (including scope, evidence requirements, and exclusions). A team’s belief that an event “should” qualify does not guarantee eligibility
Protocol teams should read and rely on the governing terms for any coverage component and should not treat coverage as a substitute for strong engineering, operational controls, monitoring, incident response planning, or appropriate risk management. Sherlock’s agreements and any reimbursement-style programs are generally structured around protocol teams, not end users. Even where a protocol team receives funds under a coverage component, Sherlock does not control how those funds are handled or distributed. Users should not assume they will be reimbursed in any exploit scenario. #### Guidance on communications Protocol teams should avoid public statements that imply guarantees, certainty of outcomes, or assured reimbursement. Any description of Sherlock’s services or optional coverage should be accurate, qualified, and consistent with the applicable written terms. #### Independent diligence Protocol teams remain solely responsible for their code, deployments, operations, and user communications. Teams should conduct their own diligence and risk assessment and should not rely on Sherlock services as the sole control for preventing loss. **Legal disclaimer** *This documentation is provided for informational purposes only and does not constitute legal, financial, tax, investment, or other professional advice. Nothing on this page forms or modifies any contract, agreement, warranty, or guarantee. Any services, deliverables, or optional coverage or reimbursement-style programs are governed solely by the applicable written agreements and program terms (including eligibility requirements, limits, and exclusions). To the extent permitted by law, Sherlock disclaims all warranties, express or implied, including merchantability, fitness for a particular purpose, and non-infringement. In the event of any conflict between this documentation and the applicable agreements or program terms, the agreements and program terms control.* # Audits for Protocol Teams Explains Sherlock’s pre-launch review options (collaborative audits, audit contests, and Blackthorn) and how teams choose the right model based on scope, timeline, and risk. Includes what to expect ### Sherlock for Protocol Teams Shipping onchain systems means shipping into an adversarial environment. Security work needs to assume motivated attackers, complex integrations, and real capital at stake. Pre-launch review through auditing is one part of that security motion. Most teams still start with an audit, but there are two common audit formats in Web3, and they solve different problems. #### Collaborative Audits A traditional audit is a staffed engagement where a small set of reviewers works closely with your team over a defined window. This model is best when you want tight coordination, architectural depth, and direct back-and-forth during remediation. #### Audit Contests An audit contest is a time-boxed public review program with clear incentives. Many independent researchers review the same scope in parallel and submit issues for judging. This model is best when you want broad scrutiny, high-throughput discovery, and measurable participation. ### Sherlock’s Approach to Auditing Sherlock combines the coordination of a staffed audit with the parallel discovery of a contest. You get a designated senior reviewer who owns the engagement end-to-end - scoping, architecture context, issue review, and fix verification: plus a large field of independent researchers competing on the same scope under clear rules. In practice, that means: * Depth plus breadth: a coordinated review led by a senior auditor, reinforced by participation from 500+ potential researchers across the network depending on scope and timing. * Findings you can ship against: submissions are judged, deduplicated, and severity-calibrated so teams get a clean set of fix-ready issues instead of raw noise. * Fix verification: the engagement includes structured fix review so teams can ship with confidence that patches are correct and don’t introduce new risk. * Cost efficiency: Sherlock is designed so the majority of spend goes to the people doing the security work — not overhead. In many engagements, \~80% of fees go directly to researchers. * A clear paper trail: you leave with legible outputs (final issue set, severity decisions, remediation notes) that support internal reporting and future upgrades.
If you want to request a review, use the intake form below. The next sections walk through scheduling, scoping, and what to expect from the process and outputs. Request an audit here: # How Collaborative Audits Work How Sherlock’s collaborative audits work, including dynamic team assembly, the engagement timeline from scoping through report, and the readiness requirements needed to start on schedule. Collaborative Audits are Sherlock’s staffed review engagements for high-stakes scopes. They are designed for teams that need depth, direct coordination with reviewers, and fix verification before release. The work runs in a shared audit workspace that tracks scope, findings, remediation status, linked fixes, and fix review through to a final report.
### Team assembly Collaborative Audits are staffed dynamically. Sherlock assembles an engagement-specific review team based on your system’s architecture, attack surface, languages, and release risk. The goal is to match reviewer strengths to the parts of the scope that matter most, rather than applying a fixed team template to every engagement.
### The timeline Sherlock aligns with your team on what is in scope, what is out of scope, and what matters most for the release. This includes repositories and languages, deployment context, actors and trust assumptions, and any prior audit history you want carried forward. #### 2) Quote Sherlock proposes staffing and a review window based on scope size and risk. Once scheduled, dates and logistics are confirmed, and your team is added to the audit workspace. #### 3) Audit preparation Before review begins, your team provides the materials that let reviewers move quickly: * target repository access and the planned freeze point (commit / branch) * auditor-facing documentation (system overview, core flows, actors/roles) * build, compile, and test instructions * any prior audit reports or relevant historical context Sherlock confirms audit readiness 3 days before the start date when you provide the frozen commit and final scope list. #### 4) Audit The audit team performs a coordinated review and logs issues in the workspace as they are found. Each issue is written for engineering: impact, exploit path, and remediation guidance. Your team stays available for clarifying questions during the review window. #### 5) Issues review and remediation This phase turns findings into a remediation plan and verified fixes. Your team confirms issues, records fix intent, links remediation PRs, and schedules fix review once patches are ready. Sherlock reviewers then validate the patch set to confirm issues are resolved and to check that changes did not introduce new risk. #### 6) Audit report After fix verification, Sherlock publishes the final report. The report reflects the validated issue set, severity decisions, and fix verification status, and serves as the record for internal sign-off and release readiness. ### Audit readiness checklist To begin on schedule, the items below must be complete by the start date. Sherlock confirms readiness 3 days before the audit begins, when you provide the frozen commit and final scope. #### Codebase sizing and pricing Final pricing is determined by the size of the codebase at the frozen commit hash. For Solidity scopes, size is measured using nSLOC via solidity-metrics (Solidity Metrics). For non-Solidity scopes, Sherlock sizes the review based on program structure, attack surface, and integration complexity. Sizing notes: * includes libraries and imports; excludes interfaces and standard well-known imports * complexity can change review effort (inline assembly, patterned code, heavy integrations) #### Frozen code and release alignment Your code must be frozen 3 days before the audit start. If you plan to rely on post-audit coverage programs, review assumptions need to match what ships: * changes between audit and mainnet deployment should be limited to security-related fixes from the audit * each fix should be made in a separate PR for traceability * if additional changes are made after the audit, Sherlock may require a follow-up review window for the modified code #### Tests and documentation **Testing:** * 100% passing tests and a target of >80% test coverage at the frozen commit * clear instructions to run tests and coverage in a clean environment (typically in README.md) **Documentation:** * auditor-facing documentation at the start of the audit * begin with an ELI5 overview, then describe core flows and contract relationships * list system actors and their intended roles/capabilities * a formal spec is optional but helpful for invariants and accounting **Build readiness:** * clear instructions to build and compile the project * compilation warnings/errors should be resolved or explicitly explained **Prior context:** * prior audit reports for the system should be shared with the review team **Team availability:** * your team should be available during the audit window for questions * schedule fix review promptly once patches are ready ### Audit philosophy The goal of a collaborative audit is to ship a safer system shortly after the review window. High-severity issues must be remediated and verified before sign-off. Lower-severity items are handled with judgment based on exploitability and real-world impact. The focus is on issues that change risk, and on fixes that can be verified before release. # How Audit Contests Work What a Sherlock audit contest is, how the process works (scoping, contest window, live judging, remediation, and fix verification), and how to plan timelines for a mainnet launch or upgrade. ### How Audit Contests Work Sherlock audit contests are time-boxed public review programs that bring many independent researchers onto the same scope under clear rules and incentives. The goal is high-throughput discovery, paired with structured judging and fix verification so teams can ship against a clean set of findings. Audit contests are commonly used for first-time mainnet launches, major upgrades, new deployments, and high-impact integrations.
#### The Audit Contest Process **1) Request + scoping** Submit an intake request. We’ll confirm scope, risk areas, constraints, and target dates. For most scopes, Sherlock can begin within a few days once scope and logistics are finalized. **2) Quote + scheduling** Sherlock provides a quote based on scope complexity and the review window. Once scheduled, your team reserves the slot with a deposit. **3) Finalizing the scope** Before the contest begins, you provide the final commit / branch and any required materials (deployment context, docs, testing guidance, known assumptions). This is the baseline the contest is judged against. **4) Contest window** During the contest, vetted researchers review the scope in parallel and submit issues. Your team should be available to answer clarifying questions in the shared channel. **5) Live judging + severity calibration** Submissions are reviewed as they come in. Sherlock judges validate issues, deduplicate similar reports, and calibrate severity so the final output is actionable. At the end of judging, you receive a curated list of confirmed findings with consistent severity and remediation guidance. **6) Acknowledgement + remediation plan** Your team acknowledges findings and indicates which ones will be addressed for the upcoming release. At this point, you also schedule fix verification. **7) Fix verification** You ship fixes as PRs and provide the new commit for review. Sherlock verifies that fixes resolve the issue and don’t introduce new risk. If the change set is large, Sherlock may recommend a short follow-up review window to re-check the updated surface area. **8) Final report** You receive a final report that includes the validated findings, severity decisions, and fix verification status — a clean paper trail your team can launch against. {% hint style="warning" %} **Important timeline considerations**\ \ The length of the audit contest itself will be communicated to the protocol team as part of the initial quote/scoping. However, the post-contest process can take a couple days, or it can take a few weeks, depending on the number of issues found:\ \ **Audit Contest:** Communicated in the quote/scoping\ **Judging Contest:** Variable number of days immediately after audit contest\ **Issue Verification:** Depends on the number of issues submitted, but could take 1 day or could take 7 days (also depends on the productivity of the protocol team)\ **Issues fixes:** Depends on the number of valid issues, but could take 1 day or could take 1-2 weeks (also depends on the productivity of the protocol team)\ **Escalation Period:** Once the issues have been verified, this is a "double-checking" process that takes 48-72 hours in total and usually occurs while the protocol team is fixing issues.\ **Fix review:** This will be done by the Lead Senior Watson if it can be accomplished in 1 day or less. If not, Sherlock suggests a small follow-up audit contest. Could take as little as 1 day, or it could take 1-2 weeks to schedule and complete (depending on number of issues and Lead Senior Watson availability, etc.)\ \ **Generally, Sherlock recommends a protocol team not expect to deploy/launch their protocol until 2-3 weeks after the audit contest finishes. However, if not issues are found, a protocol team could launch as soon as 3 days after the audit contest ends.** {% endhint %} # Audit Contest Timeline Guidance for audit contest duration based on scope size, plus what to budget for judging, remediation, and fix verification after the contest. Audit contests are scheduled around scope size, architecture complexity, and launch risk. Sherlock uses a mix of designated senior review and broad independent researcher participation, then runs live judging during the contest so findings stay clean and actionable. This page provides planning guidance for contest length based on codebase size. Final duration is set during scoping. #### Planning guidance by codebase size Sherlock estimates size using nSLOC (non-comment source lines of code), calculated using Solidity Metrics. *Note: The sizing guidance below is based on Solidity nSLOC (measured with Solidity Metrics) and is meant for EVM/Solidity scopes. For non-Solidity codebases (for example, Solana programs in Rust) and for mixed-language systems, Sherlock scopes timeline and review length based on program structure, attack surface, and integration complexity rather than nSLOC.*
Solidity Lines (nSLOC)Audit Timeline
~500~3 days
~1000~6 days
~2000~12 days
~3000~18 days
~4000~25 days
~5000~32 days
~6000~38 days
> Note: Sherlock utilizes the tool [Solidity Metrics](https://github.com/ConsenSys/solidity-metrics) to calculate nSLOC.\ > \ > \*Given the exponential complexity of very large codebases for any security expert, Sherlock will have final discretion whether to write smart contract coverage behind its audit for protocols with >6000 nSLOC For very large codebases, duration is not purely linear. Sherlock will confirm scope boundaries and expected throughput during scoping, and may recommend splitting scope or sequencing reviews if the surface area is too broad for a single contest window.
#### After the contest: remediation + verification Contest length is only one part of the timeline. Teams should also budget time for: * Judging and deduplication: live during the contest, then finalized shortly after it ends * Remediation: depends on number and complexity of confirmed findings * Fix verification: review of the patch set to confirm issues are fully resolved and no new risk was introduced #### Follow-up review windows Sometimes the patch set is large enough that a short follow-up review is the safer move. This is common for major upgrades or when remediation touches core accounting, permissions, or integrations.
In these cases, Sherlock typically recommends a shorter follow-up contest or targeted review window focused on the changes. The duration and cost are determined during scoping based on the change set and risk. # Scheduling Process How to reserve and confirm an audit slot with Sherlock, including deposits, start date confirmation, and scheduling flexibility for both major releases and update reviews. Sherlock keeps scheduling lightweight so teams can lock review time without freezing code weeks in advance. After an initial assessment and a preliminary quote, scheduling follows a straightforward flow. #### **Step 1: Reserve a slot** The protocol reserves a review slot with a **25% deposit and proposes a preferred start date.** Sherlock confirms staffing and the start date shortly after reservation. If the proposed date is not feasible, Sherlock will suggest alternatives and work with the team to select a new start date. #### Step 3: Deposit flexibility If Sherlock cannot accommodate the originally proposed start date, the protocol may withdraw the deposit in full. #### Scheduling notes Teams can often schedule on short notice, especially for narrower scopes and update reviews. For larger or higher-stakes releases, earlier scheduling gives more flexibility on dates and staffing and reduces the chance of timeline compression close to launch. # Audit Contest Preparation Covers how to prepare for an audit contest, what’s required 72 hours before start, and what happens if readiness or logistics aren’t complete. Preparing a codebase for an audit contest improves review quality and reduces noise during the contest window. Sherlock’s Audit Requirements Checklist outlines the minimum readiness standards expected by the start date so researchers can spend time on security work instead of setup and environment issues. For audits scheduled more than a week in advance, Sherlock will run check-ins with the protocol team to confirm readiness and avoid last-minute blockers.
#### 72 hours before the start date Approximately 72 hours before the audit begins, the protocol team must provide: * the frozen commit hash and branch * the final list of contracts/modules in scope At the same time, the protocol completes the remaining audit payment.
#### If requirements are not met If required logistics are incomplete (for example, payment or access), the audit will not start. If the frozen commit does not meet the Audit Requirements Checklist, or if the final scope requires more review time than originally scheduled, Sherlock will work with the protocol team on one of the following paths: * reschedule the audit window * extend the audit length (subject to staffing availability and revised pricing) * proceed on a best-efforts basis with adjusted expectations and limitations (including potential impact on eligibility for post-audit coverage programs) If the start date is blocked due to protocol readiness after a slot has been reserved, the deposit may be used to compensate reserved reviewer time. # Protocol Involvement During the Audit Process What Sherlock expects from protocol teams during audit contests and collaborative audits, including communication channels, availability, and how visibility and disclosures are handled during live rev ### Protocol involvement during the audit process Sherlock audits work best when the protocol team is available and responsive during the review window. Reviewers will have questions about intended behavior, roles, integrations, and edge cases. Fast answers reduce ambiguity and improve outcomes.
#### Communication during an audit contest At the start of an audit contest, the protocol team is added to a shared Discord channel used for auditor Q\&A. Participation isn’t mandatory, but teams that engage tend to get clearer submissions and fewer avoidable misunderstandings.
During the contest, issues are submitted and judged through Sherlock’s workflow. Findings may be reviewed and validated while the contest is still running. To protect contest integrity, visibility into submissions is controlled during the contest window, and teams should avoid sharing exploit details or partial findings publicly until the review phase completes and disclosures are coordinated. After the contest window ends, the protocol receives a curated set of validated findings with severity calibration and remediation guidance, followed by fix verification once patches are ready. #### Communication during a collaborative audit In a collaborative audit, the protocol team works directly with the staffed audit team throughout the review window. Questions, findings, and remediation details are tracked in the audit workspace in real time. This format is designed for tighter iteration: rapid clarification, faster convergence on intended behavior, and continuous alignment on fixes as they are implemented. #### Expectations for protocol teams Protocol teams should plan to be available during audit weeks for questions and clarifications, and to move promptly on remediation and fix verification once findings are confirmed. # Protocol Involvement Post-Audit What happens after an audit, including how findings are finalized, how teams confirm disposition and implement fixes, and how Sherlock verifies remediation before a final report. ### Protocol involvement post-audit After the review window ends, the work shifts from discovery to remediation and verification. Sherlock’s goal in this phase is simple: deliver a clean set of validated findings, help your team remediate them efficiently, and verify fixes before release. #### 1) Findings are finalized and validated Sherlock reviews submissions and consolidates the output into an actionable issue set. This includes validation, deduplication, and severity calibration so the protocol team is not sorting through raw noise. Sherlock prioritizes issues that change real security risk. High and medium severity findings receive the most attention because they are the most likely to lead to fund loss or material system compromise. #### 2) Protocol reviews the final issue set Once the protocol receives the final list, the team confirms disposition for each item: * Will fix for the upcoming release, or * Accepted risk (acknowledged without fixing), or * Disputed / needs clarification where the team believes context changes impact. There is no universal fixed deadline for this step. The practical requirement is responsiveness so remediation and verification can be scheduled without blocking a launch. #### 3) Remediation and PR linking For issues marked “will fix,” the protocol implements patches and links each fix to the corresponding finding (typically via separate PRs). This keeps the remediation record clean and makes fix verification faster and more reliable. #### 4) Fix verification Sherlock then reviews the patch set to confirm: * the original issue is fully resolved, * the fix matches intended behavior, and * the change does not introduce new risk. For staffed engagements, fix verification is performed by the assigned review team. For contest-based reviews, fix verification follows the same principle: reviewers verify the relevant patch set against the validated findings. #### 5) Final report and release readiness After fix verification completes, Sherlock provides the final report reflecting the validated issues, severity decisions, and verification status. This becomes the record for internal sign-off and release readiness.
#### Follow-up review windows Sometimes remediation materially changes the attack surface (large refactors, new modules, revised accounting, new integrations). When the patch set is too large to confidently verify in a short window, Sherlock may recommend a follow-up review focused on the changes before sign-off. # Rescheduling and Cancellations How Sherlock handles rescheduling and cancellations, including how deposits are treated when a start date is blocked by readiness or logistics, and how to avoid last-minute issues. ### Rescheduling and cancellations Protocols often schedule audits before a codebase is fully ready to freeze. That’s normal. Sherlock keeps rescheduling practical, but review time is also real capacity that gets reserved and staffed in advance. #### Rescheduling If you need to move an audit start date, notify Sherlock as early as possible. Sherlock will make a good-faith effort to accommodate a new date based on staffing availability and the scope
If the audit start date is blocked due to protocol readiness (for example: required access is missing, payment is incomplete, the code is not frozen, or other audit readiness requirements are not met), Sherlock may treat the reserved slot as used capacity. In these cases, the deposit may be applied to compensate reserved reviewer time, and the engagement can be rescheduled once readiness is confirmed. #### Cancellations If you need to cancel an engagement, contact Sherlock as early as possible. Refundability depends on how much reviewer time has already been reserved and committed. In general, the closer the cancellation is to the scheduled start date, the less likely the deposit is to be refundable. #### Practical guidance To avoid last-minute issues: * schedule early, but plan to freeze the scope and commit close to the start date * use the Audit Requirements Checklist to confirm readiness ahead of the 3-day freeze point * flag risks early (delayed tests, pending migrations, major refactors, access limitations) so the review plan can be adjusted\ \ \&#xNAN;*This page is provided for informational purposes only and does not create any contractual rights or obligations. All rescheduling, cancellation, and fee/deposit terms are governed solely by the parties’ executed agreement(s) (including any order form or statement of work) and may be modified by written agreement between the parties.* # Watsons Check out our latest contests [here](https://app.sherlock.xyz/audits/contests)! A Watson is a security expert who submits vulnerabilities. Watsons can also be teams that sign up under one address, so whether you’re an established audit shop, full-time independent security expert, or part-time security researcher interested in finding vulnerabilities - we want to work with you. **Initial Steps:** 1\. You can sign up for upcoming audits posted in Sherlock’s Discord channel or [Website](https://app.sherlock.xyz/audits/contests) by providing your GitHub name, Discord handle, and your wallet address (so we know where to pay you). 2\. You can submit issues found during the audit to your private GitHub repo that Sherlock will create. 3\. You have until the audit ends to select to opt out of counting the contest towards your ranking. > Note: You are allowed to opt out of a contest for ranking purposes, but still get paid based on the issues you submit! We want to encourage you to show up for as much, or as little, time as you can commit. 4\. Sherlock will pay you any prize money earned from the pool and update your ranking within 2 weeks of the audit ending. You are eligible to be a Senior Watson if you make it into the top 10% of ranked Watsons. Senior Watsons have the chance to become the Lead Senior Watson for a contest and receive fixed pay (\~$10k per audit week). **Steps for Senior Watsons:** 1\. Sherlock posts the details of an upcoming audit in the Senior Watson Discord Channel. You have 72 hours to indicate your interest in being selected as the Lead Senior Watson, or propose a set of alternative dates that work better. 2\. If you are the highest ranked Senior Watson who signed up, you will be notified after those 72 hours that you were selected to lead the audit. If you aren’t selected as the lead, you can still compete in the contest by following the “Initial Steps” above. 3\. You can submit issues found during the audit to your private GitHub repo that Sherlock will create. 4\. Sherlock will pay you any prize money earned from the pool and update your ranking within 2 weeks of the audit ending, and you’ll receive 75% of your fixed pay at this time. 5\. As the Lead Senior Watson, you’ll review all fixes made by the protocol team. See “Fix Review Process” section below for more details. 6\. Post-fix review, Sherlock will compile the final audit report and you’ll sign off on it. # Lead Senior Watson Selection Process In order to become a Senior Watson, you must pass 2 criteria: 1. **Compete in >=28 contest-days on Sherlock (contests where "USDC Only" is selected don't count)** 2. **Have at least 25% of the leaderboard points of the average of the Top 5 Senior Watsons.** Example: If the top 5 Senior Watsons have 800, 700, 650, 600 and 500 points, then the average is 650 points which means you must have at least 25% of 650 points (162.5 points) in order to pass this criteria. {% hint style="info" %} Senior Watsons have a pink crown next to their name on the [leaderboard](https://audits.sherlock.xyz/leaderboard). {% endhint %} These Senior Watsons have the opportunity to signal their interest in being selected as the Lead Senior Watson in an upcoming audit contest. Senior Watsons will be included in a specific Discord channel where new audit opportunities will be posted. The Sherlock team will also DM all Senior Watsons to check out the Senior Watson channel in Discord anytime a new audit contest is posted. Seniors Watsons have two options if they seek to be selected: 1. Indicate interest in being the Lead Senior Watson for the protocol and dates posted. 2. Indicate interest in being the Senior Watson, but propose alternative dates when you’re available. After 72 hours, Sherlock will select and notify the highest ranked Senior Watson as the Lead Senior Watson for the audit. Unselected Senior Watsons can still compete for the prize pool. If the Senior Watson does not confirm their participation in those 72 hours, Sherlock will select and notify the next highest ranked Senior Watson (who indicated interest) to the Lead Senior Watson position. If the audit was scheduled >72 hours in advance of the start date, then Sherlock will also contact the Senior Watson to re-confirm availability. We understand that life can sometimes get in the way of prior commitments, so Sherlock will reconfirm your participation to give us enough time to find an alternate Senior Watson to lead the audit contest if needed. ### Lead Senior Watson Fixed Pay Lead Senior Watsons have extra responsibilities compared to regular contest participants, such as conducting the fix review and helping with judging. However, a big advantage of leading a contest is earning fixed pay just for committing to participate. The amount of fixed pay a Senior Watson earns for a contest depends on the length of the contest. But it also depends on the relative ranking of that Senior Watson. Assuming a 1-week audit contest, here are the fixed pay breakdowns for Lead Senior Watsons: | Relative Position | Fixed Pay (per week) | | -------------------------- | -------------------- | | Top 33% of Senior Watsons | 12,500 USDC | | Top 67% of Senior Watsons | 10,000 USDC | | Top 100% of Senior Watsons | 7,500 USDC | For example, if there are 17 Senior Watsons in total and you are the 7th-ranked Senior Watson, then you are in the 41st percentile (7 divided by 17) of Senior Watsons. If you were selected to lead a contest, you would earn 10,000 USDC of fixed pay per week. # Fix Review Process The Lead Senior Watson for a contest will be expected to complete the fix review as a part of their role. The fix review ensures that the protocol’s changes post-audit have been properly implemented. The protocol will select a date within 3 weeks of the audit end-date for which they would like the fix review to be conducted. At this point one of 3 things happen: 1. Lead Senior Watson confirms that date works. 2. Lead Senior Watson proposes an alternative date for the fix review. 3. Lead Senior Watson does not have reasonable availability, and loses 25% of their fixed-pay compensation. That 25% will be used to compensate a new Watson (based on performance in that specific contest) to conduct the fix-review. If the Lead Senior Watson determines that the protocol’s code changes require >1 day to review, then Sherlock will work with the protocol team to schedule a new (hopefully smaller) contest to review these changes. The new contest can be as short as 3 days or as long as 3 weeks. When it’s determined that the protocol’s code needs a new contest, the initial Lead Senior Watson will lose their 25% fixed pay for the fix review (which did not occur), but they will get first priority to be the Lead Senior Watson on that protocol’s follow-up contest (and receive fixed pay for that). The protocol will be able to put that refunded portion (25%) of the Lead Senior Watson’s pay towards the fixed pay for the Lead Senior in that follow-up contest. The fixed pay for the follow-up contest should always be equal to or greater than the 25% fixed pay that was withheld in the previous contest. {% hint style="info" %} If a Lead Senior Watson places outside of the top 10 in the ranking for a contest they lead, then they must forfeit 25% of their fixed pay so that Sherlock can bring in a Watson who found more of the issues to conduct the fix review. {% endhint %} ### Receiving the 25% Fixed Pay The 25% Fixed Pay will be released up to two weeks after the fix review occurs. The two-week delay is so that the [Pre-Launch Bounty](/bug-bounties/pre-launch-bounty) can flag any Critical issue that should have been caught in the fix review. If no issues are reported that should have been caught in the fix review, the 25% fixed pay gets unlocked. If an issue is reported that could have been caught during the original audit or audit contest, then it is not the sole responsibility of the fix reviewer to catch, and thus the 25% fixed pay gets unlocked. If a Critical vulnerability is found that could only have been caught during the fix review (was introduced after the original audit), then, depending on the size of the Pre-Launch Bounty, some or all of the 25% fixed pay will be re-routed to the bug bounty submitter, and away from the fix reviewer. # Contest Points Sherlock has a cold-start problem. Because there are no rankings initially, Sherlock doesn’t know who the Senior Watsons should be. To fix this, Sherlock has whitelisted a select group of security experts to be Senior Watsons. This whitelist will be based on security experts who have led audits for Sherlock in the past. Rankings will show up on the leaderboard after each Watson’s first contest. However, promotion to the Senior Watson role or demotion from the Senior Watson role will only happen once a Watson has completed two contests. > Update: As of 9/21/22, Sherlock will change the required number of contests for promotion/demotion from the Senior Watson role. Instead of requiring 2 contests, Sherlock will require 4 contest-weeks to be completed. This will help give more credit to long, 4-week contests and give less credit to short 3-day contests. We think this is an important change to make the rankings and selection process more fair. If it helps you can think of each contest as consisting of a number of contest-days (based on the length of the contest). And 28 contest-days (4 contest-weeks) are required to be eligible for Senior Watson promotion/demotion. Since this scoring system went into effect on 9/21/22, the Notional, Harpie and Sentiment contests will use the old system, meaning each will be worth 14 contest-days. > Note: Watsons have the ability to decide if they want a contest to count towards their ranking. The only catch is that you must indicate this (there’s a button on the sign-up page) before the contest ends. This is to ensure that a Watson who is busy or not able to dedicate enough time to a contest doesn’t get penalized in the rankings. However, if you’re the Lead Senior Watson chosen for the contest (receiving fixed pay), the contest will always count towards your ranking. The amount of Contest Points available to gain in each contest (to move up the ranks) is determined by the average scores of the competing Watsons, based on previous Sherlock contests: Let’s assume Bob’s average score is 7, Joe’s average score is 13, and Mike’s average score is 5. And only Bob, Joe, and Mike compete in a contest. The total Contest Points available in that contest will be 25 (7+13+5). Once a Watson has competed in a Sherlock competition, their Leaderboard points (aka ranking) will be determined by their average contest points scored in their 5 most recent Sherlock competitions. It drops off after 5 competitions so that “bad” scores do not stay with you forever. > Update: As of 9/21/22, Sherlock will change the methodology for calculating Leaderboard points. Instead of taking the 5 most recent contests, Sherlock will take the last 10 contest-weeks (70 contest-days). This means that a 3-day contest will only count for \~4% (3 contest-days / 70 contest days) of your Leaderboard points (assuming you've competed in >=70 contest-days of contests already). And similarly, a 4-week contest will count for 40% (28 contest-days / 70 contest-days) of your Leaderboard points (assuming you've competed in >=70 contest-days of contests already). If you've competed in <70 contest-days worth of contests, then these contests will naturally make up a higher % of your Leaderboard points.\ > \ > However, the Notional, Harpie and Sentiment contests will each count for 2 contest-weeks (14 contest-days) because we don't want to make a retroactive change to the scoring. # How to Score Issue Points in a Contest The total Contest Points which can be earned in a contest is the sum of the average Contest Points of each competitor (plus an inflation amount to offset new entrants). In this way, Watsons aren’t given an unfair advantage or disadvantage if they compete in an audit with relatively weak or relatively strong participants. Then, each Watson generates a score based on the amount of high and medium severity findings they submit. > Note: In Sherlock contests, only Medium and High vulnerabilities count for Issue Points. There is no reward for submitting Low or Informational issues. The points awarded for each issue submitted in a specific contest are called “Issue Points." A Watson’s Contest Points and payout from the prize pool is determined by calculating their share of all the Issue Points awarded, then multiplying their share by the total Contest Points and Prize Pool available. > *Watson1 Ranking Points = (Watson1 Issue Points Awarded / AllWatson Issue Points Awarded) \** (Total Ranking Points Available) > *Watson1 Prize Pool Award = (Watson1 Issue Points Awarded / AllWatson Issue Points Awarded) \* (Total Prize Pool Available)* A Watson’s Issue Points earned is weighted based on severity and is calculated with sybil resistance in mind. The formula disincentivizes participants in the contest from submitting findings under multiple identities to try to earn more of the prize pool (i.e. a sybil attack). It does this by awarding a greater pro-rata portion of the prize pool based on not only the *severity* of the finding, but also the *uniqueness*. In instances where multiple people find the same issue, the cumulative score is less than if one person found it, effectively penalizing an individual who attempts to “sybil attack” a finding. As you can see, High issues are weighted 5x more heavily than Medium issues: > *Medium Risk Issue Points Weighting = 1 \* (0.9 ^ (IssueSubmissions - 1)) / IssueSubmissions* > *High Risk Issue Points Weighting = 5 \* (0.9 ^ (IssueSubmissions - 1)) / IssueSubmissions* # Meeting the Payout Criteria How to make sure you get paid for your findings Previously, anyone could sign up as a Watson, join a contest, and get paid for any valid issues they submit. The only caveat is that there was a USDC penalty for invalid issues. The USDC penalty is now gone, and it's replaced by 2 "Audit Contest Payout Criteria." {% hint style="info" %} If you don't pass either of these criteria at any time, your USDC payouts will be withheld until you pass both criteria, at which point they'll be paid out in full. {% endhint %} ## Audit Contest Payout Criteria ### 1. 2 Valid Issues Until you've submitted 2 valid issues with your Watson account, you will not receive USDC payouts. {% hint style="info" %} Although this rule is new, it will look at your account's lifetime record to see if >=2 valid issues have been submitted. {% endhint %} ### 2. Issues Ratio Your "issues ratio" must be >=20% otherwise you will not receive USDC payouts. The "issues ratio" is defined as: ``` # of valid issues submitted / total # of issues submitted ``` If less than 20% of the issues you submit are valid, your USDC payouts will be withheld until this ratio gets back above 20%. This is a lifetime ratio on your account, so it looks at every contest you ever participate in! {% hint style="info" %} Because this rule is new, it will only look at contests that started on or after July 1st, 2023. {% endhint %} #### What's the point of these criteria? The intention is to limit the number of invalid issues submitted to Sherlock. Sherlock receives hundreds of invalid issues in every contest and it requires a lot of time and resources for Sherlock to review each one of them. By implementing these criteria, Sherlock hopes that more of a contest's cost (in USDC) can be directed towards Watsons who are finding important vulnerabilities, and not on reviewing invalid issues. The "Issues Ratio" obviously wants to prevent a single account from submitting infinite invalid issues. The "2 Valid Issues" criteria is in place to prevent people from creating infinite accounts and submitting 1 issue in each account (hoping a few accounts get paid). # First Blood Pot ### First Blood Pot Three percent of the total payouts will be reserved for a first-blood pot, which is distributed among the first submitters of all valid issues. The first submitter of any valid issue is determined by the timestamp of the last modification on the GitHub issue, across all issues within a valid issue family. Each first submitter of an issue receives a number of shares from the first-submitter pot, based on the issue's severity and the number of duplicates it has. The number of shares is calculated using the same formula as for determining issue shares, with the key difference being that only the first submitter of that issue family receives the shares: > (First Submitter Shares) = (Severity Factor) \* (0.9 ^ (IssueSubmissions - 1)) / IssueSubmissions ### Example Consider a $100,000 contest with a $3,000 first-blood pot, which includes 2 valid High-severity and 2 valid Medium-severity issues after final judging. 1. The first High-severity issue has 4 submissions in its family.\ The first submitter will receive `5 * (0.9 ^ (4-1)) / 4 = 0.91125` shares for this issue. 2. The second High-severity issue is a solo submission.\ The first submitter will receive `5 * (0.9 ^ (1-1)) / 1 = 5` shares for this issue. 3. The first Medium-severity issue has 2 submissions in its family.\ The first submitter will receive `1 * (0.9 ^ (2-1)) / 2 = 0.45` shares for this issue. 4. The second Medium-severity issue has 4 submissions in its family.\ The first submitter will receive `1 * (0.9 ^ (4-1)) / 4 = 0.18225` shares for this issue. The percentage of the first-blood pot each submitter receives is calculated by dividing the sum of their individual shares by the total number of shares awarded. In this example, assume: * Alice was the first submitter of issue 1. * Frank was the first submitter of issue 2. * Bob was the first submitter of issue 3. * Dave was the first submitter of issue 4. The payouts for each would be: * Alice: $417.78 * Bob: $206.31 * Dave: $83.56 * Frank: $2,292.35 This example is further illustrated in [this spreadsheet](https://docs.google.com/spreadsheets/d/1eyyilZmwdjvZ2LaAsvDLzWyWKXDcqO9zabgNd2O5JWI/edit?usp=sharing). # Leaderboard Points Example A Hypothetical Walkthrough of How Leaderboard Points are Calculated First, you can find the Sherlock leaderboard [here](https://app.sherlock.xyz/audits/leaderboard). How are those leaderboard points calculated? And how you can move up the leaderboard as a security expert? ### **Where do leaderboard points come from?** Every ranked Watson carries an amount of Leaderboard Points with them into any contest where they compete for ranking. The number of Leaderboard Points each Watson brings into a contest is proportional to their leaderboard ranking.\ \ The only "new" Leaderboard Points (which come from Contest Points) are created from a small amount of Leaderboard Points inflation in each contest. This keeps the leaderboard from getting too stale over many years. Each Watson brings their Leaderboard Points into each contest, and the sum of every Watson's Leaderboard Points make up the amount of Contest Points available in that contest (plus the inflation amount). In this example, there are 5 Watsons. Each one has competed in a 7-day contest previously, so each one has some Leaderboard Points:
Next, Alice, Bob, Carol, Dan, and Emily compete in their second Sherlock contest. It's a 14-day contest and at the end of the contest, there are 5 legitimate findings. One of them is High severity and four of them are Medium severity. The "1"s represent whether the participant submitted a particular finding or not. As we can see, Alice submitted the M1, M2, M3, and M4 findings. Bob only submitted the M2 finding. H1 represents the first High severity finding and M1 represents the first Medium severity finding.
Here are the "sybil-resistant" formulas used to calculate how many "issue points" each participant gets for each finding: > *Medium Risk Issue Points Weighting = 1 \* (0.9 ^ (IssueSubmissions - 1)) / IssueSubmissions* > *High Risk Issue Points Weighting = 5 \* (0.9 ^ (IssueSubmissions - 1)) / IssueSubmissions* As you can see, High severity issues are initially worth 5x more than Medium ones. But the final "issue points" awarded to each person depend heavily on how many others found the same issue.\ \ Here's how that same table from above looks using the "issue points" formulas:
As you can see, Carol and Emily were the only Watsons to find H1 (a High severity issue) and they were awarded the most points out of anyone because of it. M2 was significantly less fruitful because it is Medium severity and everyone found it. Based on these "issue points," we can now see who performed best in the contest and earned the most from the USDC pot:
Carol and Emily each make over 30% of the contest pot (over 60k USDC), largely driven by their submissions of H1, which no other Watsons found. Dan fared the worst because he only found 2 Medium severity issues, and other participants also found both of those Medium severity issues. Now comes a bit of complexity. The 5 participants have each completed a 7-day contest (previously) and a 14-day contest. Sherlock's scoring system puts a greater weight on the 14-day contest (2x weight to be exact) because it was a longer contest with a presumably larger codebase. So we'll take the old leaderboard points of all 5 participants (based on the 7-day contest) and weigh them against the new performances in the 14-day contest. As a reminder, points gained in the 14-day contest are relative to the % of the pot captured. Emily captured the highest % of the pot in the 14-day contest at \~34%, so she could see the biggest benefit from the second contest. However, the first contest will still make up \~1/3rd (7 days out of 21 days total) of her score.
The formula being used to calculate Emily's score is the following: > (50.0 \* (7 / 21)) + ((33.7% \* 714) \* (14 / 21)) The 714 represents the cumulative amount of leaderboard points in the second contest from all the competitors, adding 2% inflation (14 extra points) for example. This is a simplified example where only the same 5 competitors happened to compete in similar-length contests. This is how the Sherlock leaderboard would look after these two contests:
Because of the increased weighting of the 14-day contest vs. the 7-day contest, Carol and Emily ended up higher on the leaderboard than Bob, despite Bob's high ranking after the 7-day contest. Carol and Emily also earned the highest USDC payouts. But every Watson (including Carol and Emily) will need to ensure they clear [both audit contest payout criteria](/audits/watsons/meeting-the-payout-criteria) in order to receive their USDC. # FAQ **I've earned some USDC through Sherlock, is there an entity I can invoice for tax/reporting purposes?** Yes, please use:\ \ DeFi Risk Management Foundation 
\ Dresdner Tower, 11th Floor 50th St. and 55th East Street 
\ Panama City, Panama 00000\ \ Tax ID: 25045786-3-2021\ \ And feel free to send the invoice to # Judging {% hint style="info" %} **Note for Protocol Teams:** There is no mandatory action to take during judging. Sherlock's judging will reach a final state without any input from the protocol team.\ \ You may focus on fixing any issues as soon as you notice them during the process. However, if you want to provide input or advice on certain issues, this is always welcome. {% endhint %} ### Phase 1: Real-Time Judging > **Purpose:** To quickly crowdsource (with advanced signal scores) judgments, explanations, and de-duplication for each issue to reduce the workload for the Lead Judge. * Happens right after the audit contest ends * Lasts a fixed number of days (# of issues / 100) days (for example 500 issues would be 5 days), with a minimum of 2 days. * Dedicated Judges sign up ahead of time to give certainty that all issues will be judged and de-duplicated by the end of this period * Often, 90% of issues are judged accurately within 12-24 hours, allowing a protocol team to start on any fixes The Dedicated Judges need to judge all issues during the fixed number of days. See [Dedicated Judge](https://github.com/sherlock-protocol/sherlock-v2-docs/blob/main/audits/judging/audits/real-time-judging/dedicated-judge.md) for more details. ### Phase 2: Lead Judge > **Purpose:** What's the purpose of this phase? Real-Time Judging often surfaces controversial and/or complex issues that are best judged by a top-tier security expert. * The Lead Judge will know his start date as soon as the contest ends (if 500 issues then he starts 5 days after the contest ends) * Lead Judge gets (# of issues / 200) days to do this preliminary judging, with a minimum of 2 days. (so 500 issues would round up to 3 days) * Lead Judge only needs to focus on the controversial issues (flagged in Real-Time Judging) during this phase * Lead Judge must write an explanation for every judgment * The Lead Judge may begin judging before the official start date. {% hint style="success" %} Checkpoint: Preliminary Results Announced {% endhint %} ### Phase 3: Escalation Period > **Purpose:** Sometimes a Watson will want to flag something they believe the Lead Judge got wrong. * After the preliminary results are announced, Watsons have 24 hours to flag any issues for re-review * Watsons must pay with their Signal Score to flag an issue * Watsons can then leave an extra comment explaining their rationale ### Phase 4: Final Judgments > **Purpose:** The Lead Judge will re-review any issues flagged during the Escalation Period. The Sherlock Judge will supervise and interject if needed. * The Lead Judge gets (# of controversial issues / 20) days to complete Phase 4, with a minimum of 2 days. * Lead Judge will review all controversial issues (new ones from the Escalation Period and old ones that he already judged) * Lead Judge will make final decisions on all controversial issues * The Sherlock Judge will closely monitor the decisions during Phase 4, be available for any questions, ask questions if something is unclear, and only overturn a decision if it’s clearly wrong. {% hint style="success" %} Checkpoint: Final Results Announced {% endhint %} # Judging Conduct Guidelines Being a Judge for a customer’s audit contest is a highly privileged role. A high degree of professionalism is expected from every Judge. To be a Judge on Sherlock, the following rules should be observed: * No comments should be written that disparage Sherlock, a Sherlock team member, the customer, a customer’s team member, or other Judges * No vulgar, spam or off-topic comments should be written * No attempt to break or game the judging system should be attempted * If any issue with the judging system is discovered, it should be reported to the Sherlock team immediately * Discussion of issues can be highly sensitive, so please keep the discussion to the comments section for issues in Real-Time Judging or the appropriate channel on Discord * No discussion of judging on an external public channel (such as X/Twitter, a non-Sherlock Discord server, etc.) should occur If any of the above guidelines are not followed, a temporary or permanent ban from judging and removal of the Sherlock Judge role will follow.
# Criteria for Issue Validity This guide aims to provide clarity for both Watsons & protocols on various categories of issues that are valid under Sherlock's judging. Sherlock is exclusively focused on high and medium-severity findings, as these vulnerabilities will cause a loss of user funds and most materially damage the reputation of the protocols Sherlock seeks to protect. ### **I. Table of Contents:** * [#ii.-criteria-for-issue-severity](#ii.-criteria-for-issue-severity "mention") * [#iii.-sherlocks-standards](#iii.-sherlocks-standards "mention") * [#iv.-how-to-identify-a-high-issue](#iv.-how-to-identify-a-high-issue "mention") * [#v.-how-to-identify-a-medium-issue](#v.-how-to-identify-a-medium-issue "mention") * [#vi.-recommendations](#vi.-recommendations "mention") * [#vii.-list-of-issue-categories-that-are-not-considered-valid](#vii.-list-of-issue-categories-that-are-not-considered-valid "mention") * [#viii.-list-of-issue-categories-that-are-considered-valid](#viii.-list-of-issue-categories-that-are-considered-valid "mention") * [#ix.-duplication-guidelines](#ix.-duplication-guidelines "mention") * [#x.-best-practices](#x.-best-practices "mention") ### **II. Criteria for Issue Severity:** (repealed; see [#iv.-how-to-identify-a-high-issue](#iv.-how-to-identify-a-high-issue "mention") and [#v.-how-to-identify-a-medium-issue](#v.-how-to-identify-a-medium-issue "mention") for details) ### III. Sherlock's standards: 1. **Subjectivity:** Despite these guidelines, we must understand that because of the complexity & subjective nature of smart contract security, there may be issues that are judged beyond the purview of this guide. However, for the vast majority of cases, this guide should suffice. Sherlock's chosen judges continue to have the last word on considering any issue as valid or not. 2. **Hierarchy of truth:** If the protocol team provides no specific information, the default guidelines always apply. If the protocol team includes specific information in the README or CODE COMMENTS, that information may be used as context during the judging process. In cases where there is a contradiction between the README and CODE COMMENTS, the README should be considered the primary source of truth. The judge can decide that CODE COMMENTS are outdated. In that case, the default guidelines apply. > Example: The code comments state that "a swap can never fail" even though the code is built to support failing swaps. The protocol team can use the README (and only the README) to define the protocol's invariants/properties. Specifically, only the following question can be used for that: > What properties/invariants do you want to hold even if breaking them has a low/unknown impact? Issues that break the invariants from the above question, irrespective of whether the impact is low/unknown, could be assigned Medium severity if it doesn't conflict with common sense. High severity will be applied only if the issue falls into the High severity category in the judging guidelines. > Example: The README states "Admin can only call XYZ function once" but the code allows the Admin to call XYZ function twice; this is a valid Medium > Example: The README states "Variable X must always match USDC amount in the contract" and a user can donate USDC to break that invariant without causing issues to the protocol; this is an invalid issue The Sherlock Judge can use public statements up until 24h before the contest ends to override the language in the chosen source of truth. If guidelines are updated, the new guidelines apply only to contests that start after the date of change. Please check [Criteria Changelog](/audits/judging/guidelines/criteria-changelog) for information on the latest changes in the judging guidelines. **Historical decisions are not considered sources of truth.** 3. **Could Denial-of-Service (DOS), griefing, or locking of contracts count as Medium (or High) severity issue?** To judge the severity we use two separate criteria: 1. The issue causes funds to be locked for more than a week. 2. The issue impacts the availability of time-sensitive functions (cutoff functions are not considered time-sensitive). If at least one of these is describing the case, the issue can be Medium. If both apply, the issue can be considered High severity. Additional constraints related to the issue may decrease its severity accordingly. If a single occurrence of the attack results in a denial of service (DOS) for less than a week, the issue should be evaluated based on a **single occurrence** of the attack, even if it can be repeated indefinitely. It qualifies as a medium-level issue only if it disrupts a clearly time-sensitive function. > Note: if the single occurrence of the attack is relatively long (e.g. >2 days), and it takes only 2-3 iterations to cause a 7-day DOS, it may be considered a valid finding. 4. **(External) Admin trust assumptions**:\ If a protocol defines restrictions on the owner/admin, issues involving attacks that bypass these restrictions may be considered valid. These restrictions must be explicitly stated and will be assessed case by case. Admin functions are generally assumed to be used correctly and not harm users/the protocol. Note: if the (external) admin will unknowingly cause issues, it can be considered a valid issue.\ Note: the internal protocol roles are trusted by default. They can be considered untrusted (i.e. act maliciously) only if it's, specifically, claimed to be untrusted in the contest README OR the user can get the role without admin/owner permission (e.g. paying a specific fee). > Example: Admin sets fee to 200%. The issue "Admin can break deposit by setting fee to a 100%+" is invalid as it's common sense that fees can not be more than 100% on a deposit. > Example: Admin sets fee to 20%. This will cause liquidations to fail in case the utilization ratio is below 10%, this can be Medium as the admin is not aware of the consequences of his action. 5. **Contract Scope:** 1. If a contract is in contest Scope, then all its parent contracts are included by default. 2. In case the vulnerability exists in a library and an in-scope contract uses it and is affected by this bug this is a valid issue. 3. If there is a vulnerability in a contract from the contest repository but is not included in the scope then issues related to it cannot be considered valid. 6. **Design decisions** are not valid issues. Even if the design is suboptimal, but doesn't imply any loss of funds, these issues are considered informational. ### IV. How to identify a high issue: 1. Direct loss of funds without (extensive) limitations of external conditions. The loss of the affected party must be significant. **Guidelines for Significant Loss:** * Users lose more than 1% *and* more than $10 of their principal. * Users lose more than 1% *and* more than $10 of their yield. * The protocol loses more than 1% *and* more than $10 of the fees. ### V. How to identify a medium issue: 1. Causes a loss of funds but requires certain external conditions or specific states, or a loss is highly constrained. The loss must be relevant to the affected party. 2. Breaks **core** contract functionality, rendering the contract useless or leading to loss of funds that's relevant to the affected party. > Note: If a single attack can cause a 0.01% loss but can be replayed indefinitely, it will be considered a 100% loss and can be medium or high, depending on the constraints. **Guidelines for Relevant Loss:** * Users lose more than 0.01% *and* more than $10 of their principal. * Users lose more than 0.01% *and* more than $10 of their yield. * The protocol loses more than 0.01% *and* more than $10 of the fees. {% hint style="info" %} **Note** Likelihood is not considered when identifying the severity and the validity of the report. {% endhint %} ### VI. Recommendations: 1. A PoC (Proof of Concept) is recommended for issues in any of the following categories to avoid placing the burden of proof on the judge: * Non-obvious issues with complex vulnerabilities or attack paths * Issues with non-trivial input constraints, to demonstrate the attack is feasible despite them * Issues involving precision loss * Reentrancy attacks * Attacks related to gas consumption or reverting message calls Additionally, Watsons are strongly encouraged to specify all conditions required to trigger the issue and to clarify scenarios where these constraints may apply. If the original report does not include a Proof of Concept (PoC), it will be considered invalid if the issue cannot be clearly understood without one. 2. Issues that depend on front-running will get their severity downgraded if the deployment chain has a private mempool. High will be Medium, and Medium will be Invalid. > For example, if we have a standard front-running slippage-related issue on DEX, which deserves High severity under normal circumstances (e.g. front-running on Eth Mainnet), should be viewed as Medium on chains with private mempool (e.g. Optimism). Also, the reports have to explain how the issue can happen with unintentional front-running, e.g. saying "the attacker will monitor the mempool looking for the victim's transaction" is invalid. ### VII. List of Issue categories that are not considered valid: 1. **Gas optimizations:** The user/protocol ends up paying a little extra gas because of this issue. 2. **Incorrect Event values:** Incorrectly calculated/wrong values in emitted events are not considered valid medium or high. 3. **Zero address checks:** Check to make sure input values are not zero addresses. 4. **User input validation:** User input validation to prevent user mistakes is not considered a valid issue. However, if a user input could result in a major protocol malfunction or significant loss of funds for other parties (protocol or other users) it could be a valid high. [Example(Valid)](https://github.com/sherlock-audit/2022-10-illuminate-judging/issues/47) 5. **Admin Input/call validation:** 1. Admin could have an incorrect call order. Example: If an Admin forgets to `setWithdrawAddress()` before calling `withdrawAll()` This is not a valid issue. 2. An admin action can break certain assumptions about the functioning of the code. Example: Pausing a collateral causes some users to be unfairly liquidated or any other action causing loss of funds. This is not considered a valid issue. 6. **Contract / Admin Address Blacklisting / Freezing:** If a protocol's smart contracts or admin addresses get added to a "blacklist" and the functionality of the protocol is affected by this blacklist, this is not considered a valid issue.\ However, there could be cases where an attacker would use a blacklisted address to cause harm to a protocol functioning. [Example(Valid)](https://github.com/sherlock-audit/2022-11-opyn-judging/issues/219) 7. **Front-running initializers:** Front-running initializers where there is no irreversible damage or loss of funds & the protocol could just redeploy and initialize again is not a valid issue. 8. **User experience issues:** Issues causing only minor inconvenience without fund loss, such as temporarily inaccessible funds recoverable by the admin, are not valid. 9. **User Blacklist:** User getting blacklisted by a token/contract causing harm only to themselves is **not** a valid medium/high. 10. Issues assuming future opcode gas repricing are not considered to be of Medium/High severity.\ **Use of call vs transfer** will be considered as a protocol design choice if there is no good reason why the call may consume more than 2300 gas without opcode repricings. 11. **Accidental direct token transfers**: users accidentally or intentionally directly transferring any tokens (native, ERC20, etc.) into the in-scope contracts, while it is not a part of the expected protocol operations, and the contract doesn't have a way to retrieve them, is **not** valid as a medium/high issue and is considered a user mistake, if the user hurts themselves only. However, if it leads to hurting the protocol and/or other users, it may be considered a valid issue. 12. **Loss of airdrops** or any other rewards that are not part of the original protocol design is not considered a valid high/medium. [Example](https://github.com/sherlock-audit/2023-02-openq-judging/issues/323) 13. **Use of Storage gaps:** Simple contracts with one of the parent contract not implementing storage gaps are considered low/informational.\ **Exception**: However, if the protocol design has a highly complex and branched set of contract inheritance with storage gaps inconsistently applied throughout and the submission clearly describes the necessity of storage gaps it can be considered a valid medium. [Example](https://github.com/sherlock-audit/2022-09-notional-judging/issues/64) 14. **Incorrect values in View functions** are by default considered **low**.\ **Exception**: In case any of these incorrect values returned by the view functions are used as a part of a larger function which would result in loss of funds then it would be a valid **medium/high** depending on the impact. 15. **Stale prices and Chainlink round completeness** Recommendations to implement round completeness or stale price checks for any oracle are invalid. > Exception: the recommendation to implement stale price checks **may** be valid. For [example](https://github.com/sherlock-audit/2024-12-mach-finance-judging/issues/41), the protocol may be using Pyth pull-based oracle, which requires requesting the price before using it. Hence, if we don't request the price firstly, or check it for staleness, then we can end up using very old price (e.g. from 1 hour/day ago). 16. Issues from the previous contests with `wont fix` labels (if it's an update contest) **and** issues from previous audits (linked in the contest README) marked as acknowledged (not fixed) are not considered valid. 17. **Chain re-org** and **network liveness** issues are not valid. 18. **ERC721 unsafe mint:** Issues where users cannot safemint ERC721 tokens due to unsupported implementation are not valid.\ Example: 19. **Future issues:** Issues that result out of a future integration/implementation that was not mentioned in the docs/README or because of a future change in the code (as a fix to another issue) are **not** valid issues. 20. **Non-Standard tokens:** Issues related to tokens with non-standard behaviors, such as [weird-tokens](https://github.com/d-xo/weird-erc20) are not considered valid by default unless these tokens are explicitly mentioned in the README. Tokens with decimals between 6 and 18 are not considered weird. 21. Using Solidity versions that support **EVM opcodes that don't work** on networks on which the protocol is deployed is not a valid issue beacause one can manage compilation flags to compile for past EVM versions on newer Solidity versions. 22. **Sequencers** are assumed to operate reliably without misbehavior or downtime. Vulnerabilities or attacks that rely on sequencers going offline or malfunctioning are invalid. ### VIII. List of Issue categories that are considered valid: 1. **Slippage** related issues showing a direct loss of funds with a detailed explanation for the same can be considered valid **high** 2. **EIP Compliance:** For issues related to EIP compliance, the protocol & codebase must show that there are important external integrations that would require strong compliance with the EIP's implemented in the code. The EIP must be in regular use or in the **final state** for EIP implementation issues to be considered valid 3. **Identifies the core issue:** In case of issues that have a large number of duplicates, Issues that identify the core issue and show valid loss of funds should be grouped. 4. **Out of Gas:** Issues that result in Out of Gas errors either by the malicious user filling up the arrays or there is a practical call flow that results in OOG can be considered a valid **medium** or in cases of blocking all user funds forever maybe a valid **high**.**Exception:** In case the array length is controlled by the trusted admin/owner or the issue describes an impractical usage of parameters to reach OOG state then these submissions would be considered as **low**. 5. **Chainlink Price Checks**: Issues related to minAnswer and maxAnswer checks on Chainlink's Price Feeds are considered medium only if the Watson explicitly mentions the price feeds (e.g. USDC/ETH) for the in-scope tokens on the in-scope chains that require this check. **Additionally**, a proper attack path and at least medium severity impact must be included in the report. See [this](https://stackoverflow.com/questions/78558661/which-chainlinks-price-feeds-still-have-minanswer-and-maxanswer-checks) to know if min/maxAnswer are deprecated on the price feed. ### IX. Duplication guidelines: The duplication guidelines assume we have a "target issue", and the "potential duplicate" of that issue needs to meet the following requirements to be considered a duplicate. 1. Identify the root cause 2. Identify at least a Medium impact 3. Identify a valid attack path or vulnerability path Only when the "potential duplicate" meets all three requirements will the "potential duplicate" be duplicated with the "target issue", and all duplicates will be awarded the highest severity identified among the duplicates. Otherwise, if the "potential duplicate" doesn't meet all requirements, the "potential duplicate" will not be duplicated but could still be judged any other way (solo, a duplicate of another issue, invalid, or any other severity) **Root cause groupings** If the following issues appear in multiple places, even in different contracts. In that case, they may be considered to have the same root cause. 1. Issues with the same logic mistake. > Example: uint256 is cast to uint128 unsafely. 2. Issues with the same conceptual mistake. > Example: different untrusted external admins can steal funds. 3. Issues in the category * Slippage protection * Reentrancy * Access control * Front-run / sandwich ( issue A that identifies a front-run and issue B that identifies a sandwich can be duplicated ) If the underlying code implementations, impact or fixes are different, then they may be treated separately. For the root cause categories above, the duplication should be based on the following groups: 1. Reentrancy: * [Reenter in the same function](https://github.com/sherlock-audit/2024-03-zap-protocol-judging/issues/157); * [Cross function reentrancy](https://github.com/sherlock-audit/2022-11-bullvbear-judging/issues/88) (in a different function inside the contract); * Cross contract reentrancy (in a different contract within the codebase); * [Read-only reentrancy](https://github.com/sherlock-audit/2022-11-bond-judging/issues/23). * [Cross-chain reentrancy](https://medium.com/immunefi/the-ultimate-guide-to-reentrancy-19526f105ac#8256). If several reports find different scenarios for the same type of reentrancy within the codebase, they should be considered to have the same root cause. 2. Front-running/sandwich/slippage protection: * Can be fixed by slippage protection; * Can be fixed by a commit-reveal mechanism (e.g. the user front-runs the admin, who's trying to blacklist them). ### X. Best practices: 1. Read the contest readme and documents thoroughly. 2. Submit issues that are considered valid according to Sherlock guidelines based on your discretion 3. Do not submit multiple issues in a single submission. Even if the 2 completely different issues occur on the same line, please make sure to separately submit them.\ Below is a valid example where multiple occurrences can be combined into one issue: [Example](https://github.com/sherlock-audit/2022-11-dodo-judging/issues/47).\ Also, there could be multiple occurrences of an issue but they may need to be submitted separately as each occurrence need not be an obvious repetition like the `safeTransfer` example. Watsons must use their own discretion in such cases. 4. Be specific and sufficiently descriptive when describing an issue's impact. Bad: Loss of funds for the user Good: Loss of funds for users as there is no access control for the ‘withdraw’ function 5. **Do not add** unnecessarily **long code snippets** into the submission. Keep the code snippet limited to the scope of the impact, and be as descriptive as possible in the Vulnerability Detail sections. 6. Do not copy-paste issues from other contests/reports/past audits. They are extremely unlikely to be valid to the respective contest. This guide shall be regularly updated as more contests are judged and with evolving Smart contract security principles, the judging standards are subject to change over time. ### XI. Glossary **Attack Path**: A sequence of steps or actions a malicious actor takes to cause losses or grief to the protocol or users and/or gain value or profit. **Front-run**: There is operation A; if executed, it typically has no losses for anyone. If some other operation B executes before A, either in the same transaction or a separate transaction, there is a loss of some sort for either the protocol or some user(s) (it can be the same user) **Root Cause**: The primary factor or a fundamental reason that imposes an unwanted outcome **Sandwich**: A front-run, followed by operation C controlled by the attacker who also executed operation B. The goal of operation C is to revert the contract to its initial state. **Vulnerability Path**: A sequence of steps showcasing how an issue causes losses or grief to the protocol or users through well-intended usage of the protocol. # Criteria Changelog All future changes to the Issue criteria page will be logged here. ## 1.12 - 24/06/2025 *** Batch 7: * SJIP 25: Clarify the guideline about invariants/properties * SJIP 26: Clarify how to determine if the protocol role is trusted * SJIP 27: Update the guideline about accidental token transfers * SJIP 28: Clarify where the protocol team should list their known issues and acceptable risk * SJIP 29: Clarify the guideline about repetitive DOS attacks ## 1.11 - 06/02/2025 *** Batch 6: *Links are added to each SJIP separately* * SJIP 20: [Clarify that acknowledged issues are not valid](https://github.com/sherlock-protocol/governance-and-discussion/discussions/23) * SJIP 21:[ Clarify front-running on chains with private mempool](https://github.com/sherlock-protocol/governance-and-discussion/discussions/22) * SJIP 22: [Remove the `min/maxAnser` guideline](https://github.com/sherlock-protocol/governance-and-discussion/discussions/25) * SJIP 23: [Clarify Oracle Staleness](https://github.com/sherlock-protocol/governance-and-discussion/discussions/21) * SJIP 24: [Likelihood is not considered during judging](https://github.com/sherlock-protocol/governance-and-discussion/discussions/24) ## 1.10 - 12/11/2024 *** Batch 5: * SJIP 19: Update judging process ## 1.9 - 12/09/2024 *** Batch 4: * SJIP 14: Clarify High and Medium severities * SJIP 15: Off-chain mechanisms question * SJIP 16: Clarify future integrations and invariants in the README and Judging Rules * SJIP 17: Remove Legacy Report Template * SJIP 18: Remove the question about hardcoded values ## 1.8 - 08/07/2024 *** Batch 3: * SJIP-11: Introduce new report template * SJIP-12: Clarify duplication considerations * SJIP-13: Fix typo ## 1.7 - 10/06/2024 *** Batch 2: * SJIP-7: Duplication * SJIP-8: Missing Curcuit Breaker Checks * SJIP-9: Change Trusted/Restricted Logic ## 1.6 - 17/05/2024 *** Batch 1: * SJIP-5: Update hierarchy of truth * SJIP-6: Improve known issue question in contest QA ## 1.5 - 29/01/2024 *** * Historical decisions are no longer considered sources of truth. They may guide Watsons, but judgments should always be based on rules as they are and mistakes should not be repeated. Private messages are not sources of truth. * Updated the [/pages/jPjV1lgaPyFBBhBADYxn#v.-how-to-identify-a-medium-issue](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#v.-how-to-identify-a-medium-issue "mention") and [/pages/jPjV1lgaPyFBBhBADYxn#v.-how-to-identify-a-medium-issue](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#v.-how-to-identify-a-medium-issue "mention") sections to better explain what high and medium severity issues are. Repealed the [/pages/jPjV1lgaPyFBBhBADYxn#ii.-criteria-for-issue-severity](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#ii.-criteria-for-issue-severity "mention") description. * Added an exception to the hierarchy of truth for cases where blatant mistakes in a higher source of truth were made. * Specified opportunity loss and design choices to be out of scope. * Updated the [/pages/jPjV1lgaPyFBBhBADYxn#vi.-requirements](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#vi.-requirements "mention") section to require the PoC in more cases and ensure that Watsons need to discover the limitations and constraints of the issue being triggered. * Rephrased the "Future issues" rule to remove ambiguity. * Changed words in several places to ensure ease of understanding. Typo fixes. ## 1.4 - 10/11/2023 *** * Made network liveness our of scope, with an exception of sequencer-like issues if they are preventable and the external admin is restricted in the [/pages/jPjV1lgaPyFBBhBADYxn#vii.-list-of-issue-categories-that-are-not-considered-valid](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#vii.-list-of-issue-categories-that-are-not-considered-valid "mention") section. ## 1.3 - 12/10/2023 *** * Addition of CHANGELOG to the docs. * Addition of rule related to CHANGELOG in the point `Hierarchy of truth` in the [/pages/jPjV1lgaPyFBBhBADYxn#iii.-some-standards-observed](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#iii.-some-standards-observed "mention") section ## 1.2 - 12/09/2023 *** * Some minor changes in the judging criteria documentation structure * Added the `Contract Scope:` sub-section under [/pages/jPjV1lgaPyFBBhBADYxn#iii.-some-standards-observed](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#iii.-some-standards-observed "mention") section in the judging criteria. * Added the [/pages/jPjV1lgaPyFBBhBADYxn#vi.-requirements](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#vi.-requirements "mention") section in the judging criteria: * Added `Non-Standard tokens:` point in the [/pages/jPjV1lgaPyFBBhBADYxn#vii.-list-of-issue-categories-that-are-not-considered-valid](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#vii.-list-of-issue-categories-that-are-not-considered-valid "mention") section * Extended the `EIP compliance` point in the [/pages/jPjV1lgaPyFBBhBADYxn#viii.-list-of-issue-categories-that-are-considered-valid](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#viii.-list-of-issue-categories-that-are-considered-valid "mention") ## 1.1 - 01/08/2023 *** * Added rules for escalations: [Broken mention](broken://pages/TJxOO0dPyMzB82z2Uwec#rules-for-escalation) * Added the `External Admin trust assumptions` sub-section under [/pages/jPjV1lgaPyFBBhBADYxn#iii.-some-standards-observed](https://docs.sherlock.xyz/audits/judging/guidelines/pages/jPjV1lgaPyFBBhBADYxn#iii.-some-standards-observed "mention") # Lead Judge The lead judge holds the authority to make final decisions on all contest issues. As Lead Judge, your role is to assess and make decisions on a subset of complex or controversial issues, typically between 1% and 10% of all cases. Your focus will be on issues that are challenging to judge and have been marked as controversial. You are expected to: 1. Evaluate Issues: Carefully analyze each controversial/escalated issue, balancing the judging guidelines and your own subjective common sense for your decisions. Use clear, reasoned explanations for why each judgment was made, especially when an issue requires subjective interpretation or a nuanced approach. 2. Use Judgement & Reasoning: While adhering to the guidelines is important, you can override them based on common-sense reasoning when you find it justified. Your decisions should reflect a balanced understanding of the context and potential impacts of each issue. Deviations from the guidelines should be made only in exceptional cases. 3. Collaborate as Needed: The Sherlock team is available to discuss decisions and provide input. You are encouraged to consult them for brainstorming or clarification, though the individual judgments remain with you. 4. Ensure Judgement Integrity: The Sherlock team will respect your final decisions unless a strong indication of error is identified. ### Deviation Template When deviating from the judging guidelines, document the decision as follows: Based on the audit context, the applicable guideline is: > {guideline} By this guideline, the issue would normally be judged as {severity}. However, in the context of the protocol's security needs, this guideline conflicts with practical considerations due to: * Reason 1 * Reason 2 * ... For these reasons, the issue will be judged as {severity}. # Community Judging You’re going to review some issues anyway, why not get paid for it? ### What’s in it for me? Roughly 8% of the value of the audit contest pot will be set aside as rewards for judges. If an audit has a $50,000 pot, then the portion of the judging pot that will be publicly available is \~$4,000. There’s no requirement to judge all of the issues submitted in a contest. If you judge 1 very difficult issue correctly, you could technically earn the majority of the judging pot. ### How can I become a Judge? You need to have 10+ judging signal to be able to judge. This means if you submit at least 1 valid issue in a Sherlock contest, you are eligible to participate in judging. Watsons that were on the audit or legacy judging leaderboard at the time of announcement will start with an initial signal score. ### What is Real-Time Judging? Real-Time Judging is a live judging contest where hundreds of Judges can contribute to judging contest issues at the same time. Normally \~8% of the audit contest pot is allocated to the judging pot. You can earn USDC by judging just one issue! You’ll be able to track every issue’s severity and duplication progress in the Overview page. You’ll also be able to see each issue’s severity and duplication status. This page will constantly update to show the latest votes of every Watson. ![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXfxORK3RQQV9cts-KCLL3Kzwf7XlX2Xn4s7vFXqbeGvglGHrJxaV5ASGuQvSf5hJncNHC5LIlfHf_g3xMhzi0NzaEqucg3y04Sweeb8LbUIPvY5vLIDwFn0pfhEh3LZBsPPFfOYc7wvcaEIszqJzaMgpDoZ?key=vBHXKQdJakMdc1gIGcMF8w) If you want to participate, you can click on any issue to view the issue description, vote on the duplication status and choose the severity (High, Medium, Invalid). ![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXfunEKJYB2KkuBoI9mll1dGqcGBLsFS5wiviNgeB-yLLW4Q4KXbCKOfNftSk_JUCtw6gcKX5Xjf-3KDOxswdZvjCrdfanRdxoDhTPjO0KUezkEzhr0cBkr7aPT2Ql17G2qQVj8r4JICnL76CTg_UrYS3Nyw?key=vBHXKQdJakMdc1gIGcMF8w)\
### Real-Time Judging Timeline Judging goes live right after the audit contest ends. You can find it in the [Contests](https://audits.sherlock.xyz/contests) section of the Sherlock app. It will be available for any contest in the “Judging” stage. Lasts a fixed number of days (# of issues / 100) days (for example 500 issues would be 5 days), with a minimum of 2 days. ### Key Features of Real-Time Judging * You can judge only a subset of the issues and still get paid for it (even just 1 issue!) * The votes and comments of other judges update in real-time * The currency of the system is called “signal” and you gain signal for correct judgments and lose signal for incorrect judgments * The reward for judging an issue increases over time * The reward for voting on an outcome (i.e. Medium) decreases after others vote for the same outcome * As issues become more controversial (i.e. lots of votes on Medium AND invalid) the signal required to finalize that issue’s outcome increases * Judging contests are finalized once there is enough signal voting in the same direction on each issue > Important! Once you vote or write a comment, changing it may incur a penalty. Think carefully before taking any action and include as much relevant detail in your comments as possible. ### What is Signal? Signal is the currency of Real-Time Judging. Every Judge starts with Signal. Signal is the weight that your vote is assigned. The more Signal you have, the more you can influence the judging results and the more rewards you earn for valid votes. ### How can I increase my signal? After an audit contest, your Signal increases for correct judgments and decreases for incorrect judgments. You can increase your Signal in two ways: 1. Submit correct judgments 2. If your Signal is <100, you can increase your Signal to a maximum of 100 by submitting valid issues in an audit contest If your Signal gets to <10, you can no longer participate in Real-Time Judging. The maximum possible Signal is 1,000. ### How is Signal calculated? For a technical calculation of Signal, see [this spreadsheet](https://docs.google.com/spreadsheets/d/1fQ-8HS4SL0sXqKg6bHHlHFFhbj8Y14cqWOiupYIpIrQ/edit?usp=sharing). To initialize the system, every Watson’s signal was calculated based on their audit and judging leaderboard positions. See [this spreadsheet](https://docs.google.com/spreadsheets/d/1fQ-8HS4SL0sXqKg6bHHlHFFhbj8Y14cqWOiupYIpIrQ/edit?usp=sharing). ### How do I earn USDC? You can see the reward and penalty for every action you take on an Issue page. And at the bottom of the Issue page, you can see the aggregate max rewards and aggregate max penalty for your submission. The rewards earned for voting increase your signal score, and the penalties decrease it. The larger your signal score, the larger the rewards you earn for voting correctly. However, the penalty for incorrect votes will also be larger. Your USDC payout is calculated by subtracting your earned penalties from your earned rewards. The judging pool is shared proportionally with the Judges who have positive points. Example * Alice earned a reward of 25 for correctly voting High on issue #1 * Alice earned a penalty of 10 for incorrectly voting Invalid on issue #2 * Bob earned a reward of 5 for correctly voting High on issue #1 * Alice ends up with 15 points (25 - 10) * Bob ends up with 5 points * Alice will take 75% of the judging pot (15/20) * Bob will take 25% of the judging pot (5/20) ### How are rewards and penalties calculated? AMM (Automated Market Maker) logic decides the rewards and penalties for each vote based on Signal that has already been voted on that judgment. The AMM logic allows for a fair distribution of rewards while mitigating sybil and collusion attacks. More details will be added to this section later. ### How does commenting work? Every severity and duplication judgment on every issue requires a comment. If someone has commented on that same judgment before you (and you agree with it), you can vote for their comment instead of writing your own. Writing a comment can earn you a 300% reward boost on that judgment if your comment accrues the most Signal, but it can result in a 10% penalty if it doesn’t accrue the most Signal. You are only able to write 1 comment per severity. And changing your comment later may lead to receiving a penalty. So only write a comment once you feel you have a strong grasp of the issue, and include as much relevant detail in your comment as possible. ### How can I escalate my issue if I disagree with the outcome? Escalations happen right after the preliminary results are released. To escalate an issue you need to make a comment in the discussion section in the judging app. There are only 24 hours to escalate your issue after the release of the preliminary results. The cost is 2 signal, and you need to have >=100 signal to comment on issues submitted by other Watsons. ### How does Real-Time Judging work in private audit contests? Only the participants in the private audit contest can participate in Real-Time Judging. The threshold to finalize issue judgment will necessarily be lower in these contests. ### What if I submit spam issues in the audit contest so I can earn rewards for them in the judging contest? If a Watson does not meet the Payout Threshold after any audit contest, the issues they submitted in the audit contest will not count for judging rewards. \ \ \
# Dedicated Judge A dedicated judge is dedicated to judge all issues in the contest and gets a 500% reward boost. The offer to be a dedicated judge will be available in the Sherlock Discord's Judging channel. The signup deadline is 24 hours before the audit contest ends. There are only 5 dedicated judges for the public contests (top 5 with highest signal out of those who signed up), and only 3 dedicated judges for the private contests. **Requirement** The dedicated judge must review all issues before the community judging period ends, with a target of assessing 100 issues per day. **Penalty** If the dedicated judge doesn't manage to judge all the issues before the end of community judging, they will receive a penalty. 1. You will not receive the 300% reward boost. Like any other judge, you will receive a 100% reward boost. 2. Your leaderboard signal score will be decreased by 50%, this is a significant penalty. **Reward** If you don't receive the penalty and successfully fulfil your obligations as a dedicated judge. You will receive a 500% reward boost. This boost applies to your 1. USDC pool rewards 2. Signal rewards 3. Signal penalty Note that incorrect judging amplifies your penalties; this will increase the drop in signal score due to the boost. ### Early November Update This update applies to all judges, but is especially relevant for the dedicated judge. Previously, the risk/reward ratio remained constant, with both risk and reward increasing at a steady rate over time. With this update, however, the risk/reward ratio will gradually increase over time. Before this update, judging uncertain issues was generally penalizing. Now, it’s less penalizing, making it advantageous to judge issues you’re unsure about closer to the deadline. # Discussion Discussions on the issue voting pages are essential for reaching the correct judgment. To maintain healthy and high-quality discussions, certain constraints apply to commenting. **Important:** Be sure to include all relevant details in your comment to ensure clarity and completeness. ### Phase 1: Community Judging During this phase: * All judges can comment without restrictions. * Judges without a signal score can only comment on their own issues (as authors). ### Phases 2, 3, and 4 When the Lead Judge and Sherlock Judge are involved, the following rules apply: * Each judge or author is limited to **one comment per issue** in the discussion section. Additional comments may be granted by the Lead Judge or Sherlock Judge. * Judges must have at least **100 signal** to comment on issues submitted by third parties. ### Escalations In Phase 3 (lasting 24 hours), judges can escalate issues by leaving a comment in the discussion. If no escalation occurs, the discussion closes at the start of Phase 4. Escalations require a fixed **signal cost**, which is non-refundable. This cost discourages unnecessary escalations by removing the incentive to escalate freely. # Sherlock's Exclusive Judging Apprentice Program What is the Sherlock Judging Apprentice Program, and how does it help you level up your judging skills? {% hint style="info" %} Note: Judging Apprentices are hand-picked based on their performance on the platform, you **cannot** apply to this program. {% endhint %} As one of the chosen, you'll receive: * **500 Signal** for contributing to the judging process of a contest you've already participated in. * **Boost Your Leaderboard Ranking**: Your judging efforts will directly impact your signal score, offering a unique chance to climb the leaderboard based on your performance. * **Direct Communication with Sherlock's Top Judges**: Get exclusive access to Sherlock’s expert judges for personalized guidance and mentorship. * **Join a Prestigious Circle**: Once graduated you'll join the chat with other graduates, sharing insights and strategies to sharpen your skills. * **Special Recognition** in the Sherlock Discord: Stand out in the community with a unique role that highlights your expertise. * **Earn up to $10k per month**: Master the art of judging and unlock the potential to earn up to $10,000 per month by applying your expertise to contests. * **Higher chance of becoming a Lead Judge**: consistently showing exceptional performance in judging contests after the program, almost guarantees receiving a Lead Judge opportunity. This program runs across **3 contests**, and once you've successfully judged all three, you will have a **high leaderboard signal score**, significantly increasing your earning potential. Performing well in these contests will allow you to make **serious money** by continuing as a top judge. However, to judge contests after you've entered the Judging Apprentice Program, you'll have to sign up as a **dedicated judge**, which means judging all the reports submitted in the contest. As a Judging Apprentice, you will be expected to: * **Thoroughly review and judge** all the issues in the contest you've signed up for as a dedicated judge. * **Provide insightful commentary** and engage in professional discussions, adhering to Sherlock’s judging guidelines. # Referral Program Welcome to Sherlock's Referral Program! Sherlock offers a referral program for teams and individuals who introduce protocol teams to Sherlock. Qualified referrals earn fixed payouts: $1,000 for audit referrals, $1,000 for Sherlock AI referrals, and $500 for bug bounty referrals. ### Overview The Sherlock Partnership Program is for ecosystem operators who regularly advise protocol teams on security decisions. Sherlock owns evaluation, scoping, contracting, and delivery. Partners are paid when referred teams purchase. ### How it works Referrals are submitted through the program form (preferred) or via a formal introduction thread that includes Sherlock. Sherlock runs evaluation, scoping, contracting, and delivery. Referral payouts are issued after customer payments are received and cleared. ### Compensation **Audits**: $1,000 per qualified audit referral (paid once per purchased engagement). **Sherlock AI**: $1,000 per qualified Sherlock AI referral (paid once per new customer subscription). **Bug bounties**: $500 per qualified bug bounty referral (paid once per new bounty program purchase). ### Referral qualification A referral is qualified if: * The referred team is not already in an active sales process with Sherlock at the time of submission. * The referral is submitted through the program form or via an introduction thread that includes Sherlock. * The referred team purchases within the attribution window. Referrals remain eligible for 180 days from submission. ### Payout timing Audits: paid after the customer’s payment is received and cleared by Sherlock. Sherlock AI: paid after the customer’s initial subscription payment is received and cleared by Sherlock. Bug bounties: paid after the customer’s payment is received and cleared by Sherlock. ### Program integrity Sherlock attributes referrals to the first qualified submission on record. Sherlock may decline referrals involving spam, misrepresentation, or low-integrity outreach. If a customer payment is refunded or reversed, the associated referral payout may be reversed or offset. ### How to refer Submit referrals here: [**https://sherlock.xyz/referral-program**](https://sherlock.xyz/referral-program) Sherlock also provides resources to help referrers explain Sherlock’s offerings and refer the right teams - available upon request.
If you’re introducing a team directly, include Sherlock in the intro and share: * Referrer name (individual or organization) and primary contact handle * Referred team name and primary contact handle * What the team is looking for (audit, Sherlock AI, bug bounty) * Timing and any context Sherlock should know before reaching out *** ### Legal *This program is offered at Sherlock’s discretion and may be modified, paused, or terminated at any time. Referral eligibility, attribution, and qualification are determined solely by Sherlock based on the criteria above. Payouts are contingent on receipt and clearance of customer payment; refunds, chargebacks, or reversals may void or offset associated payouts. Referrers are responsible for any taxes or reporting obligations related to payouts.* # Pre-Launch Bounty A Web3 bug bounty is a program that rewards security researchers for responsibly disclosing vulnerabilities. * shorter in duration * smaller in payout * more situational in use Compared with post-launch bug bounties, pre-launch bug bounties are usually: Pre-launch bug bounties are not the default path for most teams. They are typically used only when launch timing, release complexity, or deployment sequencing creates a meaningful pre-mainnet window. * giving whitehats an incentive to report issues before deployment * creating a formal disclosure path during the final stretch before launch * adding one more layer of external scrutiny before code reaches production In that window, a pre-launch bug bounty can help by: A pre-launch bug bounty is a more specific type of Web3 bug bounty used before a protocol goes live.
**Most protocol teams ultimately want a post-launch bug bounty on live code, but a pre-launch bounty can be useful when there is still a gap between audit completion, fix review, and mainnet deployment.**\ \ **Note:** Unlike an audit contest, which is a fixed pre-launch review event designed to pressure-test a codebase at scale, a pre-launch bug bounty is a narrower disclosure program used to keep incentives active during the gap between fix review and mainnet launch. # Post-Launch Bounty Sherlock protects teams against hacks at every step of the journey **Bug Bounty for Qualifying Customers** Qualifying customers who have undergone a Sherlock audit have the opportunity to participate in Sherlock's Post-Launch Bug Bounty Program. Sherlock's Bug Bounty Program is hosted on Sherlock's website. Security Researchers are able to submit vulnerabilities that relate to the customer's respective Bug Bounty program through a secure messaging portal, to which customers are given access. Customers are given access to the platform for an unlimited number of Submission Managers as whitelisted by the customer. Customers are given access to free triaging and issue explanations from a verified Security Researcher who has previously demonstrated proficiency with the customer's codebase (often through a Sherlock audit contest). Customers are also given access to Sherlock's full arbitration suite that includes access to the Sherlock Protocol Claim Committee and the UMA Optimistic Oracle to help with dispute resolution. Customers are provided with co-marketing of the customer's Bug Bounty Program according to Sherlock's standard marketing efforts. **Required Fees of Qualifying Customers** Qualifying customers are required to pay the Platform Fee. The Platform Fee is equal to ten percent (10%) of the Research Fee. The Research Fee is paid by the Customer to a Security Researcher who submits a valid finding in accordance with the rules and payout guidelines of the Bug Bounty Program. The Research Fee includes any goodwill payments. Qualifying customers are required to make payment to Sherlock as follows: 100% paid within 10 days of latest resolution (Sherlock Judge, Sherlock Protocol Claims Committee, UMA Optimistic Oracle). # Platform Rules In order to facilitate cordial and productive exchanges between protocol customers and whitehats, Sherlock has established a set of rules for whitehats and protocol customers to define proper conduct. Breaking these rules as a whitehat could result in removal or ban from the Sherlock platform and/or withholding of payout. Breaking these rules as a protocol team could result in removal from the Sherlock platform and/or provide cause for breakage of the mutually signed agreement. ### Whitehats #### Ethical Standards * Adhere to ethical standards and legal guidelines. Any actions that compromise the integrity, privacy, or availability of systems beyond what is necessary for testing are strictly prohibited. * No harm: Ensure that your testing does not negatively impact users or infrastructure. * Always default to the assumption that the protocol team has good intentions. * Do not threaten, blackmail, dox, or otherwise create a negative environment for the protocol customer. * Do not communicate with the protocol customer outside of the official channel provided by Sherlock * By submitting a vulnerability through Sherlock, you are agreeing to abide by the outcome of the Sherlock dispute resolution process #### Testing Environment * Replicating tests on public mainnet or testnet is prohibited. All testing should be conducted on local forks of either testnet or mainnet. * Use only authorized environments for testing to avoid any unintended disruptions or security risks. * Avoid testing with external dependencies and third-party systems not controlled by the protocol customer to avoid any leaks of the potential vulnerability #### Service Disruptions * Any denial of service attacks that are executed against project assets are strictly forbidden. * Automated testing of services that generates significant amounts of traffic is not permitted. #### Vulnerability Disclosure * Do not publicly disclose vulnerabilities before they are resolved. Reports must be submitted through the Sherlock platform, and we will notify you when it is safe to disclose. * Do not discuss (publicly or otherwise) any aspect of a submitted vulnerability without consent from the protocol customer * Report via Sherlock: Use the official reporting channels to submit your findings. * Never exploit a vulnerability or threaten to do so * Do not attempt to rescue funds without the written consent of the protocol customer * Publicly known bugs or bugs reported in a previous audit are never eligible for payout or reimbursement of deposit #### Payouts * Do not try to cajole a protocol customer into paying you. Always use the provided Sherlock resolution mechanisms. ### Protocol Customers #### Ethical Standards * Do not communicate with the whitehat outside of the official channel provided by Sherlock. * Do not pay whitehats who submit bugs on Sherlock outside of Sherlock’s designated channel or without Sherlock’s consent. * Do not claim a bug report is a known or duplicate issue without clear evidence of where it was publicly available before the whitehat’s submission timestamp. * Always default to the assumption that the whitehat has good intentions. * By listing your bug bounty program on Sherlock, you are agreeing to abide by the outcome of the Sherlock dispute resolution process.
# Dispute Resolution ## Bug Bounty Dispute Resolution From time to time, the submitter of a vulnerability will disagree with the protocol team about the owed payout amount. Because of incentives, this situation may occur somewhat frequently. Sherlock has created a system designed to maximize fairness while promoting and allowing for an environment of goodwill and friendliness between a submitter, protocol team, and any other party involved. Because of this, any participant in the system who seems to be acting in bad faith (badgering, threatening, harassing, etc.) may be removed (banned) from the Sherlock platform. Sherlock maintains full discretion in removal decisions. ### 3-Tiered Court System The Sherlock Dispute Resolution process can roughly be thought of as a 3-tier court system: * District/local courts (Sherlock Bounty Judge) * Circuit/regional courts (7-member Sherlock Protocol Claims Committee) * Supreme Court (UMA Optimistic Oracle) ### Level 1: Sherlock Bounty Judge Once a bug is submitted and the Sherlock team has been involved, the Sherlock Bounty Judge will eventually decide on the bug's validity and payout amount. The Sherlock Bounty Judge is a member of the Sherlock core team. They will make a decision after examining all facts and evidence presented by the report submitter, protocol team, and designed security expert reviewer. This is similar to other bug bounty platforms. And it’s not great because anyone who works at the bug bounty platform itself may be biased. If a bug gets paid out, the platform makes money. If not, the platform makes no money. That’s why there are 2 more levels to the Sherlock system. But before we get to the 2nd layer, a decision on validity and payout amount will be made by the Sherlock Bounty Judge. If the issue is deemed invalid or the payout amount is less than desired, the issue submitter has a few options: 1. Do nothing and abide by the decision 2. Enter into a limited (Sherlock-supervised) negotiation with the protocol team 3. Pay $1k to escalate the issue to the 2nd level of the court system: the Sherlock Protocol Claims Committee On the other hand, if the issue is deemed valid and the payout amount is higher than desired, the protocol team has a few options: 1. Abide by the decision and pay the requested amount 2. Enter into a limited (Sherlock-supervised) negotiation with the protocol team 3. Pay $1k to escalate the issue to the 2nd level of the court system: the Sherlock Protocol Claims Committee 4. “Ghost” Sherlock and the submitter and eventually get removed from the Sherlock platform (Note: Sherlock may attempt to enforce any terms of the legal agreement) ### Level 2: Sherlock Protocol Claims Committee The current members of the Sherlock Protocol Claims Committee can be found [here](https://docs.sherlock.xyz/governance/roles#sherlock-protocol-claims-committee). This committee is enforced by a 4 of 7 multisig and the members may change in the future. The Sherlock Protocol Claims Committee has been in existence for over 3 years and has shown itself to be trusted with multi-million dollar situations in Sherlock’s smart contract coverage protocol. The Sherlock Protocol Claims Committee will have 1 week to come to a decision. ### Level 3: UMA Optimistic Oracle But of course, these members may have certain biases or may not come to a decision that the submitter or protocol team agrees with. In that case, either the submitter or protocol team may pay \~$15k to escalate the decision to the 3rd level of the Sherlock Dispute Resolution process: the UMA Optimistic Oracle. The UMA Optimistic Oracle is best explained [here](https://docs.uma.xyz/protocol-overview/how-does-umas-oracle-work). It is the same mechanism that Polymarket uses to resolve disputed markets that may be worth hundreds of millions of dollars. Sherlock believes it is the best and most trusted third-party dispute resolution system in crypto at the time of writing. ### Negotiation The vast majority of legal cases in the world are settled before going to court. Sherlock hopes that the 2nd and 3rd tiers of the Sherlock Dispute Resolution process are rarely used. That’s why Sherlock allows for a limited period of negotiation as an alternative to escalating to the SPCC or UMA Optimistic Oracle. However, the negotiation MUST take place in the Sherlock-approved channel where Sherlock can view and moderate the discussion. Negotiation must not last longer than 14 days before an alternative option (pay the requested bounty, accept the decision, escalate to the 2nd or 3rd tier) must be selected. Negotiation must remain “good faith” and cordial. \
# Criteria for Bug Bounty reports validity This page includes the standards, duplication clarifications and general out of scope issues general for all Bug Bounty programs. #### I. Sherlock's standards: 1. If the protocol team includes specific information in the Bug Bounty Page or Code Comments, that information may be used as context during the triaging process. In cases where there is a contradiction between the Bug Bounty Page and Code Comments, the Bug Bounty Page should be considered the primary source of truth. The judge can decide that Code Comments are outdated. In that case, the default guidelines apply. > Example: The code comments state that "a swap can never fail" even though the code is built to support failing swaps. 2. The report should include one vulnerability, and if the submitter identifies several vulnerabilities, they should be submitted separately. 3. **(External) Admin trust assumptions**:\ Admin functions are generally assumed to be used correctly and not harm users/the protocol, unless the protocol provides specific trust assumptions/restrictions in the Bug Bounty Page. 4. **Contract Scope:** 1. If a contract is in Bug Bounty Scope, then all its parent contracts are included by default. 2. In case the vulnerability exists in a library and an in-scope contract uses it and is affected by this bug this is a valid issue. 3. If there is a vulnerability in a contract that is not included in the scope then issues related to it cannot be considered valid. #### II. List of Issue categories that are not considered valid: 1. **Gas optimizations:** The user/protocol ends up paying a little extra gas because of this issue. 2. **Incorrectly calculated/wrong values in emitted events** are not considered a valid issue. 3. Check to make sure input values are not zero addresses are **not** considered valid issues. 4. **User input validation to prevent user mistakes** is not considered a valid issue. However, if a user input could result in a major protocol malfunction or significant loss of funds for other parties (protocol or other users) and it qualifies for in-scope severity definitions, then it can be valid. 5. **Admin Input/call validation:** 1. Admin could have an incorrect call order. Example: If an Admin forgets to `setWithdrawAddress()` before calling `withdrawAll()` This is not a valid issue. 2. An admin action can break certain assumptions about the functioning of the code. Example: Pausing a collateral causes some users to be unfairly liquidated or any other action causing loss of funds. This is not considered a valid issue. 6. **If a protocol's smart contracts or admin addresses get added to a "blacklist"** and the functionality of the protocol is affected by this blacklist, this is not considered a valid issue. 7. **Front-running initializers** where there is no irreversible damage or loss of funds & the protocol could just redeploy and initialize again is not a valid issue. 8. Issues causing only **minor user experience issues inconvenience** without fund loss, such as temporarily inaccessible funds recoverable by the admin, are not valid. 9. **User getting blacklisted** by a token/contract causing **harm only to themselves** is **not** a valid issue.\ However, if the malicious actor can use a blacklisted address and harm other parties (protocol or other users), and it qualifies for in- scope severity definitions, then it can be considered valid. 10. Issues assuming future opcode gas repricing are not considered to be valid issues.\ **Use of call vs transfer** will be considered as a protocol design choice if there is no good reason why the call may consume more than 2300 gas without opcode repricings. 11. **Users accidentally or intentionally directly transferring any tokens** (native, ERC20, etc.) into the in-scope contracts, while it is not a part of the expected protocol operations, and the contract doesn't have a way to retrieve them, is **not** a valid issue and is considered a user mistake, if the user hurts themselves only. However, if it leads to hurting the protocol and/or other users, it may be considered a valid issue (if qualifies for in-scope severity definitions). 12. **Loss of airdrops** or any other rewards that are not part of the original protocol design is not considered a valid issue. 13. **Incorrect values in View functions** are by default considered **invalid**.\ **Exception**: In case any of these incorrect values returned by the view functions are used as a part of a larger function which would result in loss of funds then it can be considered valid if it qualifies for in-scope severity definitions. 14. **Stale prices and Chainlink round completeness** Recommendations to implement round completeness or stale price checks for any oracle are invalid. > Exception: the recommendation to implement stale price checks **may** be valid. For [example](https://github.com/sherlock-audit/2024-12-mach-finance-judging/issues/41), the protocol may be using Pyth pull-based oracle, which requires requesting the price before using it. Hence, if we don't request the price firstly, or check it for staleness, then we can end up using very old price (e.g. from 1 hour/day ago). 15. Issues from the previous audits (linked in the Bug Bounty Page) marked as acknowledged (not fixed) are not considered valid. 16. **Chain re-org** and **network liveness** issues are not valid. However, if the underlying protocol is blockchain and the malicious actor can force a chain re-org affecting the protocol and the users, it can be a valid issue if it qualifies for in-scope severity definitions. 17. Issues where users cannot safemint ERC721 tokens due to unsupported implementation are not valid. 18. **Future issues:** Issues that result out of a future integration/implementation that was not mentioned in the docs/README or because of a future change in the code (as a fix to another issue) are **not** valid issues. 19. Issues related to **tokens with non-standard behaviors**, such as [weird-tokens](https://github.com/d-xo/weird-erc20) are not considered valid by default unless these tokens are explicitly mentioned in the Bug Bounty Page. Tokens with decimals between 6 and 18 are not considered weird. 20. Using Solidity versions that support **EVM opcodes that don't work** on networks on which the protocol is deployed is not a valid issue beacause one can manage compilation flags to compile for past EVM versions on newer Solidity versions. 21. **Sequencers** are assumed to operate reliably without misbehavior or downtime. Vulnerabilities or attacks that rely on sequencers going offline or malfunctioning are invalid. 22. **Design decisions** are not valid issues. Even if the design is suboptimal, but doesn't imply any loss of funds, these issues are considered informational. 23. **Lack of storage gaps** in parent contracts are not considered valid issues. #### III. Duplications: If the report is a duplicate of a previously submitted report, then it won't be rewarded even if the issue hasn't been fixed prior to the subsequent submissions. The timestamp of the submission will be used to decide which report was submitted earlier. The duplication of the issue will be considered based on the **root cause** of the reported issue. Therefore, if the reported issues have the same root cause or address the same vulnerability, but appear in multiple places, even in different contract, they may be considered to have the same root cause and considered duplicates. #### IV. Best Practices 1. Read the Bug Bounty page and documents thoroughly. 2. Submit issues that are considered valid according to Sherlock guidelines based on your discretion. 3. Be specific and sufficiently descriptive when describing an issue's impact. Bad: Loss of funds for the user Good: Loss of funds for users as there is no access control for the ‘withdraw’ function 4. **Do not add** unnecessarily **long code snippets** into the submission. Keep the code snippet limited to the scope of the impact, and be as descriptive as possible in the Vulnerability Detail sections. 5. Do not copy-paste issues from other contests/reports/past audits. They are extremely unlikely to be valid to the respective contest. # About Sherlock AI What Sherlock AI is, how it analyzes repositories in context, and what teams use it for during development and pre-launch review. Sherlock AI is an auditor-grade AI security system for onchain code. Teams use it during development and pre-launch review to surface exploit paths earlier, tighten assumptions, and produce fix-ready findings while code is still changing. Sherlock AI is built for real repositories, not isolated snippets. It reads the codebase in context, forms a working model of intended behavior and trust boundaries, then runs targeted analysis paths that map to common exploit surfaces (permissions, value flow, external calls, upgrades, invariants). The output is written for engineers: what breaks, how it can be abused, and what to change. ### How it works Sherlock AI runs analysis as a job-based workflow. Requests are submitted, queued, and processed asynchronously so teams can run audits without blocking on execution time, and so larger orgs can run scans across many repos with consistent tracking. Each job moves through a deterministic, stage-based pipeline designed to reduce variance and produce structured intermediate artifacts that roll up into final findings. A typical run follows five stages: 1. **Plan** — identify scope, language, and relevant files 2. **Research** — build a structured view of the codebase and generate hypotheses 3. **Validate** — test and refine hypotheses against the code and context 4. **Judge** — apply stricter criteria to confirm or reject findings 5. **Report** — produce final issue reports and emit lifecycle events ### What you get Sherlock AI produces structured findings that are meant to be fixed, tracked, and reviewed: * Clear issue statements tied to concrete exploit paths * Supporting evidence and traceability back to the relevant code * Outputs that can feed into review workflows and dashboards via lifecycle events (and optional webhook-style integrations, where configured) ### Where teams use it Sherlock AI is commonly used in three moments: * During development, as code changes daily * As a readiness pass before a staffed audit or contest * Across many repositories for periodic security sweeps and regression checking ### What to expect Sherlock AI is designed to reduce late-stage surprises by turning “we think this might break” into a concrete, fix-ready security report while there is still time to act. It does not replace human review for high-stakes releases; it changes the baseline teams bring into that review. # Configuring a Sherlock AI Run Runs can be configured in two ways: a quick per-run setup in the UI, and a shared default via a repo config file. *** ### UI flow 1. Click **Create Codebase Run** at the top of the dashboard. 2. Select the **repository**, then its **branch**, then the exact **commit**. 3. The **Advanced options** toggle appears. Open it to: * Choose **Files to analyze** (whitelist specific files or folders from that commit). * Add **Additional context files** (docs/configs that help the model). * Provide an **Additional context prompt** such as key areas to focus on, vulnerabilities to skip, or relevant information about the codebase. Changes made here apply only to that run. *** ### Repo defaults with `.sherlock-ai.json` Place a `.sherlock-ai.json` at the repo root (on the branch/commit being run). When the commit is selected in the UI, the values in `.sherlock-ai.json` will prefill the advanced options. Example: ```json { "whitelist_files": ["contracts/core/Vault.sol", "contracts/periphery/Router.sol"], "context_files": ["docs/security-model.md", "specs/withdrawals.md"], "extra_prompt": "Prioritize withdrawal logic and pause/unpause controls." } ``` Fields: * `whitelist_files` (string\[]): if empty, the whole repo is eligible. Only paths to files are supported. Paths should be relative to the repo root. Only `.sol` files are supported. * `context_files` (string\[]): documentation to load and help the model. Only paths to files are supported. Paths should be relative to the repo root. The following file extensions are supported: `.md`, `.txt`, `.json`, `.yml`, `.yaml` * `extra_prompt` (string): concise guidance. Useful for specifying key areas to focus on, vulnerabilities to skip, and relevant information about the codebase. Configurations done through the UI will override what's defined in `.sherlock-ai.json` # Understanding Sherlock AI results How to read Sherlock AI run output, validate assumptions and exploit paths, triage issues as valid or invalid, and close findings with fixes and re-runs. Every Sherlock AI run is tied to a specific snapshot of your code. When you open a run, you’re reviewing findings generated against a particular branch/commit and the assumptions the analysis used to reason across the repository. Treat the run like an audit artifact: it should map cleanly to a PR, a patched commit, and a follow-up re-run.
### Run summary At the top of the run you’ll see the run identifier, status, timestamp, and branch. You’ll also see two counters that matter for triage: #### **Assumptions made** These are explicit assumptions Sherlock AI relied on to model behavior across the system. They often relate to integration reality (external contract interfaces, token behavior), configuration (addresses wired in, upgrade state), and trust boundaries (which roles are expected to be trusted). Assumptions act like dependencies for findings: if a finding depends on an assumption that doesn’t hold in your deployment, the path may be irrelevant or the mismatch may itself be a risk you should address. #### **Issues found** The number of issues produced for the run, grouped by severity. Severity is a prioritization signal. Before treating severity as release-blocking, confirm reachability and exploit preconditions against your actual deployment model. #### Issues list and navigation The left panel is an index of issues grouped by severity (for example, High and Low). Titles are written to be grep-able: they typically name the component/function and the failure mode. Use search and filters to work through a run the same way you’d work through a formal report: start with High severity issues, then move down, or focus on the subsystem you’re actively changing. ### Anatomy of an issue Each issue is structured to help you validate quickly and fix deterministically. **Title / summary** A direct statement of what breaks and where. Good issue titles usually include the relevant module/function and the failure mode (for example, DoS via a revert, privilege escalation, accounting drift, or integration mismatch). **Severity** Shown near the top of the issue. Severity is based on expected impact if the path is reachable under stated assumptions. It is not a substitute for checking access control, state constraints, and integration reality. **Valid issue / Invalid issue** These controls are how you record triage decisions. Mark Valid when you’ve confirmed the path is reachable in your environment and the behavior violates your security model. Mark Invalid when the report depends on assumptions that don’t hold, misinterprets intended behavior, or describes a path blocked by constraints that are actually enforced (role gating, state invariants, configuration, interface guarantees you control).d If you mark an issue Invalid, leave a short technical reason in your internal tracking (or link a note/PR discussion) so the decision remains auditable later. ### Core sections you’ll see in findings Most issues follow a consistent structure:
**Explanation** A mechanical description of why the issue exists. This should identify what the code assumes, what boundary is being crossed, or what invariant is being violated. When you’re validating, look for the exact dependency: “this external contract must implement method X,” “this role must be untrusted,” “this state transition is reachable,” etc. **Attack Path** A step-by-step call sequence that shows how the failure occurs. This is the fastest way to validate. Walk the path against the code snapshot and check preconditions: * Who can call the entry point? * Under what state is the path reachable? * What inputs are required? * What external contracts/interfaces must behave a certain way? If you can’t make the path work on paper against your code and deployment constraints, the issue is likely invalid or dependent on a wrong assumption. **Impact** What breaks if the path triggers: denial of service on a critical operation, incorrect accounting, privilege escalation, stuck funds, or value loss. Use impact to decide urgency and ownership (core protocol engineers, integration owners, or infra). **Suggested Fix** A fix direction written for engineers, sometimes including a minimal code change. Treat this as a patch hypothesis, not an instruction. The right close-out is always: implement the fix in a PR, ensure tests cover the failure mode, then re-run Sherlock AI against the patched commit. ### How to triage technically (fast and reliably) A good triage loop is consistent and repeatable: **Start with assumptions** Identify which assumptions the issue depends on and confirm they match your intended deployment. A large portion of “looks scary” findings become straightforward once the underlying assumption is confirmed or corrected. **Confirm reachability** Verify the entry point is callable by an attacker class you care about (public user, privileged role, external system) and that state conditions needed for the path can actually occur. **Confirm the failure mode** Find the line(s) where behavior breaks: the revert reason, arithmetic behavior, storage write, call result, or state invariant violation. You want the concrete “this is the moment it fails,” not just a narrative. **Decide disposition** Mark Valid or Invalid. If Valid, decide whether it blocks the release or can be scheduled. **Patch and re-run** After remediation, re-run Sherlock AI on the new commit. The run is your regression check: it confirms the exploit path is closed on the code you actually plan to ship. Severity helps you prioritize, but it isn’t magic. Two technical checks matter more than the label: * **Reachability**: the path must be callable under real constraints. * **Impact domain**: what the path enables if it triggers (DoS vs value loss vs privilege).
High severity findings are often “integration-real”: they become critical only when a particular external contract or configuration is used in production. That’s why the assumptions counter exists. If the assumption is correct, treat the issue with urgency. If the assumption is wrong, treat it as a signal to tighten configuration validation or integration guards. ### Closing out a run A run is in good shape when: * High severity issues are either patched or explicitly accepted with clear reasoning. * Fixes are tied to PRs/commits, not vague statements. * A follow-up run on the patched commit shows the exploit paths are no longer present.
Sherlock AI is strongest when you use results this way: as a structured set of testable claims tied to a commit, with a workflow that turns each valid issue into a verified patch. # Sherlock Shield Exploit payout coverage for qualified audited code Welcome to Sherlock Shield. Sherlock Shield is available for qualified codebases that complete an audit with Sherlock and meet the requirements for coverage. Shield is not included by default with every audit. Here’s how it works: 1. Complete an audit with Sherlock 2. Complete the fix review 3. Sherlock evaluates the audited codebase for Shield eligibility 4. Confirm scope, coverage amount, and final terms 5. If approved, Sherlock Shield provides exploit payout coverage for the covered code Sherlock Shield is part of Sherlock’s broader lifecycle security model, extending protection beyond the audit itself for qualified code that meets coverage requirements. ### Coverage Amount Criteria The amount of coverage Sherlock gives is based on the vulnerabilities found in the Sherlock audit: Each Medium severity vulnerability is worth 1 point, and each High severity vulnerability is worth 5 points. \ \ Additionally, there are multipliers for the type of audit done: | Audit type | Points Multiplier | | ------------- | ----------------- | | Recommended | 0.75 | | Minimum | 1.0 | | Best Efforts | 2.0 | | Private | 1.5 | | Collaborative | 1.5 | \ Like golf, you want your score to be as low as possible so you can access the maximum amount of coverage: | Points | Coverage Amount | | ------------ | --------------- | | 0 | $500,000 | | Less than 3 | $250,000 | | Less than 6 | $200,000 | | Less than 9 | $150,000 | | Less than 12 | $100,000 | | Less than 15 | $50,000 | | Less than 18 | $25,000 | | Less than 21 | $10,000 | | Less than 30 | $5,000 | | 30 or more | $1,000 | Note: Sherlock does not guarantee payment or the availability of funds. Payouts are determined by the [on-chain claims process](broken://pages/nKd9ARrg41HSYsewqIVT) of the Sherlock protocol on Ethereum mainnet. Please review the [Sherlock Disclaimers](/disclaimers) to better understand the coverage offering. # Security Researcher Privacy Policy **Privacy Policy for Sherlock** **Effective Date: 25 June 2025** This Privacy Policy (“Policy”) describes how DeFi Risk Management Foundation (“we,” “us,” “our,” or “Sherlock”) collects, uses, processes, and discloses your personal data when you access or use the website located at (the “Website”) and any related platforms, products, services, or applications we provide (collectively, the “Services”). #### 1. Data Controller Information The entity responsible for determining the purposes and means of processing your personal data is as follows: DeFi Risk Management Foundation, registration number 24045786, registered at Dresdner Tower, 11th Floor, 50th St. and 55th East Street, Panama City, Panama 00000. Where applicable, certain personal data processing activities may also be conducted by or on behalf of Sherlock’s identity verification partner. #### 2. Information We Collect We collect information from you when you interact with our Services. This includes: * Personal information voluntarily provided by you during registration, specifically username associated with your profile. * Information linked to social media accounts or public profiles, including the provided GitHub, Discord, Telegram, and X username. * Content you upload or submit, including materials in code repositories. #### 3. KYC and Identity Verification To comply with regulatory obligations and for security purposes, Sherlock may require you to undergo Know Your Customer (“KYC”) procedures. These are conducted through a third-party provider, currently Sumsub, whose privacy practices are available at . As part of this process, you may be required to submit personally identifiable information, including but not limited to scans of government-issued identification, proof of address, and biometric verification. All such data is collected, processed, and stored by the KYC provider in accordance with its own terms and policies. #### 4. Use of Your Information Your information may be used for the following purposes: * To enable your access to and use of the Services. * To provide support, fulfill requests, and respond to inquiries. * To perform due diligence, conduct identity verification (KYC), and comply with anti-money laundering (AML), counter-terrorism, and other legal obligations. * To improve, personalize, maintain, and secure the Services. * To analyze user behavior for internal research, analytics, and reporting. * To prevent, detect, and respond to fraudulent, unauthorized, or illegal activities. * To enforce our legal agreements. * With your consent, for any other purpose disclosed at the time of data collection. #### 5. Data Access and Disclosure Sherlock will not sell your personal data. Access to your data is strictly limited to the aforementioned usernames and may occur under the following circumstances: * To authorized Sherlock staff, contractors, or service providers acting on our behalf. * In response to lawful requests by public authorities, including to meet national security or law enforcement requirements, subpoenas, court orders, or other legal processes. * When reasonably necessary in cases of substantiated ethical violations or fraud investigations. * With your explicit consent, such as when you authorize data sharing with a third-party application or service. 6\. User Termination. If you wish to discontinue your use of the Services, you may do so at any time by simply ceasing to access or make use of the platform. If you would like to delete the KYC data from Sumsub, please contact us at . 7\. Changes to This Privacy Policy We may update this Privacy Policy from time to time. If we make material changes, we will notify you by updating the date at the top of this page and, where appropriate, by additional notice through the Services. We encourage you to review this Policy periodically to stay informed about how we are protecting your information. By using the Services, you acknowledge that you have read and understood this Privacy Policy.

# Customer Privacy Policy **Effective Date: October 4, 2025** Sherlock ("We," "Us," or "Our") is committed to protecting your privacy. This Privacy Policy explains how Sherlock collects, uses, discloses, and safeguards your information when you use our website, our services including collaborative audits, audit contests, bug bounties, and our AI audit product ("Sherlock AI"), or otherwise interact with us. By accessing or using our Services, you agree to this Privacy Policy. If you are a resident of the European Economic Area (EEA), United Kingdom (UK), or California, you may have additional rights under applicable data protection laws such as the General Data Protection Regulation (GDPR), UK GDPR, or California Consumer Privacy Act (CCPA). We act as a data processor for certain data related to our Services, particularly code and repository data accessed via Sherlock AI. Key Points: * We prioritize data security: Your code and personal information are handled with enterprise-grade protections, including encryption and access controls. We do not use your proprietary code for AI training without explicit consent. * Limited data collection: We collect only what's necessary for providing Services, such as account details, usage data, and code snippets for vulnerability disclosures. * No unnecessary sharing: Data is shared only with authorized service providers or as required by law; we do not sell your data. * Enterprise considerations: For large organizations, we offer data processing agreements (DPAs), support for GDPR/CCPA compliance, and options for data residency. Research suggests that tools like ours must balance innovation with privacy, and we lean toward strict controls to build trust. * User rights emphasized: You can access, delete, or opt out of certain processing; however, evidence from industry guides indicates that complete data anonymity in AI tools is challenging, so we provide transparent opt-outs where possible. #### What Information We Collect We collect personal data (e.g., name, email, IP address) when you create an account or contact us, and non-personal data like code snippets and vulnerability reports during audits. For Sherlock AI, we access GitHub repositories with your permission to scan pull requests (PRs) for vulnerabilities, but we do not store your code except snippets needed in vulnerability reports. #### How We Use Your Information Data is used to deliver Services, improve security insights, and comply with legal obligations. For AI audits, a proprietary codebase is analyzed in real-time but not stored long-term. #### Your Privacy Choices Request access or deletion via . CCPA residents: We do not sell personal information. *** This Privacy Policy ("Policy") describes our practices regarding the collection, use, disclosure, and protection of information when you use our Services. Please read it carefully. If you do not agree, do not use our Services. ### 1. Interpretation and Definitions #### Interpretation Capitalized terms have the meanings defined below, applicable in singular or plural. #### Definitions * Account: A unique profile for accessing our Services. * Company: Sherlock, operating under DeFi Risk Management Foundation, located at Dresdner Tower, 11th Floor 50th St. and 55th East Street, Panama City, Panama 00000. * Cookies: Small files tracking browsing activity. * Device: Any tool accessing our Services (e.g., computer, mobile). * Personal Data: Information identifying an individual (e.g., name, email). * Services: Our website, audits, contests, bounties, and Sherlock AI. * Usage Data: Automatically collected data (e.g., IP address, visit duration). * You: The individual or entity using our Services. ### 2. Collecting and Using Your Personal Data #### Types of Data Collected **Personal Data** We may collect: * Email, name, and contact details for account creation and communication. * Payment information (processed via third-party providers like Stripe). * GitHub authentication data when integrating Sherlock AI. **Usage Data** Automatically collected: * IP address, browser type, pages visited, time spent. * For mobile access: Device ID, OS, browser. **Code and Repository Data (Non-Personal but Sensitive)** For Sherlock AI and audits: * Code snippets for vulnerability reports. * Vulnerability findings and metadata. This data is treated as confidential and processed only for security analysis. We do not collect data from full repositories unless authorized. **Data from Third-Party Services** * GitHub integration: We receive repo access tokens, usernames, and metadata per your permissions. * Social logins (e.g., Google): Name, email. **Tracking Technologies and Cookies** We use: * Essential Cookies: For authentication and functionality. * Performance Cookies: To analyze usage. * You can manage cookies via browser settings. 3\. Use of Your Personal Data We use data for: * Providing Services: Conducting audits, running AI reviews, reporting vulnerabilities. * Account management: Registration, support. * Performance of contracts: Fulfilling audit or bounty agreements. * Communications: Updates, security alerts (opt-out available). * Compliance: Legal obligations, dispute resolution. * For Sherlock AI: Real-time analysis of PRs to detect vulnerabilities; no long-term storage of code. We do not use your proprietary code to train AI models unless you explicitly opt-in via enterprise agreements. ### 4. Sharing of Your Personal Data We share data: * With Service Providers: For hosting (e.g., AWS), analytics (e.g., Google), under strict confidentiality. * Affiliates: For internal operations, bound by this Policy. * Business Partners: For joint services, with your consent. * In Business Transfers: During mergers/acquisitions. * With Your Consent: For other purposes. * For Legal Reasons: To comply with laws, protect rights, or respond to authorities. We do not sell Personal Data. For enterprises, we offer DPAs outlining processor responsibilities. | Sharing Scenario | Recipients | Purpose | | ------------------ | ------------------------------- | ------------------- | | Service Providers | Cloud hosts, payment processors | Operational support | | Legal Compliance | Government agencies | As required by law | | Business Transfers | Acquirers | Asset evaluation | ### 5. Retention of Your Personal Data * Personal Data: Retained as needed for Services, legal compliance (e.g., 7 years for financial records). * Code Data: Not stored except in code snippets used in vulnerability reports, unless retained for audits with consent. * Usage Data: Retained for 12 months for analytics. ### 6. Transfer of Your Personal Data Data may be processed outside your jurisdiction (e.g., US servers). We use Standard Contractual Clauses (SCCs) for EEA/UK transfers and ensure equivalent protections. ### 7. Security of Your Personal Data We employ encryption and access controls. However, no system is 100% secure. For Sherlock AI, proprietary code is not collected and access is limited to authorized personnel. ### 8. Your Privacy Rights * Access, correct, or delete your data. * Opt-out of marketing or certain processing. * GDPR/CCPA Rights: Object to processing, request portability, non-discrimination. Contact: . We respond within 30 days (45 for CCPA). For California Residents: * Categories Collected: Identifiers, commercial info, internet activity. * Sources: Directly from you, GitHub. * Disclosures: To providers for business purposes. * No sales in past 12 months. ### 9. Children's Privacy Services not for under 18; we do not knowingly collect data from children. ### 10. Links to Other Websites We are not responsible for third-party privacy practices (e.g., GitHub). ### 11. Changes to This Privacy Policy Updates posted here with "Last Updated" date. Significant changes notified via email. ### 12. Contact Us Questions? Email . Last Updated: October 4, 2025