Evaluate a bug-bounty disclosure policy without exploiting anything

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

This is a policy review, not a testing guide

A reader can evaluate whether a protocol has a credible vulnerability-disclosure route without sending unusual traffic, touching production contracts or attempting an exploit. Work only from public policy pages, repositories, security contacts and archived versions. If you discover a vulnerability incidentally, stop interacting, preserve minimal evidence and follow the published channel. Authorization is scope-specific; a bounty headline is not permission to test anything you choose. A disclosure policy also does not replace signer controls; the Bybit signing case shows that what authorized people see can be part of the security boundary.

Read the policy in six passes

1. Assets: list exact contracts, repositories, domains and versions in scope. Note exclusions and third-party dependencies.
2. Impacts: record eligible outcomes and the severity framework. A policy that pays only named impacts may reject a real bug outside its table.
3. Authorization: find explicit good-faith or safe-harbor language, governing terms and jurisdiction. CISA's federal directive treats a commitment not to pursue action for good-faith compliance as a core policy element; that model does not automatically bind a private project.
4. Methods: note prohibited mainnet testing, denial of service, social engineering, privacy access, automated traffic and third-party interaction.
5. Process: identify the official channel, required report fields, acknowledgement targets, remediation communication and publication rules.
6. Payment: record ranges, caps, proof requirements, identity checks, duplicate rules and whether funds are visibly committed. Maximum bounty is not expected payout.

Immunefi's current rules prohibit mainnet or public-testnet testing, exploitation, unauthorized fund rescue, high-traffic automation and premature disclosure for its programs. Its severity system says individual projects may add restrictions. Those two pages must be read alongside the specific project's page.

Hypothetical comparison

Hypothetical: Program A lists three deployed contracts by address, links immutable code revisions, authorizes local-fork proofs, defines impacts, names a 24-hour acknowledgement target and explains coordinated publication. Program B advertises '$1 million maximum' but says only 'all contracts', has no authorization language, no reporting SLA and no version date. Without testing either system, Program A offers stronger operational evidence. Program B's large number does not answer whether a researcher knows what is allowed or how a report will be handled.

Decision criteria and limits

Rate each dimension as explicit, ambiguous or absent, then preserve the page URL and retrieval date because terms change. Save a hash or archived copy where policy terms allow it, and record the page's stated version separately from the retrieval date. Cross-check a security.txt file and repository security policy, but treat conflicts as unresolved. A published policy improves reporting readiness; it does not prove the project pays fairly, remediates quickly or has few vulnerabilities. Conversely, no bounty does not prove insecurity. Pair this review with the audit-scope workflow to compare preventive review with post-discovery handling. Do not contact staff outside the stated channel, test excluded assets or interpret this editorial framework as legal advice.