Mina Protocol: Program info

NOTE! Mina is entitled to make payments in MINA tokens

Known Vulnerabilities Check out this github page for list of known and submitted issues on the Mina Protocol: https://github.com/MinaProtocol/mina/issues

Technical docs To best understand how to get started on Mina, documentation can be found here: https://docs.minaprotocol.com

Protocol focus areas -Chain Quality Attack Additional Information: Any activity which may lower the chain quality (minwindowdensity) of the chain the network converges on would reduce the honest stake assumption required to perform a long fork attack against our blockchain. We want to discover any behavior which can trigger a reduction in the density of blocks produced on the main chain of the network.

-Lowering the Honest Stake Assumption Additional Information: Our honest stake assumption with our current parameters is 65%, so an adversary needs >35% of the network’s supply in order to break that assumption and execute attacks which manipulate the chain. Exempting the above chain quality attack, we want to find any activity which may lower the honest stake assumption, including (but not limited to): temporary manipulatable network partitions, block production/receipt denials, and gossip network inconsistencies.

-Transaction/Snark Work Selection Manipulation Additional Information: We’d like to discover any ways in which a node can manipulate the selection of transactions/snark work for inclusion in blocks in a way where the block producer is not making choices that are in their economic incentive. As an example of this kind of an attack: “there is a way to make a block producer select a piece of snark work you created over another piece of work which would have cost less to a block producer”.

-DDoS (RPC DDoS, Peer ID spam, transaction/snark work spam) Additional Information: Given the severity of DDoS attacks, we’d only like for you to describe the (theoretical) way/scenario in which such an attack could happen. Once the MIna Foundation engineering team reviews your submission, we might invite you to try to attack the network in actuality – please wait for permission from us prior to attack of the network.

-Bootstrap Attacks Additional Information: We’d like to avoid instances in which an adversary could fool a bootstrapping node to bootstrap to a malicious chain, and not the main chain. We’d also like to make sure that an adversary is not able to cause a synchronized node to enter bootstrap by sending it messages as opposed to eclipsing it and waiting for time to pass.

-Eclipse Attack Additional Information: We’d like to discover instances in which an adversary could separate a node from the rest of the network or could trick a node into thinking that a handful of nodes are a good representation of the network when they’re really not.

-Consensus attacks (long fork attack, epoch seed manipulation) Additional Information: We're interested in vulnerabilities that could result in consensus attacks. These could take on several forms, including:

• Forcing a reorganization of the chain. For example, If an attacker can manipulate consensus to the point where you can control what block is included in the longest chain, it'll be a consensus attack.
• Performing a long fork.
• Causing reorgs to happen at length greater than k. Causing a reorg with longer than k blocks could indicate a problem with the network.
• Manipulating the epoch seed. This would be a major attack as if an adversary could use it to give themselves good vrf distribution so they win more.

-Corrupt Messages Additional Information: We want to make sure that the network is resilient against corrupt messages. For example:

• We want to guard against attacks in which, for example, an adversary sends to the network a “garbage” message that’s several bytes-long and the network tries to read it.
• Similar to the Message Length Attack, we want to make sure that we’re resilient to corrupt RPC messages (where these messages contain garbage data). It’s important to protect against these as they might cause a crash and be a denial of service.

Know-Your-Customer (KYC) Verification Submitters participating in the bug bounty program must undergo a Know-Your-Customer (KYC) identity verification process. KYC verification is necessary to ensure the authenticity of submitters and their eligibility to receive bounty rewards.

• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue may not be eligible for a reward.
• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• In the event that we get multiple vulnerability reports on the same issue, the report that contains comprehensive information and detailed instructions for replicating the problem will receive the reward.
• Judges reserve the right to reward subsequent submissions.
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.
• You can fork a private chain to find bugs.
• Employees of O(1) Labs, ecosystem partners compensated by the Foundation, and employees of the Foundation are ineligible for rewards.

• As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.

To participate in this program, you must:

• be at least 18 years of age and not be prohibited from participating in the Program by any applicable law or regulation;
• not be a citizen or resident of any jurisdiction subject to sanctions as enforced by the Office of Foreign Assets Control, including without limitation, Crimea and Sevastopol, Cuba, Iran, Iraq, North Korea, Syria, and you must not be named by Office of Foreign Assets Control as a Specially Designated National or Blocked Person;
• not be an employee, contractor, shareholder, investor or other related party of Foundation;
• not be an employee, contractor, shareholder, investor or other related party of any company, organization or entity that operates a business as a miner, staker or other validator on a public blockchain, if another Tester shares the same affiliation(s) – i.e. only one person per company can participate in the program;
• warrant that you have read and fully understand the Program Details as set forth above, and agree to complete testing with the role that you are assigned.

For more questions on our program rules, please join our Discord server #bug-bounty-support channel to ask any questions you might have.