Bug Bounty

Get CPOOL or USDC for finding security bugs

Introduction

At Clearpool we aim to maintain the highest level of cyber security, so the users of our protocol can enjoy a quality and worry free experience. To maintain this high quality, Clearpool has established an ongoing Bug Bounty Program. The Bug Bounty program is designed to encourage and reward those who discover and timely report any potential hacking angles, which can jeopardize security or user experience. For any special one-time bug bounty campaigns we run, please stay up-to-date by following us on Telegram, Twitter or Medium. Otherwise, we invite any whitehat hackers and cybersecurity specialists to participate in this ongoing program.

Rewards

All bounty submissions will be rated by the Clearpool Core Team and via Governance in the near future. The rewards payouts are based on vulnerability ratings (see below). All payouts will proceed in USDC or CPOOL tokens (subject to change).

• All bug reports must be submitted to https://github.com/orgs/clearpool-finance/discussions/categories/bug-reports.

• Asking for payment in exchange for vulnerability details will result in immediate ineligibility of bounty payments.

• If we cannot reproduce your findings, your report will not be eligible for payout. We ask you to provide as detailed a report as possible with all steps necessary to reproduce your findings.

• Include your Ethereum based address for payment. Please make sure your address is not a centralized exchange wallet. Payment minimums are defined below.

• All payments may be modified at Clearpool’s discretion.

• The minimum payout is equivalent to 500 USDC.

Scope

The following properties are in scope for bug bounty rewards

URL	Property name
https://clearpool.finance	Marketing website
https://clearpool.finance	Application website

Vulnerability Ratings

Critical

Critical severity issues present a direct and immediate risk to a broad array of our users or to Clearpool itself. They often affect relatively low-level /foundational components in one of our application stacks or infrastructure. For example:

• arbitrary code/command execution on a server in our production network

• arbitrary queries on a production database

• access to sensitive production user data or access to internal production systems

High

High severity issues allow an attacker to read or modify highly sensitive data that they are not authorized to access. They are generally more narrow in scope than critical issues, though they may still grant an attacker extensive access. For example:

• XSS which bypasses CSP

• discovering sensitive user data in a publicly exposed resource

• gaining access to a non-critical, system to which an end user account should not have access

Medium

Medium severity issues allow an attacker to read or modify limited amounts of data that they are not authorized to access. They generally grant access to less sensitive information than high severity issues. For example:

• disclosing non-sensitive information from a production system to which the user should not have access

• XSS that does not bypass CSP or does not execute sensitive actions in another user’s session

• CSRF for low risk actions

Low

Low severity issues allow an attacker to access extremely limited amounts of data. They may violate an expectation for how something is intended to work, but it allows nearly no escalation of privilege or ability to trigger unintended behavior by an attacker. For example:

• Triggering verbose or debug error pages without proof of exploitability or obtaining sensitive information.

Ineligibility

Reports in which we are not interested include:

• Vulnerabilities on sites hosted by third parties

• Vulnerabilities affecting outdated or unpatched browsers.

• Vulnerabilities in third party applications

• Vulnerabilities that have been released publicly prior to Clearpool issuing a comprehensive fix.

• Vulnerabilities already known to us, or already reported by someone else (reward goes to first reporter). Issues that aren't reproducible.

• Vulnerabilities that require an improbable level of user interaction.

• Missing security headers without proof of exploitability.

• Any report without an accompanying proof of concept exploit.

• The output from automated tools/scanners.

• Issues without any security impact.

Non-security Issues

You can let us know about non-security issues at https://github.com/orgs/clearpool-finance/discussions or at https://clearpool.finance/feedback.