We are enacting an Augur v1 market cutoff date to facilitate the transition to Augur v2. The cutoff, which will take place at the end of September 15th, 2019 is the latest time at which an Augur market can expire and still be guaranteed to resolve before the launch of v2. Markets that expire after the cutoff may not resolve before v2 is launched and are at higher risk of resolving incorrectly. We’ll explain here exactly what this means and how traders, market creators and reporters can avoid or minimize risks associated with this cutoff.
Augur v2 (Version 2) is the first major upgrade to the Augur protocol. Augur v2 contract code is complete, now undergoing audits and is on course for release later this year. After v2 is deployed, Augur v1 will still exist on the Ethereum Mainnet, as it has no escape hatch or way of being shut down or altered. Augur v1 and Augur v2 will exist independently of one another, each using a separate version of REP. This post is mostly directed toward traders, reporters and market creators on Augur. In a future post, we will dive more into what v2 means specifically for REP holders.
We have set the cutoff at September 15th, 2019 23:59:59 UTC. All markets that expire (enter reporting) before this time will be waited on to resolve (complete reporting) before v2 is launched, while markets that expire post-cutoff may resolve after v2 is launched.
For example, a market that expires September 14th will be waited on to resolve before launching v2, while one that expires September 16th will not necessarily resolve before v2 is launched. Markets that expire before the cutoff will be unaffected by the transition to v2, while markets that expire after the cutoff are at higher risk of resolving incorrectly or forking.
Once v2 is launched, REP holders will be heavily incentivized to migrate their REP to v2, since it is expected to be a far more usable and popular platform in the long run, and The Forecast Foundation will no longer actively develop v1. So v1 markets that resolve after v2 is launched will likely have minimal value in REP available to stake on their outcomes and accurately resolve them. At that point, the v1 oracle may be cheaper to attack by reporting false outcomes and potentially triggering a fork. In the event that a post-cutoff market forked, reporters remaining in v1 would no longer be able to migrate their REP to v2.
This risk applies to traders, market creators, and reporters interacting with markets that expire after the cutoff. REP holders in general are not directly affected by this.
Since markets that expire after the cutoff are at higher risk of resolving incorrectly, we advise the following to traders:
1. Do not enter positions in markets that expire after the cutoff.
2. If you already have positions in any such markets, consider closing your positions.
3. Cancel any open orders in such markets (with the exception that you already have shares in the market and the orders, if filled, would reduce your exposure).
The UI now has several updates to minimize and help communicate this risk to traders. By default, markets that expire after the cutoff are now hidden on the markets page. Traders who have any positions or open orders in post-cutoff markets are automatically alerted in the UI and any such markets are flagged on the portfolio page. We also added multiple warnings on trading pages for post-cutoff markets that caution against trading.
We advise against creating markets that expire after the cutoff. If you have already created a market that expires after the cutoff, you are at greater risk of not receiving back your validity bond. No-show bonds will be paid in Rep v1, which may have little or no value. The market creation interface now displays alerts that discourage setting post-cutoff expiration dates.
We caution against reporting on and disputing markets that expire after the cutoff (with the possible exception that you are the market creator), since in the event of a fork, all reporters remaining in v1 would lose their ability to migrate their REP to v2. We have updated the UI to caution against reporting on markets that expire after the cutoff.
We believe that v2 will dramatically improve Augur’s usability, security and reliability, but the transition out of v1 may not be as smooth as we would like. We have taken action to ensure that future version changes run more smoothly and to modify Augur v2 contracts in order to make downtime explicit and understandable. The community is currently discussing options for improving releases for v3 onward with the goal of reducing or eliminating downtime. We are also working hard to improve the reliability of Augur in general, including changes both in v2 and pre-v2 to address Invalid market risks. We will dive more into these in an upcoming post.
We will no doubt face some growing pains as we advance one of the most complex and ambitious projects in crypto, technology and finance. Looking at the big picture, we have never been so optimistic about the long-term potential of Augur. These are early days and all we can do is keep building and improving Augur, day by day.
If you have any questions, feel free to jump on the Augur Discord, a vibrant community of Augur users, developers, and enthusiasts.