Oracles

Oracles are applications that produce data feeds that make offchain data sources available to the blockchain for smart contracts. This is necessary because Ethereum-based smart contracts cannot, by default, access information stored outside the blockchain network.

Giving smart contracts the ability to execute using offchain data extends the utility and value of decentralized applications. For instance, onchain prediction markets rely on oracles to provide information about outcomes that they use to validate user predictions. Suppose Alice bets 20 ETH on who will become the next U.S. President. In that case, the prediction-market dapp needs an oracle to confirm election results and determine if Alice is eligible for a payout.

Prerequisites

This page assumes the reader is familiar with Ethereum fundamentals, including nodes, consensus mechanisms, and the EVM. You should also have a good grasp of smart contracts and smart contract anatomy, especially .

What is a blockchain oracle?

Oracles are applications that source, verify, and transmit external information (i.e. information stored offchain) to smart contracts running on the blockchain. Besides “pulling” offchain data and broadcasting it on Ethereum, oracles can also “push” information from the blockchain to external systems, e.g., unlocking a smart lock once the user sends a fee via an Ethereum transaction.

Without an oracle, a smart contract would be limited entirely to onchain data.

Oracles differ based on the source of data (one or multiple sources), trust models (centralized or decentralized), and system architecture (immediate-read, publish-subscribe, and request-response). We can also distinguish between oracles based on whether they retrieve external data for use by onchain contracts (input oracles), send information from the blockchain to the offchain applications (output oracles), or perform computational tasks offchain (computational oracles).

Why do smart contracts need oracles?

Many developers see smart contracts as code running at specific addresses on the blockchain. However, a more general view of smart contracts is that they are self-executing software programs capable of enforcing agreements between parties once specific conditions are met - hence the term “smart contracts.”

But using smart contracts to enforce agreements between people isn't straightforward, given that Ethereum is deterministic. A deterministic systemopens in a new tab is one that always produces the same results given an initial state and a particular input, meaning there is no randomness or variation in the process of computing outputs from inputs.

To achieve deterministic execution, blockchains limit nodes to reaching consensus on simple binary (true/false) questions using only data stored on the blockchain itself. Examples of such questions include:

• “Did the account owner (identified by a public key) sign this transaction with the paired private key?”
• “Does this account have enough funds to cover the transaction?”
• “Is this transaction valid in the context of this smart contract?”, etc.

If blockchains received information from external sources (i.e. from the real world), determinism would be impossible to achieve, preventing nodes from agreeing on the validity of changes to the blockchain’s state. Take for example a smart contract that executes a transaction based on the current ETH-USD exchange rate obtained from a traditional price API. This figure is likely to change frequently (not to mention that the API could get deprecated or hacked), meaning nodes executing the same contract code would arrive at different results.

For a public blockchain like Ethereum, with thousands of nodes around the world processing transactions, determinism is critical. With no central authority serving as a source of truth, nodes need mechanisms for arriving at the same state after applying the same transactions. A case whereby node A executes a smart contract’s code and gets "3" as a result, while node B gets "7" after running the same transaction would cause consensus to break down and eliminate Ethereum’s value as a decentralized computing platform.

This scenario also highlights the problem with designing blockchains to pull information from external sources. Oracles, however, solve this problem by taking information from offchain sources and storing it on the blockchain for smart contracts to consume. Since information stored onchain is unalterable and publicly available, Ethereum nodes can safely use the oracle imported offchain data to compute state changes without breaking consensus.

To do this, an oracle is typically made up of a smart contract running onchain and some offchain components. The onchain contract receives requests for data from other smart contracts, which it passes to the offchain component (called an oracle node). This oracle node can query data sources—using application programming interfaces (APIs), for example—and send transactions to store the requested data in the smart contract's storage.

Essentially, a blockchain oracle bridges the information gap between the blockchain and the external environment, creating “hybrid smart contracts”. A hybrid smart contract is one that functions based on a combination of onchain contract code and offchain infrastructure. Decentralized prediction markets are an excellent example of hybrid smart contracts. Other examples might include crop insurance smart contracts that pay out when a set of oracles determine that certain weather phenomena have taken place.

What is the oracle problem?

Oracles solve an important problem, but also introduce some complications, e.g.:

• How do we verify that the injected information was extracted from the correct source or hasn’t been tampered with?

• How do we ensure that this data is always available and updated regularly?

The so-called “oracle problem” demonstrates the issues that come with using blockchain oracles to send inputs to smart contracts. Data from an oracle must be correct for a smart contract to execute correctly. Further, having to ‘trust’ oracle operators to provide accurate information undermines the 'trustless' aspect of smart contracts.

Different oracles offer different solutions to the oracle problem, which we explore later. Oracles are typically evaluated on how well they can handle the following challenges:

1. Correctness: An oracle should not cause smart contracts to trigger state changes based on invalid offchain data. An oracle must guarantee authenticity and integrity of data. Authenticity means the data was gotten from the correct source, while integrity means the data remained intact (i.e. wasn’t altered) before being sent onchain.

2. Availability: An oracle should not delay or prevent smart contracts from executing actions and triggering state changes. This means that data from an oracle must be available on request without interruption.

3. Incentive compatibility: An oracle should incentivize offchain data providers to submit correct information to smart contracts. Incentive compatibility involves attributability and accountability. Attributability allows for linking a piece of external information to its provider, while accountability bonds data providers to the information they give, so they can be rewarded or penalized based on the quality of information provided.

How does a blockchain oracle service work?

Users

Users are entities (i.e., smart contracts) that need information external to the blockchain to complete specific actions. The basic workflow of an oracle service starts with the user sending a data request to the oracle contract. Data requests will usually answer some or all of the following questions:

1. What sources can offchain nodes consult for the requested information?

2. How do reporters process information from data sources and extract useful data points?

3. How many oracle nodes can participate in retrieving the data?

4. How should discrepancies in oracle reports be managed?

5. What method should be implemented in filtering submissions and aggregating reports into a single value?

Oracle contract

The oracle contract is the onchain component for the oracle service. It listens for data requests from other contracts, relays data queries to oracle nodes, and broadcasts returned data to client contracts. This contract may also perform some computation on the returned data points to produce an aggregate value to send to the requesting contract.

The oracle contract exposes some functions which client contracts call when making a data request. Upon receiving a new query, the smart contract will emit a log event with details of the data request. This notifies offchain nodes subscribed to the log (usually using something like the JSON-RPC eth_subscribe command), who proceed to retrieve data defined in the log event.

Below is an example oracle contractopens in a new tab by Pedro Costa. This is a simple oracle service that can query offchain APIs upon request by other smart contracts and store the requested information on the blockchain:

1pragma solidity >=0.4.21 <0.6.0;
2
3contract Oracle {
4  Request[] requests; //list of requests made to the contract
5  uint currentId = 0; //increasing request id
6  uint minQuorum = 2; //minimum number of responses to receive before declaring final result
7  uint totalOracleCount = 3; // Hardcoded oracle count
8
9  // defines a general api request
10  struct Request {
11    uint id;                            //request id
12    string urlToQuery;                  //API url
13    string attributeToFetch;            //json attribute (key) to retrieve in the response
14    string agreedValue;                 //value from key
15    mapping(uint => string) answers;     //answers provided by the oracles
16    mapping(address => uint) quorum;    //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted)
17  }
18
19  //event that triggers oracle outside of the blockchain
20  event NewRequest (
21    uint id,
22    string urlToQuery,
23    string attributeToFetch
24  );
25
26  //triggered when there's a consensus on the final result
27  event UpdatedRequest (
28    uint id,
29    string urlToQuery,
30    string attributeToFetch,
31    string agreedValue
32  );
33
34  function createRequest (
35    string memory _urlToQuery,
36    string memory _attributeToFetch
37  )
38  public
39  {
40    uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
41    Request storage r = requests[length-1];
42
43    // Hardcoded oracles address
44    r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
45    r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
46    r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;
47
48    // launch an event to be detected by oracle outside of blockchain
49    emit NewRequest (
50      currentId,
51      _urlToQuery,
52      _attributeToFetch
53    );
54
55    // increase request id
56    currentId++;
57  }
58
59  //called by the oracle to record its answer
60  function updateRequest (
61    uint _id,
62    string memory _valueRetrieved
63  ) public {
64
65    Request storage currRequest = requests[_id];
66
67    //check if oracle is in the list of trusted oracles
68    //and if the oracle hasn't voted yet
69    if(currRequest.quorum[address(msg.sender)] == 1){
70
71      //marking that this address has voted
72      currRequest.quorum[msg.sender] = 2;
73
74      //iterate through "array" of answers until a position if free and save the retrieved value
75      uint tmpI = 0;
76      bool found = false;
77      while(!found) {
78        //find first empty slot
79        if(bytes(currRequest.answers[tmpI]).length == 0){
80          found = true;
81          currRequest.answers[tmpI] = _valueRetrieved;
82        }
83        tmpI++;
84      }
85
86      uint currentQuorum = 0;
87
88      //iterate through oracle list and check if enough oracles(minimum quorum)
89      //have voted the same answer as the current one
90      for(uint i = 0; i < totalOracleCount; i++){
91        bytes memory a = bytes(currRequest.answers[i]);
92        bytes memory b = bytes(_valueRetrieved);
93
94        if(keccak256(a) == keccak256(b)){
95          currentQuorum++;
96          if(currentQuorum >= minQuorum){
97            currRequest.agreedValue = _valueRetrieved;
98            emit UpdatedRequest (
99              currRequest.id,
100              currRequest.urlToQuery,
101              currRequest.attributeToFetch,
102              currRequest.agreedValue
103            );
104          }
105        }
106      }
107    }
108  }
109}
Prikaži sve
 Kopiraj

Oracle nodes

The oracle node is the offchain component of the oracle service. It extracts information from external sources, such as APIs hosted on third-party servers, and puts it onchain for consumption by smart contracts. Oracle nodes listen for events from the onchain oracle contract and proceed to complete the task described in the log.

A common task for oracle nodes is sending a HTTP GETopens in a new tab request to an API service, parsing the response to extract relevant data, formatting into a blockchain-readable output, and sending it onchain by including it in a transaction to the oracle contract. The oracle node may also be required to attest to the validity and integrity of submitted information using “authenticity proofs”, which we explore later.

Computational oracles also rely on offchain nodes to perform computational tasks that would be impractical to execute onchain, given gas costs and block size limits. For example, the oracle node may be tasked with generating a verifiably random figure (e.g., for blockchain-based games).

Oracle design patterns

Oracles come in different types, including immediate-read, publish-subscribe, and request-response, with the latter two being the most popular among Ethereum smart contracts. Here we briefly describe the publish-subscribe and request-response models.

Publish-subscribe oracles

This type of oracle exposes a “data feed” which other contracts can regularly read for information. The data in this case is expected to change frequently, so client contracts must listen for updates to the data in the oracle’s storage. An example is an oracle that provides the latest ETH-USD price information to users.

Request-response oracles

A request-response setup allows the client contract to request arbitrary data other than that provided by a publish-subscribe oracle. Request-response oracles are ideal when the dataset is too large to be stored in a smart contract’s storage, and/or users will only need a small part of the data at any point in time.

Although more complex than publish-subscribe models, request-response oracles are basically what we described in the previous section. The oracle will have an onchain component that receives a data request and passes it to an offchain node for processing.

Users initiating data queries must cover the cost of retrieving information from the offchain source. The client contract must also provide funds to cover gas costs incurred by the oracle contract in returning the response via the callback function specified in the request.

Centralized vs. decentralized oracles

Centralized oracles

A centralized oracle is controlled by a single entity responsible for aggregating offchain information and updating the oracle contract's data as requested. Centralized oracles are efficient since they rely on a single source of truth. They may function better in cases where proprietary datasets are published directly by the owner with a widely accepted signature. However, they bring downsides as well:

Low correctness guarantees

With centralized oracles, there's no way to confirm if the information provided is correct or not. Even "reputable" providers can go rogue or get hacked. If the oracle becomes corrupt, smart contracts will execute based on bad data.

Poor availability

Centralized oracles aren't guaranteed to always make offchain data available to other smart contracts. If the provider decides to turn off the service or a hacker hijacks the oracle's offchain component, your smart contract is at risk of a denial of service (DoS) attack.

Poor incentive compatibility

Centralized oracles often have poorly designed or non-existent incentives for the data provider to send accurate/unaltered information. Paying an oracle for correctness does not guarantee honesty. This problem gets bigger as the amount of value controlled by smart contracts increases.

Decentralized oracles

Decentralized oracles are designed to overcome the limitations of centralized oracles by eliminating single points of failure. A decentralized oracle service comprises multiple participants in a peer-to-peer network that form consensus on offchain data before sending it to a smart contract.

A decentralized oracle should (ideally) be permissionless, trustless, and free from administration by a central party; in reality, decentralization among oracles is on a spectrum. There are semi-decentralized oracle networks where anyone can participate, but with an “owner” that approves and removes nodes based on historical performance. Fully decentralized oracle networks also exist: these usually run as standalone blockchains and have defined consensus mechanisms for coordinating nodes and punishing misbehavior.

Using decentralized oracles comes with the following benefits:

High correctness guarantees

Decentralized oracles attempt to achieve correctness of data using different approaches. This includes using proofs attesting to the authenticity and integrity of the returned information and requiring multiple entities to collectively agree on the validity of offchain data.

Authenticity proofs

Authenticity proofs are cryptographic mechanisms that enable independent verification of information retrieved from external sources. These proofs can validate the source of the information and detect possible alterations to the data after retrieval.

Examples of authenticity proofs include:

Transport Layer Security (TLS) proofs: Oracle nodes often retrieve data from external sources using a secure HTTP connection based on the Transport Layer Security (TLS) protocol. Some decentralized oracles use authenticity proofs to verify TLS sessions (i.e., confirm the exchange of information between a node and a specific server) and confirm that the contents of the session were not altered.

Trusted Execution Environment (TEE) attestations: A trusted execution environmentopens in a new tab (TEE) is a sandboxed computational environment that is isolated from the operational processes of its host system. TEEs ensure that whatever application code or data stored/used in the computation environment retains integrity, confidentiality, and immutability. Users can also generate an attestation to prove an application instance is running within the trusted execution environment.

Certain classes of decentralized oracles require oracle node operators to provide TEE attestations. This confirms to a user that the node operator is running an instance of oracle client in a trusted execution environment. TEEs prevent external processes from altering or reading an application’s code and data, hence, those attestations prove that the oracle node has kept the information intact and confidential.

Consensus-based validation of information

Centralized oracles rely on a single source of truth when providing data to smart contracts, which introduces the possibility of publishing inaccurate information. Decentralized oracles solve this problem by relying on multiple oracle nodes to query offchain information. By comparing data from multiple sources, decentralized oracles reduce the risk of passing invalid information to onchain contracts.

Decentralized oracles, however, must deal with discrepancies in information retrieved from multiple offchain sources. To minimize differences in information and ensure the data passed to the oracle contract reflects the collective opinion of oracle nodes, decentralized oracles use the following mechanisms:

Voting/staking on accuracy of data

Some decentralized oracle networks require participants to vote or stake on the accuracy of answers to data queries (e.g., "Who won the 2020 US election?") using the network’s native token. An aggregation protocol then aggregates the votes and stakes and takes the answer supported by the majority as the valid one.

Nodes whose answers deviate from the majority answer are penalized by having their tokens distributed to others who provide more correct values. Forcing nodes to provide a bond before providing data incentivizes honest responses since they are assumed to be rational economic actors intent on maximizing returns.

Staking/voting also protects decentralized oracles from where malicious actors create multiple identities to game the consensus system. However, staking cannot prevent “freeloading” (oracle nodes copying information from others) and “lazy validation” (oracle nodes following the majority without verifying the information themselves).

Schelling point mechanisms

Schelling pointopens in a new tab is a game-theory concept that assumes multiple entities will always default to a common solution to a problem in absence of any communication. Schelling-point mechanisms are often used in decentralized oracle networks to enable nodes reach consensus on answers to data requests.

An early idea for this was SchellingCoinopens in a new tab, a proposed data feed where participants submit responses to "scalar" questions (questions whose answers are described by magnitude, e.g., "what is the price of ETH?"), along with a deposit. Users who provide values between the 25th and 75th percentileopens in a new tab are rewarded, while those whose values deviate largely from the median value are penalized.

While SchellingCoin doesn’t exist today, a number of decentralized oracles—notably Maker Protocol’s Oraclesopens in a new tab—use the schelling-point mechanism to improve accuracy of oracle data. Each Maker Oracle consists of an offchain P2P network of nodes ("relayers" and "feeds") who submit market prices for collateral assets and an onchain “Medianizer” contract that calculates the median of all provided values. Once the specified delay period is over, this median value becomes the new reference price for the associated asset.

Other examples of oracles that use Schelling point mechanisms include Chainlink Offchain Reportingopens in a new tab and Witnetopens in a new tab. In both systems, responses from oracle nodes in the peer-to-peer network are aggregated into a single aggregate value, such as a mean or median. Nodes are rewarded or punished according to the extent to which their responses align with or deviate from the aggregate value.

Schelling point mechanisms are attractive because they minimize onchain footprint (only one transaction needs to be sent) while guaranteeing decentralization. The latter is possible because nodes must sign off on the list of submitted responses before it is fed into the algorithm that produces the mean/median value.

Availability

Decentralized oracle services ensure high availability of offchain data to smart contracts. This is achieved by decentralizing both the source of offchain information and nodes responsible for transferring the information onchain.

This ensures fault-tolerance since the oracle contract can rely on multiple nodes (who also rely on multiple data sources) to execute queries from other contracts. Decentralization at the source and node-operator level is crucial—a network of oracle nodes serving information retrieved from the same source will run into the same problem as a centralized oracle.

It is also possible for stake-based oracles to slash node operators who fail to respond quickly to data requests. This significantly incentivizes oracle nodes to invest in fault-tolerant infrastructure and provide data in timely fashion.

Good incentive compatibility

Decentralized oracles implement various incentive designs to prevent Byzantineopens in a new tab behavior among oracle nodes. Specifically, they achieve attributability and accountability:

1. Decentralized oracle nodes are often required to sign the data they provide in response to data requests. This information helps with evaluating the historical performance of oracle nodes, such that users can filter out unreliable oracle nodes when making data requests. An example is Witnet’s Algorithmic Reputation Systemopens in a new tab.

2. Decentralized oracles—as explained earlier—may require nodes to place a stake on their confidence in the truth of data they submit. If the claim checks out, this stake can be returned along with rewards for honest service. But it can also be slashed in case the information is incorrect, which provides some measure of accountability.

Applications of oracles in smart contracts

The following are common use-cases for oracles in Ethereum:

Retrieving financial data

Decentralized finance (DeFi) applications allow for peer-to-peer lending, borrowing, and trading of assets. This often requires getting different financial information, including exchange rate data (for calculating the fiat value of cryptocurrencies or comparing token prices) and capital markets data (for calculating the value of tokenized assets, such as gold or the US dollar).

A DeFi lending protocol, for example, needs to query current market prices for assets (e.g., ETH) deposited as collateral. This lets the contract determine the value of collateral assets and determine how much it can borrow from the system.

Popular “price oracles” (as they are often called) in DeFi include Chainlink Price Feeds, Compound Protocol’s Open Price Feedopens in a new tab, Uniswap’s Time-Weighted Average Prices (TWAPs)opens in a new tab, and Maker Oraclesopens in a new tab.

Builders should understand the caveats that come with these price oracles before integrating them into their project. This articleopens in a new tab provides a detailed analysis of what to consider when planning to use any of the price oracles mentioned.

Below is an example of how you can retrieve the latest ETH price in your smart contract using a Chainlink price feed:

1pragma solidity ^0.6.7;
2
3import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";
4
5contract PriceConsumerV3 {
6
7    AggregatorV3Interface internal priceFeed;
8
9    /**
10     * Network: Kovan
11     * Aggregator: ETH/USD
12     * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331
13     */
14    constructor() public {
15        priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
16    }
17
18    /**
19     * Returns the latest price
20     */
21    function getLatestPrice() public view returns (int) {
22        (
23            uint80 roundID,
24            int price,
25            uint startedAt,
26            uint timeStamp,
27            uint80 answeredInRound
28        ) = priceFeed.latestRoundData();
29        return price;
30    }
31}
Prikaži sve
 Kopiraj

Generating verifiable randomness

Certain blockchain applications, such as blockchain-based games or lottery schemes, require a high level of unpredictability and randomness to work effectively. However, the deterministic execution of blockchains eliminates randomness.

The original approach was to use pseudorandom cryptographic functions, such as blockhash, but these could be manipulated by minersopens in a new tab solving the proof-of-work algorithm. Also, Ethereum’s switch to proof-of-stake means developers can no longer rely on blockhash for onchain randomness. The Beacon Chain’s RANDAO mechanismopens in a new tab provides an alternative source of randomness instead.

It is possible to generate the random value offchain and send it onchain, but doing so imposes high trust requirements on users. They must believe the value was truly generated via unpredictable mechanisms and wasn’t altered in transit.

Oracles designed for offchain computation solve this problem by securely generating random outcomes offchain that they broadcast onchain along with cryptographic proofs attesting to the unpredictability of the process. An example is Chainlink VRFopens in a new tab (Verifiable Random Function), which is a provably fair and tamper-proof random number generator (RNG) useful for building reliable smart contracts for applications that rely on unpredictable outcomes. Another example is API3 QRNGopens in a new tab that serves Quantum random number generation (QRNG) is a public method of Web3 RNG based on quantum phenomena, served with the courtesy of the Australian National University (ANU).

Getting outcomes for events

With oracles, creating smart contracts that respond to real-world events is easy. Oracle services make this possible by allowing contracts to connect to external APIs through offchain components and consume information from those data sources. For example, the prediction dapp mentioned earlier may request an oracle to return election results from a trusted offchain source (e.g., the Associated Press).

Using oracles to retrieve data based on real-world outcomes enables other novel use cases; for example, a decentralized insurance product needs accurate information about weather, disasters, etc. to work effectively.

Automating smart contracts

Smart contracts do not run automatically; rather, an externally owned account (EOA), or another contract account, must trigger the right functions to execute the contract’s code. In most cases, the bulk of the contract’s functions are public and can be invoked by EOAs and other contracts.

But there are also private functions within a contract that are inaccessible to others;, but that are critical to a dapp's overall functionality. Examples include a mintERC721Token() function that periodically mints new NFTs for users, a function for awarding payouts in a prediction market, or a function for unlocking staked tokens in a DEX.

Developers will need to trigger such functions at intervals to keep the application running smoothly. However, this might lead to more hours lost on mundane tasks for developers, which is why automating execution of smart contracts is attractive.

Some decentralized oracle networks offer automation services, which allow offchain oracle nodes to trigger smart contract functions according to parameters defined by the user. Typically, this requires “registering” the target contract with the oracle service, providing funds to pay the oracle operator, and specifying the conditions or times to trigger the contract.

Chainlink’s Keeper Networkopens in a new tab provides options for smart contracts to outsource regular maintenance tasks in a trust minimized and decentralized manner. Read the official Keeper's documentationopens in a new tab for information on making your contract Keeper-compatible and using the Upkeep service.

How to use blockchain oracles

There are multiple oracle applications you can integrate into your Ethereum dapp:

Chainlinkopens in a new tab - Chainlink decentralized oracle networks provide tamper-proof inputs, outputs, and computations to support advanced smart contracts on any blockchain.

RedStone Oraclesopens in a new tab - RedStone is a decentralized modular oracle that provides gas-optimized data feeds. It specializes in offering price feeds for emerging assets, such as liquid staking tokens (LSTs), liquid restaking tokens (LRTs), and Bitcoin staking derivatives.

Chronicleopens in a new tab - Chronicle overcomes the current limitations of transferring data onchain by developing truly scalable, cost-efficient, decentralized, and verifiable oracles.

Witnetopens in a new tab - Witnet is a permissionless, decentralized, and censorship-resistant oracle helping smart contracts to react to real world events with strong crypto-economic guarantees.

UMA Oracleopens in a new tab - UMA's optimistic oracle allows smart contracts to quickly and receive any kind of data for different applications, including insurance, financial derivatives, and prediction markets.

Telloropens in a new tab - Tellor is a transparent and permissionless oracle protocol for your smart contract to easily get any data whenever it needs it.

Band Protocolopens in a new tab - Band Protocol is a cross-chain data oracle platform that aggregates and connects real-world data and APIs to smart contracts.

Paralinkopens in a new tab - Paralink provides an open source and decentralized oracle platform for smart contracts running on Ethereum and other popular blockchains.

Pyth Networkopens in a new tab - The Pyth network is a first-party financial oracle network designed to publish continuous real-world data onchain in a tamper-resistant, decentralized, and self-sustainable environment.

API3 DAOopens in a new tab - API3 DAO is delivering first-party oracle solutions that deliver greater source transparency, security and scalability in a decentralized solution for smart contracts

Supraopens in a new tab - A vertically integrated toolkit of cross-chain solutions that interlink all blockchains, public (L1s and L2s) or private (enterprises), providing decentralized oracle price feeds that can be used for onchain and offchain use-cases.

Further reading

Articles

• What Is a Blockchain Oracle?opens in a new tab — Chainlink
• What is a Blockchain Oracle?opens in a new tab — Patrick Collins
• Decentralised Oracles: a comprehensive overviewopens in a new tab — Julien Thevenard
• Implementing a Blockchain Oracle on Ethereumopens in a new tab – Pedro Costa
• Why can't smart contracts make API calls?opens in a new tab — StackExchange
• Why we need decentralized oraclesopens in a new tab — Bankless
• So you want to use a price oracleopens in a new tab — samczsun

Videos

• Oracles and the Expansion of Blockchain Utilityopens in a new tab — Real Vision Finance
• The differences between first party and third party oraclesopens in a new tab - Blockchain Oracle Summit

Tutorials

• How to Fetch the Current Price of Ethereum in Solidityopens in a new tab — Chainlink
• Consuming Oracle Dataopens in a new tab — Chronicle

Example projects

• Full Chainlink starter project for Ethereum in Solidityopens in a new tab — HackBG