Augur V2 has launched and we’re excited that the system has worked as intended— earlier invalid signaling, faster resolutions, and secure oracles.

Despite a successful launch there is a lot left to do for Augur. Liquidity and usage are orders of magnitude lower than what most envision for the protocol for a variety of reasons, the two most notable being:

• Transactions are expensive. During most of Augur V2’s development, gas prices hovered in the 5 gwei range. While the system was tailored around that expectation, it is clearly no longer the case and Augur needs to adapt.
  
• Demand for DAI trading isn’t as high as expected. In particular there is a competing demand to be able to trade using ETH like in Augur V1, especially in a bull market. This sentiment existed and was vocal during Augur V2 development, so it’s not entirely surprising, but the decision was made to focus on one user experience for launch.

Expensive Transactions

The issue of expensive transactions for Augur is a fun problem. In reality, doing almost anything on Ethereum is expensive with 150+ gwei being the new normal.

The existing trading contracts on Augur V2 are an implementation of a traditional order book model, where a user can advertise some number of shares for sale at a particular price and another user can take that specific order. This architecture has some really nice properties and is commonly thought to be the preference of market makers and professional traders.

Because the Augur system is built on 0x, the creation of orders is nearly instant and also costs no gas. Taking an order at minimum 700k gas, however, means someone has to pay $50-100 just to enter their position (before considering system fees, time value of money, and the transaction fee to exit their position). Compare this to something like a Uniswap trade, which costs ~$4.

There are many ways to try and address this issue. The two main strategies though are:

• Provide a new trading mechanism on Ethereum where transactions cost less gas, like Uniswap.
• Replicate the existing trading mechanism on a Layer-2 platform.

We’re actively working on both of these solutions right now.

Augur AMM

The rise in popularity of constant product market makers throughout the Ethereum ecosystem makes a lot of sense. The UX is fantastically simple, and liquidity providers—the equivalent of market makers—just have to provide capital to start earning fees (instead of crafting a proper book).

Providing a good UX for a constant product market on prediction markets takes a custom implementation. Ideally one which handles the underlying currency, Invalid shares, and otherwise models the behavior of a two asset market using outcome shares.

As a liquidity provider one wants to simply provide Cash, and as a trader one should be able to enter a position with Cash and exit one's position to receive Cash. One should never have to consider the possibility of an Invalid market; and should it occur, one should simply get their money back.

We’re nearly finished writing a market implementation that fulfills all of these goals and have started on a very simple UX to use it.

Augur on L2

While having cheaper, simpler mechanisms for both providing liquidity and trading is a good start, it does not—and probably cannot—satisfy the long term vision for Augur.

To do this the existing trading system needs to run with trades that are truly cheap (less than a dime) and instantaneous (near a second). These are both possible on many existing L2 solutions for Ethereum, such as Matic.

The Augur V2 contracts have built-in support for symbiotic side-chain usage. A side-chain can have the Augur trading contract deployed to it and be configured to use a token which is bridged from the Ethereum Augur and will properly count as Open Interest for the larger system.

This makes deploying a trading-only variant of Augur onto an L2 chain a theoretically simple proposition. The current difficulty of that work centers around how to handle exits from an L2 back onto the main chain, and how to provide an nice UX for migrating Ethereum funds to a format usable on that L2.

Multiple Currency Support (Para Augur)

In order to let users trade with whatever currency for which there is demand, the protocol needs the ability to add new currency types. Previously this was thought to require an entirely new deployment including a core upgrade and REP token migration.

As it turns out this is possible with a parallel deployment that still points to the core Augur V2 contracts but maintains its own Open Interest accounting and trading contracts.

Every Universe within a Parallel Augur points to an Origin Universe within the Augur V2 deployment. It receives markets passively from this Origin Universe so that any new Parallel Augur will immediately have the full collection of markets available.

The first Para Augur deployment will support ETH trading.

OI Nexus

The Augur Protocol needs to know the total amount of money held in all markets in order to guarantee oracle security. It uses this knowledge to apply pressure on the price of REP by adjusting fees charged when people turn in their shares.

The problem with parallel deployments is that each parallel Augur needs to know the amount of money locked in the others so it can adjust its own fees correctly.

This is solved, however, by the introduction of the OI Nexus. The OI Nexus allows a new Parallel Augur instance to be registered. Any Parallel Universes then created will adjust the composite reporting fee used by every Parallel Universe pointing to the same Origin Universe.

This introduction does raise an issue in that some entity needs the power to control what Para Augurs are added to the OI Nexus. The initial proposal, at least for the first deployment, is that this be some form of REP voting contract with a timelock—though more community feedback and discussion is needed.

Other ideas for the long term are being explored as well and the Augur community's input around these will be much appreciated.

Fee Pool

As an added benefit of redesigning some of the Augur contracts we were able to refactor the Participation Token mechanism entirely into something that is:

• Easier
• Cheaper to use
• More profitable and fair in general

Each Parallel Universe will have its own Fee Pool which serves as an ERC20 token. Fee Pool tokens are minted by staking REP. While held any fees collected from trading will be distributed proportionally to all Fee Pool Token holders. If you transfer your Fee Pool Tokens you may still withdraw any fees earned while they were held by you.

There are no windows. You don’t have to worry about when to deposit or spend gas and time withdrawing and depositing.

We are excited to unveil the newest plans for Augur v2 (and beyond) and cannot wait to get the Augur community's feedback around them!

Follow along or join the discussion in the Augur Community Discord chat!