Browse docs
docs / 02

How It Works

How each engagement format runs, and the full journey of a bug bounty report.

Hunt runs three engagement formats, and they do not share one workflow. Most of this page describes the bug bounty report lifecycle, because that is the format with a triage-and-payment pipeline behind it. Challenges and audit contests are covered first, and briefly, because there is less machinery to explain.

#Challenges

A challenge is a time-boxed mission with a published window. You open it from Explore, read the mission, instructions, schedule, and resources, and enroll — which means accepting that challenge's rules. Enrollment can be capped, and it closes when the challenge does.

While a challenge is live you can withdraw your enrollment. Once the challenge moves into judging, or your run is recorded as complete, the enrollment is locked and withdrawal is no longer offered.

Some challenges are worked entirely on Hunt; others send you to an external destination to do the work, and Hunt records your participation and the outcome. Where the work happens is stated on the challenge page, and the link is released to enrolled participants.

Scores, placements, and outcome notes stay hidden — from you as well as from the leaderboard — until CertiK publishes that challenge's results. Publication is one explicit switch, so a score that exists internally is not visible early. Each challenge also declares who its published results are for: public (anyone, signed out included), participants (enrolled researchers), or private (CertiK only). Before publication, an in-audience viewer sees an empty board rather than a partial one.

The challenge listing is open to every researcher, at every access level. Each individual challenge still declares its own minimum level, shown on its Explore card and on the challenge page; most sit at Challenger, which is where every account starts. Above your level a challenge stays listed with its schedule and its requirement, but the mission, instructions, resources, and external link stay closed.

#Audit contests

An audit contest is a fixed-window review of pinned code. Before submissions open, the contest page publishes the repository, the exact commit under review, the scope, the submission deadline, the duplicate policy, the judging criteria, and the prize pool. There is no enrollment step — eligibility is your access level, and you submit within the window.

Each contest declares its own minimum access level; the format is designed for Sentinel and above.

Status. The contest surfaces are built and live, but the participant flow is not finished: submitting a finding runs through the same report machinery as a bug bounty, and those report surfaces are currently Vanguard-only. How a Sentinel's contest submissions reach them is an open decision, and it will be settled before a contest opens rather than described here as though it already works.

#Bug bounties: the report lifecycle

Bug bounty reports require Vanguard access. Every report follows one main path: Submitted → Triage → Sent to project → Project review → Accepted → Paid. Everything else branches off that spine.

#Stage by stage

1. Submitted. Your report enters the queue. Automated checks confirm the required fields are present, your submission is within rate limits, and the target asset is in scope. Missing required fields or out-of-scope targets are rejected at this stage.

2. Triage (manual review). A CertiK triager reads your report end to end, reproduces your proof of concept, sets the severity, and certifies whether it's a valid finding. Valid findings are sent to the project; invalid ones are rejected with a reason.

3. Sent to project. Your certified finding is relayed to the project. A response window begins.

4. Project review. The project confirms the finding, adjusts severity, or rejects it. CertiK rates severity independently of the project — the project's decision on validity and reward stands, subject to the appeals process below, but the independent assessment is on record.

5. Accepted → Paid. Accepted findings move toward payment. If the program requires KYC, you complete it before payout. The project pays you directly — CertiK never holds or disburses funds. The payment is confirmed on-chain and your report is marked Paid.

You can Withdraw a report yourself (permanent, no payment) any time before a payout is in flight — through Accepted — but not once it reaches Payment Pending or Pending KYC, where a real off-platform payment may already be moving; to abandon a report at that point, ask triage. A report can also move into Remediation for appeals and manual handling. The only terminal states are Paid and Withdrawn — a Rejected report is closed but not final, and can still be re-opened through the appeals or remediation path below.

#Severity levels

Hunt uses three severity levels: Critical, High, and Medium. Low and Informational findings are deliberately excluded to keep the focus on real impact. The exact reward range for each level is set per program — check each program's page.

#Service timelines

We track two clocks and report against them transparently:

  • First response (acknowledgment): a triager makes first contact within 48 hours of submission, counted in business days (Mon–Fri). Critical reports are acknowledged fastest — typically within 24–48 hours.
  • Resolution (Accepted → Paid): our target from acceptance to payout is about three weeks.

These are independent of how quickly the project responds. If a project goes silent, the report doesn't disappear — see the backstop below.

#When a project goes silent

Projects have a defined window to respond after a finding is sent to them. If a report sits without a project response for an extended period, you have a recourse: it can be escalated for manual handling so CertiK can chase the project on your behalf. There is no automatic acceptance — but a stalled report won't be forgotten.

#Appeals

  • Rejected by a triager: final.
  • Rejected by a project: final, unless the project re-opens it.
  • Automated rejections: can be appealed once into manual review.
  • Issues after acceptance (for example, a payout problem) are handled through Remediation rather than the appeals path.

Disagreements about validity, severity, or reward are normal. Raise them professionally through the platform's review and appeals process — see Rules of Conduct.