Security Review Contests
A structured public review where many guards analyse the same frozen scope at once, under fixed rules and incentives. Two Lead Guards anchor coverage, two Lead Judges decide what is valid, and the engagement closes with a review of your fixes rather than a list of findings handed over.
Who it is for
Teams use a contest for a first mainnet launch, a major upgrade, or a high-risk release that introduces new integrations or changes core logic. The common thread is a release where one reviewer’s blind spot is expensive.
How the contest runs
Scoping and quote. You send the repository, the target release and your timing. We price on scope size, complexity and format, then you reserve a slot on the calendar.
Scope freeze. You hand over a final commit, branch or tagged release candidate, with setup instructions and known limitations. That frozen version is the baseline for submissions, judging and remediation.
AutoGuard round. AI agents and static analysers compete first, for 10% of the prize pool. Straightforward and semi-obvious issues surface here, and are judged before the human contest starts, so the researchers who follow spend their time on the attack paths a tool will never find.
Guard contest. The AutoGuard findings are judged and your fixes land before this phase opens, so researchers start on a codebase that no longer carries what the agents already found. They review the scope in parallel using their own methods, competing for the remaining 90%, with two Lead Guards anchoring coverage for the duration.
Community judging. When the contest closes, the guards who took part give an initial assessment of each submission: validity, likelihood and impact. It ranks the likely outcomes quickly and surfaces the issues that need a closer look.
Dual judging. The two Lead Judges then review the submission set in depth, validating findings, grouping duplicates, assigning severity and writing the reasoning behind each decision. This is where the output becomes a fix-ready issue set.
Escalation and final judgment. Preliminary results are posted and guards have a fixed 72-hour window to escalate a decision. Escalated issues are re-reviewed, then judgment is final.
Mitigation review. Once your fixes are ready, we confirm the original issue is no longer reachable, the fix behaves as intended, and the patch introduces no new risk.
What you should prepare
A clean frozen scope, reliable setup and test instructions, and a responsive contact for the duration. Ambiguity you remove up front is time guards spend on real attack paths instead of guessing at your intent.
It also helps to map each planned fix to a commit hash when you plan remediation. Clear mapping makes verification substantially faster.
Planning your timeline
Budget for two review windows and their judging, not one. Two points are predictable: the main contest duration, fixed during scoping, and the 72-hour escalation window after preliminary results. Everything after that depends on how many submissions arrive, how contested they are, and how quickly your team ships clean fixes.
Do not plan a launch for the day the contest closes. The phases that follow can be short or can run for weeks.
Scope it with us.
Tell us what you are shipping and when you launch. We come back with scope, timeline and a price, usually within two working days.