On Monday (April 8), the team behind Augur, “a decentralized oracle and peer to peer protocol for prediction markets”, announced that version 2 of the software is feature-complete and ready for third-party formal audits. This article provides an overview of these features.
What is Augur?
According to its website, Augur is:
- “a decentralized oracle and peer to peer protocol for prediction markets”
- “a protocol, freely available for anyone to use however they please”
- “accessible through a desktop client app, similar to interacting with an Ethereum or Bitcoin node”
- “a set of smart contracts written in Solidity that can be deployed to the Ethereum blockchain”
- “free, public, open source software, portions of which are licensed under the General Public License (GPL) and portions of which are licensed under the Massachusetts Institute of Technology (MIT) license”
It is important to note that Augur is NOT a prediction market; it is “a protocol for cryptocurrency users to create their own prediction markets.”
What is Reputation (REP)?
- “The Reputation (REP) is a cryptocurrency, used by reporters during market dispute phases of Augur.”
- “REP holders must perform work, in the form of staking their REP on correct outcomes, to receive a portion of the markets settlement fees.”
- “If you do not report correctly, you do not get the fees.”
- “If you report incorrectly, you lose your REP.”
- “If you don’t participate in a fork (when the network has a very large dispute over an outcome), you lose 5% of your REP.”
- “Passive holders of Reputation (REP) that are not using their Reputation (REP) within the Augur protocol to stake on disputes and forks are penalized.”
What Is New in Augur Version 2?
Per the Augur team’s blog post, this is the “first major upgrade to the platform” since it was first released in July 2018. Work on version 2 (“v2”) started “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.”
The Augur team’s description of each major feature will be accompanied by excellent commentary provided by Spencer Applebaum, an investment analyst at crypto hedge fund Multicoin Capital, who analyzed these features and explained what they mean in plain English in a highly impressive 14-tweet thread.
DAI Denomination Token
Description:
“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.”
Commentary:
“Augur markets are currently denominated in ETH. This means that users must take on two forms of risk: risk in the market they’re betting on, and the ETH-USD price. Dai will remove the second risk”
Invalid As A Tradeable Outcome
Description:
“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.”
Commentary:
“In Augur's current version, malicious users can purchase less probable outcome shares & flip them for 0.5 ETH (or 1 ETH / # of outcomes) in the event of an invalid market. With invalid as explicit outcome, this exploit is entirely impossible”
REP Price Auction
Description:
“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 platform and the price of REP. To determine the price of REP in V1, a centralized price feed was put in place. Shortly after launch, a bug was discovered that rendered this price feed pointless, as the fees did not adjust in relation to the centralized feed. Because of this bug, the key needed to update this price feed was discarded.
We have resolved the aforementioned bug in V2, and furthermore, we are making the platform fully decentralized by introducing a built-in double auction that will act as the price feed. Two double auctions will take place each week where a pot of DAI and REP are sold for one another, and a REP price is calculated from the sale prices. The platform will mint a small amount of REP weekly to compensate for any losses from the auction. This will introduce a small amount of inflation to REP in exchange for a decentralized price feed used to maintain platform security.”
Commentary:
“It appears that Augur currently uses @MakerDAO price feed. In v2, Augur will use a DAI-REP auction to serve as the oracle (to determine reporting fees based on open interest). This introduces REP inflation into the system, a tradeoff for decentralized oracle”
Use It Or Lose It Forking
Description:
“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.”
Commentary:
“Augur v2 will incentivize 100% REP holder participation in case of a fork. REP holders who don't participate in a v2 Augur fork will *lose all of their REP tokens*. Contracts won't allow migration to child universe after 60 day allotted period”
Immediate Dispute Rounds Up To A Threshold
Description:
“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.”
Commentary:
“In Augur v1, REP holders must wait until the next 7-day fee window to challenge a market's current tentative outcome (this delays payouts to winners). In v2, up to a certain threshold, REP reporters can immediately challenge outcome to next round”
Designated Reporting Reduced To One Day
Description:
“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.”
Commentary:
“When markets are created, the market creator must assign a “designated reporter” to supply an initial outcome for the market. In v1, the initial reporter has 3 days to report the outcome. This will change to 1 day in v2 (speeding up finalization)”
Pre-Emptive Contributions To Tentative Winning Outcomes
Description:
“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.”
Commentary:
“As seen in Midterm House Market and Bastille Day Markets, dispute rounds go back and forth until a winner is determined. In v2, reporters can stake REP and contribute to future rounds instead of coming back later. This speeds up disputes”
Upgrade Token Standard To ERC777
Description:
“ERC20 is a simple, commonplace standard in the Ethereum ecosystem that allows for many applications. That said, it has some deficiencies. One of the proposed token standards, ERC777, is backward compatible with ERC20 but also improves upon many of its features.
In particular, the reason we wanted V2 to support this standard was so that developers can make use of the ‘tokensReceived’ fallback function feature. This feature will allow developers to make their apps interact with Augur tokens without the need for users to give full transfer permissions or make an extra approval transaction for every action they take.”
Commentary:
“In Augur's current version, 'AugurCos' and dApps must attain transfer permission from users to interact with shares (because of ERC20 requirements). The switch to ERC777 will eliminate this clunky UX problem”
Floating Formulas Altered To Decrease Much Slower Than Increase
Description:
“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.”
Commentary:
“Augur encourages valid markets by requiring market creators to submit a validity bond (the creator forfeits the validity bond if market is deemed invalid). The floating bond formula is changing in v2, eliminating quick algorithmic drops of validity bond”
Remove ETH Fees From Disputing
Description:
“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.”
Commentary:
“Staking REP to report/dispute in Augur's current version does not compensate enough for Ethereum Gas fees. Thus, V2 will not award reporting fee for dispute. According to Augur team, 40% ROI will be enough of an incentive to encourage disputing”
Ability To Make Signed Trades Off-Chain That Can Be Executed By Another Party
Description:
“With the introduction of DAI to denominate markets, it is possible to reach users who do not possess ETH. The V2 trading contracts include a mechanism for executing a signed message which contains data about a trade. This means that someone can generate a trade, such as ‘Buy 1 @ .9’, and post it publicly where another party can spend the gas to execute it and the system will take the signer’s required capital to execute the trade. In theory this enables a system that allow ETH-less trading, though in practice they still need to have an ETH account with DAI and also need to approve their DAI for transfer which will cost ETH in gas costs.”
Commentary:
“v2 Augur will introduce a feature that allows users to broadcast limit orders off-chain. If the trade is executed by another party, the maker will pay Gas to approve Dai transfer”
KYC Token Support / Integration
Description:
“The trading functions allow a token to be specified which will cause trades to take place in an orderbook segregated only to holders of that token. The intention of this feature is to support tokens that are awarded through different providers.”
Commentary:
“Augur v2 will enable KYC-compliant trading by whitelisting holders of a KYC token. This is massively important for 'AugurCos' who choose to be compliant. Allows them to comply with U.S.A. KYC laws, but can also operate globally”
Affiliate Marketing Support
Description:
“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.”
Commentary:
“Taking a page out of Binance and BitMEX playbooks. In v2, market creators can specify an address to share market creation fee with. Presumably, the person behind the affiliate address will advertise the market and work to amass volume on it”
Featured Image Courtesy of Forecast Foundation
