Moonbeam Network-logo

Moonbeam Network

Moonbeam is an Ethereum-compatible smart contract platform on the Polkadot network that makes it easy to build natively interoperable applications. This Ethereum compatibility allows developers to deploy existing Solidity smart contracts and DApp frontends to Moonbeam with minimal changes. As a parachain on the Polkadot network, Moonbeam benefits from the shared security of the Polkadot relay chain and integrations with other chains that are connected to Polkadot.

Polkadot
Blockchain
L1
Rust
Maximum Bounty
$1,000,000
Live Since
16 December 2021
Last Updated
21 October 2022
  • PoC required

  • KYC required

Rewards by Threat Level

Blockchain/DLT
Critical
Up to USD $1,000,000
High
Up to USD $50,000
Medium
Up to USD $20,000
Low
Up to USD $5,000
Websites and Applications
Critical
Up to USD $15,000
High
Up to USD $7,500
Medium
Up to USD $2,500
Low
Up to USD $1,000

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.

All web/app bug reports must come with a PoC in order to be considered for a reward. For smart contract bug reports, at the discretion of the team, a PoC may be required in order to determine if the bug exists, and if necessary, to calculate the extent of the damage the bug could have if exploited.

The payout for critical vulnerabilities is dependent on the ratio between the funds at risk and the combined market cap (as listed on coinmarketcap on the day of the report) of the Moonbeam and Moonriver Blockchains.

This ratio is known as the “risk ratio”, i.e.:

Risk Ratio = Funds at Risk / ( Moonbeam Market Cap + Moonriver Market Cap)

The exact payout is determined as follows:

  • If the risk ratio is at or below 0.5, the payout is calculated linearly between 0$ and 250K.
  • If the risk ratio is above 0.5, the payout is calculated linearly between $250K and $1M; with a maximum cap of $1M

This results in the following payout graph: MoonbeamNEW

Note that a bug reported for one of either the Moonbeam or Moonriver networks that applies to both will be treated as a single report and paid only once.

The Moonbeam Foundation requires KYC to be done for all bug bounty hunters submitting a report and wanting a reward. The information needed is an ID scan along with a selfie to verify identity.

Payouts are handled by the Moonbeam Foundation team directly and are denominated in USD. However, payouts are done in USDT or USDC.

The Moonriver parachain on Kusama and the Moonbeam parachain on Polkadot (estimated launch in Jan 2022) are both included in the assets-in-scope.

All source code of Moonbeam can be found at https://github.com/PureStake/. However, only those in the Assets in Scope table are considered as in-scope of the bug bounty program.

Program Overview

Moonbeam is an Ethereum-compatible smart contract platform on the Polkadot network that makes it easy to build natively interoperable applications. This Ethereum compatibility allows developers to deploy existing Solidity smart contracts and DApp frontends to Moonbeam with minimal changes. As a parachain on the Polkadot network, Moonbeam benefits from the shared security of the Polkadot relay chain and integrations with other chains that are connected to Polkadot.

For more information about Moonbeam Network, please visit https://moonbeam.network/.

This bug bounty program is focused on their Moonriver and Moonbeam parachains (deployed to Kusama and Polkadot respectively) and dApps and is focused on preventing:

  • An attack triggering the network not being able to confirm new transactions (Total network shutdown)
  • An attack causing an unintended permanent chain split requiring hard fork (Network partition requiring hard fork)
  • An attack causing direct loss of funds
  • An attack causing permanent freezing of funds (fix requires hardfork)
  • An attack causing the minting/creation of network utility tokens (MOVR/GLMR) outside of the normal, on-chain inflation mechanism
  • Ability to execute system commands
  • Extract Sensitive data/files from the server such as /etc/passwd
  • Stealing User Cookies
  • Signing transactions for other users
  • Redirection of user deposits and withdrawals
  • Subdomain takeover resulting in financial loss (applicable for subdomains with addresses published)
  • Wallet interaction modification resulting in financial loss
  • Direct theft of user funds
  • Tampering with transactions submitted to the user’s wallet
  • Submitting malicious transactions to an already-connected wallet

KYC required

The submission of KYC information is a requirement for payout processing.

Prohibited Activities

Default prohibited activities
  • Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
  • Any testing with pricing oracles or third-party smart contracts
  • Attempting phishing or other social engineering attacks against our employees and/or customers
  • Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
  • Any denial of service attacks that are executed against project assets
  • Automated testing of services that generates significant amounts of traffic
  • Public disclosure of an unpatched vulnerability in an embargoed bounty
  • Any other actions prohibited by the Immunefi Rules

Feasibility Limitations

The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity. Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.