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.
Rewards by Threat Level
Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System. 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.
- 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.
- 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).
- 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.
Smart Contracts and Blockchain
- Up to USD $54,000
- Up to USD $10,000
- Up to USD $1,000
Assets in Scope
For the Initializable, ReentrancyGuard, SafeCast, SafeMath, IERC20, and IVault smart contracts, this bug bounty program only accepts bug reports for the changes that were performed compared to the original, as well as any improper use of them that leads to actual issues in the contracts previously mentioned to be in scope. Any bug that is reproducible in the original vendored contract is out of scope.
Any vulnerabilities mentioned in this audit report are considered as out-of-scope.
The following are also considered as out-of-scope:
- Migration methods.
- Services that build and submit the settlement transaction (e.g., denial of service, exploiting settlement transactions to extract value via sandwich attacks).
- Gas efficiency improvements.
- Any issues relating to networks other than the Ethereum Mainnet.
- Steal funds from the settlement contract as a solver.
- Price manipulation from the solver, for example: choosing the orders and the prices to settle that would lead to the solver getting a better-than-market price.
- Price manipulation from the solver, for example: reusing the same token twice in a settlement to give different prices to different orders.
- Smart Contract - GPv2AllowListAuthentication
- Smart Contract - GPv2EIP1967
- Smart Contract - GPv2Settlement
- Smart Contract - GPv2Signing
- Smart Contract - StorageAccessible
- Smart Contract - GPv2Interaction
- Smart Contract - GPv2Order
- Smart Contract - GPv2Trade
- Smart Contract - GPv2Transfer
- Smart Contract - GPv2SafeERC20
- Smart Contract - GPv2Authentication
- Smart Contract - GPv2EIP1271
- Smart Contract - GPv2VaultRelayer
- Smart Contract - Initializable
- Smart Contract - ReentrancyGuard
- Smart Contract - SafeCast
- Smart Contract - SafeMath
- Smart Contract - IERC20
- Smart Contract - IVault
We are especially interested in receiving and rewarding vulnerabilities of the following types:
- Logic errors
- including user authentication errors
- Solidity/EVM details not considered
- including integer over-/under-flow
- including unhandled exceptions
- Misuse/wrong trust model for dependencies
- including composability vulnerabilities
- Oracle failure/manipulation
- Novel governance attacks
- Economic/financial attacks
- including flash loan attacks
- Congestion and scalability
- including block stuffing
- including susceptibility to frontrunning
- Consensus failures
- Cryptography problems
- Signature malleability
- Susceptibility to replay attacks
- Weak randomness
- Weak encryption
- Susceptibility to block timestamp manipulation
- Missing access controls / unprotected internal or debugging interfaces
Examples of desired vulnerabilities/exploits
- Take funds from users’ allowances outside of a trade.
- Steal funds from the settlement contract as an external user (but not as the owner or a solver).
- Add or remove solvers without being the owner.
- Execute trades that have not been authorized by a user (e.g., a forged signature).
- Execute trades with different parameters from what the user signed (e.g., as sell order instead of as buy order).
- Execute expired trades.
- Replay already executed fill-or-kill orders.
- Execute more, in total, than the maximum amount for a partially fillable order.
- Execute a settlement so that the limit price of an order is not respected.
- Execute an interaction from the settlement contract to the vault relayer.
Out of Scope & Rules
The following vulnerabilities are excluded from the rewards for this bug bounty program:
- Attacks that the reporter has already exploited themselves, leading to damage
- Attacks requiring access to leaked keys/credentials
- Attacks requiring access to privileged addresses (governance, strategist)
- Incorrect data supplied by third party oracles
- Not to exclude oracle manipulation/flash loan attacks
- Basic economic governance attacks (e.g. 51% attack)
- Lack of liquidity
- Best practice critiques
- Sybil attacks
- Running out of gas
The following activities are prohibited by bug bounty program:
- Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
- 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
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty