# Welcome

Distributing real-world data to blockchains using Polkadot.

Welcome to the wiki for ORAO. We have separated information for the ORAO network into several sections. [*Introduction*](https://app.gitbook.com/@orao-nik/s/orao/introduction) covers background information on the oracle space in general, as well as the design philosophy of ORAO. [*The ORAO Solution*](https://app.gitbook.com/@orao-nik/s/orao/the-orao-implementation) explains the architecture of the platform in detail. [*Token economics*](https://app.gitbook.com/@orao-nik/s/orao/token-economics) provides details on token vesting periods, lockups, valuations etc. [*Installation Guides*](https://app.gitbook.com/@orao-nik/s/orao/installation-guides) provide simple instructions to run different parts of the codebase. [*Development Milestones*](https://app.gitbook.com/@orao-nik/s/orao/development) section provides information on the development goals we have set and our progress toward them. We provide daily changelog updates as well. The [*Media*](https://app.gitbook.com/@orao-nik/s/orao/media) section contains contact information for media companies, and will also provide useful infographics for them in the future.


# Introduction

The strengths of blockchain and smart contracts are manifold. However, they also suffer from some limitations that are inherent to the technology. There are many kinds of information we would like to be able to feed to smart contracts or store onchain. But blockchains themselves have no way to support verifying information from the outside - they must be printed to the chain and then trusted.

Oracle platforms allow this to happen without requiring you to trust the data provider. They do this by providing economic incentives, punishing bad information with confiscation and rewarding honesty with money. The exact mechanics to optimize this are subject to some debate, and we will go through various earlier implementations and mention what they did well, what did not work out, and what we have learned from their efforts. A number of issues remain, however, which earlier oracle platforms have failed to solve:

**Lack of Interoperability:** As the blockchain and cryptocurrency space grows, it is becoming clear that no one chain will be the only relevant chain for smart contracts and data marketplaces. While Ethereum has led the way and 2.0 is expected to alleviate high fees and congestion, the oracle platforms that serivce only Ethereum simply cannot compete in a market where data has to move between blockchains. In particular there is a lack of support for Polkadot, where we expect strong growth in the next few years due to its superior scalability and interconnectedness.

**Narrow data specializations:** Most oracle platforms support very limited data products, typically price feeds, with a few supporting other financial data. For oracles to enable unprecedented growth in the reach and capabilities of smart contracts, a wide range of data products must be supported, from weather data and the outcome of hockey matches to disaster verification and flight delays.

**Reactive-only reputation systems:** While most oracle platforms do have reputation systems, current implementations support only reactive penalties - attackers can build up a good reputation score and bide their time until they find an opportunity to provide false data at a critical moment, typically fake price feeds to profit off of a smart contract inocrrectly pricing assets.


# Earlier oracle platforms - what we have learned

The first oracles in crypto date as far back as 2016 and 'Oraclize'. Oraclize is in fact still live and providing data feeds on Ethereum. However, unlike later platforms it is entirely centralized, in a market that does not like single points of failure.

Another weakness shared by most oracle platforms is that the range of data they support is very narrow - typically limited to financial data, especially price feeds. Given the high premium on volume in crypto, the information provided is typically also limited in other ways. Outside the blockchain, tapping into for example an exchange API can give you a live feed not only on the latest spot price for Bitcoin, but also order depth, trade volume, price slippage for large orders, etc. This kind of rich information rarely gets transmitted by oracle services - the bloat required to print so much information would cost too much for most data buyers who might otherwise be interested... In addition, oracle platforms up to now have varied greatly in their approach on ensuring high quality data. Rating and reputation systems work differently, and some platforms do not even have them.

For Chainlink, a data provider improves their reputation score by receiving and completing assignments, fulfilling orders quickly, and by staking a greater number of tokens. The more tokens they stake, the more they have to lose by getting caught selling bad data, and the more exposed they are to a fall in the price of the token, should the network develop a bad reputation. This system has afforded data buyers a high degree of confidence in the data they buy, but there have been a few unintended tradeoffs. Data providers are penalized for failing to fulfill even spam orders, which can force the providers to choose between paying high network fees, losing them money, or abandoning requests, penalizing their reputation score. In August 2020 the Chainlink network was hit with a sustained spam attack that caused data providers to lose over 700 ETH over a few hours to protect their reputation scores.

DOS Network also has a reputation system of sorts, but it is not one consumers can interact with directly. Multiple data providers are randomly selected to handle any query. Malicious and excessively inactive members lose their stake. There is no human interaction involved – if the other randomly selected data providers reach a consensus that disagrees with you, your tokens are gone. For data requests where only one reasonable answer can be given, any deviation from the correct answer is of course suspect, however this approach does also limit DOS Network Oracles to providing fairly terse data, with little room for requests where the answer might change by tiny degrees from one second to the next. The system also requires multiple data providers to perform the same data collection and computations, necessitating a significant amount of wasteful, redundant work which eats into the profits of each data provider and raises the cost for the buyer.

Our third example, Band, does not have a traditional Reputation system. Instead they allow stakers to challenge any data provided, resulting in a trial with fellow stakers as jury, with stake determining voting strength. To prevent wealthy attackers from buying enough voting power to steal trials they are implementing time delays to begin staking and to unstake, but importantly they are also using a bonded curve for the generation and sale of the specific sub-tokens staked to be a data provider. This means that a wealthy attacker will pay an increasingly higher price for every token they need to secure their voting power, making it impractical and expensive to join the network only to attack it. However, it also means that honest participants seeking to join the ecosystem have to pay that same increasing price, in what is effectively an unavoidable wealth transfer from all new participants to the oldest. While this approach is understandably popular with very early adopters, it cannot help but struggle to gain acceptance with a maturing market.


# Introducing ORAO - Overview

The oracle space has come a long way since Oraclize. And just as earlier decentralized oracle platforms have built on the first generation of centralized versions, so we have had the benefit of seeing what has worked well for current platforms and what pitfalls others have discovered for us to avoid.

Orao has taken from projects like Chainlink and DOS a reputation system that judges data providers on factors like the freshness of data provided, order completion rates, quick fulfillment of tasks, etc. But through the integration of Data Protocols we can also judge providers on data normalization, and through the harnessing of Machine Learning we are able to make our reputation system proactive rather than reactive. With other platforms, an attacker is able to build up a good reputation score, only to deliberately provide false data if they can somehow benefit more from their trickery than they stand to lose from having their staked tokens confiscated. ORAO's system however analyzes data as it comes in, and even seasoned data providers are not blindly trusted if the data they provide goes too much against recent outputs, by the same provider or by others.

ORAO also vastly expands the range of data that can be traded on the platform. There are by now a dozen oracles buyers can tap into for financial data. Bitcoin price feeds on chain have been with us for going on five years. But through ORAO's predefined Data Protocols data providers can sell anything from soccer game outcomes to weather data to information about movies from IMDB. Because of how we built our platform, new Data Protocols can be added as demand is identified by buyers and providers. For anything that you can reasonably nail down an objective, verifiable answer, ORAO can support a Data Protocol for it and create a market.

Lastly, ORAO is blockchain agnostic. It has been built for Polkadot, and so can support cross-chain interactions between anything from Ethereum to EOS to Zilliqa. Any compatible chain can be connected to ORAO as demand rises.


# Usecases

We thought we would include a page on example markets enabled by ORAO. Our Data Protocol structure will support a great many usecases outside of simple price feeds, including but not limited to:

**Sports betting:** Gambling has become a popular usecase for smart contracts already. However, using Data Protocols it becomes possible to import information from the outside world, like who won a specific soccer game or baseball match, with betting smart contracts simply purchasing data on the outcome at the end of a game and paying out accordingly.

**Decentralized insurance:** Allowing smart contracts to purchase real world data also allows things like decentralized insurance, which until now has required a trusted central authority. With ORAO it becomes possible to set up an insurance smart contract that calculates fair fees and payouts based on historic data, and then checks at predetermined times or on request whether conditions for payout have been met.

For an example we will look at the case of a farmer wishing to purchase drought insurance. The insurance smart contract can request historic precipitation data and trends for the area where the farmer operates, and set fees and payout amounts accordingly. At the end of the contract period the contract can then purchase data on how much precipitation the area has received during the period of time the farmer bought insurance for. If it has rained enough, the farmer is assumed to have secured a good harvest. However, if precipitation levels did not reach some previously agreed upon threshold the contract acknowledges a drought and the farmer receives his payout immediately. Removing the middle man of an insurance company (And claims adjusters) makes the process much faster, and also more transparent and reliable. It either rained in the farmer's area or it did not.

Similarly such smart insurance contracts can reach out for real estate price data, cost of replacing electronics, flight delays and cancellations, even cause of death in the case of life insurance.

**Financials:** In addition to the typical crypto price feeds that every oracle network supports, ORAO data providers can offer anything from stock and ETF performance history to property and car prices to ICO schedules.

**Cross-chain information gathering:** ORAO being based on Polkadot for cross-chain compatibility also means it becomes possible for smart contracts to request information from other chains, and from smart contracts on other chains, all without human intermediaries.

**Foreign Exchange:** As Blockchain and Smart Contracts see ever increasing adoption, it is easy to see how price data on fiat currencies will become as important as cryptocurrency price data, especially in DeFi, bank-less remittances, etc.

**Travel data:** Taking advantage of the decentralized nature of oracle systems, ORAO data providers can supply ads-b and other non-public flight data for private and corporate flights all across the world. They can also tap into train schedules, hotel prices and occupancy rates, 

**Arbitrary information verification:** Because any number of Data Protocols can be added, oracles on ORAO will be able to provide virtually any kind of information. As an example one of the first Data Protocols we enabled was for scouring information on movies from IMDB. If in ten years someone comes up with a smart contract that requires access to recreation or entertainment data like TV schedules or Netflix availability by region, ORAO oracles will be able to provide that.


# The ORAO Solution

This section describes the architecture of the ORAO platform, as divided into the four subsections; [*Predefined Data Protocols*](https://app.gitbook.com/@orao-nik/s/orao/the-orao-implementation/predefined-data-protocols), which allow for a much wider range of data products. [*Machine Learning with TensorFlow*](https://app.gitbook.com/@orao-nik/s/orao/the-orao-implementation/machine-learning-with-tensor-flow), which powers our proactive reputation system for enhanced security. [*Auction System and Reputation*](https://app.gitbook.com/@orao-nik/s/orao/the-orao-implementation/auction-system-and-reputation)*,* the nitty gritty of how data buyers and provider are matched. And [*Cross-Chain Interoperability with Polkadot*](https://app.gitbook.com/@orao-nik/s/orao/the-orao-implementation/cross-chain-interoperability-with-polkadot)*,* which should hopefully be self explanatory.


# Predefined Data Protocols

When data is transmitted through an oracle on ORAO, it is normalized to comply with one of our predefined Data Protocols. For example, a generic request for the state of Bitcoin trading would return:

* ```
  {
      "symbol":"BTC",
      "name":"Bitcoin",
      "price_usd":"27988.53",
      "price_btc":"1.00000000",
      "volume_usd":"52193908909.683",
      "marketcap_usd":"520178893106.43"
  }
  ```

But of course, financial data is already covered by multiple other oracle platforms. ORAO however offers a wide range of predefined Data Protocols, allowing for data markets for all kinds of information. For example, an insurance smart contract may need to request environmental data from local environmental sensors. Casting a wide net the smart contract might receive the following:

```
{
  "temperature_celsius": 10.53072,
  "temperature_celsius_raw": 14.03072,
  "temperature_fahrenheit": 62.5584,
  "temperature_tolerance": 0.2,
  "humidity": 51.67533,
  "humidity_tolerance": 2,
  "humidity_abs": 6.219711,
  "humidity_abs_tolerance": 0.251124,
  "gas_raw": 121,
  "gas_lpg": 1,
  "gas_co": 1,
  "gas_smoke": 4
}
```

Of course, there is some redundancy in the information, and the buyer may not have need of both temperature *and* humidity values. Thus it is possible to request more or less information.

ORAO supports the creation of new Data Protocols as demand is identified. Maybe there is demand for verification of arbitrary information like who starred in a certain movie. To show the range of our Data Protocols we have already created one for this exact purpose - connecting to IMDB to draw information from their databases on demand.


# Machine Learning with Tensor Flow

One of the issues ORAO was created to solve is earlier oracle platforms' reliance on reputation systems that trust data providers until they are actually caught supplying false information. While these systems do require providers to stake tokens which they may lose, there is always the risk of an attacker who invests some time into securing a good reputation, then lies in wait for an opportunity to trick for example a smart contract into making the wrong decision, allowing the attacker to steal funds of greater value than the stake they lose as a penalty for lying.

ORAO's solution is the introduction of Machine Learning. Using TensorFlow we are able to maintain neural nets that calculate trust scores based in part on past performance, but also on the trustworthiness of the data provided on its own merit, judged against a backdrop of similar data provided in the past, both by that particular data provider and recent data provided by others.

ORAO's neural nets are initially trained by our developers, using historical data and trusted sources. This allows the neural nets to rate data providers fairly from day 1, including providers for new Data Protocols who may not yet have competitors. Note that this is not an oracle service provided by ORAO itself, it merely serves as a backbone for ensuring reliability and trust on a platform where new Data Protocols are expected to to appear over time.


# Auction System and Reputation

ORAO's reputation system is designed to produce a gradient. That is to say, it doesn't simply lump data providers into 'good' and'bad'/untrustworthy. Our neural nets judge providers on things like the freshness of data being streamed, meaning if one data provider has significantly higher ping than others, thier score will end up slightly lower because the data they provide is not as optimal as it could be.

Of course, for the vast majority of buyers receiving data that is two seconds out of date is not going to be an issue, especially not when block time is taken into account, or if the data requested is not time sensitive. The outcome of a completed hockey match is not going to change.

For some buyers, however, tiny differences may well matter. With this spread of needs in mind, ORAO's reputation system allows data buyers to set thresholds for what minimum scores providers must meet to take on their requests. At the same time the network is set up to match buyers with the cheapest data providers who match their criteria. As a result, a market is created where the highest quality data providers are able to charge more for their services, while less optimized providers are still able to compete for buyers who are not willing to pay higher premiums.

Unlike some oracle networks, on Orao data providers with larger stakes do not receive an unfair boost to their reputation through the stake they have, instead suggested providers within each tier are sorted by their stake - larger stake, more visibility. We believe this to be the optimal compromise between incentivizing large stakers to keep their whole stake and protecting smaller network participants from wealthy holders controlling the network. No amount of higher staking will raise your reputation if a smaller staker is providing better data than you, however an incentive does exist to keep your stake in the form of greater visibility within each tier.


# Cross-Chain Interoperability with Polkadot

With the explosive growth of blochain since its invention, and especially in the last few years, it has become untennable for oracle platforms to only support a single chain. One of the most restrictive limitations on earlier platforms is that they chose one chain (Typically Ethereum) and build for oracles to only ever operate on that one chain.

We believe Ethereum has a strong future, we really do. But we also look around and see that it is never going to be the only relevant base layer, especially with climbing network fees and with Ethereum 2.0 still years away from relieving congestion on the original chain.

So. We have built ORAO from the ground up for Polkadot, where we will run a parathread. This allows ORAO to ensure the fastest possible, most secure and best scaling cross-chain transfers and operations. Through the native interoperability of Polkadot we can implement oracle gateways on Ethereum, Cosmos, EOS and any number of other blockchains as we see demand. Currently the most popular blockchain for dApp development is Ethereum (See the recent explosion in DeFi applications) - which we naturally support from the get go. With the scaling difficulties and high network fees currently experienced on Ethereum, however, we believe demand for oracles will increase on other blockchains as well, and by positioning ourselves on Polkadot it will be easy for Orao to expand wherever demand may arise.


# Token Economics

The ORAO token and its role in the data marketplace

The ORAO utility token is the heart's blood of the ORAO network. It serves as its central unit of staking and exchange. Anyone wishing to become a data provider or data buyer must stake an amount of tokens, and payments for data are made with the token as well.

We have made the conscious decision not to allow data providers to artificially inflate their reputation score by holding more tokens. A top score should indicate the best possible data reliability, and nothing else. However, an incentive does exist for large holders to keep their full stake in the form of increased visibility within the provider's own tier.

The ORAO network operates cross-chain through Polkadot, thus data providers must stake tokens on every chain they wish to operate on. A data provider who wants to sell the same data on both Ethereum and EOS, for example, must stake tokens on both chains.

#### Token Supply, Distribution, Vesting

![](https://936946365-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MPg3aGCWRvzOhOSB828%2F-MW4SL_St4WZQW_yVSNk%2F-MW4UX3P5An-l_irfz6S%2FTokenomics%20distribution.png?alt=media\&token=bef84a12-1548-4d56-a380-872f3b0f98d8)

There will be a total supply of 1,000,000,000 ORAO tokens. 290 million of these were allocated to private sales in the early days of the project, with another 66 million earmarked for the presale. Network incentives exist in the form of 200 million tokens in Validator rewards, 60 million in Customer rewards, as well as 50 million set aside to ensure liquidity and 33 million in reserves. The Team and Advisor/Partner allocations are 200 and 100 million, respectively.

![](https://936946365-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MPg3aGCWRvzOhOSB828%2F-MW4WQ6wcTw9SRXoTC1b%2F-MW4Xaop8npOVffD9h6W%2Fimage.png?alt=media\&token=3bb240c8-a4a4-4197-837c-accabac8277e)

Network incentives and team/advisor allocations are subject to a 3 to 18 month lockup, as shown above. They are further subject to a vesting period, as are private sale tokens.

Immediately following the Token Generation Event the circulating supply will be 36,250,000 tokens. For the purpose of token sales the market cap evaluation at that time will be a modest $543,750, with a token price of $0.015 USD. However only the market can determine prices from there.


# Data Providers

This section is not yet public.


# Development Milestones

**Changelog Apr 15th 2021**

* **app updates**
  * ui / ux
  * auctions logic upgrades
  * auctions functionality upgrades

**Changelog Mar 31st 2021**

* blockchain node upgrades
  * big data storage
  * parathread (foundations)
  * upgrade substrate to v3 ✓
* IPFS upgrades
* blockchain multiNode upgrades
* dataProtocol logic upgrades
* updates to ethereum node
* swagger everything that needs swaggering :)

**Changelog Mar 5th 2021**

* implement new website design ✓ desktop ✓ tablet ✓ mobile ✓
* new brand book ✓
* implement new app design and UI
* ML reputation scores ✓
* basic Node compute ✓
* compute support ✓
* fast-gateway ingestor updated: if a dataprovider node (DPnode) has tech issues delivering data to the ingestor provide an analytical dataset with 10s, 60s, 5m, 10m, 30m, 1h, 6h, 12h, 24h averages. The same is applied when the DPnode refresh time is lower than the requested refresh time ✓

\---------------------------------------------------------

#### Milestone #3 Feb 2nd 2021

The nodes need to be able to get data as-it-happens and can't rely on pulling the data. We want to add live data streaming through websockets. At this point compute is available (outlier, pricing bands etc.) and is specific per data protocol. Most, if not all of the requests from data clients will be implemented, whether they are data protocol support or compute functionalities

* data streaming through websockets ✓
* frontend admin panel for auctions / bids / oracles / profiles ✓
* frontend signup/login ✓
* frontend add oracles / config file generator / private key generator ✓
* Code base migration (rust where it makes sense) ✓
* dataProvider node updates ✓
  * protocols ✓
  * serve or pull mechanism ✓
  * update notification func ✓
* better data protocol definition and flexibility ✓
* data gateway upgrades (rust/warp) ✓

*In progress*

* frontend bids / auctions
* cumulus integration parachain/parathread
* new UI and UX
* additional documentation and examples

#### Milestone #2 Jan 15th 2021

Support added for different data protocols:

* additional data protocol code pushed (named OraoSensors - class MQTT) ✓
* datasource demo wss server for IoT ✓
* "generic" dataprovider for wss (websockets) sources ✓
* sports data protocol
* movies data protocol based on IMDB ✓

Plus a scattering of other improvements:

* tested new data protocol ingestion ✓
* data gateway in rust, response times lowered to 5ms ✓
* fast scaling node updates ✓
* blockchain explorer ✓

We may add sports data and movies data sources at this point as well. Other than the data agnostic protocol support, an important part of this milestone is provider reputation scoring. This means we will have trained models for the data protocols we demo and this will be a part of data provider reputation scoring. During this milestone we will work towards moving nodejs codebase to more performance-oriented languages and optimizing topology.

#### Milestone #1 Dec 19th 2020

* The PoC reads the data from the external data source (coin.market API in this case) as a dataProvider node. The data providers can get the docker images at <https://hub.docker.com/repository/docker/oraodev/dataprovider>. ✓
* This data is sent to the gateway which transforms the data based on conditions (floats, rounds etc. in this case), it adds mock provider and data scores. ✓
* At this point, the data is available to the orao offchain worker which acts as a passive reader. It launches on every block, checks the gateway and writes the update (if there is an update). ✓

####


# Media

##