__Asset Accuracy Assurance__

Bugs found on assets incorrectly listed in-scope will be considered valid and be rewarded.

__Private Known Issues Reward Policy__

Private known issues, meaning known issues that were not publicly disclosed, are valid for a reward equal to that of a bug one severity lower.

__Known Issue Assurance__

Shardeum commits to providing Known Issue Assurance to bug submissions through their program. This means that Shardeum will either disclose known issues publicly, or at the very least, privately via a self-reported bug submission. 

In a potential scenario of a mediation, this allows for a more objective and streamlined process, in order to prove that an issue is known. Otherwise, assuming the bug report is valid, it would result in the report being considered as in-scope, and due a reward.

__Primacy of Impact vs Primacy of Rules__

Shardeum adheres to the Primacy of Rules for all impacts. Which means that the whole bug bounty program is run strictly under the terms and conditions stated within this page. 



__Eligibility Criteria__

Security researchers who wish to participate must adhere to the rules of engagement set forth in this program and cannot be:
- On OFACs SDN list 
- Official contributor, both past or present
- Employees and/or individuals closely associated with the project 
- Security auditors that directly or indirectly participated in the audit review

__Responsible Publication__

Whitehats may publish their bug reports after they have been fixed & paid, or closed as invalid, with the following exceptions:
- Bug reports in mediation may not be published until mediation has concluded and the bug report is resolved.

Immunefi may publish bug reports submitted to this audit competition and a leaderboard of the participants and their earnings.

__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](https://immunefisupport.zendesk.com/hc/en-us/articles/16913132495377-Feasibility-Limitation-Standards) which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.

__Immunefi Standard Badge__

By adhering to Immunefi’s best practice recommendations, Shardeum has satisfied the requirements for the [Immunefi Standard Badge](https://immunefisupport.zendesk.com/hc/en-us/articles/15006865432209-The-Immunefi-Standard-Badge).

Blockian

throwing5tone7

ZhouWu

bountyhunter2048

periniondon630

fomohacker

riproprip

neploxaudit

gladiator111

Pig46940

XDZIBECX

https://drive.google.com/file/d/1VrAHi9k1DaWxxWLpf-BapmsIMHaLA08p/

Shardeum is an EVM-based, linearly scalable network offering low gas fees forever while maintaining true decentralization and (hopefully) solid security. Shardeum is a large project and as such, will be split over two concurrent boosts. This boost, called Core III, will cover the Web3 aspects of the project. This will cover four components: Shardus Core Protocol, Shardeum Validator Nodes, networking libs, and Crypto-utils. For more information about Shardeum, please visit [https://shardeum.org/](https://shardeum.org/)


Network not being able to confirm new transactions (total network shutdown)

Direct loss of funds

Permanent freezing of funds (fix requires hardfork)

Causing network processing nodes to process transactions from the mempool beyond set parameters

Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours

Shutdown of greater than or equal to 30% of network processing nodes without brute force actions, but does not shut down the network

Shutdown of greater than 10% or equal to but less than 30% of network processing nodes without brute force actions, but does not shut down the network

Modification of transaction fees outside of design parameters

Bypassing Staking Requirements

Bypassing Penalties

Blocking specific wallet addresses from making transactions

**Which chains and/or networks will the code in scope be deployed to?**

Shardeum

**Which parts of the code are you most concerned about?**
We are concerned with the web3 and business logic within all four repositories in this boost. Things like transaction queuing, penalties, and consensus. This includes any internal transactions or things involving the global account.

**What attack vectors are you most concerned about?**

Parsing/signature errors, cheating the rotation system, and transaction processing. We received quite a few message parsing and signature related reports in the previous boosts and feel like there may still be some vulns to find. Secure accounts and multisig transactions involving them will be valuable targets and need extra scrutiny.
**Which part(s) of the system do you want whitehats to attempt to break the most?**
transaction queuing, penalties, and consensus.
**Are there any assumed invariants that you want whitehats to attempt to break?**
Sum of EOA account balances before attack == Sum of EOA account balances after attack + transaction fees. This should cover SHM disappearing from the network or being created out of thin air

**What external dependencies are there?**

These are listed in package.json

**Where might Security Researchers confuse out-of-scope code to be in-scope?**


A note on Shardeum and Shardus Core scope: the default config in release mode in the branch is in scope. Whitehats are free to configure, patch, and modify their own malicious nodes however they want. However, target nodes must be running the default config in the target branch in release mode. This is to prevent the whitehats from wasting time reporting things we specifically allow in debug mode. The only exception is minNodes and maxNodes settings, which allow different size networks to be created. Certain vulnerabilities may only exist in certain network sizes, and we do not wish to limit Whitehat activity and participation for lack of computing power attempting to run a large local network. However, network-wide attacks that only work under 128 nodes may be rejected or reduced in severity at our discretion. If the researchers can enable debug mode options remotely then that is valid and can be paid out.

Attacks that require the network to still be initializing/bootstrapping are out of scope. Wait until the network mode reaches “processing” + 15 cycles after startup before launching attacks. The rules for staking/join are a little different and the network will not be public during this time. Attacks on a network that is repairing itself (was once in “processing” mode but has since degraded to “safety” or “recovery”) are in scope.
This bounty introduces the concept of a KYC-required “genesis node”. Attacks performed with genesis nodes are in scope, attacks performed against genesis nodes are in scope. Nodes attacking themselves are out of scope.

0day vulnerabilities in dependencies are in scope. Any other vuln in dependencies is out of scope. Smart contracts are out of scope

Finally, the more nodes that are required to launch an attack, the more at risk the vuln is of being downgraded. If it takes 33% (for example) of the nodes in the network being malicious to cause damage, then it becomes difficult to distinguish the impact from a brute-force/51% attack, which is completely out of scope.

**Are there any unusual points about your protocol that may confuse Security Researchers?**

Please consider how your vulnerability will behave on a network with a shard size of 129 nodes. We will accept reports with a PoC on a smaller network, but the severity may be affected if the impact is less feasible on network with a shard size of 129 nodes.

https://reports.immunefi.com/shardeum-core

Shardeum’s up to date codebase can be found at

Shardeum's codebase

Shardeum’s youtube page can be found at

Shardeum’s youtube page

Tech walkthroughs

Whitepaper

Documentation

Script to clean up code to make review easier:

Script

The following reward terms are a summary, for the full details read our [Shardeum Core III Reward Terms](https://immunefisupport.zendesk.com/hc/en-us/articles/31793771662865-Shardeum-Core-III-Audit-Competition-Reward-Terms)

The reward pool size is determined by the greatest condition met. If multiple conditions are met only the largest reward pool applies.

If one or more Critical severity bugs are found, the reward pool will be **100% of the respective reward pool, $250,000 USD**
If one or more High severity bugs are found, the reward pool will be **75% of the respective reward pool, $187,500 USD**
If one or more Medium severity bugs are found, the reward pool will be **50% of the respective reward pool, $125,000 USD**
Otherwise, the reward pool will be **25% of the respective reward pool, $62,500 USD**

Duplicates and private known issues are valid for a reward.

**Duplicates of Insight reports are not eligible for a reward.**
Rewards are distributed according to the impact of the vulnerability based on the [Immunefi Vulnerability Severity Classification System V2.3.](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/).

**Reward Payment Terms**
Payouts are handled by the Shardeum team directly and are denominated in USD. However, payments are done in USDC on Ethereum.

**Insight Rewards Payment Terms**
Insight Rewards: Portion of the Rewards Pool
The "Insight" severity was introduced on Audit Competition & Attackathon programs to recognize contributions that extend beyond identifying immediate vulnerabilities. Currently, it's not an option to select the Insight severity when submitting a report. However, our team or program will designate it accordingly if applicable. "Insights" underscores our commitment to valuing all types of contributions that contribute to a more secure environment and will always be rewarded. [View more information about Insights.](https://immunefisupport.zendesk.com/hc/en-us/articles/13333032674961-Severity-Classification-System?utm_source=immunefi)

NAME	EARNINGS	TOTAL VALID BUGS	CRITICAL	HIGH	MEDIUM/LOW	INSIGHTS
1	$94,767	11	10	0	1	0
2	$34,483	3	3	0	0	0
3	$32,346	4	4	0	0	3
4	$32,014	3	2	1	0	1
5	$17,111	2	2	0	0	0
6	$13,766	1	1	0	0	0
7	$12,820	3	2	0	1	0
8	$10,297	2	2	0	0	0
9	$1,147	1	0	0	1	0
10	$625	0	0	0	0	1
11	$625	0	0	0	0	1

Audit Comp | Shardeum: Core III

Status

Status