Flow Protocol: Program info

Important Note on Reproduction Requirements

Reports which follow the General and Target-specific Reporting Requirements in the Program Rules section are much more likely to be prioritized for review.

Reports that do not follow the reporting requirements might not receive a response.

Reward Tiers and Classification

This program accepts only Critical severity reports.

Severity: Critical Reward: **$100,000 USD.

A report qualifies as Critical if it demonstrates one or more of the following:

• Vulnerability in the execution layer, leading to unauthorized account manipulation, or circumvention of resource semantics (e.g. unauthorized resource construction, duplication, or destruction)".
• Vulnerability in the protocol layer, originating from a malicious access node, leading to altering existing data in the databases of execution or consensus nodes.

Note: Reward level depends on value at risk. The maximum reward is the lesser of $100,000 or the on-chain value at risk.

Out of Scope (Exclusions)

Flow Protocol

Flow ecosystem is working on progressively decentralizing the network by hardening the protocol level security and introducing permissionless nodes. For this reason, Flow still relies on protocol-compliant nodes and bounties are limited to permissionless node types. Only attacks originating from unstaked Access and observer nodes will qualify.

Protocol-level vulnerabilities which are only exploitable through the control of Collection, Consensus, Execution or Verification nodes are excluded.

Other Exclusions

• Denial of service, network outages, or performance degradation.
• Griefing attacks where the attacker causes damage or inconvenience to others without gaining unauthorized access to accounts or on-chain assets.
• Theoretical vulnerabilities without any proof or demonstration
• Old compiler version, or compiler version is not locked
• Vulnerabilities in imported contracts
• Code style guide violations, redundant code, best practice issues
• Gas optimizations
• Vulnerabilities that can be exploited through front-run attacks only
• Reports based solely on static analysis tool output without manual validation.
• Reports that describe vulnerabilities in dependencies outside of the target repositories (e.g., upstream Go libraries, libp2p internals).

Target-specific Scope Clarifications

Atree

To qualify for a Flow protocol reward, the vulnerability reproducer should use an unmodified version of flow-emulator on Flow localnet. If modifying the source code of any Flow component is necessary to reproduce the vulnerability, please describe each modification and why the vulnerability cannot be reproduced without modifying Flow components.

Security reports should not evaluate Atree as a standalone component, because Atree relies on some limits and security guarantees provided by other components in Flow (such as onflow/cadence and onflow/flow-go). Before submitting a report, please try to reproduce the vulnerability using a Cadence script running on an unmodified flow-emulator.

Flow EVM Bridge

Reports are in scope only if they demonstrate a vulnerability in:

• Contracts and handlers in https://github.com/onflow/flow-evm-bridge
• Logic exercised when bridging assets between Cadence and EVM, including:
  • Incorrect value conversion between UFix64 and uint256 (decimals, rounding, truncation) that results in loss of escrowed funds.
  • Loss, theft, or permanent lock of assets escrowed by the bridge.
  • Bypass or incorrect behavior of pause, association, admin, or COA logic.
  • Forcing the bridge COA or handlers to call untrusted contracts in a way that can drain, corrupt, or mis-account bridge escrows.
  • Unauthorized capability claims on bridge-managed resources.
  • Bypassing entitlement checks in bridge Cadence contracts.
  • Resource duplication or loss during cross-VM asset transfer.
  • Incorrect handling of Cadence NFT metadata when bridging to EVM.
  • The PoC must deploy a standards-compliant ERC20/ERC721 or Cadence FT/NFT contract and demonstrate that the desync arises from bridge logic, not from nonstandard token behavior.

Out-of-scope

The following reports are not considered valid for Flow EVM Bridge:

• Issues that affect standalone handled assets only (e.g. WFLOW behavior) and would exist even without the bridge, unless they directly impact bridge escrows or users during bridging.
• Attacks that rely on deliberately malicious ERC20/ERC721 contracts that:
  • lie about balances or totalSupply,
  • emit fake/spoofed events, or
  • otherwise violate basic ERC20/ERC721 assumptions, where the impact is limited to that same malicious asset and its own holders.
• Any attack that requires deploying a contract that intentionally violates the behavioral spec of its token standard (ERC20, ERC721, Cadence FT, or Cadence NFT) is out of scope, regardless of the specific mechanism used.
• PoCs that do not use the flow-evm-bridge contracts, and instead reimplement similar logic in a separate local project.
• Theoretical concerns or “design critiques” without a practical exploit and without impact on users who bridge assets.
• Reports that do not include a runnable PoC against flow-evm-bridge contracts and do not demonstrate impact on bridge users will be treated as out of scope for this target.

Safe Harbor

If you conduct your security research and vulnerability disclosure in accordance with the rules outlined in this policy, we will consider your research to be authorized. We will not initiate legal action against you, and we waive any claims under the Computer Fraud and Abuse Act (CFAA) or similar international anti-hacking laws.

General Reporting Requirements

• Avoid unit/integration tests as reproducers: Wherever possible, use sequence of contract deployments and transaction sent to the network to demonstrate the vulnerability. Tests require higher effort to evaluate - reports that use tests for reproduction may not receive response.
• Flow Environment Requirement: You MUST:
  • Provide reproduction steps using either the emulator initialized form Flow CLI or Flow Local Instrumented Test Environment (FLITE, a.k.a localnet). This significantly increases the chances of reporting a valid vulnerability.
  • Use the latest version of Flow CLI.
  • Include the version of the environment used for reproduction.
  • In rare cases where these environments are not suitable for reproducing the vulnerability, explain why.
• Demonstrating the Vulnerability: A valid vulnerability report must demonstrate an exploit against the official, unmodified source code in scope. If your exploit requires modifying the source code of any Flow component to demonstrate its impact, your report must include:
  • A detailed description of each code modification.
  • A clear justification explaining why the vulnerability cannot be reproduced without these changes.
  • The modifications themselves, submitted as a .diff or .patch file.
• Reproduction data: Document each steps to reproduce the vulnerability with:
  • Exact Flow CLI or other commands and their full output.
  • Complete and minimal required source code, including Cadence/Solidity source code for contracts, transactions, and scripts.
• Data Privacy: Localize all tests to your own accounts. Avoid compromising personal data or modifying/accessing other users' data.
• Service Integrity: Make every effort to avoid damaging or restricting the availability of our services. Stop testing immediately if you notice service degradation.

Target-specific Reporting Requirements

Flow Execution layer

Step 1: Start the emulator or localnet environment.

Step 2: Create and set up the victim account. Note: The victim account must deploy only intentionally correct contracts. Reports where the vulnerability exists solely due to a bug or mistake in the victim's own smart contract are not valid. The reproducer must demonstrate a flaw in the Flow protocol or Cadence runtime, not in user-deployed code.

Step 3: Record the state before the exploit - e.g. victim account's initial state (ideally by running a script created for this specific purpose). Include the full output in the report.

Step 4: Create and set up the attacker account.

Step 5: Execute the exploit. The exploit transaction must be signed exclusively by the attacker's account. Co-signing by the victim or any other privileged account invalidates the report.

Step 6: Demonstrate the vulnerability - e.g. victim’s account state change. Run the same state-checking script from Step 3 and include the full output in the report.

Prohibited Actions

• No Automated Overload: Do not use web scanners to crawl, "hammer" endpoints, generate massive traffic, spam forms or account creation flows.
• No Denial of Service: Do not perform any attack that may cause DoS/DDoS to the network, hosts, or applications.
• No Non-Technical Attacks: Social engineering, phishing, spam, or physical attacks against employees, offices, or data centers are strictly prohibited.
• No Data Destruction: Do not download, destroy, or disclose any confidential or personal information you may encounter.

Reporting Standards

• Technical Detail: Provide a clear textual description with reproduction steps in accordance with Reporting Requirements. Include screenshots or Proof of Concept (PoC) code.
• No AI Spam: AI-generated reports without a runnable PoC are not accepted.
  • Submitters must attach actual logs, terminal output, and a runnable script (not pseudocode).
  • Submitters must reference specific commit hashes of the repos being tested
• Sensitive Data: Do not include "Sensitive Data" in your reports

Coordinated Disclosure

• Confidentiality: Keep information about any vulnerability you discover confidential between you and the HackenProof/Company team.
• Publicity: Do not communicate any details to third parties without express permission, even after a fix.

Rewards

• Chained Vulnerabilities: If you report a chain of vulnerabilities, we will pay only for the single vulnerability with the highest severity.

To be eligible for a monetary reward under this program, you must meet the following requirements:

• Originality: When reported, we must not have already known of the issue, either by internal discovery or other reports.
• Material Impact: You must provide a demonstrable vulnerability where, if exploited, the issue would materially affect the confidentiality, integrity, or availability of our assets and requires technical mitigation.
• Employment: You must not be a current or former employee or contractor of the Company.
• Account Integrity: You must use the exact email address associated with your HackenProof account for all communications.
• Timeliness: Vulnerabilities must be reported exclusively through HackenProof within 24 hours of discovery.
• Compliance: You must stay within the defined scope of this program at all times.