Augur v2 Details

4 min readOct 5, 2018


Twelve weeks after the initial deployment of Augur, we’re sharing some planned changes for the Augur protocol v2 deployment. While all these changes will be tentative up until all the code is written and audited, we’re confident in this feature list and are currently planning to develop all listed changes below.

The Augur v2 deployment will require optional, manual migration of REP to the new set of Augur contracts. There is no expected timeline currently, however the development team has begun the necessary research and development into all listed features.

These are specifically contract changes that affect the underlying protocol. All the UI feedback gathered in the wishlist thread has been reviewed and prioritized, and is being worked on in parallel. Augur App and the UI are receiving continuous updates.

The Forecast Foundation appreciates any feedback, input or suggestions regarding this feature set, particularly in the #dev or #game-theory rooms of the Augur Discord.

DAI Integration:

Integration of a stable coin as the denomination for markets will allow money at risk to be exposed to less volatility.

Use or Lose Forking:

Instead of incentivizing migration during a fork by providing a 5% bonus the new contracts will instead simply not allow migration to any child universe once the fork time period is over.

This provides a much greater motivation to participate, simplifies the contracts, allows the buyback feature detailed below, and allows us to reduce reporting fees while keeping the system secure.

Auction-Based REP Price Oracle:

In the V1 contracts, the REP price Oracle is essentially centralized, with humans manually providing the current market price of REP. In V2 the contracts will instead derive this information by holding a double auction where REP is minted as needed and sold to determine its price.

The current plan is to initially ignore the results of this auction and monitor it while using a centralized price oracle. If the system is functioning well then it can be gradually depended on until such a time as the system can be switched over and the key to the centralized oracle thrown away.


A variety of non-critical bugs that have been discovered since launching will be addressed in the V2 contracts.

ERC-777 Support:

V2 contracts will update all of the Augur tokens to be ERC-777 and ERC-20 backward compatible.

Variable Validity Bond:

Market creators will be able to provide a higher validity bond optionally to signal that the market is valid and can be traded on safely.

Invalid as Explicit Outcome:

Invalid being an explicit outcome simplifies trading such that one can understand what is actually at risk and makes trading based on the belief that the market is invalid much more clear. Additionally, it simplifies the contracts and eliminates a known (and intentional) rounding error.

Burning Dispute Profits:

Currently, there are potential avenues for a griever with a large bankroll to delay market resolution without significant financial losses. By burning a portion of the profit made from disputing (tentatively burning ⅕ of the dispute profit) we eliminate this tactic as being a “free” method of disrupting the platform.

Accelerated Bond Increases:

Currently the validity and no show bonds increase and decrease at the same rate relative to no shows and invalid markets. In v2 we’re going to make the increase multiplicative but the decrease additive so that once a sufficient deterrent level is reached it won’t go back to insufficient levels as fast.

Optional messaging for dispute contributions:

Disputing and Initial Reporting in V2 will include the optional ability to provide a text message explaining the intent of the report or dispute.

Dispute Round Changes:

Designated Report Time reduced to 1 day from 3 days

Designated Reporters that do show up do so very quickly. This will reduce the time spent waiting for open reporting in the case a designated reporter is absent.

Continuous Dispute Rounds:

The 7 day minimum between all dispute rounds makes disputing take a very long time since the initial few rounds are relatively low stakes. This change allows rounds to occur back to back up until a threshold is reached where time to prepare against a fork is needed.

Trading API Changes:

Condensed Functions:

The “WithLimit” variant of trading functions is now the only available option as the standard functions which operate based on provided gas are too cumbersome to use in practice.

Ability to ignore owned shares:

If desired the trading functions allow someone to ignore owned shares and thus buy shares in opposing positions using tokens instead.

Ability to trade based on total investment and price:

Instead of specifying total shares desired one can specify a total investment amount and price

Gas & Transaction Optimizations:


In V1 each market creates a new mailbox for the market creator to receive and withdraw their fees. V2 will provide each market creator instead with a single mailbox which will be more efficient for market creation and withdrawing fees and will allow some major client code simplification.


Some contract optimizations for trading will be in V2 which will reduce trading gas costs by a factor of about ¼. We’ll be investigating potential other reductions as well until audit time in an effort to get it down further.




An open-source, decentralized, peer-to-peer prediction market platform built on Ethereum.