RANGE OF BOUNTIES

• Low (0.25 ETH-1 ETH)
• Medium (1 ETH -5 ETH)
• High (5 ETH - 20 ETH)
• Critical (20 ETH - 200 ETH)

There are specific ‘In Scope’ and ‘Out of Scope’ areas that have been identified, however if a vulnerability is found which doesn’t fall into these categories, then please make a submission following the submission guidelines and your submission will be duly triaged.

IN-SCOPE: SMART CONTRACT VULNERABILITIES

We are looking for evidence and reasons for incorrect behavior of the smart contract, which could cause unintended functionality:

• Stealing or loss of funds staked Critical
• Permanent freezing of funds staked Critical
• Theft of unclaimed yield High
• Direct theft of any commission, whether at-rest or in-motion High
• Permanent freezing of unclaimed yield High
• Temporary freezing of funds High
• Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol) Medium

For the avoidance of doubt Critical issues are limited to loss of funds staked (incl. permanent freeze).

OUT OF SCOPE: SMART CONTRACT VULNERABILITIES

Conceptual

• Theoretical vulnerabilities without any proof or demonstration
• Vulnerabilities in Kiln Smart Contracts that do not demonstrate in scope impact

Build

• Old compiler version
• The compiler version is not locked
• Vulnerabilities in imported contracts
• Code style guide violations
• Redundant code
• Impacts on test files and configuration files
• proxy contract related or vulnerabilities relating to contract upgrades

Feature Specific

• Gas optimizations
• Best practice issues and feature requests
• Triggering withdrawal from a Recipient as long as funds go to the right address

Permissions & Malicious User Roles

• Impacts caused by attacks requiring access to leaked keys/credentials
• Impacts caused by attacks requiring access to privileged addresses (governance, strategist) except in such cases where the contracts are intended to have no privileged access to functions that make the attack possible
• The following roles: Operator, Admin and Proxy Admin are trusted to behave properly and in the best interest of the users. They should not be considered as malicious. Reports taking this assumption will be considered invalid.

Network

• Incorrect data supplied by third party oracles
• Impacts requiring basic economic and governance attacks (e.g. 51% attack)
• Impacts from Sybil attacks
• Impacts involving centralization risks

Known issues - known issues will be disclosed publicly: either as an issue on the repository, or via a self-reported bug submission. This helps to streamlined triage and mediation process to prove that an issue is known. Specific known issues can be found on the audit reports.

• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact
• Make every effort not to damage or restrict the availability of products, services, or infrastructure
• Avoid compromising any personal data, interruption, or degradation of any service
• Don’t access or modify other user data, localize all tests to your accounts
• Perform testing only within the scope
• Don’t exploit any DoS/DDoS vulnerabilities, social engineering attacks, or spam
• Don’t spam forms or account creation flows using automated scanners
• In case you find chain vulnerabilities we’ll pay only for vulnerability with the highest severity.
• Don’t break any law and stay in the defined scope
• Any details of found vulnerabilities must not be communicated to anyone who is not a HackenProof Team or an authorized employee of this Company without appropriate permission
• Avoid any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet

Proof of Concept (PoC) Requirements A PoC is required for all Severity levels.

Metamask supports the protection of organizations and hackers engaged in Good Faith Security Research as defined by the U.S. Department of Justice. “Good Faith Security Research” is accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services.

We consider Good Faith Security Research to be authorized activity that is protected from adversarial legal action by us. We waive any relevant restriction in our Terms of Use that conflicts with the standard for Good Faith Security Research outlined here.

This means that, for activity conducted while this program is active, we: (1) Will not bring legal action against you or report you for Good Faith Security Research, including for bypassing technological measures we use to protect the applications in scope; and, (2) Will take steps to make known that you conducted Good Faith Security Research if someone else brings legal action against you.

You should contact us for clarification before engaging in conduct that you think may be inconsistent with Good Faith Security Research or unaddressed here. We are not able to authorize security research on any other third-party program or infrastructure, and a third party is not bound by this statement.

• Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization
• No vulnerability disclosure, including partial is allowed for the moment.

We thank everyone who submits valid reports which help us improve our security. However, only those that meet the following eligibility requirements may receive a monetary reward:

• Not be a resident of any country under U.S. sanctions or any country that does not allow participation in these types of programs
• Be at least 14 years old and have legal capacity to agree to these terms and participate in the Program
• The vulnerability must be a qualifying vulnerability
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through hackenproof.com
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
• You must not be a former or current employee of Consensys or Kiln or one of its contractor.
• ONLY USE the EMAIL under which you registered your HackenProof account (in case of violation, no bounty can be awarded)