CoW Protocol
Gnosis builds new market mechanisms for decentralized finance. Their three interoperable product lines allow you to securely create, trade, and hold digital assets on Ethereum.
PoC required
Rewards by Threat Level
Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.
The Gnosis Protocol v2 bounty program considers a number of variables in determining rewards. Determinations of eligibility, score, and all terms related to an award are at the sole and final discretion of the Gnosis Protocol v2 bug bounty panel.
The Gnosis core development team, employees, and all other people paid by Gnosis, directly or indirectly (including the external auditors), are not eligible for rewards.
In order to be eligible for a reward, bug reports must include an explanation of how the bug can be reproduced, a failing test case, a valid scenario in which the bug can be exploited. Critical vulnerabilities with all of these have a maximum reward of USD 50 000. If a fix that makes the test case pass is provided, an additional USD 4 000 is provided for critical vulnerabilities, for a maximum reward of USD 54 000.
In addition to the Immunefi Severity Classification System, the following information is provided for each severity level. In case of discrepancies between this information and the Immunefi Severity Classification System, this information will prevail.
Critical:
- Changing the owner address of the authentication contract as well as adding a solver without authorization.
- Forgery of a user’s signature that would allow them to execute a funded trade without using the user’s private key.
- Execute arbitrary settlements without being a solver.
- Executing a user’s trade that is expired or at a price worse than the limit price (also as a solver).
- Transferring in tokens more than once for the same fill-or-kill order in the same settlement (also as a solver).
- Access to user funds outside of a trade.
High:
- Changing the order of a legitimate interaction, as well as skipping one, in a settlement.
- Removing a solver without authorization (also as a solver).
- Making the contract unable to be operated by any solver, e.g., through self-destruction (also as a solver).
Medium:
- Freeing storage without being a solver.
- Invalidate an order without the permission of the user who created it.
Payouts are handled by the Gnosis Protocol v2 bug bounty panel directly and are denominated in USD. However, payouts are done in ETH.
Program Overview
Gnosis builds new market mechanisms for decentralized finance. Their three interoperable product lines allow you to securely create, trade, and hold digital assets on Ethereum.
Gnosis is running a bug bounty program focused on Gnosis Protocol v2, a fully permissionless protocol that leverages batch auctions to provide MEV protection, plus integrates with on-chain liquidity sources to offer traders the best prices.
For some background information, consider reading this high-level summary, which describes the motivation behind building Gnosis Protocol v2, as well as the reasons behind the architectural design choices described in this announcement.
The bug bounty program is focused around its smart contracts and is mostly concerned with the loss of user funds.
KYC not required
No KYC information is required for payout processing.
Prohibited Activities
- Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
- Any testing with pricing oracles or third-party smart contracts
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Any denial of service attacks that are executed against project assets
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty
- Any other actions prohibited by the Immunefi Rules
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity. Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.