In the presentation above, Tellor’s CTO, Nicholas Fett, gives us an overview of his work building a decentralised oracle network. Before we dive into Nick’s presentation, here are some important basics.
What is Tellor?
Tellor is a decentralized oracle network. Tellor is made up of a permissionless community of data providers, validators, and token holders. It makes use of crypto-economic incentives to secure the process of moving any type of data on-chain. Operating on multiple L1s and L2s, the Tellor team is obsessed with decentralisation. Some examples of projects that use Tellor’s oracle services are Liquity, Reflexer, and Ampleforth.
Tellor Backstory & Why Derivatives Run into the Oracle Problem
Back in 2017, Nick worked on Daxia – a smart contract creation platform for Over-The-Counter (OTC) derivatives on decentralised networks. Derivatives are financial assets that derive their value from a chosen assets’ performance. Derivatives in DeFi are especially important because of the lack of interoperability between blockchains. For instance, the Bitcoin blockchain is written in a different programming language than that of the Ethereum blockchain. This means that Ethereum smart contracts cannot be used on Bitcoin and vice versa.
A way around this incompatibility of languages is wrapped tokens, a common derivative used in the blockchain space. An oracle service would be important in ensuring that as long as Wrapped BTC is used on the Ethereum network, the corresponding amount on the Bitcoin network is not spent. Using this WBTC example., derivatives run head-first into the oracle problem because in order for the correct amount of WBTC issued on ethereum needs to correspond with the amount of BTC locked on the bitcoin network.
Back when Daxia was created, the only oracle service available was Oraclize, now known as Provable Things. Oraclize, however, was a very centralised service, with just one server reporting data. This made it the single point of failure for decentralised platforms using Oraclize data – if Oraclize was ever corrupted, your entire platform would receive false data.
After running into all of this while building Daxia, Nick and his co-founders, Brenda Loya and Michael Zemrose, founded their own decentralised oracle solution – Tellor.
Fast Forward to Now – What has changed?
Since Tellor was launched, a lot has changed in the blockchain space. There are now several different widely-used L1s and L2s. Protocols are no longer restricted to building on just Ethereum. (Our panel, titled “The future is multichain”, will be released soon.) Before we get into the specifics of how these changes affect oracle design, here are some important terms mentioned in the talk that are important to know.
- Layer 1s, or L1s, like Avalanche, Solana, or Algorand, each have their own pros and cons with regards to transaction costs, speed of transactions, EVM compatibility and more.
- Ethereum Virtual Machine or EVM compatibility refers to smart contracts that can be easily migrated from Ethereum to other EVM compatible blockchains, and vice versa.
- Cross-chain communication, refers to how different blockchains communicate with each other.
- Cross-chain decentralised exchanges: while decentralised exchanges (DEXs) like Uniswap have a lot of users and liquidity, Uniswap operates on one chain, ethereum. A cross-chain DEX would allow users to buy and sell tokens on different chains without a centralised third-party processing the trades.
- Bridging protocols are used to transfer tokens from one blockchain to another.
Cross-chain communication, DEXs and bridges are all totally reliant on portable and reliable data, and are therefore reliant on robust oracle networks that can provide accurate data in a multi-chain environment.
What are Oracles Missing?
Most, if not all, of the oracle solutions operating today require centralised teams to deploy the oracle on new chains. Nick envisions a future where deploying an oracle network on a new L1 or L2 is as permissionless and decentralised as creating your own smart contract on ethereum, meaning anyone can do it anytime.
Nick also mentions the need for better ways of ensuring the liveness of data. Blockchain prices change constantly, 24/7. When oracles fail to report up-to-the-second data, millions can be lost. Liveness refers to how constantly up-to-date an oracle is.
What does the ideal oracle look like?
According to Nick, the ideal oracle is simple, has minimal governance risk, and is flexible. The flexibility of an oracle can refer to how easily it is deployed on different chains, whether end users are able to request any data, or even the rate at which data is received. Aside from speed, different data types and information should be readily available for requesting, whether it is on-chain price data or off-chain data like weather or election data.
At the same time, the ideal oracle should be decentralised and permissionless, meaning anybody should be able to become a node operator. There should be no restrictions on who can deploy a smart contract to the blockchain, and also on who can consume data from oracle nodes. Users should also be able to choose the nodes they wish to pull data from, including nodes they themselves operate.
Why Decentralisation Matters
Nick ends his presentation by reiterating the importance of decentralisation and mentions his experience working at the CFTC. The Commodity Futures Trading Commission (CFTC) is a regulatory body in the US for derivatives markets. He brings up the case of Polymarket being fined by the CFTC for operating as its own oracle and the implications of this case on other oracle operators. For more details about the case and its implications on oracles, check out this video.
Another factor in the importance of decentralisation is how the over-reliance on the reputation of centralized authorities for accurate data can be dangerous. In theory, an established enough global entity, such as the Bank of England or the European Commission, would be incentivised to continue being honest because of the repercussions that dishonesty would lead to. There have been many instances, however, where trusted global entities have been allowed to continue operations in spite of their dishonesty – like the banks in the LIBOR scandal. The London Inter-Bank Offered Rate (LIBOR) is an average interest rate calculated by using submissions from leading banks from around the world, and is referred to as the most important number in the world. In 2012, it was uncovered that several banks colluded with each other to fix the rates in each other’s favour.
Such collusion and manipulation could wreak havoc on DeFi, and building decentralised applications on decentralised blockchains with a reliance on data from a few trusted centralised entities flies in the face of blockchain values like trustlessness and decentralisation. In this new environment, robust and decentralised oracle networks like Tellor provide verifiable reliability instead of old-fashioned trust.
Tellor was an Oracle Partner of the inaugural Blockchain Oracle Summit: Berlin. BOS22 was the first conference to focus solely on oracles’ importance and design. Leading speakers from across the DeFi-TradFi spectrum came to Berlin to take deep-dives into their work using oracles to power exciting use-cases of blockchain technology.