Oracle Networks: A Deep Dive Into Data Bridging Solutions

A blockchain oracle is a third party data-feed that serves as a bridge between blockchains and data that exists off-chain. As the crypto industry surges with an influx of builders and ideologists, the need for a reliable oracle becomes increasingly urgent. The reliability of the data presented by a smart contract can make or break the level of trust on the client side for a new project.

 In the ‘real’ world of centralized governance, when you form a contract with predetermined conditions for a transfer of value, you have an arbitrator. An arbitrator validates whether the terms and conditions are met before the transfer. Unfortunately, due to the consensus mechanism of different blockchains, smart contracts structurally have no way to directly interact with external data providers to validate the outcome of non-blockchain-related events. This gap in data accessibility limits the capabilities of blockchain adaptability and growth. 

Oracles are an absolute necessity for the growth and reliability of smart contracts, especially within the decentralized finance space. It’s arguable that the massive growth in blockchain adaptability over the last few years is attributable to the reliability of data transfer that oracles have brought. With that being said, oracles have one major problem, referred to as the oracle problem. 

There are several security risks with oracles. Most smart contracts rely on outside data to execute properly. The data that the oracle receives is pulled from an off-chain centralized API or data feed. This is ironic relative to the decentralized nature of blockchain technology. It leaves room for corruption and exploitation. In a nutshell, the oracle problem proposes the following question: How do you bring off-chain data onto the blockchain in a decentralized, reliable, and secure way?

The ‘Oracle Problem’ is a construct of overgeneralized issues, with current solutions limited to the scope of the problem viewed by their proposers. In this article, we dive into the different oracle models that currently exist, and how they propose to address these issues. 

Figure A. An overview of Chainlink’s internal architecture

 Chainlink is a decentralized network of oracles that provides smart contracts with the definitive truth about the external world, enabling them to produce and present reliable outcomes. Unlike centralized oracles, Chainlink pulls data from its decentralized network of thousands of oracles (DONs), which are operated by independent, security-reviewed, and performance-proven Node Operators. Chainlink is different from other oracles because its inherent architecture allows for a focus on data validation, and consensus about individual off-chain values. They do this through a combination of multiple security techniques that promote a trustless, reliable, and secure data service.

Chainlink connects any blockchain to any input and output.

The diverse use-cases of smart contracts create problems that are equally  immense and quickly growing. It would be naive to assume that there could be a single means of securing and validating every use case. This brings up a justifiable point; if we know that a single oracle model can’tprovide the level of flexibility required by smart contracts, then it’s only natural to think that it’s only a matter of time before competitors start to spring up in different verticals. While this is true, Chainlink’s heterogeneous architecture enables developers to create their own solutions, maximizing the amount of value Chainlink can capture. Chainlink currently secures a total value of $64 Billion and is being utilized by several different niches. For a more detailed list of current use-cases, read more here.

A monolithic architecture utilizes a single collection of nodes work in conjunction, using the same validation structure for computational processes. This is similar to how the consensus mechanism of a blockchain works, where all the nodes in the network execute a replicable set of operations. This model makes sense for validating signatures and hashing blocks, but not so much in the realm of oracles. If an oracle were to deploy this architecture, its scalability, efficiency, and security  become extremely limited. Being limited to one oracle network model creates a single point of failure, introducing security risks. Additionally, because off-chain data feeds are often paywalled, and a monolithic approach would require every node to access the same data packages, it would not be economically feasible. 

Chainlink is not a monolithic oracle network; it utilizes a permissionless framework. It is a highly customizable and modular network that allows any number of individual oracle networks to be created with specific parameters. These different network models run simultaneously and are independent of each other. Utilizing a design that eliminates standardization across all oracle networks allows Chainlink to scale horizontally by enabling node operators to have the capability to specialize in specific types of services—creating a competitive environment that naturally incentivizes growth and innovation. 

The advantage of Chainlink’s modular design is that it inherits the ability for each component of the protocol to be upgraded. This further supports the point that is arguably the easiest way to evaluate Chainlink's future; it's, by design, scalable.

With the recent introduction of Off-Chain Reporting (OCR), Chainlink’s price feed networks can now bypass the issue that comes with Ethereum-based protocols. Ethereum is an expensive network to interact with. As a result, financial problems can arise given how computationally expensive maintaining real-time data feeds is. OCR solves this by taking these expensive on-chain computations and offloading them off-chain into what is essentially a coetaneous network. In doing this, OCR reduces operating costs by up to 90%, and enables smart contracts to perform more advanced computations. Additionally, with the help of OCR, the amount of real-world data available to smart contracts is massively increased, leading to an acceleration in blockchain innovation. 

A significant downside of distributed blockchain ledger technology is a lack of co-operability. Instead, each blockchain network functions in isolation, and, without cross-chain technology, would have no way to interact. Chainlink’s CCIP looks to help close the gap between chains by leveraging Chainlink’s architecture to introduce decentralized interchain messaging and secure cross-chain token movements. 

In legacy systems, it’s standard that multiple coding languages are used in conjunction (e.g., HTML websites typically consist of HTML, JS, CSS, and Python). CCIP brings an analagous standard to the blockchain, enabling developers to build in a more familiar environment by pulling in any code they deem optimal for their smart contracts, regardless of the chain the code originates from. 

In August 2021, Chainlink’s CEO Sergey Nazarov introduced CCIP in a keynote presentation. He stated that CCIP helps accommodate the cross-chain interoperability needs of CeFi services as demand for DeFi access grows. During this keynote talk, Celsius Network’s co-founder Alex Mashinsky referred to CCIP as a long-term solution for CeFi service providers to guarantee the scalability of their services through an all-inclusive multi-chain DeFi integration.

If you’ve made it this far, you should clearly understand that the amount of network value Chainlink can capture is immense. At the end of the day, what everyone is looking to understand is: How much of that value is captured by Chainlink’s native token, $LINK?

Just as $ETH is the fuel that powers Ethereum, $LINK is an ERC677 utility token used to secure and bootstrap the growth of the Chainlink Network. The $LINK token has three main use-cases:

Implicit-Incentive Framework (Implicit Staking)

The first crypto-economic security element introduced with Chainlinks staking is their implicit-incentive framework (IIF) or Implicit Staking. IIF is a mechanism implemented to help enforce crypto-economic security for the Chainlink Network. The dynamic of implicit staking has been proven effective by successfully securing Bitcoin and other blockchain networks for several years. 

By having every single node operator on the Chainlink network get paid in $LINK tokens, a positive feedback loop is created where there’s a financial incentive for nodes to perform honestly. Furthermore, $LINK tokenomics make $LINK a proxy for measuring the value of the network's transferred data. Any malicious act will cause the network's reputation to decrease, consequently decreasing the value of $LINK and the value of node incentives. 

Explicit Staking

Explicit staking is a crypto-economic mechanism that aims to improve the security and reliability of oracle networks. This is accomplished by leveraging the $LINK requirement for node operators to use $LINK as a security deposit to ensure that the transferred data is properly delivered. Depending on the API data request, there will be a predetermined “penalty fee” taken from the node operator’s collateral if it fails to deliver on its service request.  

The main difference between Implicit staking and explicit staking is that explicit staking creates guarantees about fulfilling specific individual service agreements. In contrast, implicit staking guarantees are generalized toward the functions of a protocol.

Application Programming Interfaces (APIs) are a standard in legacy tech for the development of software applications. Founded in December, 2020, API3 is a platform that enables data providers to bridge their existing web2 API onto the blockchain. What others call the ‘Oracle Problem,’ API3 calls the API Connectivity Problem. 

As mentioned earlier, the Oracle Problem is a generalized abstraction of problems that refer to the transparency, vulnerability, and decentralization of data bridging solutions on the blockchain. API3 believes that the root of the problem is that there is no inherent way for existing APIs to be connected to the blockchain. With that in mind, their oracle solution aims to directly bridge the gap left by developers being unable to access traditional APIs by utilizing an innovation called Airnodes. 

Airnodes

Not to be confused with a blockchain node, Airnodes are a piece of cloud service infrastructure that allows data providers to deploy their existing web2 API onto the blockchain, creating what API3 calls a dAPI (Decentralized API). To understand the advantages of this new framework, we must first understand the difference between first-party data and third-party data.

First-Party Data vs. Third-Party Data

The distinction between First-Party oracles and Third-Party oracles is an important one to be made when evaluating the value of transmitted data. First-party oracles relay data directly from data providers. In contrast, third-party data introduces an intermediary that aggregates the first-party data and forwards it to the end-user (ownership vs. non-ownership). The thesis for API3 is that by eliminating oracle networks, and instead allowing data providers to run their own nodes, the quality of data will consequently be improved. Generally speaking, oracle networks have no incentives that force them to source higher quality data versus cheap and easily accessible data. 

At first glance, it’s easy to categorize this as a more centralized approach to bringing data onto the blockchain. However, after further research, I’ve concluded that there are a couple of key advantages to API3’s model versus oracle networks. 

Transparency

The irony here is that the entire premise of the blockchain’s distributed ledger technology is that it’s a transparent, publicly accessible ledger. Even so, over the years, DeFi has found itself in several situations where a lack of transparency becomes an issue. Such is the case with third-party data oracles. 

It would be difficult to state with certainty that existing oracle networks are sourcing cheap, low quality data. Herein lies the issue-there is no transparency in where the data being pulled into oracle networks originates. So, whether a group of oracle nodes is made up of multiple data sources of high or low quality, users are none the wiser. This is directly contrasted byAPI3’s model, where the nodes are run by public facing, reputable data providers. 

Security

Going back to transparency, oracle networks themselves aren’t individual data providers. A decentralized platform introduces new attack vectors, as data can be skewed by multiple bad actors working together. Furthermore, a particularly bad actor can execute what’s called a Sybil attack- An attack where trust can be built in the short term within multiple identities in order to establish a reputable record to optimize the reliability of an attack vector route. 

The two main options for recourse from a malicious data provider are service coverage by the API3 collateral pool (similar to Chainlink’s explicit staking, note that this hasn’t been released yet). Additionally, there are potential legal remedies directly against the public data provider. However, inserting a network of third-party oracles between the data source and the users removes the data provenance. This means that the legal remedies against data sources are no longer a viable option for users. 

Ease of Use

Airnodes are a serverless oracle node that was designed with simplicity in mind. As a result, the level of involvement between the deployment of an Airnode and an API provider is minimal and requires very little technical understanding. In fact, data providers don't have to interact with the blockchain or handle cryptocurrencies at all. With its simplistic design, API3 is a more straightforward proxy for tradfi data providers who have yet to dabble in crypto, increasing the potential for new forms of data being bridged into the blockchain. 

Unlike $LINK, which is a utility token, $API3 is a governance token that has three core use-cases.

Staking

API3 incentivizes staking by granting inflationary rewards. This is implemented to increase the amount of $API3 tokens that are used to secure the network, ultimately attributing to the network's growth. The increase in supply is offset by the burning mechanism, in which the API3 DAO requires users to burn API3 tokens to gain access to data services. 

Collateral

Similar to Chainlink’s explicit staking mechanism, $API3 tokens will be used as a form of collateral to guarantee services. Participants are financially incentivized to ensure a quality, honest service. API3 has partnered with Kleros, a decentralized arbitration dispute service, in order to decentralize their insurance services and provide guarantees in the form of insurance claims. These insurance claims are paid out in the native $API3 token, ultimately introducing additional sell-pressure  given the assumption that users will sell their tokens immediately to recover losses from damages.

Band Protocol is a cross-chain decentralized oracle platform that aims to bring high-quality data onto the blockchain. Band Protocol is second to Chainlink in integrations, and has seen up to $16.73 Billion in Total Value Secured (TVS). The protocol leverages Bandchain, an independent Cosmos-SDK-based blockchain network that was designed to be a blockchain-agnostic network for handling oracle computations. While there are similarities between Band Protocol and Chainlink, key architectural distinctions differentiate them.

The Cosmos SDK is a generalized framework that facilitates the creation of modular blockchain applications on top of Cosmos Tendermint BFT consensus mechanism. Band Protocol leverages Cosmos innovative network architecture by creating its own SDK-Based blockchain, BandChain. Band Protocol’s oracle differentiates itself from other oracle solutions in three ways:

Speed & Cost - Without additional upgrades, the scalability of an oracle solution is bottlenecked by the native blockchain that they’re based on (e.g., node operators on Ethereum are likely not profitable due to expensive gas fees). Band protocol addresses this by designing Bandchain specifically for oracle computational requirements. Similar to Chainlink, when a smart contract requires external data from Band protocol, they’re required to pay node operators in the oracle’s native token. However, with Band protocol being hosted on Cosmos, these transactions are faster and more cost-efficient relative to an oracle like Chainlink, which is hosted on Ethereum and has speed limitations due to factors such as network congestion.

Interoperability -Band protocol is blockchain-agnostic; it is able to query data seamlessly with any IBC-compatible blockchain. This has enabled Band to gain a first-mover advantage on multiple blockchains such as Avalanche, Celo Network, Oasis Network, Optimism, etc. 

Flexibility - Like Chainlink, Band Protocol’s data source scripts are very customizable and flexible to meet a smart contract’s requirements. Furthermore, participants can program an oracle script in multiple programming languages, enabling a fundamentally appealing developer environment. 

The last oracle that we’ll mention in this paper is a new, up-and-coming protocol, Pyth Network. Pyth is a Solana-based oracle network with similar ideologies to API3. By utilizing Solana’s architecture, Pyth can reliably stream data at a sub-second latency (currently 400ms), with relatively low costs compared to its competitors. Furthermore, instead of using third-party data (like Chainlink), Pyth incentivizes market participants(Market Makers, exchanges, hedge funds, etc.)to provide pricing data directly on-chain. With that in mind, they're aiming to be a first-mover in their target market of first-party on-chain data aggregation feeds. 

As we know, there’s a lack of transparency with third-party data oracles. Additionally, regardless of the number of nodes being run on an oracle network, if the data is coming from the same provider, there are significant risks regarding data accuracy. These risks are especially apparent in TWAP oracle models used by AMM Dexs(such as Uniswap), as relying on data from a single exchange introduces a lack of market coverage that doesn’t consider the liquidity fragmentation across different pairs. Pyth addresses these underlying oracle issues by:

Confidence Interval - Publishers will generally be market participants and financial institutions. Different exchanges and platforms have access to different types of data and may use different methods of pricing assets. Pyth networks require publishers to report a confidence interval for each price they publish. The confidence interval represents the perceived strength of that input data as per the publisher. The confidence intervals among publishers are then aggregated, creating an aggregated confidence interval for each price. Not only is this a benefit to the consumer, who can then view the aggregated confidence levels and scale accordingly, but it also enables an environment where publishers are transparent regarding the varying levels of accuracy between different priced assets, leading to a lower chance of being slashed. Refer here for further reading on confidence intervals. 

Aggregated price feeds  - Pyth network’s price feed provides complete coverage by aggregating all of the publisher price data and weighing each data point. Publish weights are determined by the data staking mechanism and are automatically rebalanced weekly. Combined with aggregated confidence intervals, Pyth’s price feeds provide a future-proof oracle mechanism that automatically tracks new liquidity fragmentation across publishers. To read more about how staking weights work, including the underlying math, it is explained in great detail within Pyth’s whitepaper on page 9, section 4.1. 

Price & Confidence Interval EMA  - Pyth Network provides a time-weighted EMA for both aggregated prices and time intervals. Information regarding Pyth’s implementation can be found here, along with further reading on Price/Confidence EMA here.

While Pyth and API3 both subscribe to the idea that first-party data is a more reliable framework, each protocol leverages its solution for different purposes.  To better understand how Pyth intends to use its architecture to scale its solution, we must understand who the network participants are and how Pyth intends to incentivize them. 

Publishers - Data providers, typically exchanges, market makers, financial institutions, or any entity that regularly prices assets. Similar to other oracle models, data providers capture a portion of the fees generated by the products they price. The appeal is that the Pyth network is introducing an additional revenue stream for market participants, receiving payments for sharing data that they would already be generating within their everyday operations. Pyth network intends to utilize its own version of explicit staking; Publishers are required to stake $PYTH tokens as collateral; if their data deviates away from the truth, the deposited collateral gets slashed. A list of current publisher partners can be found here

Consumers - Users who contract Pyth Network for their data needs. Users can be both on-chain and off-chain applications. Consumers pay for Data services which are then distributed to Publishers and Delegators (mentioned below). In doing so, consumers are hedging their risk for using Pyth price feeds as any oracle issues that occur would be reimbursed from Delegator/Publisher collaterals. Unlike Chainlink, consumers aren’t required to pay for their service agreement in the native oracle token. Instead, the fees can be paid in any governance-approved asset. The benefit of having multiple forms of payment versus native token payments is that it eliminates the sell-pressure that comes from node operators' market-selling tokens, weighing down the price.

Delegators - Token holders who are incentivized to stake their $PYTH tokens into the network by earning a portion of fees paid out by consumers(reward distribution is initially set at 80/20, delegators are the majority). This rewards mechanism is referred to as ‘Data staking.’ The tokens locked up by delegators serve as collateral that guarantees data quality relayed on the network. While it may be more attractive for a delegator to delegate all of his stakes to a long-standing reputable publisher, delegators are encouraged to diversify their delegation between publishers to further increase general network security. In a case where a consumer is affected by inaccurate data, they are able to generate a claim. The governance-voted results of a claim determine whether delegators' stakes get slashed. There are currently no APR projections as staking isn’t live. However, one could assume that the incentives would have to be sustainable, and significantly greater than the perceived value at risk. For more details regarding Pyth’s reward distribution system, refer to page 8, section 4 of Pyth Network’s whitepaper. For more information about their claims system, which utilizes HUMAN protocol,  refer to page 6, section 3.1.

This report is for informational purposes only and is not investment or trading advice. The views and opinions expressed in this report are exclusively those of the author, and do not necessarily reflect the views or positions of The TIE Inc. The Author may be holding the cryptocurrencies or using the strategies mentioned in this report. You are fully responsible for any decisions you make; the TIE Inc. is not liable for any loss or damage caused by reliance on information provided. For investment advice, please consult a registered investment advisor.