CertiK Hunt

Each program defines its own scope, reward ranges, and rules. On top of that, every program 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 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.
A common reference point is 10% of funds at risk, capped at the program's maximum reward — never above the defined maximum.
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.