Augur v2 launched a new prediction-market system on Ethereum

Augur launched the second version of its decentralized prediction-market protocol on Ethereum on July 28, 2020, replacing neither the original contracts nor their records but creating a separate system alongside them.

The distinction mattered. Augur v2 was not an ordinary software update applied to a centrally controlled service. The project’s migration documentation described it as an entirely new deployment whose contracts formed a separate Augur “universe.” Because Augur v1 had no administrative mechanism for stopping trading or upgrading the protocol in place, its contracts continued to exist independently.

Contemporaneous reporting on July 28 confirmed that the upgraded platform had launched. An Ethereum indexing manifest associated with Augur v2 identified the main protocol address and began indexing it from block 10,543,755, providing an additional technical record of the deployment.

A prediction market denominated in DAI

One of the most visible changes was the use of DAI for trading and settlement. Augur’s first version exposed market participants to changes in ether’s dollar value while their positions remained open. Denominating v2 markets in DAI was intended to make the amount at risk and the potential payout easier to interpret in dollar-like terms.

That did not make DAI equivalent to insured bank money or guarantee that it would always trade at exactly one dollar. It meant that Augur v2’s contracts used DAI as their settlement asset. The protocol’s documentation described market bonds, complete sets of outcome shares and winning-share redemptions in DAI.

The new design also treated “Invalid” as an explicit possible outcome. That was important because ambiguously written or objectively unresolvable markets could otherwise produce incentives and pricing that confused traders. Making invalidity visible as a tradeable outcome gave market participants a way to price that risk before resolution, although it could not prevent poorly drafted markets from being created.

REP migration created a separate responsibility

Augur’s Reputation token supported the reporting and dispute process rather than serving as the currency used to place positions. Participation in the v2 reporting system required REPv2. Existing REP holders could migrate their tokens through a one-way process, but the project said there was no immediate deadline merely because the new deployment had launched.

The old and new tokens therefore represented participation in different protocol universes. The migration record warned exchanges, wallets and custodians that they needed to decide how to support REP and REPv2. Kraken’s July 27 notice, for example, said it planned to add REPv2 support on August 4 while initially allowing the two versions to coexist.

Augur also restored a “use it or lose it” rule for the exceptional case of a network-wide market fork. If a dispute ever reached that stage, holders would have a 60-day window to select an outcome universe. Tokens left behind after that window could not migrate into a post-fork universe. On July 28, this was a contingency built into the security model, not evidence that such a fork had occurred.

Why the launch mattered

The launch tested whether a complex prediction-market application could combine stablecoin settlement, an on-chain order and reporting system, and decentralized dispute resolution without an operator empowered to reverse outcomes. It also illustrated the cost of immutability: defects could not simply be patched inside the existing v1 contracts, so users and infrastructure providers had to coordinate around an entirely new deployment.

No launch-day record established adoption, reliable liquidity or the long-term security of the mechanism. Those questions depended on subsequent markets, reporting behavior, integrations and contract operation.

Later context

Reporting published in October 2020 said Augur issued a “v2 Redo” release soon after the initial launch to address problems discovered in the first release. That later correction does not change the July 28 deployment date, but it limits any interpretation that the launch-day software was already a finished or fully validated product.