The XDC Specifications detail the design rationale for the Execution Layer and Consensus Layer.
Consensus Layer Specifications Execution Layer SpecificationsTypes of Bugs
Specification Documents
Clients run the XDC Network, and they need to follow the logic set out in the specification and be secure against potential attacks. The bugs we want to find are related to the implementation of the protocol.
Currently execution layer clients (ClientName, ClientName, ClientName, ClientName and ClientName) and consensus layer clients (ClientName, ClientName, ClientName, ClientName and ClientName) are included in the Bug Bounty Program. More clients may be added as they complete audits and become production ready.
Types of Bugs
Helpful Links
XDC Network
The Solidity and Vyper compilers are in scope of the bug bounty program. Please include all details necessary to reproduce the vulnerability such as: Input program that triggers the bug, Compiler version affected, Target EVM version, Framework/IDE if applicable, EVM execution environment/client if applicable and Operating system, Please include steps to reproduce the bug you have found in as much detail as possible.
Solidity and Vyper does not hold security guarantees regarding compilation of untrusted input – and we do not issue rewards for crashes of the compiler on maliciously generated data.
Helpful Links
The specifications and source code of the XDC Chain Deposit Contract is part of the bug bounty program.
Helpful Links
Deposit Contract Specifications Deposit Contract Source Code
Certain dependencies are crucial for the XDC Network to function, and some of these have been added to the bug bounty program. Currently, the list of dependencies included in the bug bounty program are A-XYZ-0000 and AB-CDEG-0000.
Helpful Links
The EF will also provide rewards based on:
Quality of description: Higher rewards are paid for clear, well-written submissions.
Quality of reproducibility: A Proof of Concept (POC) must be included to be eligible for rewards. Please include test code, scripts and detailed instructions. The easier it is for us to reproduce and verify the vulnerability, the higher the reward.
Quality of fix, if included: Higher rewards are paid for submissions with clear description of how to fix the issue.
Attacker can sometimes put a node in a state that causes it to drop one out of every one hundred attestations made by a validator.
Submit Low Risk BugAttacker can successfully conduct eclipse attacks on nodes with peer-ids with 4 leading zero bytes.
Submit Medium Risk BugAttacker can successfully partition large parts of the network, and it is trivial for an attacker to trigger the vulnerability.
Submit High Risk BugAttacker can successfully conduct remote code execution in a majority client, and it is trivial for an attacker to trigger the vulnerability.
Submit Critical Risk BugThe bug bounty program is an experimental and discretionary rewards program for our active XDC Community to encourage and reward those who are helping to improve the platform. It is not a competition. You should know that we can cancel the program at any time, and awards are at the sole discretion of XinFin Foundation bug bounty panel. In addition, we are not able to issue awards to individuals who are on sanctions lists or who are in countries on sanctions lists (e.g. CountryName, CountryName, etc). Local laws require us to ask for proof of your identity. You are responsible for all taxes. All awards are subject to applicable law. Finally, your testing must not violate any law or compromise any data that is not yours and must take place on local running testnets.
See a real example of a quality vulnerability submission.
Description: Remote Denial-of-service using non-validated blocks
Attack scenario: An attacker can send blocks that may require a high amount of computation (the maximum gasLimit) but has no proof-of-work. If the attacker sends blocks continuously, the attacker may force the victim node to 100% CPU utilization.
Impact: An attacker can abuse CPU utilization on remote nodes, possibly causing full DoS.
Components: Go client version v0.6.8
Reproduction: Send a block to a Go node that contains many txs but no valid PoW.
Details: Blocks are validated in the method Process(Block, dontReact). This method performs expensive CPU-intensive tasks, such as executing transactions (sm.ApplyDiff) and afterward it verifies the proof-of-work (sm.ValidateBlock()). This allows an attacker to send blocks that may require a high amount of computation (the maximum gasLimit) but has no proof-of-work. If the attacker sends blocks continuously, the attacker may force the victim node to 100% CPU utilization.
Fix: Invert the order of the checks.
Please allow a few days for someone to respond to your submission.
We aim to respond to submissions as fast as possible. Feel free to email us at bounty@xinfin.org if you have not received a response within a day or two.
No.
No end date is currently set. See XDC latest news.
You can do this, but it might make you ineligble for rewards.
Submitting anonymously or with a pseudonym is OK, but will make you ineligible for XDC rewards. To be eligible for XDC rewards, we require your real name and a proof of your identity. Donating your bounty to a charity doesn’t require your identity. Please let us know if you do not want your name/nick displayed on the leader board.
Rewards are paid out in XDC.
Rewards are paid out in XDC after the submission has been validated, usually a few days later. Local laws require us to ask for proof of your identity. In addition, we will need your XDC address.
Every found vulnerability / issue is assigned a score.
Every found vulnerability / issue is assigned a score. Bounty hunters are ranked on our leaderboard by total points.
Yes!
We can donate your reward to an established charitable organization of your choice.
Yes.
Please use 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
PGP Key
