Quick Answer
Sherlock contests put watsons on a fixed scope for a fixed window, with a judging and escalation process that rewards clear, well-substantiated reports. The scope you can actually read carefully is the scope you can find bugs in.
Sherlock contests publish a scope, a prize pool, and a fixed submission window. After the window closes, findings go through judging with a structured escalation period where watsons can dispute severity or duplicate classifications before final payouts. The judging process is more formalized than most contest platforms, which means report clarity and substantiation carry real weight.
Read the scope and any known-issues doc before touching code
Sherlock scopes usually specify exact commit hashes and sometimes prior audit reports — check whether a contract was already reviewed before spending contest hours on it.
Scan the full scope for an initial map
A function and access-control inventory across every in-scope contract gets you oriented faster than reading a large diff cold, especially on contests with 10+ files in scope.
Cross-reference flagged patterns against the protocol's actual design
Sherlock's judging process penalizes reports that don't hold up under scrutiny — a flagged pattern is only worth submitting once you've confirmed it's a real, exploitable deviation from intended behavior, not just an unusual-looking line.
Spend the bulk of your window on manual review of the unusual files
Once the scan tells you which contracts have custom logic worth attention, that's where careful manual reading and report-writing happens.
Sherlock's escalation process means a rushed, thin report is more likely to get disputed or downgraded than on some other contest platforms. That changes the math on where triage time is worth spending — getting oriented fast matters, but so does leaving enough of the window to actually build a defensible case for each finding you submit.
Sherlock contests frequently involve protocol forks or large DeFi codebases with dozens of files. Scanning each in-scope contract individually (or the whole set if you're working from a repo) gives you a working inventory before you start tracing cross-contract calls by hand — which is usually where the time crunch actually happens.