赏金计划是为了更好的借助社区的力量参与到 Qtum 主网及周边应用的开发建设中，让 Qtum 持续地保持安全、高效的运行，同时能满足更多行业用户的需求。

漏洞分级与奖励体系

1、如果已经有类似的 Issue 或者 Qtum 团队已经知道并在解决该问题的情况将不适用于该赏金计划。

2、如果在解决前将问题公开，并造成危害的将不会获得赏金。

3、修复时，请 fork 代码到自己的仓库中进行修复，然后提交 pull request 在 Qtum 成员 review 之后正式合入主干。

4、Qtum 团队成员是受雇于 Qtum 基金会，Qtum 成员直接或间接的参与 bug 修复的情况将不会获得赏金。

5、赏金计划以解决 Qtum 核心产品的技术，提升产品健壮性，Qtum 网站、论坛、组织架构等不在赏金计划之列。

6、赏金计划的奖金与众多因素有关、工作量、影响范围、严重程度等，赏金计划的具体赏金数额以 Qtum 安全团队的结论为准且对于赏金计划 Qtum 安全团队有最终解释权。

范围

请注意，这里的范围只是我们现在关注的重点产品，如果有未被列在上面，但是同样是被验证的软件漏洞，我们也欢迎通过漏洞上报的方式进行上报和赏金申请，Qtum 团队将会对此作出评定并及时给予反馈。

我们主要希望在核心代码的已发布版本中寻找可利用的软件漏洞，这些漏洞可能会造成以下问题：

• 损失、盗取用户资产。例如在用户未授权的情况下进行交易的漏洞
• 拒绝服务攻击。例如会引起 Qtum 主网崩溃或导致 Qtum 主网使用过量资源的漏洞
• 引起共识机制的失败。例如，允许攻击者划分网络的漏洞。
• 无法控制的通货膨胀。例如，允许攻击者在 coinstake 交易中制造更多 Qtum 币的漏洞。
• 允许未经授权的访问。例如，能控制分散合约关联的漏洞。

漏洞的等级与分类

漏洞的等级与分类我们会参照 OWASP 模型，我们将漏洞氛围严重、高危、中危、低危、改进，具体定义方法请参考：OWASP风险评级方法

*漏洞分级会由 Qtum 团队完成，Qtum 团队成员对此有最终解释权

漏洞评级及奖励标准

注：单位为美元

1、 对于在比特币、以太坊等网络上已上报的问题，赏金会相应的折算。

2、 以上奖励数额为该级别漏洞的最高奖励数额，具体的奖励发放数额会由 Qtum 安全团队决定。

对于奖励的发放我们还会参照其中几项来进行评审，如仅上报漏洞者，只需要关注上报材料一项。

上报材料（15%）：

完整填写上报材料，具体请参考申报模板link，所有上报材料均为英文版本。

代码修复（40%）：

完成代码修复，并不引入新的问题，如果有新的问题被引入，需要在同一次提交中解决该问题。

自动化测试脚本覆盖或手动测试方法说明（15%）：

自动化测试脚本对代码的持续集成、快速迭代下的质量控制有极其重要的作用，所以自动测试脚本的完善会作为一项重要的考核指标：

修复时间与效率（15%）

修复时间指Issue上报被确认后到修复代码被review过后合到代码库间的时间。在Issue上报后，Qtum 安全团队确认漏洞的反馈邮件中会明确指出期望的修复时间，该时间会与开发者协商。

该部分奖励说明：

修复思路及方法介绍与文档完善（15%）：

对于修复完的漏洞，希望完成技术材料的整理与文档的提交

漏洞的上报与修复流程

报告阶段

报告者访问bug上报页面提交漏洞详情

(状态：待审核)

处理阶段

1. 一个工作日内，Qtum 安全团队会确认收到的漏洞报告并跟进开始评估问题， 同时将情报反馈给上报者(状态：审核中)

2. 三个工作日内，Qtum 技术团队处理问题、给出结论与期望完成时间(状态：已确认/已忽略)。必要时会与报告者沟通确认，请报告者予以协助，评估完成后会将评估结果告知开发者。

修复阶段

1. 提交者着手修复该安全漏洞(状态：修复中)

2. 对于修复完成的问题，提交者可以将状态改为（状态：待复查）修复时间根据问题的严重程度及修复难度而定，一般来说，严重和高危问题 24 小时内，中危问题七个工作日内，低危问题十五个工作日内。客户端安全问题受版本发布限制，修复时间根据实际情况确定

3. Qtum 安全团队对问题进行复查，确认修复后会告知提交者结论和漏洞得分(状态：已复查/复查异议)

材料整理阶段

根据要求完成测试脚本、手动测试说明、修复思路与文档完善等信息

赏金发放阶段

Qtum 安全团队对提交人的材料完整性和修复完成度进行审核并发布奖励(状态：已结束)