CertiK Hunt

Every bug bounty program defines its own scope, reward ranges, and rules. On top of that, each one inherits a universal baseline that programs may extend but not weaken. This page covers the platform-wide defaults — always read the specific program's page as well.

Scope and rewards below are the bug bounty rules. Challenges and audit contests publish their own scope, rules, and prize structure on the engagement page; they do not run on the reward tables here.

#Scope principles

Impact First. Real-world impact can raise severity above the rule-classified level. It applies to scope, too: an in-scope impact demonstrated through a technically out-of-scope asset can still be eligible.
Rules First. Program-specific rules govern where they contradict general principles — within the universal baseline. Programs can extend or restrict, but can't drop below the universal floor.
First to report. The first valid report of a root cause wins; duplicates earn nothing.

#Standard out-of-scope

The following are out of scope by default on every program (programs may add to this list, not remove from it):

Testing on mainnet or public testnets against deployed code.
Testing using pricing oracles or third-party smart contracts.
Social engineering, phishing, and physical attacks.
Denial of service (DoS / DDoS).
Vulnerabilities already publicly disclosed (within the prior two weeks).
Bugs requiring leaked or compromised credentials.
Bugs requiring privileged access without modifying those privileges.
51% / consensus attacks and basic economic or governance attacks.
Sybil attacks and centralization risks.
Theoretical impacts with no proof of concept.
Best-practice recommendations and feature requests.
Impacts requiring attacks the reporter has already executed.
Public disclosure of an unpatched vulnerability in an embargoed program.

#Web & App — additionally out of scope

Theoretical impacts without proof or demonstration.
Attacks requiring physical access to a victim's device, or access to the victim's local network.
Reflected plain-text injection (this does not exclude reflected HTML injection, with or without JavaScript, or persistent plain-text injection).
Self-XSS.
CAPTCHA bypass via OCR without demonstrated impact.
CSRF with no state-modifying security impact (for example, logout CSRF).
Missing HTTP security headers or cookie flags without demonstrated impact.
Server-side disclosure of non-confidential information (IPs, server names, most stack traces).
User/tenant enumeration only.
Impacts requiring un-prompted, out-of-workflow user actions.
Missing SSL/TLS best practices; SPF/DMARC misconfiguration.
Issues that only enable DoS.
UX/UI issues that don't materially disrupt use of the platform.
Issues primarily caused by browser or plugin defects, or requiring browser bugs to exploit.
Leakage of non-sensitive API keys (e.g. Etherscan, Infura, Alchemy).
Automated scanner output without demonstrated impact.

#Smart Contract — additionally out of scope

Incorrect data supplied by third-party oracles (this does not exclude oracle-manipulation / flash-loan attacks).
Basic economic and governance attacks (e.g. 51% attacks).
Lack-of-liquidity impacts.
Sybil attacks and centralization risks.

#How rewards are determined

The project chooses the payout within the severity range it has defined. For Critical and High, the top of the range generally reflects funds-at-risk impacts and the lower end reflects non-funds-at-risk impacts.
A discretionary goodwill payout for a valuable out-of-scope find is allowed, at the project's option.
Critical Smart Contract rewards are calculated as 10% of value at risk, clamped to the program's published minimum–maximum band — never below the Critical minimum, never above the Critical maximum. See Reward by Threat Level for the full calculation.
Triage recommends; the project decides and pays directly.

For the full methodology — how a threat level maps to a reward, value-scaled smart-contract bands vs. flat DLT rates, the feasibility downgrade, and the floor guarantee — see Reward by Threat Level.

#Currency

Any currency may be accepted, but stablecoins are strongly preferred (USDC is the default). Volatile or native tokens are allowed only with a clearly defined FX rate — typically a 7-day average at report confirmation — and a program may switch to a stablecoin if a token is too volatile.

#KYC

CertiK does not hold or disburse funds, so KYC is not a CertiK payout gate. Where a program requires it, you complete KYC with the paying project (or via an optional facilitation service) before the project pays you. A payout is held, never forfeited, until any required KYC is complete. Researchers operating as a business can support invoices and business accounts.

#Eligibility

To participate you must be:

18 or older.
Not located in or a national of a comprehensively sanctioned jurisdiction, and not on the OFAC SDN list (or equivalent).
Not a project insider — see conflict of interest below.

Sanctions screening at payout is performed by the paying project.

#Conflict of interest

You are not eligible on a program if you are a current employee of that project, a former employee within the past 12 months, a contributor to in-scope code, or an auditor of in-scope code within 3 months of completing that audit. (Note: this concerns the project — CertiK staff and auditors may participate as researchers.)

#Known issues

Projects are encouraged — but not required — to declare known issues and prior audit findings; declared items reduce duplicate disputes. A "duplicate / known issue" rejection made without prior declaration is still appealable. A project cannot retroactively reject a valid finding by claiming undisclosed prior knowledge.