The Forecast Foundation looks forward to working with the security community to find security vulnerabilities in order to keep the Augur protocol safe.

SLA

The Forecast Foundation will make a best effort to meet the following SLAs for hackers participating in our program:

• Time to first response (from report submit) - 1 business days
• Time to triage (from report submit) - 1 business days
• Time to bounty (from triage) - 5 business days

We’ll try to keep you informed about our progress throughout the process.

Disclosure Policy

• Before discussing your findings publicly, please allow us time to fix the vulnerability and ask our permission before doing so.
• Follow HackerOne's disclosure guidelines .

Program Rules

• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.
• You are ineligible for bounty rewards if the vulnerability submitted is already known by the Forecast Foundation, if it's publicly disclosed prior to the completion of the bounty process with the Forecast Foundation, or if it's found to have been exploited on the main Ethereum network.

Rewards

Our rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and that reward decisions are up to the discretion of the Forecast Foundation.

Critical (9.0 - 10.0) | High (7.0 - 8.9) | Medium (4.0 - 6.9) | Low (0.1 - 3.9)
---|---|---|---
$30,000 | $5,000 | $2,500 | $1,000

The above amounts are base awards and bonuses will be awarded at the discretion of Augur.

You can view the prior Augur v1 bounty scope here . Augur v1 and it's corresponding contracts are no longer in scope of this HackerOne bounty program.

Market Creation Template Bounties

The Augur Bug bounty program has been appended to include bounties for finding vulnerabilities in the market creation templates. The scope of these bounties is as follows:

The Augur market creation templates are designed to give market creators a rigid rubric for creating popular types of markets in popular categories, such that they mitigate the chance of a market resolving as ‘invalid’. Bounties will be paid for finding errors or oversights in the template construction that allow for errors or exploitations which can cause the market to be ‘invalid’.

Templates can be found here

Bounties will be paid in the amount of $100 (in REP) flat per vulnerability surfaced.

Example:

“Market Creator can enter multiple names in a market that specifies: "Will [Single Person's Name] host the [Year] [Event]?"

Areas of exploit we are aware of (and thus won’t be eligible for bounty):

-Those that are covered in the covered by invalid resolution rules:

• The market question, resolution details or its outcomes are ambiguous, subjective or unknown.

• The result of the event was known at market creation time.

• The outcome was not known at event expiration time.
  It can resolve without at least one of the outcomes listed being the winner, unless it is explicitly stated how the market will otherwise resolve in the resolution details.

• The title, details and outcomes are in direct conflict with each other.

• The market can resolve with more than one winning outcome

• Any of the outcomes don’t answer the market question ONLY. (outcomes cannot introduce a secondary question)

• If using a resolution source (a source is a noun that reports on or decides the result of a market), the source's URL or full name is NOT in the Market Question, regardless of it being in the resolution details.

• If using a resolution source, it is not referenced consistently between the Market Question and Resolution Details e.g. as either a URL or its full name

• For any sports markets that list a player or team not in the correct league, division or conference, at the time the market was created, the market should resolve as invalid.

• A market only covers events that occur after market creation time and on or before reporting start time. If the event occurs outside of these bounds it has a high probability as resolving as invalid.

-Bad information on manual inputs (i.e. Inputting Dates and times that invalidate the market, Inputting the wrong team for a match)
-Entering the market end date on financial templates out an extraordinary amount of time
-The absence of a template for a particular event

What We’re Interested In

The most important class of bugs we’re looking for are any parts of the contract code which would either result in a loss of funds or the platform becoming broken or un-usable.

Loss Of Funds

A loss of funds bug includes any vulnerability where a user can siphon assets from other users or the platform in an unintended way. If for example a user was able to take SAI, REP, or shares in a market that they were not entitled to this would be a loss of funds bug.

Also included in this would be any bug allowing someone to lock up funds in such a way that they are irrecoverable.

Manipulating Open Interest

Our contracts keep a record of the current Open Interest (OI) escrowed within the platform for trading. This value is used to determine the fee which is taken from traders and paid to reporters on a weekly basis. If someone can find a way to arbitrarily manipulate this value they could render the platform unusable by increasing fees to an absurd amount (33%) or keep them incorrectly low (0.01%). OI should only be “manipulatable” through the purchase and sale of complete sets and with the correct amount of corresponding ETH escrowed in markets)

Forking State

One of the key features Augur provides is the ability to fork the platform into multiple universes, each corresponding to an outcome in a market that proved too contentious for traditional dispute mechanics. When this happens the system enters a special state called “forking” and new child universes get spawned that should behave normally. Because this behavior is complicated and difficult to create and think through completely it is worth investigating specifically to see if any broken state arises or could be caused during forking.

Platform Architecture and Setup

At a high level the components that make up our stack are:

• Augur Core : The Ethereum contracts written in Solidity
• Augur SDK : The Augur Middleware library
• Augur UI : The Augur client code

Setting up your testing environment

There are a variety of ways to set up your environment and begin interacting with the platform.

The most helpful way to submit a bug report is to provide an automated test demonstrating the error.

For the contracts our test suite is written in python and uses py-evm.

From the Augur Core project follow the installation instructions and then tests can be run with this command:

python3 -m pytest tests

For the Augur SDK middleware our tests suite can be found here and is written in Typescript. Simply run yarn and tests can then be run via:

yarn test

If you wish to actually run the client UI there are a few ways to accomplish this.

Starting from easiest to most involved:

Hosted Kovan UI

We host a beta test version of the client which can be connected to with Metamask pointed at Kovan.

Local Setup

Instructions can be found here

Architecture and Components

[Augur Core

](https://www.google.com/url?q=https://github.com/AugurProject/augur/tree/master/packages/augur- core&sa=D&ust=1579821265129000)

The actual Augur contracts, automated tests, and deployment related scripting. This repo and the associated contract code are our primary concern and should be the main area of focus in finding vulnerabilities since problems here cannot be fixed trivially once in the wild.

A very detailed and thorough explanation of the platform can be found here

The following is a very high level summary of how the contracts work and interact:

Deployment

The first contract uploaded and the contract which most defines an Augur deployment is the Augur contract. This contract:

• Maintains a registry of the legitimate Augur contracts
• Maintains whitelists that give certain contracts elevated privileges within the platform.
• Is the central authority for all logs emitted
• Is the approval target for users to authorize the platform move their SAI

There is a seperate and similar contract AugurTrading which is a registry for the trading portion of Augur contracts that gets uploaded next.

After this all the remaining contracts are uploaded and registered as appropriate.

Universe

the Universe represents a version of the deployed Augur platform that corresponds to a chain of truth. Initially there is one universe, but there could be child universes and children of those if forks occur. A fork occurs when a Market can not be resolved easily, resulting in a new Universe for any outcome in that Market.

Markets

Markets are created through convenience methods found on the Universe, and are the central component to trading. Markets ask a question and users may purchase and trade shares indicating a belief in that questions outcome. Funds are escrowed within the Market’s corresponding universe for this purpose. At the Markets end time the reporting process will determine how much the system will award users holding shares for a particular position.

Trading

The contracts located under trading all deal with the creation, sale, and transfer of shares in a particular Market.

Users can place orders to purchase a position, fill specific orders, or request that the system fill whatever orders are possible then create an order for whatever remains. Fees are collected by the system to compensate reporters and market creators whenever a "complete set" is sold back to the system during this process. A "complete set" is just a set of all the shares offered by a Market.

Trading never ends, even after a Market has finished reporting and even during a fork in the Universe.

Reporting

Once a Market has reached its end time it can be reported on to indicate the result of the question it asked.

[Augur

](https://www.google.com/url?q=https://github.com/AugurProject/augur/tree/master/packages/augur- sdk&sa=D&ust=1579821265133000)SDK

As querying & parsing Ethereum logs via client code can become extremely expensive time wise we built a middleware service to run on top of Ethereum which provides a more efficient querying API for Augur. On startup it will connect to a local Ethereum node and based on the network ID will sync itself with the contracts it has for that network.

It maintains a local indexeddb database of relevant Augur data, such as the orderbook, reporting & disputing results, and profit / loss data based on user trades.

Since Augur SDK is primarily expected to be run as a local client service the ability to crash, DDOS, or inject malicious data remotely via a getter is not a primary concern, but are all still of interest.

An attack which creates false data or a corrupt state done entirely by legitimate ethereum logs would be a more concerning exploit.

[Augur UI

](https://www.google.com/url?q=https://github.com/AugurProject/augur/tree/master/packages/augur- ui&sa=D&ust=1579821265134000)

The client code is separated into a middleware component of the SDK and the actual web application Augur UI.

The Augur Artifacts package is notably where the mapping from network id to contract addresses is stored.

The typical client exploits are up for consideration in these components, though are not especially critical since they are easy to fix and the initial expectation is that people access the UI locally.

These components do provide some helpful utilities to aid in testing:

Flash Scripts

The Augur Tools repo contains a collection of scripts which can be run and inspected via the command:

node scripts/flash

A few notable useful examples:

• Listing existing markets
• Moving time forward
• Creating/Filling Orders
• Reporting/Disputing Markets
• Causing a fork

Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:

• Clickjacking on pages with no sensitive actions.
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept.
• Missing best practices in SSL/TLS configuration.
• Denial of service that is not a result of application engineering.
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS.
• Game theory attacks which are noted already in the whitepaper (e.g parasitic markets, malicious resolution source).

Known Contract Bugs

The following vulnerabilities / bugs are already known and are not eligible for bounty:

• To Be Specified as Discovered

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Thank you for helping keep the Augur protocol safe!