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.
PoC required
KYC required
Rewards
Rewards by Threat Level
Reward amount is 10% of the funds directly affected, capped at the maximum critical reward of:
$100,000Rewards 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 bug reports must come with a detailed PoC demonstrating the exploit in a real-world scenario; and written instructions to reproduce, in order to be considered for a reward. Theoretical vulnerabilities without a working POC will not be accepted. 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.
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 2,500$ and 25K.
- If the risk ratio is above 0.5, the payout is calculated linearly between $25K and $100K; with a maximum cap of $100K
This results in the following payout graph:
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
- Extraction of sensitive data/files from the server such as /etc/passwd
- 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.
Proof of Concept
Proof of concept is always required for all severities.
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.