Augur
Augur is a platform for creating prediction markets in a trustless, decentralized way. You can create a prediction market for any future event, and anyone can participate on it. The central and most interesting part of the platform is its oracle, and that’s what we’ll focus on in this issue.
Prediction markets
I’m not going to explain prediction markets in depth, but here’s a quick recap. If you already know what they are and how they are supposed to work, you can skip this section. For a more detailed explanation, you can read the previous issue about Gnosis’s Conditional Tokens.
Prediction markets are markets where participants can trade on the possible outcomes of some future event. A typical example is a sport match, where the market’s underlying event is “Will team X win the match?” and the possible outcomes are “Yes” and “No”. People can then buy and sell shares that represent each of these outcomes. When the event finally happens, the shares that correspond to the actual outcome can be redeemed (for example for USD), while the rest of the shares become worthless.
Typically, each share can be redeemed for 1 USD. If that’s the case, then —ideally— the market price of each share will reflect what the market thinks are the “real” odds of that outcome happening. For example, if the “X will win the match” outcome share is trading at 0.1 USD, this means that most people think that the team will lose. The price of 0.1 is then interpreted as a 10% of chances of them winning.
Notice that, so far, we haven’t mentioned Ethereum at all. Prediction markets have existed for a long time, but their usage in decentralized technologies is interesting for obvious reasons¹.
A decentralized oracle
The main challenge for prediction markets in Ethereum is, of course, how does a smart contract knows that some event happened? When we talked about conditional tokens, we mentioned that they don’t attack that problem: the oracle is some address, and that address can be anything. Augur takes the opposite approach, by including a decentralized oracle as part of the protocol. In fact, one could argue that the oracle is the protocol, and that the prediction markets are just a necessary part of it. In any case, it’s by far the most complex and interesting part of Augur. Let’s see how it works.
The core idea behind Augur’s decentralized oracle is that users can use their REP (Augur’s token) to vote on the correct result for a given market. Instead of explaining how they do it, we’ll do something different: we are going to start from the simplest implementation of this idea, and then iterate on it until we get to how Augur actually does it.
In all these examples we are going to use as example a binary market; that is, a market that has two possible outcomes: Yes or No. We’ll also assume that the market uses DAI as its currency. That means that you can exchange each token of the winning outcome for 1 DAI. Let’s start.
The first version of our oracle is very simple: when the market's underlying event occurs, anyone can use their REP to vote on the outcome. Here "voting" means that you lock your REP in favor of that outcome. After some time (say, a week), the voting closes and the outcome with more votes is considered the "real" outcome. The users that voted for it will then get their REP back and, to incentivize people to vote for the correct outcome, all the losing outcomes will be distributed to the people that voted for the winning outcome.
In this scenario, the Yes outcome got 100 REP and the No outcome got 130, so the market is finalized with No as the winning outcome. This means that people can exchange their No shares for 1 DAI each. Besides that, the 100 REP used to vote for Yes will be distributed in a proportional basis to the people that voted for No: if you used 13 REP to vote for No you will be compensated with 10 REP more, if you used 65 REP you’ll earn 50 more, and so on. Is you voted Yes, you lose the REP you used.
There are a lot of problems with this idea. One of them is that someone can wait until the last minute to turn the results around. Suppose the correct answer for the market is Yes and there are 100 REP backing it. Then a malicious actor can wait until the voting time window is about to end to use 101 REP in the No outcome.
If no one reacts quickly enough, then the voting period will be over and the malicious actor will walk up with 201 REP for their 101 REP investment (that’s a ROI of almost 100% for the attack!). Not only that: if they had No shares, they will win even more since now that’s the winning outcome.
A possible improvement is to restart the voting window every time someone votes, but this enables a very simple and cheap griefing attack: you just wait until the voting period is about to end and then cast a vote with, say, 1 REP. And then you repeat this every week, preventing the market to be closed.
A slightly better idea is to restart the voting period but only if the winning outcome has changed. This is an improvement, but then something like this can happen:
If two participants have opposing views about which one is the correct result (or if one of them is an attacker), it could make sense for them to use only the minimum amount necessary to make their chosen outcome the winner.
This takes us to our next idea: we reset the voting period but only if the new winning outcome has significantly more votes than the other outcome. How much is “significantly more”? Let’s say you need to have twice the votes to start a new voting period. It would look like this:
In this scenario, Yes is the winning outcome at the end of the first period, and No is the winning outcome at the end of the second period. But then, at the end of the third week there aren’t enough new votes on Yes to get to 400 REP (the double of the amount staked on the No outcome) and therefore the market is finalized with No as its winning outcome.
We are almost there! Now we have a new problem. Imagine that you are a participant in the previous example, and it’s the start of the third week. You think that the Yes outcome is the real answer, but you only have 100 REP to vote. This will take the REP staked in Yes to 200, but if there isn't more people backing that result, you will lose your tokens. The solution is that the new votes in the last period aren't used as payoff for the winners. So our third week will look more like this:
Again, the No outcome will be the winner, but only the 100 REP that were staked at the start of that period will be the ones used as reward. The new 250 REP, that weren't enough to reach the required threshold of 400, will be returned to the users that staked them. That way you can vote for an outcome without the risk of losing your tokens if there aren't enough other voters. Of course, if you do this and the 400 REP are reached, and after that the No outcome wins anyway in a later period, your tokens will be used as a reward.
There's something important to notice here: if you are in the winning side of a dispute, you will always get 0.5 REP for each REP you staked². This is a ROI of 50%, so there's a strong incentive to dispute an outcome! But this only makes sense if you think the "correct" outcome will eventually win. We'll come back to this later.
Kickstarting a market
So far we've been talking mainly about disputing a potentially winning outcome, but ideally most answers won't be disputed. Our ideal scenario is one in which the underlying event happens, someone stakes some REP on the correct outcome, and then the market is finalized. The question is, what's in for that person if there was no dispute?
Augur’s solution to this is to make the market creator post a bond in REP that will be used as the initial stake in the reported outcome. This is called the creator bond. The market creator also chooses a designated reporter, who is the only person that can report on this market (of course, the market creator can designate himself as the reporter).
This doesn't mean that the designated reporter has the last word! After they stake the creator bond on an outcome, anyone can dispute it. They also have a limited time of 24 hours to do the initial report. If they don't do it during that initial period, then anyone can use the bond to make the initial report on some outcome.
So there are three possible things that can happen to this bond:
If the designated reporter shows up in time and if the outcome they choose ends up being the winning outcome, then the bond is returned to the market creator. This works as an incentive to choose a responsible reporter (or to report correctly, if they designate themselves).
If the designated reporter doesn't report on time, then the first person to use the bond after the initial 24 hours end will keep it after the market finalizes (of course, only if the outcome they choose ends up winning!).
If the first outcome that is chosen doesn't end up being the winning outcome, the creator bond will be part of the REP that is used to pay the users that won the dispute. This is the case both if the designated reporter shows up, or if someone else does the initial report after the 24 hours period.
The garden of forking paths
We still haven’t quite finished explaining how Augur’s oracle works. In fact, we are missing a crucial piece.
Our explanation so far makes it look like a dispute over a market’s result can continue as long as there are competing participants with enough REP. But that’s not the case: when the amount of REP used in a dispute exceeds a threshold³, the whole platform enters a state called a fork. You read that right: not the market, the whole platform.
While there are a lot of details around what does that mean, I think the most important part is this: when a market triggers a fork, all REP holders have to participate in that dispute and pick a side. Put another way, if a market gets too heated, everything stops and an Augur-wide plebiscite is done. Everyone that holds REP has to vote, otherwise they lose their REP.
This is obviously a very disruptive event, and ideally it should never occur (it hasn’t so far). But its main importance for the protocol is that it exists, not that it happens. A malicious actor with a lot of REP can drag a dispute for a long time, but they know that this can trigger a fork, and if that happens they’ll only win if they control more than 50% of the REP. The forking mechanism is like a nuclear deterrent: you don’t want to use it, but you want everyone to know that it can happen.
Let’s examine in more detail how it works. First, it’s called a fork because what actually happens it that the Augur’s universe will be forked: a “new Augur” will be created for each possible outcome, and all the participants have to choose in which universe they want to live. I’m not making this up.
The fork goes on for 60 days, after which all the REP that wasn’t migrated to a new universe becomes worthless. The REP that was migrated to each new universe becomes a new token that is different to the REP in the parent universe and different to the REP in the “sibling” universes. That means that you migrate for good: you can’t go back, nor can you change your mind later and move to another universe.
The universe to which more REP is migrated is considered the winning one. But the other universes exist too! If, for example, 97% of the REP is migrated to the Yes universe (that is, the universe where the result of the market is “Yes”) and 3% is migrated to the No universe, the people in the latter one can continue using the protocol, but their REP will probably fall in price significantly.
Again, the goal of this mechanism is to be a nuclear option, and ideally it will never happen. And if it does happen, then the expectation is that the vast majority of REP holders will choose the “correct” universe, and life will go on. But it’s also theoretically possible to have a market so divisive that the resulting universes end up with approximately half the REP in each one. Maybe some day Augur will fork in a way that reflects a polarized world?
Further reading
Augur’s whitepaper is extremely good, and it goes into more detail on a lot of very cool things. Highly recommended reading for anyone interested in mechanism design.
You can check the existing markets and the probabilities they have in this explorer.
Footnotes
Prediction markets have two characteristics: they work better the more people participate in them, and they are heavily regulated. So you can see why decentralized prediction markets are attractive.
In Augur this is actually 0.4 REP, since 20% of the losing REP is burned (I’m not sure why).
To be precise: a fork is triggered if 2.5% of all the REP is staked on some outcome. See the paper for the details.