Reward by Threat Level

This explains how CertiK maps a vulnerability's threat level to a reward, and how feasibility is factored in. It applies to two asset categories: Smart Contracts and Blockchain / DLT. (Web & App scope follows each program's published table.)

Status: Draft framework — the impact taxonomy is still in development. The definitions below are working drafts; concrete, testable criteria will replace them as the taxonomy is finalized. Each program's exact reward figures are published on its own page.

#Principles

1. Impact-first. A finding is rated by the real-world consequence of a successful exploit — not by its novelty or the effort to find it.
2. Separation of impact and feasibility. What an exploit could do and how practical it is to pull off are scored separately. Potential impact sets the starting threat level; feasibility then downgrades that level to match the realistic impact. The reward always follows from the final threat level — feasibility never reduces a reward directly.
3. Bounded and predictable. Every reward is published in advance — a minimum–maximum band for value-scaled smart-contract tiers, or a single flat amount for DLT tiers and the smart-contract Medium tier — so you know the upside and projects can plan the cost.

Threat levels are Critical · High · Medium. There is no Low tier.

#Impact taxonomy (in development)

CertiK is building its own impact taxonomy — the definitive list of which concrete impacts map to each threat level. The definitions below are working drafts. The "Where the line sits" column states the test that separates one tier from the next, so terms like significant or recoverable have a concrete boundary.

#Smart Contracts

#Blockchain / DLT

#From threat level to reward

A finding converts to a reward in four steps:

1. Impact — what a successful exploit could do.
2. Threat level — Critical / High / Medium, assigned from the impact taxonomy.
3. Reward model — the value-scaled band (Smart Contracts) or flat rate (DLT) for that tier.
4. Feasibility adjustment — the threat level is downgraded where the exploit is less practical than its full potential suggests.

CertiK uses two reward models, chosen by asset type:

• Smart Contracts → value-scaled (a minimum–maximum band), because funds at risk can be measured directly from on-chain state.
• Blockchain / DLT → flat rate per tier, because the value at risk at the network layer cannot be measured reliably.

#Smart Contracts — value-scaled

Value at risk means the maximum extractable loss — the largest amount an attacker could extract if the bug were exploited to its fullest, not the figure a proof-of-concept happens to show. A bug demonstrated with a small PoC that could scale to drain more is valued at the larger amount and stays Critical. How hard the exploit is to execute is handled separately by feasibility.

Materiality gate. Where the maximum that can ever be lost is below the Critical minimum, the finding's impact type stays "fund theft / Critical," but its final threat level is lowered to the tier whose reward is proportionate to that maximum (down to Medium) — so a program never pays a Critical minimum larger than the funds it actually protected.

#Blockchain / DLT — flat rates

Each tier (Critical / High / Medium) pays a single published amount per program. There is no min–max band and no value-scaling step; the flat rate is the reward for that tier.

Negligible-scope carve-out. A protocol-layer fund-loss or fund-freeze impact that is negligible in scope is rated by magnitude — placed in the tier matching its realistic size rather than awarded the full Critical rate. (This is the DLT counterpart of the smart-contract materiality gate.)

Why DLT uses flat rates: network-layer impacts have no single measurable pool of "funds at risk" — a consensus halt or chain split endangers the entire network's value and operation, not an identifiable balance. A defensible value-at-risk estimate would need heavy, time-sensitive, network-wide simulation that two reviewers could model very differently. A flat rate per tier keeps DLT rewards fast to assess, consistent between reviewers, and predictable, while the taxonomy still places each finding in the correct tier with a coarse threshold check (e.g. "does this affect ≥ 20% of network activity?").

#Feasibility adjustment (the final step)

The earlier steps set a finding's preliminary threat level and reward from its full potential impact. The final step tests how practical the exploit actually is.

Potential impact sets the starting threat level. Feasibility then downgrades that threat level to match how achievable the exploit truly is. When the realistic, achievable impact is materially lower than the theoretical maximum, the finding is moved down one or more tiers (e.g. Critical → High) and paid at the lower tier's rate.

Feasibility has one lever, for both Smart Contracts and DLT: it lowers the threat level — never the reward within a tier, and never upward. A heavily constrained Critical is moved out of Critical, rather than paid the Critical minimum for a barely-exploitable bug. (Within a smart-contract band, position is set by value at risk, not by how hard the exploit is.)

Floor guarantee. Once the final threat level is set — after any feasibility downgrade or materiality-gate adjustment — the payout is never below that tier's published minimum. For fixed tiers (smart-contract Medium and all DLT tiers) the single published amount is that minimum. A finding only reaches Critical if its impact is both genuinely realizable (feasibility) and material in size (materiality gate).

#Worked example

#Summary

This is a living document. The impact taxonomy and the smart-contract adjustment parameters are actively being developed and will be versioned as they are finalized. For the exact reward figures, see each program's page; for the general reward rules see Scope & Rewards.