From Smart Contracts to the Initial Oracle Offering: How We Got Here

Stefan Furris
Zap Protocol
Published in
6 min readJan 24, 2019

We have all heard the term “smart contract.” But what is that really?

The subject in that phrase is the word “contract.” It is simply an agreement between at least two people. A smart contract adds a few extra dimensions. It uses the form of a software program, which at its core is a series of instructions which issue commands, define terms, set forth conditions or contingencies, and establish events which need to occur in order to trigger subsequent events.

How are smart contracts useful? For starters, they can trigger economic events on a blockchain based on the data that is provided to it and the conditions that are set within it; agreements between two or more parties can be written directly into lines of code. The coded agreements exist across one or more distributed, decentralized blockchain network(s).

Smart contracts, however, are closed systems, meaning that they are unable to access data from outside the network they are on. In order for smart contracts to reach their fullest potential (and to have the greatest value to their users) they must be able to reliably access information from outside the blockchain on which they are hosted.

We solve the problem of smart contracts being restricted to on-chain data sources by enabling access to outside, or “off-chain” data. The missing link is what we call an “oracle.”

Oracles are trusted third party or decentralized data feeds that provide data to a blockchain-based smart contract. These oracles essentially hold the “private key” to the smart contract — an oracle has the power to decide which party wins in a smart contract. Think of it like being a witness whose testimony one way or the other will determine the outcome of the case. And in many smart contract use cases, an oracle is necessary for the smart contract to function.

This means that with the proliferation of oracles, the utility and prevalence of smart contracts will grow from the select few applications available today such as ICOs, Crypto Kitties, decentralized exchanges, and decentralized gambling.

With proper off-chain data integration, smart contracts can readily be used for a nearly limitless range of purposes. Think back on the Ethereum whitepaper, where claims of decentralized financial derivatives, identity systems, decentralized crop insurance, and more are mentioned as some of the many applications of Ethereum and the EVM (Ethereum Virtual Machine). The applications listed above, and many more, are not possible without the use of oracles.

The decentralized derivatives need a data feed for the exchange rate of USD/ETH in order to operate. Decentralized crop insurance contracts need micro-weather data to determine the rainfall on a farmer’s crop. An identity/reputation system may need many data feeds in order to adequately verify identity. In short, if you want a smart contract that will respond to real-world events in real-time, you need to have up-to-date, quality data fed into the contract.

The proper use of oracles will determine the utility that smart contracts will eventually have. Because of how important oracles are in terms of making good smart contracts that provide real value to the world, the data that they report has to be perfect.

Oracles that have value, that are trusted, must ALWAYS report accurate data.

We realized that data providers, in the short term, could have an inherent incentive to report false data, even if they have no stake in the smart contracts they are affecting.

Hypothetically, in a smart contract between two parties, one may contact the data provider and attempt to bribe them to report false data that will make the contract decide in the attacker’s favor. Further, centralized data sources are prone to attacks themselves. Even if the provider has no intention of reporting false data, the centralized nature of their organization makes it much, much easier to attack. So what then solves the issue of needing accurate data provided by decentralized means?

With Curation Markets, Quality Data Stands Out From the Rest.

In order to combat this, we turned to curation markets, fueled by bonding curves. Zap uses bonding curves to give users access to unique and competing oracles, or data feeds. When ZAP tokens are bonded to an oracle, a user receives dots, our secondary token, in return. Each dot is representative of one data request to an oracle. The amount of dots received per ZAP changes based on how many ZAP are bonded to that oracle over time. Dots can be redeemed back into Zap at anytime. More on bonding curves can be found here, as well as the blog of Simon de la Rouviere, the inventor of curation markets.

Curation is assembling, managing and presenting some type of collection; in our case, that is data. In short, curation markets allow for an unprecedented degree of flexibility in oracles as there’s no single format that works for every application. Since anyone can create an oracle, the vast and diverse data needs of the world can be met by anyone who can now monetize their data and provide it directly with the long-term, and profitable, incentive to stay honest and accurate over time.

Bonding curves are market based incentives that reward data providers for providing accurate, quality data, and punish them harshly if they report falsely. One can expect more Zap bonded to the good, credible oracles while less Zap will be bonded to oracles of bad actors or newer and more speculative oracles. Moreover, this creates a whole new market for data feed speculation based on the perceived value of the data and hope that an oracle will remain honest. The essence of the market is the incentivization of great behavior and the maintenance of credibility.

So what are Initial Oracle Offerings and how do they fit in to all of this?

Initial Oracle Offerings (IOO) are the next step towards maximizing smart contract utility and adaptability, allowing them to reach their true potential. As the ecosystem develops, there will be users who are providing the same data, causing one or both to try to undercut the other and gain subscribers from the other.

How is a subscriber to know which user is the one that is providing quality data, who is simply re-wrapping others’ data, and which to stay away from due to unreliable or possibly fraudulent data?

The Initial Oracle Offering is simply a format for data providers to prove to their subscribers that their data is the feed worth subscribing to over the others providing the same or similar data.

These IOOs can be simplistic, perhaps nothing more than a couple sentences stating how they acquire data and plan to provide it consistently and accurately.However, we anticipate the use of oracles being much too important for such a simple explanation.

We envision data providing to be a business in and of itself, and as such we imagine natural competition will force data providers to put a significant effort in to persuading subscribers that their oracle is the most accurate and reliable..

The ICO model is proven to be extremely effective, as startups have raised nearly $4 billion in 2017 and more than $12 billion so far in 2018. If the model is good enough to raise money and awareness for the many smart contracts, smart contract platforms, and smart contract applications, it will be just as good for the data fueling all of these ICO projects’ infrastructure.

Thanks for reading! Make sure to bookmark our blog at https://media.zapproject.org, follow us on Twitter @ZapOracles, and join our Telegram channel https://t.me/zaporacles to stay up to date with the latest news and updates from the Zap team. We’re always happy to hear from you: send your questions and comments to hello@zap.org.

--

--