Bug Bounty

This document describes the terms of our bug bounty.

To report security issues, please email [email protected]

Threat model

For reference, the original audit and threat model for Snowbridge is here: https://github.com/oak-security/audit-reports/blob/main/Snowbridge/2024-05-24%20Audit%20Report%20-%20Snowbridge%20v1.1.pdf.

Bug Bounty Scope

Snowbridge Git Repository

https://github.com/Snowfork/snowbridge (Only the main branch)

Contracts

Ethereum Contracts which cover our Beefy Light Client, Parachain Light Client, Gateway, Agent, Messaging Protocol and Asset transfer functionality:

https://github.com/Snowfork/snowbridge/tree/main/contracts

Relayer

Offchain relayer code which submits messages to both sides of the bridge:

https://github.com/Snowfork/snowbridge/tree/main/relayer

Web App

Javascript SDK used by web applications for interacting with the bridge:

https://github.com/Snowfork/snowbridge/tree/main/web

Snowbridge Web App

Web app (Only the main branch)

Web app for the bridge’s UI:

https://github.com/Snowfork/snowbridge-app

Snowbridge Polkadot SDK Code

Pallets (Only the main branch)

Pallets and related code on Bridge Hub in the Polkadot SDK:

https://github.com/Snowfork/polkadot-sdk/tree/snowbridge/bridges/snowbridge

Assets at risk in scope

User Funds

What is this?

User funds in the Polkadot or Ethereum chain to be transferred through the bridge.

How should it work?

Applications implemented on top of the Bridge's Transport Layer involve transferring user assets. The key process for this type of asset is to freeze user funds on the source chain and create funds on the target chain using the bridge's functionality. Balances on both sides of the bridge transaction must match current asset availability and quantity.

What to look for?

Any bugs around:

  • Mechanism to freeze and (un)lock non authorised funds

  • Logic errors in pallets or smart contracts for bridges

  • Consensus or light client exploitation

  • Possibility of incorrect block generation

  • XCM Bridge communication exploitation

  • XCM Bridge or network DoS

Relayer Rewards

What is this?

Relayer owner funds including compensation for transaction fees and rewards for running a relayer, as well as any funds stored in the relayer’s account.

How should it work?

Funds are defined by the operator and generated to compensate for weight transaction and infrastructure costs to make the bridge work.

What to look for?

Any bugs around:

  • Mechanism to freeze and (un)lock non authorised funds

  • Misbehaving of the system that may lead to chain penalise relayers without justification.

  • Re-routing rewards to a different owner address without consent

Bug Bounty Submission Evaluation Process

Evaluation

There are six stages in the process:

  • Submission: Reporter sends submission to [email protected].

  • Initial Sanity Check

    • Check for completeness, collect missing or incomplete information

    • Confirm submission, assign first reviewer

  • Verify bug and evaluate severity

    • If needed, collect missing information or incomplete information to reproduce

    • Reproduce and provide regular status updates

  • Technical discussion

    • Involve technical teams working the bridges components

    • Define complexity to patch the report

    • Assign an engineer to work in the fix and expedite a timeline

  • Provide feedback

    • Provide comprehensive feedback on criticality and remediation process

    • Announce Payout Award or explain reasons of ineligibility

  • Remediation and bug disclosure

    • Create a PR with the fix

    • Get the PR audited before merge

    • Release a new version of bridges components with the changes

    • Publish a disclosure with report details (including technical and security assessments)

Disclosure timeframe

The bug bounty program mandates a specific remediation period, detailed in the policy, for all confirmed and in-scope bug submissions. The disclosure of these bugs is scheduled for a set period after the release of the fix, and is based on the Parity disclosure policy. However, disclosure will not occur without a completed fix, audit, and release; the disclosure timeline will be adjusted as necessary. For detailed information, please refer to the Parity disclosure policy.

Bug Bounty Severity Classification

The Bug Bounty’s approach to risk severity reflects the importance of measuring risk from both a technical and organisational perspective. Criticality ratings also take into account an attack’s likelihood and its prerequisites for successful exploitation. As in typical risk assessments, attacks more likely to occur are prioritised over less-likely attacks and will be classified accordingly. Following is a semi specific classification of severities for reports to keep in mind while participating and sending submissions:

Critical (up to $50,000)

  • Governance compromise

  • Onchain issues that can cause significant loss of end-user assets

  • Unauthorised assets minting

  • Unauthorised assets burning

  • Double spending

  • Direct loss of bridged funds due to onchain issues

  • Transaction/consensus manipulation

  • Extended shutdown of core or full network functionality

High (up to $15,000)

  • Extended shutdown of partial network functionality

  • Extended blocking or modifying governance process

  • Extended blocking users from accessing their funds

Medium (up to $5,000)

  • Blocking stuffing / Storage bloating leading to performance or cost issues on the bridge

  • Putting on-chain data into a unexpected state without interrupting the system or users from performing their tasks

  • Bugs in the Javascript SDK or web UI that cause loss of end-user assets

Low (up to $1,000)

  • Incorrectly priced weights or transaction fees

  • Bugs in the off chain relayer that could result in failed relaying or loss of relayer funds

Bugs in the web app, Javascript SDK and off chain relayers will only qualify for Low and Medium rewards, besides for exceptional circumstances at our discretion.

Bugs in the web app, Javascript SDK and off chain relayers that do not involve loss of funds or blocked access to the bridge will only qualify for the bug bounty at our own discretion - this bounty is primarily focused on security and protection of funds, rather than UX/UI bugs.

Rules Of The Road

This bug bounty campaign will run starting from the confirmation of the referenda

  • Submissions outside the official start date will not be considered for this campaign. If you suspect that the flaw you found may be fatal for the items in the scope, please do NOT take further actions. Instead, describe your assumptions as detailed as possible in the report.

  • If you’re able to compromise something significant, please stop at the point of recognition, collect the small evidence (enough to understand where you are and what you can do), and report the vulnerability.

  • Duplicate submissions made within 72 hours of each other will split the bounty between reporters. If duplicate submissions are of unequal quality, the split will be at the level of the lesser report, and the greater report will receive a prorated additional bounty on top of the split. Despite striving to be transparent as much as possible, we do not disclose other participant’s names in such cases.

  • If you inadvertently access, modify, delete, or store user data, we ask that you notify us immediately at [email protected] and delete any stored data after notifying us.

Our Security team will investigate and level up the bounty if it has a greater impact than you were able to determine without breaking our stuff. Please do not break our (or anyone’s) stuff as during the bounty program period more people will be using the same resources.

What Is A Good Submission?

If there is no impact, then we aren’t really interested. Purely-theoretical findings are sometimes entertaining to investigate, so feel free to send us any. However, if there’s no way it can be used to break our systems in practice, it won’t be eligible. Read carefully and avoid submissions being discarded:

  • Provide a working proof-of-concept (or equivalent evidence) — assuming that your research didn’t produce unrecoverable changes. This helps us to evaluate whether your submission is within the program’s scope and usable in possible attacks.

  • Include your vision of the potential impact and potential attack scenario, including required attack conditions.

  • The bug must be original and previously unreported (no traces of reporting in public issues or internal audits), however, include links to issues or PR where conversations lead you to the discovery or introduction of the vulnerability.

Reward Eligibility

As a main rule, a reward will ONLY be made once the patch for the vulnerability has landed and been released and you are NOT allowed to share any part of the security issue with any third party, without our written consent first. In addition, consider the following:

  • You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Polkadot/Kusama project.

  • You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.

  • We might be prevented by law from paying you. For example, if you happen to live in a country on a sanctions list that applies to us. In this case, if we can, we’re happy to make a donation to a well-established charity.

  • You must NOT either directly or indirectly exploit the security vulnerability for your own gain/incite, or encourage/assist anyone else in doing so.

  • Each bug will only be considered for a reward once.

Do not threaten or attempt to extort members of the Polkadot/Kusama/Snowbridge ecosystem. We reserve the right to disqualify individuals if they threaten to withhold the security issue from us or threaten to release the vulnerability, or any exposed data, to the public or any third party — or otherwise act in a malicious, disrespectful, or disruptive manner.

The reward mechanism is articulated over following areas:

  • A Hall of Fame of the Bug reporter will be published and regularly updated based on new reports and associated criticality (if they wish to preserve their anonymity, this can be skipped)

  • Based on the criticality a financial reward will be awarded

How You Get Paid

  • Bounty eligible bug hunters will be asked to do a KYC to prove their identity.

  • Bug hunters have to sign a reward letter.

    • Details about payment timeframe and more will be detailed in the letter.

  • We will request a USDC address to send you the reward.

The Bug Bounty Program is a discretionary rewards program for our active community to encourage and reward those who are helping to improve the systems we build. It is not a competition. We can cancel the program at any time and awards are at our sole discretion.

All Bug Bounty awards are subject to compliance with local laws, rules, and regulations. We will not issue awards to individuals who are on sanctions lists or who are in countries on sanctions lists. Please be advised that we might conduct background checks via our screening tool in order to verify this. You are responsible for all taxes payable in connection with the receipt of any rewards. Finally, your testing must not violate any law or compromise any IP rights, data — or funds — that are not yours.

Privacy and Data Protection

As part of participating in the Bug Bounty Program, you will need to share personal data including your name, email address, ID information and photos, and a blockchain address. Snowbridge is committed to protecting and respecting your privacy. Your data will not be shared outside of Snowbridge without your explicit permission.

Legal Safe Harbour

This program strongly supports and encourages security research into Polkadot/Kusama/Snowbridge. If you conduct genuine, in-scope, bug-hunting research in good faith and in accordance with this policy, we will consider your actions to be legitimate and not seek prosecution. But for the avoidance of doubt, this does not give you permission to act in any manner that is inconsistent with the law or might cause us to be in breach of any of our legal obligations.

Curators

The curators are responsible for evaluating the effectiveness of the different phases and for the attribution of the reward to the bug bounty reporter. The bounties will be curated by the Snowbridge team directly.

Last updated