What is Fetch Oracle and How Does It Work?

True DeFi users want decentralization everywhere possible. 

But many projects are actually Fake-DeFi because they rely on centralized oracles.

Centralized oracles have admin keys or a multisig that the founding team controls in order to input data to a smart contract.

These oracles are just one bad actor away from causing a multi-million dollar exploit. 

The solution here is a truly decentralized blockchain oracle service such as Fetch Oracle. 

What is Fetch Oracle?

Fetch Oracle is a fully decentralized blockchain oracle native to PulseChain which supplies accurate and reliable data to various projects on the blockchain. 

The Fetch system, modeled after Tellor, utilizes a decentralized network of reporters to report data.

The system uses simple economic incentives which reward correct data entry and penalize erroneous data entry. 

Fetch Oracle Use Cases

The Fetch Oracle can provide a large variety of information for many use cases. Here are three primary examples:

1. Price Feeds. For example, Liquid Loans uses Fetch as the primary source of an accurate price for $PLS.
2. Prediction Markets. A smart contract for a gambling service might want an accurate and trustless answer to “Who won the baseball game last night?”
3. Bridging Assets. Blockchain bridges need both accurate price feeds to determine ratios of assets to lock/unlock and also a trustless way to determine if an asset was received in a pool.

How Does Fetch Oracle Work?

The Fetch Oracle starts when a querier submits a request for data (e.g. Price of $PLS) and inputs a tip in FETCH Token.

The distributed network of data reporters, who have staked a certain amount of FETCH token, race to input the data in order to earn the tip.

If the data is correct, the querier is happy because they now have the data they wanted on-chain, and the reporter is happier because they are one tip richer. 

If the data is incorrect, another party will “dispute” the data and it is then taken off chain and moved to a vote. If the disputer is correct, and the data is deemed erroneous, the disputer receives the entirety of the disputed reporter's FETCH stake. 

By utilizes this model, Fetch relies on a fully-decentralized method of getting desired data on-chain without relying on a central party to input and verify information.

For a more technical explanation of how Fetch Oracle works, read the Whitepaper here. 

How Fetch Oracle Achieves Decentralization

The Fetch Oracle achieves decentralization by two fundamental design principles:

1. Anybody can input data
2. Anybody can censor incorrect data

Centralized oracles typically have a limited pool of individuals who can input data and a similar limited pool who can edit data.

To the contrary, Fetch uses a distributed network of reporters who are all equal in the eyes of the system much like a decentralized blockchain. There is no central entity who can override data entry.

Why Does Liquid Loans Need an Oracle?

Liquid Loans has many different functions which require price feeds for PLS and USDL from a decentralized oracle:

• Vault Collateral Ratios. Vaults inside the LL protocol must remain above the ratio of 110 PLS: 100 USDL to avoid liquidations. In order to set these ratios, the LL protocol needs accurate, reliable, and timely price feeds for both PLS token and USDL stablecoin. Any hiccups in the price feeds of either token could result in unfair liquidations. And since LL is immutable, getting this correct the first time around is essential.

• Minting USDL from Collateralized PLS. USDL is minted based on a percentage of the dollar value of PLS which is collateralized. Therefore, an accurate price for PLS must be provided from an oracle.
• USDL Redemptions. A key feature to the LL protocol is the ability to always be able to redeem on USDL for one dollar's worth of PLS. In order to accurately deliver the correct amount of PLS per USDL, an accurate price feed is required.

So who gets to decide what the prices of PLS and USDL are?

Ideally, it would be a distributed network of nodes who are incentivized to input the correct information. And any information that is incorrect is amended and the provider is penalized.

This is necessary because there is plenty of financial incentive for bad actors.

For example,

Say an entity owns a large quantity of USDL and they are staked in the Stability Pool.

If this entity has the ability to enter the price of PLS at $0, all of the vaults will liquidate. As a results, the stability providers will end up with all of the PLS in the protocol at a hefty premium.

Therefore, ensuring that this is never possible is critical to the health and longevity of Liquid Loans.