The Master Plan

Delphi
5 min readJul 27, 2017

--

Over the past few weeks, we have outlined our reasoning on a number of subjects. We’ve discussed the power of prediction markets, how this power is being stifled by incongruous and anachronistic regulations (and what we plan to do about it), and our professional evaluations of the various approaches being taken by others in the industry.

We’ve also touched on the importance of the oracle component when it comes to smart-contract based prediction markets, and explained the basics of our own oracle framework. And while we have mentioned that we intend to start small and grow from there, and explained that so far everything is going exactly according to plan, we do recognize that the tactical exposition of information can be a powerful tool of leverage, so we have taken care not to reveal too much, too soon.

We are happy to fill the role of the underdog, and part of our growth strategy is to take advantage of the market’s underestimation of our project’s potential. Even so, as our crowdsale draws to a close, we feel it is time to describe (at least the first phase of) our Master Plan.

The Oracle Wars

The next battleground for decentralization will undoubtedly be around oracles (after all, control of the oracle amounts to control of the entire contract, when execution depends on external data in any way). In other words, oracles represent a “centralization chokepoint” threat to many different types of smart contracts, including those for prediction markets. Though we’re not seeing antagonistic oracle-based control exerted today, if any of the decentralized prediction markets start to enjoy any sort of significant success (whether this is Augur, Gnosis, Delphi, or another project entirely), it will inevitably prompt efforts to compromise or centralize the oracles involved.

We won’t risk letting our hard work go to waste by ignoring this threat. Delphi’s focus will be totally dedicated to the oracle component. Our strategy on this front will allow us to bootstrap our oracle networks, receive revenue as we grow, and benefit from the efforts of other projects in the industry.

How Pythia Fits In

The Pythia oracle framework is a linchpin of our strategy. By providing robust distributed oracle models, tools, and formal analysis, we expect to lay the foundations for a thriving oracle ecosystem. Eventually, we expect Pythia to evolve into a full-fledged Oracle Marketplace (though this would likely be over the long-term, and certainly not part of Phase One of our Master Plan). We intend to take full advantage of our own platform and tools. Pythia creates new revenue models (after all, oracles require incentives), and we will leverage this opportunity to generate profits and finance our project’s growth by participating as an oracle service provider ourselves.

We will offer our (pseudonymous, always-honest) oracle services via Pythia, not only to bootstrap the distributed oracle network, but as a core revenue stream for Delphi. This will allow us to achieve our project vision (and ensure that there is always at least one difficult-to-compromise oracle out there) while also financing our efforts along the way.

It is important to recognize that Pythia is a generalized oracle framework, and is not Delphi-specific. This provides a number of advantages; for one, existing oracle solutions (e.g. Augur and Oraclize) can be pillars in Pythian oracle deployments, collecting fees in exchange for the outputs they furnish.

This also means that Pythia (and the oracle service providers built or deployed with it) can succeed independently of Delphi as a prediction market platform. In a hypothetical universe where Gnosis managed to survive and succeed despite the shortcomings we have identified with their model and execution, it is entirely possible (and even likely) that most Gnosis contracts are resolved via Pythian oracle outputs.

In other words, with Pythia, we position ourselves to be long-term allies of Augur and beneficiaries of Gnosis.

Bifurcations

Both Gnosis and Delphi share an interesting technical property: the respective token contracts are not tightly-coupled with the prediction market implementation specifics. This grants an opportunity to have a “best of all worlds” solution when it comes to our platform’s design.

We have decided to simultaneously maintain a Gnosis-compatible platform implementation and a parallel, incompatible implementation with a design emphasis on simplicity and extensibility. Both implementations will be powered by the same DEL tokens, but feature independent functionality.

We encourage further experimentation towards expanding the capabilities of DEL, and are happy to work with those who set out to do so. We ask that any such initiatives make technical transparency an absolute priority; ideally, such extensions should be accompanied by detailed code explanations, design rationales, and extensive documentation to ensure the fullest community understanding possible.

With this approach, backwards-compatibility is maintained (in at least some respects) with Gnosis, allowing integration between Pythian oracles and Gnosis markets, but we are also free to expand beyond the limitations of their design. Users can choose to take advantage of whichever features most suit them, and the market can make its own determination on which model is appropriate for any given set of circumstances.

The Roadmap

It might initially seem overambitious to commit to maintaining multiple separate (and in some ways incompatible) platform implementations. However, the more complex implementation (the Gnosis-compatible codebase) is ultimately going to represent little more than a local clone of Gnosis’ official repository (with a few custom interfaces added and some of the more disingenuous and misleading naming decisions revisited), so almost all of the development effort will be provided by Gnosis rather than Delphi for this. The alternative (Gnosis-independent) platform, which we will call Omphalos, is designed to be as simple and minimal as possible (to best accommodate future extensions), and because our approach doesn’t require coordinating network-wide consensus and the token contract is not tightly coupled to the platform implementation, our frameworks and tools can safely be developed incrementally.

In short, we are confident that we aren’t biting off more than we can chew, and that we can deliver what we have described so far within the next year.

In the first few weeks and months, we will be releasing a formal Pythia whitepaper, alpha implementations of Pythia and Omphalos, and various tools to facilitate different aspects of Delphi development and usage. As these deliverables are published, we will provide detailed updates on the next steps that we are taking at each stage (and legitimate opportunities for community feedback and input). Even so, our Medium articles will slow down considerably from here (and our GitHub activity will increase accordingly) as we concentrate more fully on software development. We will, of course, remain in continual communication with the community as needed.

We look forward to taking over the world with you.

--

--