Note: This bug bounty is no longer live. This post is only available for informational purposes.
Security is important, especially when an entire community is a stakeholder in a project. Before the vote staking period for the dxDAO begins, we’ll be running a bug bounty program with rewards up to $150k.
The bug bounty payouts for hackers focus on two major attacks:
- Gaining access to ETH or ERC20 tokens in locking contracts
- Breaking the DAO, either by passing a decision or draining its funds against a majority vote
If bountied vulnerabilities are found, hackers can either report the bug or drain the associated funds. If reported, the rewards can be paid out if the funds are still accessible. Payout for the bug bounty program will not exceed the funds used in the test dxDAO. Please see the Contract Addresses section below for links to the code, and Reporting section below for further details on the reporting process.
How’s it different? The test dxDAO parameters
The open bug bounties will be on a test-version of the dxDAO — not the live dxDAO itself. However, this test version will have $150k worth of real funds involved in order to incentivize hackers to attack it. The test dxDAO will have as close as configuration as possible to the soon-to-launch actual dxDAO, with a few differences:
- Timeline: The test dxDAO will provide the same four primary methods for the vote staking period to gain voting power (Reputation). During the vote staking period, there will still be ten GEN auctions, but each one will only run for a half day (12 hours), and the maximum amount of time tokens can be locked for will be 1 month.
- Price feed and MGN: The price feed is used to weigh the amount of Reputation participants receive by locking ERC20 tokens during the vote staking period. The test dxDAO will use a static oracle for prices. The mock Magnolia (MGNm) supply will be controlled by Gnosis.
- Governance Phase: After the vote staking period when the dxDAO assumes governance powers, the test dxDAO will not have a front-end interface, so hackers will be expected to interact directly with the blockchain. Additionally, the governance parameters of the Genesis protocol in the test dxDAO are more rapid:
- Boost period: 3 days. This is how long a boosted proposal is available to vote on before either passing or failing.
- Regular queue expiration: 6 days. This is how long a proposal is open to be passed with a 51% absolute majority vote before expiring.
- “Quiet ending” time: 6 hours. This is the length of time in which a proposal is extended if the vote result changes.
- Pre-boosting period: 12 hours. After the boosting threshold is reached, it is still possible for users to stake against proposals during this period. If a sufficient quantity of GEN is staked against the proposal during pre-boosting, it is effectively blocked from being boosted and returns to the regular queue.
Bug Bounty Rewards
We’ve set bounties on several attack vectors during the test dxDAO run.
During the vote staking period (January 31st to February 9th):
- 45% on ETH ($45k worth of ETH)
- 45% on tokens ($22.5k worth of GEN + $22.5k worth of GNO)
- 10% on GEN ($10k worth of GEN)
During the live governance phase (February 10th to February 16th):
- 80% on the avatar ($40k worth of ETH)
- 20% on the wallet contract controlled by the avatar ($10k worth of ETH)
Test dxDAO Timeline
The bug bounties will be open during the test dxDAO’s timeline:
- February 4th: Deployment
- February 4th: Vote staking period begins and bounty funds placed in locking contracts
- February 9th: Vote staking period ends and voting power distribution begins
- February 10th: The governance phase is live
- Bug bounty funds are moved from the locked contracts to the avatar address
- February 16th: Bounty ends and funds removed
The two major, bountied attacks occur during different time periods:
- Vote staking period (February 4th to February 9th): Gaining access to ETH or ERC20 tokens in the locking contracts or GEN in the auction contract
- Governance phase (February 10th to February 16th): Breaking the dxDAO, either by passing a decision or draining its funds against a majority vote
Be sure to get ready for the test dxDAO bug bounty period, by checking out DAOstack’s documentation and blog posts on the dxDAO.
Contract Addresses
Deploying account — 0xBAaAe8671a2BaFEEB3BB7862C2e70CE8BcC4B4A3
Deployed contracts:
Wallet — 0x8680a273B2CC43A229C8e971c6A60EEeE0574DA8
Avatar — 0x98AbA700cC0Bd58aB92CE2361c96c217e9A77470
Token — 0xAbD9FF907f2111EdE8072d78B96441A84d971f42
Reputation — 0xb42375540b5efc173f3C665387258D4cA45Ca634
Controller — 0xA1B98DBC311fF4B28a392B96A5343FfF080Fcc95
ETH Locking Scheme — 0xE3443bF7Ef2fA607c3285B732D9883C02d1d8Ce1
Whitelisted Token Locking Scheme — 0x6b9ee9e79bB893d394dA79E2eA51685D1855318E
MGN Registration Scheme — 0xD3085707c2c612E81E6ddCD220d1ed1c1BdefFf8
GEN Auction Scheme — 0x4E7e7bdB77F08505da6A670BF8247Fd1206e823b
Fixed Price Oracle — 0x2AF3cD240D4A8E6217e4e85A07c5969e7B4D2023
MGN Mock (ExternalTokenLockerMock) — 0x596C0072D9Ee70f1ABD70780745BD410F5Ee28b1
Used contracts:
GenesisProtocol — 0x50932521953CA7a1fA11434891cc9D9b0183fBc5
Scheme Registrar — 0xa94b887e15f30db3831AcdDDCd2008a0fFDDe0E3
Generic Scheme — 0x1f6E0a3dCADBcd86E5dC5f7157b5802035CF59d1
Contribution Reward Scheme — 0x082Ea4D85055dE18297be0F112240F8c6a6ae319
Reporting
This blog post contains all the relevant information on the scope, timeline, and compensation of the program.
Most of the Ethereum Foundation bug bounty program rules also apply to the Gnosis bug bounty program:
- Issues that have already been submitted by another user or that are known to the Gnosis team are not eligible for bounty rewards.
- Public disclosure of a vulnerability makes it ineligible for a bounty.
- The Gnosis core development team, employees, and all other people paid by Gnosis, directly or indirectly (including the involved Solidified auditors), are not eligible for rewards.
- The Gnosis 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 bug bounty panel.
Responsible Disclosure Policy
If you comply with the policies below when reporting a security issue to us, we will not take legal action against you in response to your report.
We ask that:
- You give us reasonable time to investigate and mitigate an issue you report before making public any information about the report or sharing such information with others.
- You make a good faith effort to avoid privacy violations and disruptions to others, including (but not limited to) destruction of data and interruption or degradation of our services.
- You do not exploit a security issue you discover for any reason. (This includes demonstrating additional risk, such as attempted compromise of sensitive company data or probing for additional issues.)
- You do not violate any laws or regulations.
Reporting Process
Public disclosure of the bug or indication of an intention to exploit it on the Mainnet will make the report ineligible for a bounty. Please refer to the Ethereum bug bounty program rules if in doubt about any aspect of the bounty.
Please report bug bounty submissions to bounty@gnosis.pm.
Don’t forget to include your ETH address so you can be rewarded (if more than one address is provided, only one will be used at the discretion of the Gnosis bug bounty panel).
Anonymous submissions are welcome.
