Security experts, software developers and hackers who dedicate time and effort to improve the RSK platform are rewarded. Determinations of eligibility, score and all terms related to an award are at the sole and absolute discretion of RSK Labs.
Rules and rewards
Submit your findings and earn rewards!
The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.
We accept anonymous submissions, but in that case the bounty reward will be donated to charity.
The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.
RSK may cite the submitter name and points earned in RSK blog posts and online bounty rankings.
If you prefer not to be identified in RSK communications by your real name you must clarify this and provide a pseudonym in your submission.
Issues that have already been submitted by another user or are already known to the RSK team are not eligible for bounty rewards.
Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.
You can start or fork a private chain for bug hunting. Please refrain from attacking the RSK mainchain and test networks. Also please refrain from attacking the ETH or ETC main-chains and test networks. An attack will make the vulnerability ineligible for a bounty.
RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.
A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.
RSK websites, infrastructure and assets are NOT part of the bounty program.
RSK bounty program considers a number of variables in determining rewards.
Determinations of eligibility, score and all terms related to an award are at the sole and absolute discretion of RSK Labs.
Examples
The value of rewards paid out will vary depending on severity. The severity is calculated according to the OWASP risk rating model based on Impact and Likelihood
A bug triggered by a single low-cost transaction that forks the RSK blockchain into some nodes accepting a block containing the transaction and some nodes rejecting that block, will be generally considered High.
This is because it is highly likely to be used for an attack but the impact is medium, because a double-spend attack must also be perpetrated to steal assets.
A remote attack to a specific node that steals its private keys with some very low probability will be generally considered High.
This is because the impact is high but the likelihood is medium, and many nodes must be probed until the attacker finds the right victim.
An attack that spams the blockchain or the state with a cost much lower than the expected, will be generally considered Medium.
A remote attack that reveals some private information of a node that does not lead to the loss of funds will be generally considered Low.
The RSK reward program considers a series of variables to determine the rewards.
Eligibility determinations, scoring and all terms related to a prize are at the sole and absolute discretion of RSK Labs.
RSK protocol stack has some similarities with Ethereum, but differs in many ways. Most of the protocols, such as consensus, blockchain synchronization, state trie and EVM have been redesigned or modified. As there is no currently formal description of these new protocols, vulnerabilities in the protocol design would be evaluated against the intended functionality, which may not be evident.
We encourage researchers to look for problems in the design of the following areas:
Bitcoin Bridge (two way peg)
Federation members management
Block difficulty adjustment algorithm
Selfish mining incentives
SPV security
Uncle mining incentives
State Trie security
Misaligned / unintended economic incentives and game theoretic flaws
Security weaknesses / attacks on the PoW algorithm or Merge-Mining system
A concrete example could be a contract that consumes very little gas but leads to a lot of computational effort effectively opening the door for DoS attacks.”
Assuming that the protocols and algorithm designs are flawless, does a client implementation conform to the intended behaviour? Issues could include:
Validations of blocks, transactions and messages
RSK Virtual Machine code execution
Transaction execution
Contract creation
Message calls
Calculation and enforcement of gas and fee
This category focuses on generalized attacks on the whole network or a subset of it:
51% and other X% attacks.
Isolation attacks
Finney attacks.
Sybil attacks.
Replay attacks.
Transaction / messages malleability.
(global) DoS.
Attacks on a single RSK client relating to the RSK platform:
DoS / resource abuse
Account / wallet address gathering/probing
Broadcast / withhold attacks
This category addresses more classical security issues:
Data type overflow / wrap around, e.g. integer overflow.
Panics or not properly handled errors.
Concurrency, e.g. synchronization, state, races.
Issues related to external libraries used.
This category includes:
Incorrect implementation / usage / configuration of:
Elliptic curve (secp256k1, ECDSA).
Hash algorithms (Keccak-256).
Merkle Patricia trees.
Key management
Random source quality
Side channels and information leaks
Want to know more?