Crypto Bug Bounty Program: Scope, KYC, Vault Funding and Response

Platform choice

Design the response process before advertising the maximum reward. A crypto bug bounty program needs an owner who can validate reports, reach engineers and arrange an eligible payment. A platform can support that workflow, but it cannot supply the protocol's missing deployment knowledge or authority to fix a contract.

Start with the assets the team can actually maintain. Identify production contracts, applications and any other targets the program intends to cover. Then evaluate whether a platform's reporting, triage and disclosure process fits those assets. A platform comparison is incomplete if it discusses only the headline reward and ignores who handles a valid report at an inconvenient time.

Immunefi's public rules define requirements for researchers and projects, while individual program pages specify their own scope and conditions. Other platforms may structure those obligations differently. When comparing Immunefi with HackenProof or another provider, inspect the current program agreement and operational terms directly; do not assume identical mediation, payment or disclosure rules from the shared label bug bounty.

Run a rehearsal using a clearly synthetic report before launch. Confirm that the assigned owner receives it, can identify the deployment and can reach the people needed to validate a fix. This is a proposed operational check, not a claim that we tested the sampled programs. The acceptance evidence should be retained by the team operating the bounty.

Displayed vault balances and advertised maxima

Method

Source and selection

All distinct information-page links in the initial server-rendered Immunefi bounty listing, preserving DOM order. This is the visible listing slice, not the full platform. Record language for manual policy classification.

Retrieved

2026-09-05

Observation

All 10 distinct information-page links in the initial server-rendered Immunefi listing were opened. Figures are displayed website values, not independently verified on-chain balances.

Results

In 8 of the 10 sampled program pages, the displayed vault funds were below the displayed maximum bounty. The other 2 showed a higher balance. This comparison describes the page snapshot; it does not establish whether a project can pay its maximum reward from other resources.

All 10 pages also displayed an all-severity proof-of-concept requirement. Eight carried a KYC-required label and two carried a not-required label. Program prose can qualify a badge: ENS, for example, states that it generally does not require KYC while reserving the right to request identity verification in stated circumstances.

Limits

• The initial listing slice can be ranked or promoted and is not the full Immunefi population.
• Vault valuations can move with balances and asset prices. No on-chain ownership, withdrawal restriction or external treasury was verified.
• A displayed balance below a maximum is not a finding of insolvency, nonpayment or inadequate program design. The payout terms and available funding path need separate review.

The reproducible record is kept in the repository: seo/research/articles-32-41-2026-09-05/surveys.py and seo/research/articles-32-41-2026-09-05/survey-40.json. These file paths are not public downloads.

Scope and exclusions that gut a program

A scope should connect an asset to the impacts the team intends to reward. A contract address without a chain or implementation context can become ambiguous. A repository name without a revision or clear deployment relationship can leave a researcher unsure whether a finding affects an eligible asset.

Distinguish exclusions that define the program from exclusions that defeat its purpose. Excluding a test fixture may be appropriate. Excluding every path involving privileged behavior can become problematic if the production design expects untrusted users to reach an administrative integration. The team should review each exclusion against the threat model rather than copy another project's list.

Immunefi's severity documentation contains recommended out-of-scope categories and notes that the actual exclusions differ by program. Its rules also reject unsupported or misrepresented impact claims. Those constraints should be visible to the people writing the program and the engineers receiving reports.

A program that remains tied to retired addresses can produce technically valid but ineligible reports while leaving the live deployment unclear. Make scope updates part of the release process. The owner should compare the program page with the deployed artifact whenever a release changes an eligible target.

Include a route for ambiguity. If a researcher cannot determine whether an integration or impact is covered, the team needs a way to clarify the question before the activity expands. Record the clarification through the platform's authorized process. Private assurances that never reach the program record can create disputes later.

KYC and sanctions exposure

Identity requirements should be explicit before a researcher invests in a submission. A program can require identity information for payment while allowing an initial report without it. The program should state the applicable stage and the process rather than leave the researcher to discover a new requirement after validation.

KYC labels summarize a policy but may not capture every condition. In the sampled pages, the difference between the ENS badge and its conditional prose illustrates why the full terms matter. Read both and resolve apparent conflicts before presenting an eligibility summary.

The protocol's payment process also needs the appropriate legal and compliance review. Eligibility and sanctions obligations can depend on the parties and payment arrangement. A generic article cannot decide whether a particular recipient may be paid. Assign that determination to the organization's authorized owner and document the process the researcher must follow.

Do not ask researchers to send sensitive documents through an improvised public channel. Use the approved process and identify who handles the information. The program's own data-handling choices should be reviewed with the same care as the target application.

A rejected or incomplete identity check should not silently change the technical status of a report. Preserve the distinction between a confirmed vulnerability and a payment-eligibility decision. That separation makes remediation possible even when the reward process encounters a legitimate restriction.

Funded vs advertised caps

The maximum bounty is a conditional promise under the program's terms. A displayed vault balance is an observation about one funding mechanism. They are related but not interchangeable. A project may use other funds, replenish a vault or impose impact-based limits on the reward calculation.

Our measurement shows why a buyer or researcher should ask about the funding path rather than stop at either number. A page can display a large cap while showing a smaller vault balance. That is a question for the program owner, not proof of a payment failure. Equally, a balance above the cap does not establish that the recipient has satisfied the program's conditions or that the funds cannot move.

Write the reward calculation so the responsible team can apply it to a real report. Identify the eligible impact, cap, payment asset and any valuation rule. If a calculation depends on funds at risk, state how that quantity is determined. An undefined financial term is likely to become a dispute when the report is valuable.

1. Validate the report against the actual assets and reward conditions.
2. Apply the documented calculation and record the supporting evidence.
3. Complete the required eligibility checks and obtain funding authority.
4. Make the authorized payment and retain its evidence and disclosure status.

Advertised maximum

The largest reward the program states under its applicable conditions.

Displayed vault funds

The platform's presented value for the vault at the observation time.

Approved reward

The amount determined for a particular eligible report under the program's process.

Executed payment

The actual transfer or settlement record after the required approvals.

Keep those quantities separate in internal reporting. A dashboard that counts advertised maxima as paid rewards overstates actual researcher compensation. A dashboard that treats a momentary vault valuation as the project's entire funding capacity makes a different unsupported claim. The underlying records should decide which label is used.

Safe-harbor wording

A bounty policy should describe the activity it authorizes and the limits that accompany it. The operational team needs to understand those conditions well enough to answer a scope question consistently. A broad promise of researcher protection without an adopted process can create expectations the team has not prepared to meet.

Separate ordinary reporting from intervention during an active exploit. The Security Alliance's Safe Harbor framework describes a specific adopted agreement for whitehat rescue activity. Its documentation identifies protocol adoption steps and limits to protection. A bounty page mentioning safe harbor does not automatically authorize every form of live intervention.

Use qualified legal review for the agreement the project actually adopts. The technical team should supply the asset scope, operational constraints and intended rescue or reporting workflow. Counsel can then assess the terms and jurisdictional implications. Copying a reassuring sentence from another program does not establish that it fits the protocol's authority or custody model.

Pharos Production's incident-response planning and application security assessment scope is relevant to preparing the technical controls around a bounty: identifying exposed applications, clarifying response paths and organizing remediation work. It does not replace the program's legal agreement or confer authority on a researcher. Agree the technical deliverables separately from the adoption decision.

The researcher reporting guide explains the other side of the boundary. A usable policy allows the researcher and the receiving team to reach the same conclusion about what activity is permitted before a report becomes an incident.

Program economics

Budget for operating the program as well as rewarding findings. Someone must validate reports, reproduce supported impacts and coordinate fixes. An advertised cap says little about that workload. The team should estimate it from its own system and retained submission data rather than import a generic cost ratio.

Record the outcome of each submission with a reasoned status. Separate confirmed findings, duplicates, unsupported claims and unresolved reports. Those categories help the owner identify whether the bottleneck is scope clarity, triage capacity or remediation. A single closed-report count hides that distinction.

Use elapsed time carefully. Time awaiting a project's engineering answer differs from time awaiting required researcher information. Preserve the event timestamps needed to explain delays. A response metric without its start and stop conditions is difficult to compare or improve.

1. Assign a technical program owner and a backup who can identify production targets.
2. Document the triage and escalation process, including access to maintainers and payment decision-makers.
3. Rehearse a synthetic report through validation, remediation and payment approval without moving real reward funds.
4. Review scope and funding arrangements when deployments or operating conditions change.
5. Use retained report outcomes to improve unclear terms and recurring engineering weaknesses.

Our Pharos Production profile and audit scoping hub can help define outside technical work that supports this process. External review and a bounty serve different roles. The audit contest comparison explains another bounded assessment option without treating it as permanent program ownership.

The launch decision belongs to the owner who can demonstrate the workflow. The program is ready when an eligible report can reach someone able to validate it, the fix can be checked and a reward can follow the published process. A large number on the page is not a substitute for that operating evidence.

Test the handoff before a real report arrives

A synthetic rehearsal can reveal a missing owner without asking a researcher to discover it during an incident. Prepare a clearly fictional finding against a test artifact, then follow the proposed submission and escalation process. The exercise should identify who receives the report, who validates the impact and who can authorize the relevant engineering work.

Include an ambiguous case. For example, the supplied report may identify a real behavior in the exercise but leave its eligibility unclear under the draft scope. The useful outcome is a documented clarification process. An operator who invents a new exclusion during the rehearsal has identified wording that should be resolved before publication.

Exercise the payment decision without moving reward funds. The owner should be able to identify the applicable calculation, approval authority and any required information. If the funding path depends on another team or governance process, record that dependency and the expected handoff. The advertised maximum should not obscure an operational step that no one has authority to complete.

Finally, review the record as a maintainer joining the program later. It should distinguish technical validation, eligibility, remediation and payment status. Those decisions can progress at different times. Keeping them separate helps the team continue fixing a confirmed issue while an unrelated payment question remains open.

The measurement's label classifications and displayed currency values are retained in seo/research/articles-32-41-2026-09-05/classify-bounties.py and the survey output. They describe the fetched pages only. The rehearsal above is a proposed internal acceptance exercise, not an operational test of those sampled programs.