The Bounty Program is to enable developers to better participate in the development and construction of the QTUM main network and peripheral applications with the help of the community, so that QTUM remains safe, efficient, and meets the needs of more industry users.

Bug rating and reward system

1. It will not apply to the Bounty Program if there has been a similar issue or the Qtum team has known and is solving the bug.

2. Responsible Disclosure: no bounty will be rewarded if the reporter discloses the vulnerability publicly before the bug fix has been deployed.

3. Please fork the code to your own repository, fix the bug, and then submit pull request. It will formally be merged into the main branch after Qtum members' review.

4. The Qtum team members are employed by Qtum Foundation. They will not receive any bounties if they participate in bug repair process directly or indirectly.

5. The Bounty Program is to solve the technical problems of Qtum core products and improve product robustness. Qtum website, forum, organizational structure and so on are not included.

6. The bonus of Bounty Program is related to many factors, such as workload, incidence, severity, etc. The specific amount of Bounty Program is based on the conclusions of QTUM security team. QTUM security team reserves the right of final explanations for Bounty Program.

Scope

Please note that these are guidelines, final decisions regarding eligibility of issues are at the sole discretion of the Qtum Foundation. If you find any issue that does not fit in this scope but you still believe to be a security issue, we encourage you to report it. We are primarily looking for exploitable software bugs in the release version of the core code that cause one of the following:

• Loss/theft of funds. For example, bugs that allow an attacker to spend UTXOs that they do not control the private keys for.
• Denial of Service. For example, bugs that allow an attacker to cause qtumd to crash or cause qtumd to use "excessive" resources.
• Consensus failures. For example, bugs that allow an attacker to partition the network.
• Uncontrolled inflation. For example, bugs that allow an attacker to mine more coins in the coinstake transaction than the block subsidy.
• Enabling unauthorized access. For example, bugs allowing an attacker to gain control of the decentralized governance contracts.

Bug level and classification

The primary factor for determining the reward for an eligible submission is the severity of the issue evaluated using the OWASP risk rating model

*Qtum team makes the bug rating and reserves the right of final explanations.

Bug rating and reward criteria

Note: The currency is US dollars

1. The bounty will be discounted accordingly for bugs that have been reported on Bitcoin, Ethereum, etc.
2. The amount of rewards above is the highest for the level. QTUM security team determines the specific amount of rewards. Besides, we will refer to other items for review for the issuance of rewards. Those who only report bugs only need to pay attention to the reported materials.

Reported materials (15%):

Complete the report materials. Please refer to the application template link for details. All submitted materials should be in English.

Code repair (40%):

Finish the code repair and do not introduce new problems. If new problems are introduced, they should be resolved in the same submission.

Automated test script coverage or manual test method description (15%):

Automated test scripts play an extremely important role in the continuous integration of code and quality control under rapid iterations, so the improvement of automated test scripts will be an important indicator:

Repair time and efficiency (15%)

The repair time means the duration from the time when the Issue report is confirmed to the time when the repair code for bugs is merged into the codebase. QTUM security team will confirm the bug feedback messages and negotiate with the developer and explicitly indicate the expected repair time.

Introduction of repair ideas and methods and improvement of documents (15%) ：

We expect complete technical materials and documents.

Bug Report and Repair Process

Reporting Stage

Reporter visits the bug report page to submit bug details.

(Status: Pending review)

Processing Stage

1. Within one working day, the QTUM security team will confirm the bug report, follow up the evaluation of the issue, and feedback the intelligence to the reporter (Status: Review).

2. Within three working days, the QTUM technical team will deal with the issue, draw conclusion, and give the expected completion time (Status: Confirmed/Ignored). If necessary, we will communicate with the reporter to confirm, ask the reporter to assist, and inform the developer of the evaluation result after completing assessment.

Repairing Stage

1. The reporter sets out to fix the security bug (Status: Repaired).
2. The reporter can change the status to (Status: To Be Reviewed) after repair completion. The repairing time depends on the severity of the bug and the difficulty of the repairment. Generally speaking, within 24 hours for the critical and high risk bugs, within 7 working days for the medium-risk bugs, and within 15 working days for the low-risk bugs. The client security issue is limited by the version release, and the repairing time is determined according to the actual situation.
3. After the reporter has confirmed that the security bug had been repaired, the QTUM security team would inform the treatment conclusion and the vulnerability score.(State: Reviewed/Reviewed Objections).

Material Stage

Complete test scripts, manual test instructions, repair ideas, and improvements of documents as required.

Appreciation Stage

QTUM security team reviews the author's material integrity and repair completion level, and then issues a reward (Status: Closed)