On Augur

Delphi
6 min readJul 11, 2017

If you have read our whitepaper, then you probably noticed that we spent a lot of time comparing and contrasting the respective approaches taken by Delphi and Gnosis, but very little discussing the distinctions between Delphi and Augur. This was a deliberate decision, because while we do greatly respect the team at Augur, we also recognize that their design is not perfect; in fact, in our estimation it is actually architecturally inferior to the approach that Gnosis has taken.

Fundamentally, as you might expect, there are many similarities between Delphi and Augur. Both platforms recognize and support the same 3 types of events (Binary, Categorical, and Scalar), and both are built on top of Ethereum and make use of ERC20 tokens. Both organizations have taken precautions to protect against certain types of government interference (although at Delphi, we seem to take this much more seriously than the team at Augur), and in both cases, it is clear that significant time, effort, and research has been dedicated towards building a sustainable decentralized oracle model. We particularly appreciate the rigorous analysis/modeling that we have seen out of Augur in the past few years, which has inspired our own methodology to a considerable degree.

But you’re not here to read about all the ways that Delphi and Augur are similar. It is much more illuminating to consider instead how they are different. This is a question worth taking a moment to answer, but it is also worth bearing in mind that this article does not represent a comprehensive comparison of the two protocols, which would be outside the scope of any reasonably-succinct piece on Medium.

Which Augur Are We Talking About?

Before taking a look at the Augur design and implementation as it currently stands, it is worth noting that since their inception, the project has pivoted many times. It was originally written as an extension to the Bitcoin Core source code (using Script), and actually progressed through numerous failed iterations during this stage. In the words of Paul Sztorc, who invented the consensus model that Augur was built on:

“Augur only deliberately made one change to original Truthcoin (don’t even get me started on the numerous mistakes). This single change actually managed to break the entire incentive structure. I pointed out the flaw, and they (eventually) were forced to admit that their change was a terrible idea, and they changed it back.

Then, believe it or not, they changed that thing again, and broke it a second time. Again, I pointed out the error, and again, (months later) they were ultimately forced to agree that they had again made a mistake.

And then, get this, they actually changed it a third time to something else, which was again broken! …

In short, the problem is that Augur’s improvements always suck”

While we don’t agree with the unprofessional rhetoric and vitriol, we acknowledge the validity of the underlying point that Sztorc was trying to make: haphazardly fiddling with the details of a consensus system will almost invariably fundamentally undermine the model it is built on. Beyond that, if the specification of a system is being continually rewritten, it renders it especially resistant to serious analysis, even by experts in the space, because it represents a “moving target” that is unable to be concretely criticized. Even after transitioning from a Bitcoin-based architecture to an Ethereum-based one, Augur has radically evolved over time, making it relatively difficult to find accurate and up-to-date information regarding their current specification and approach, and even more difficult to draft a formal critique of it.

With that said, we believe that Augur’s current design is conceptually sound, and we have not been able to identify any fundamental flaws in their operating model. We believe that they have settled upon a valid and reasonable network incentive structure and consensus model, which will (at least in theory) successfully do what it is supposed to do.

Alright, so what exactly do we do differently?

Augur vs Delphi

First and foremost, Augur is predicated around one particular event resolution model, where the system itself functions as a single rigid and monolithic oracle powered by an iterative commit-and-reveal process that any REP holder is free to participate in.

Contrast this with Delphi, which is instead designed to support any type of oracle solution that the market is able to design or provide. It is a much more flexible model, where we do not dictate the specific, behind-the-scenes details of oracle operation. Instead, the Delphi protocol is set up with generalized oracle interfaces (just as Gnosis is), ready to accept any solutions that implement the basic oracle functions we have defined. This way, as technology evolves and designs are refined, Delphi is set up to work with the different types of oracles that arise, and open market competition ultimately decides which implementations are predominantly used. In terms of near-future implementations, we have constructed what we consider to be the most sophisticated decentralized oracle design to date, with our Pythia framework. This is a component which we will describe much more thoroughly in the coming days, but for now, suffice to say that it represents a radically different approach to the Oracle Problem from the one that Augur has adopted.

Augur is designed so that platform fees are collected on the base layer of the stack and must be shared among all voters, whereas Delphi is set up so that fees are only paid on the higher layers of the stack (this is what our PHI tokens will be used for), and do not need to be distributed except to the relevant service providers (e.g. oracle systems). We believe that keeping the underlying protocol free-to-use will ultimately compel users to gravitate to Delphi rather than Augur. We also think that this effect will be compounded by the predictable usage costs that Delphi is able to provide with its dual-token architecture.

Augur sports a relatively heavyweight design, whereas Delphi is much more lightweight and modular (and, we hope, simple-to-understand). Augur requires much more active participation (e.g. voting and appealing) on behalf of its token holders, and relies upon a democratic event resolution model; Delphi is perfectly capable of working with such models, but is also designed to be compatible with other approaches (even ones that haven’t been invented yet).

By ensuring that even outcome tokens adhere to the ERC20 standard, Delphi is able to natively support more complex “conditional markets” much more easily (effectively allowing predictions to be “chained” together). We believe that the implications of this functionality are profound.

In order to safely accommodate disputes in their model, Augur is designed to resolve over longer time frames (days to months). Delphi is expected to reach event resolution much quicker than this in almost all cases; because we are not fundamentally limiting the oracle component to a particular design and instead are allowing the market to innovate with it, the average time-to-resolution in Delphi is expected to drop to the minimum possible interval. Basically, faster oracle services will probably be more popular and successful than slower ones, if users are given a choice in the matter.

These are just a few of the high-level differences that distinguish Delphi from Augur. We feel that comparing our respective technical designs paints a pretty clear picture, but of course there is always room for other interpretations and perspectives when it comes to complex subjects like this.

The Market Speaks

Many (but not all) of these improvements, optimizations, and additional features over what Augur provides were incorporated by Gnosis, too. As we said in our introduction, architecturally, we believe that Gnosis actually represents a better solution than Augur does, which is why we decided to focus on maintaining backwards compatibility with their design rather than Augur’s. It looks like the market currently agrees with our assessment of the matter, because Gnosis is the #1 ERC20 token by market cap, while Augur is #4. And if you can’t trust the market’s assessment of the subject (as reflected in the prices and market-caps of the respective tokens) then you are rejecting the basic premise behind prediction markets anyway. At this moment, the world is indicating its belief that of the two platforms, Gnosis stands the greater chance of ultimate success. Therefore, we have considered Gnosis the “gold standard” in decentralized prediction market technology, and as a result we have concentrated our efforts into improving directly upon their approach, rather than Augur’s.

--

--