Advancing Augur:

We couldn’t be more excited for Version 2, a comprehensive suite of improvements to Augur and the first major upgrade to the platform. We recently announced the big news that V2 code is complete and now ready for formal audits.

Since day one of Augur’s first release last July, we have compiled improvements to the protocol from users, bug reports, internal discussion, and observation of Augur in the wild. We commenced work on V2 a few months ago, and contracts are now ready for the first round of audits with integration work in progress with the rest of the Augur platform.

We look forward to soon publishing more in-depth write-ups on some of the new features. If you want more specifics on anything mentioned here, feel free to check out our code on Github or contact us on Discord. To get started on Augur, visit augur.net.

Please note that all REP holders will be required to participate in the final dispute round if a market forks in Augur v2 in order to maintain their REP (the original intended functionally of REP from the crowdsale). See more in Use It or Lose It Forking.

DAI Denomination Token:

We are excited to satisfy the single biggest request we have received since our initial release: allow for trading with a stablecoin. V1 Augur uses ETH for all trading. While this is a natural fit in many ways for a decentralized platform running on Ethereum, ETH is highly volatile. Introducing stablecoin denomination will make trading less volatile and more accessible.

For V1, the usage of ETH was accomplished by using a contract (“Cash”) that wrapped ETH and was given additional trust by the Augur contracts to take privileged transfers. The V2 contracts will still reference “Cash,” which will instead point to an ERC20 Token with no extensions. At release time, this will be set to the Multi-Collateral DAI token.

Invalid As A Tradeable Outcome:

In V2, we address another major pain point for Augur users: the risk of invalid markets.

In V1, a market resolves as “Invalid” when reporters deem its outcome ambiguous or unverifiable. Shares in such markets can be turned in for an equal amount of money. For example, a three outcome market with outcomes A, B, and C that resolves Invalid will give .33 ETH for a share of each outcome. Bad actors have capitalized on this by, for instance, creating markets that end before the event outcome is known and buying cheap shares that earn a profit once the market resolves Invalid.

In V2, Invalid will be a tradeable outcome like any other, enabling traders to hedge the risk of Invalid outcomes and gauge their likelihood via market forces. For example, if a market’s order book consistently has BUY orders for Invalid above .2, that suggests there is a greater than 20% chance the market is Invalid. For conservative users, this should be a warning to not trade the market.

We thank the Augur community whose feedback and intellectual contributions facilitated this improvement like many others here.

Use It Or Lose It Forking:

TL;DR: If a market in Augur v2 forks, you have 60 days to participate or you will lose all your REP..

In V1 Augur, if a fork occurs, REP holders are given 60 days to participate in the resolution by migrating to a Universe correlated with the forking market’s outcomes. For example, if a market for the 2016 U.S. presidential election forked, there would be a Universe where Trump won and a universe where Hillary won. The Universe with the most REP by the end of the 60 day period or which reaches 50% of all REP, wins. In order to incentivize people to migrate their REP before the fork resolves, anyone in V1 who does so receives a 5% bonus to their migrated REP in their new universe.

While this is a theoretically rational incentive, it has a couple problems:

First, this method introduces a security vulnerability that means the cost to force a fork must be higher than 5% of all REP. While this was easy to solve, it is arguably preferable to have flexibility in the values being used.

The larger issue is that a 5% bonus is an insufficient motivator to secure the platform. In an ideal world, we get 100% REP holder participation, in which case a 51% coalition is needed to determine the winner. For example, if the 5% bonus is only enough to incentivize 10% of REP holders, then only a 5.1% coalition is needed to determine the winner. This is only twice the amount of REP used in one side of the dispute to get to the fork in the first place.

In order to combat this, the V2 contracts will not allow migration to children universes after the 60 day window has ended. This is the most effective way to motivate participation in a fork, which is the crux of the Augur security model. Thanks to the community for its input in developing this solution.

Uniswap v2 Price Feed:

Adjusting fees paid to reporters by traders is one of the main mechanisms that keeps Augur secure. The fee is adjusted based on the total open interest (OI) on the protocol and the price of REP. In order to obtain the price of REP, Augur v2 will utilize Uniswap v2 as a decentralized oracle and price feed. Additionally, Augur v2 uses Uniswap v2 to pay the 0x protocol fee using DAI.

Prior plans included a REP Price Auction, where two double auctions would take place each week with a pot of DAI and REP being sold for one another to calculate the price of REP. This proposal introduced a small level of inflation to REP in exchange to compensate for losses from the auction. This proposal has been replaced with using Uniswap v2.

Immediate Dispute Rounds Up To A Threshold:

In V1, markets often take a while to resolve. Well, this is about to change... We are excited to introduce a suite of improvements that will speed up this process.

First off, in V2, disputes can occur immediately following one another. In V1, when an outcome is disputed, REP holders must wait until the next window to dispute the tentative winning outcome. This effectively paces disputes such that each round takes a week. In V2, for an outcome to win, it still must be undisputed for an entire seven-day window, however anyone may dispute that outcome regardless of when it won or when the next window begins.

This feature will turn off if a market reaches a sufficient size (currently, once it is large enough that a fork could occur in eight rounds) and rounds will return to a weeklong pace. The longer timeframe will allow reporters to mobilize the large amount of REP necessary for dispute. For example, reporters can use the time to convince large REP holders to participate or to access REP that is held in cold storage.

Designated Reporting Reduced To One Day:

We have also compressed the designated reporting window to a day since the vast majority of designated reporters that show up to report do so within 24 hours of market expiration.

First Dispute Window Reduced To One Day:

The first dispute window is also reduced to 24 hours in order to speed up market resolution. Reporters will have 24 hours after the designated reporting window closes to dispute the initial report.

Pre-Emptive Contributions To Tentative Winning Outcomes:

As proposed by the Augur community, V2 formalizes and improves a sort of accidental feature from V1 that can accelerate market resolution: allowing REP holders to contribute any desired amount to their reported outcome (up to the threshold at which dispute pacing turns on again, described above). If the tentative winning outcome is disputed, then these contributions automatically go toward a dispute.

For example, imagine a market has an initial report for outcome A with 1 REP. Now imagine that a REP holder wishes to make sure that the market resolves quickly should it be disputed. They can contribute 200 REP safely toward outcome A. If the market is disputed, let’s say for outcome B with 2 REP, that 200 REP will immediately be used to dispute outcome B in favor of A in a single large bond. To progress to the next round, disputers would need to put up 400 REP toward outcome B.

Removal Of Controller Contract & Escape Hatch:

In V1, the Controller contract serves as a central registry for the Augur contracts as well as the entrypoint for interacting with the system. The functionality required for V2 has been implemented directly in the Augur contract.

Maximum Market Duration Of X Months:

While there is no technical reason for a market end time limitation, there are two compelling issues that make this limit a good idea in practice:

The first issue is that when a new version of the platform is released, REP holders can and will be expected to migrate REP to the new version of Augur. Because the security of the platform relies upon the price of REP, as well as OI, this means that any markets which are on the old version will increasingly become insecure as time goes on. A limit on market duration will help combat this risk.

The other issue is that fees in Augur are only taken at settlement. This means that someone can purchase shares from the system and only pay fees after market finalization. This is in contrast to the trading fees which are paid any time two parties trade in their shares for Cash. The greater the OI and the longer it is held without fees being paid, the more cost this places on the system for trading which extracts fees. This is because the security model and adjustments to the fee for reporters are based on the OI in the platform. With a limited market duration, we limit the impact this has to at least prevent a weaponized variant where a malicious party parks a large amount of OI in the system without trading.

It should be noted that for V2, we have chosen to not implement time based fees. However, we are considering this change for a future version. We believe that currently the issue is likely low impact and not worth introducing yet.

Floating Formulas Altered To Decrease Much Slower Than Increase:

An important way that Augur encourages creating valid markets is via the validity bond. In V1 Augur, this bond rate changes over time and responds to the number of invalid markets being created. While the V1 bonds are moving and the formulas are generally working, the way they are tuned means that the bond rate being stable depends on the overall rate of invalidity not to be performing particularly well.

For example, the system targets a 1% rate for Invalid markets. It may take several weeks of an increased rate of Invalid markets for the bond to double, and a single week with a 0% Invalid rate will halve it. In effect, when a level is reached that discourages creating Invalid markets, the bond will immediately halve, undoing the multiple weeks of increases.

In another community-proposed solution, the floating bond formula in V2 is altered such that the maximum increase is still 100%, but the maximum decrease for one period is only 10%. This should allow bonds to stay at the appropriate level longer but also allow them to decrease if platform behavior changes. This change will also apply to the no show bond and the initial reporter bond amounts.

Dispute Winnings Reduced to 40%

In v1, disputers earn a 50%+ when they stake on the winning outcome. v2 reduces the dispute winnings to 40% in order to prevent disputers from being able to arbitrarily draw out the disputing process without incurring a loss. The remaining 10% will be burned.

Remove ETH Fees From Disputing:

REP used in reporting and disputing in V1 Augur awards reporting fees. While this seems logical enough, the volume of REP staked works out such that any fees gained this way are less than the additional gas cost of tracking them in the majority of cases. In order to spare REP holders this cost and to simplify the code, both reporting and disputing in V2 will simply not award reporting fees. The 40% ROI from disputing is considered more than enough of an incentive to encourage disputing

Trading Changes:

Multiple features are being added to the trading API:

0x Trading:

Augur V2 is using 0x (v3) to power off-chain order books, which allow people to place orders fee-free, as well as set automatic order expiration. The trades still settle on chain giving users the security of the Ethereum Blockchain for trading. This latest version of 0x also supports peer-to-peer order transmission, making these order books censorship resistant and powered by the community of users who are trading on the Augur platform

Ability To Ignore Shares When Trading:

As proposed by the Augur community, in the event that someone wishes to use the trading functions but also not sell existing shares, they can now specify that preference. When this option is used, the system will not automatically liquidate complete sets.

Affiliate Marketing Support:

In order to incentivize marketers to advertise markets to traders, the trading functions now allow for an affiliate address to be specified. This will give a portion of the market creator’s fees to the specified address. That portion is set by the market creator during market creation and can be 0 if they do not wish to enable this feature.

Bug Fixes:

All v1 bug fixes can be found here.

Miscellaneous Changes:

Solidity Compiler Upgraded to 0.5.4, removal of the waiting period on claiming winning shares, trades automatically sell any owned complete sets, functions for creating or canceling multiple orders in one TX added, function for modifying order price, profit & Loss trading data on chain and in logs