The Current Oracle Landscape:

How Decentralized Are These Feeds?

We’ll touch on Tellor a bit in this article, but mainly we just want to talk about the designs of oracles in general, what’s being used in Defi at the moment, and ultimately what we can do about it.

To begin, let’s get into the love story between oracles and blockchains and how it all went down.

Even before Ethereum, the glorified escrow contracts which we call smart contracts realized that they needed a way to access off-chain information. Early adopters recognized that playing around with digital ledger entries is only so much fun if you can only reference these self-contained transactions.

And so the dream of having access to information off-chain began. They started early on with visions of derivatives, stablecoins, prediction markets and other gambling protocols for the speculators increasingly making up a larger portion of the crypto scene. And so, like any good community of entrepreneurs would do, we began to build these products to meet demand.

And it worked, sort of. We have all of those things, but unfortunately now we’re all stuck in the position of looking at these products and wondering if they actually deliver. As more money gets thrown into these protocols, we’re just now beginning to look and see if they ever actually developed the oracle technology necessary to make these trustless like they promised.

Stepping back from the landscape let’s look at what an oracle actually is. Before there was any differentiation of on-chain vs off-chain data, all you had were databases. The question a decade ago was very similar to the oracle problem: how do you come to consensus on data? As we all know, the solution to this question was bitcoin and the blockchain. Regardless of what system you’re running, they all have various ways of agreeing upon specified data (who’s sending who what in bitcoins case) and this is all built into the system.

Oracles differ because there is no pre-specified consensus mechanism. You need something not only to reach consensus on pre-specified fields which work nicely with these simple payment systems, but also on other things, namely information about some event or state not at all related to the blockchain. The big difference here is that now the consensus layer is on-chain, namely the pieces that determines both who can push the data and then whether or not this correct.

Now let’s get into some designs for oracles.

As you all know the easiest oracle is just one person. You either enter the price yourself or you can whitelist me to enter it in your smart contract, and I put it in. For those that don’t know, the biggest name for this method in the Ethereum space is Provable (formerly Oraclize) and to be fair it works really well. It’s just a completely centralized model, but it’s also simple and easy to understand who is in charge. The obvious risk here is that the central party can either manipulate your price or if they shut down their servers, you don’t even get a price. This latter problem is what we call a lack of a “liveness guarantee”.

Moving on, the second easiest design is a multisig. For this design, you don’t whitelist just one person, you whitelist a handful of parties and they all place the data on-chain and then you take the median, average, or whatever other transformation you want to do. As you can tell, this is a little better, more like the Proof-of-Authority version of an oracle if we’re correlating them with layer 1 solutions. And so if this is say the v2 oracle, not to burst any bubbles, but most of defi right now is between v1.5 and 2.5. We’re really not much beyond here.

Of course there are more designs on this. A slightly worse version that you see around is where you have multiple parties sign prices and then one party (or a list of a few parties) pushes. This helps separate the risks, so in this oracle one group of parties can manipulate the value and the other can censor your system by shutting down and not pushing prices on chain. So you may have collusion and liveness issues here.

A big question you have to ask yourself with these reputation based systems is whether or not more parties that are known makes something more decentralized or censorship resistant. Some may say yes. So if you have Goldman, Deutsche Bank, and Bank Of America setting your price that this is better than just JP Morgan….maybe, but it’s for sure not quite the homerun that the bitcoin “OGs” dreamt of.

Next, kind of like a version of the POA system, would be a dPOS oracle. Here you’d just have whitelisted nodes that have to stake a deposit that they can lose if they lie when reporting. This is better, but you have to pay close attention to the whitelister and the process. Can they unwhitelist everyone on a dime? What’s the security mechanism for slashing? How do nodes get added? Also for any of these, you need to know how well the nodes communicate and how easily they can collude. The point of centralization may be obscured with these systems, but it’s definitely still there.

Now on a positive note, let’s talk real quick about prediction market oracles. Probably not as popular now, they had their day in the sun and a lot of the literature in the space was written by these guys so it would be sort of unfair not to point them out. These work by simply placing a bet or voting on the right outcome. If you assume that you have 51% honesty in your system and parties don’t want to lose money, it works and is decentralized. I like this method a lot, but unfortunately regulatory, speed, liquidity and even cost concerns have made them sort of untenable for many defi needs. But I think you may see some of these play a role for certain oracle needs in the future and even our system built on a lot of the principles that these guys pioneered.

And so that’s basically it for what’s currently in use for Defi. The design space continues to innovate; well or at least raise lots of money to try and hide their centralization, but I think we’ll start to see the users demanding better with options, just like you see with the backlash against Tether or centralized exchanges, it takes time and I really think oracles are going to be added to that list.

Despite all of these centralized designs, the truth is that we always knew how to crypto-economically validate data; we do it with Bitcoin and every other early layer 1. You have a way to pick some anonymous person or group of persons to enter the information. Then you add in some form of probabilistic finality so that the community of validators can collectively agree on whether or not to accept this answer. As long as you make it economically expensive to pretend to be the majority for any period of time, you’re good to go.

This is how we built our system and others are starting to build similar things.

Of course there are drawbacks.

Like any actually decentralized layer 1 chain, this is slow and expensive. If you take anything from this talk, just realized that the scalability trilemma holds for oracles too. Anyone that tells you differently likely has a coin to sell you. As is widely recognized in the EOS ridicule, Ethereans and Bitcoiners alike have realized that instantaneous transactions when it comes to layer 1 are a dream, but for some reason defi doesn’t accept this or hasn’t made the connection when it comes to oracles.

Now that we have models though, let’s see what we currently use in defi. I know that the number of partnerships out there and all the noise in the crypto echo chamber makes defi look huge, but in reality you can count 10, maybe 20 if you stretch it, projects with actual volume and I don’t think our litmus tests for decentralization would really give any of them a passing grade for their oracle.

First on the list of course is Maker. Depending on how you measure it, this is basically all of Defi at the moment. I mean come on guys, if you’re not using DAI in your protocol are even trying these days. I joke, but the other stablecoins don’t even attempt decentralization. On their oracle specifically though, keep in mind that Maker’s oracle is used not only for Maker, but also other projects in the space, notably Dydx and many smaller projects that need a robust ETH/USD feed.

Now, Maker’s oracle structure at the moment is basically a complex Proof-of-Authrity model with a lot of secrecy. They’ve luckily recently moved to a model where anyone can be a relayer, but who the data providers and what their incentives are remain out of sight. Actually, the only reason I wouldn’t give them a completely failing grade is that they actually follow some best practices, namely they have an hour delay in their oracle updates. This Oracle security module which is a smart contract on chain allows their token holders to say whether it’s a bad value and they can freeze the system. This is actually cool because it means that the oracle isn’t in complete charge of their protocol, they are. Now if you’re using DAI, token holders being able to freeze the system may not be comforting, but at least its a slightly more democratic process than a centralized oracle. And not to bash on Maker at all, they do have some really cool features which are on their roadmap, but if you’re using their oracle or DAI now, just be sure that you have some fallbacks in place too, because unfortunately it’s not really up to par on the censorship resistance piece.

Next on the list Compound. So Compound has a similar structure to Maker, but they have their own reporters and a different mechanism for handling what happens when it gets on chain. Don’t need to go into it too much since it should look pretty familiar, but their roadmap does look a bit different. Whereas Maker’s oracle plan seems basically to be continuing to perfect their own PoA oracle, Compound has stated they’re open to actually using other oracle providers once decentralized versions come online, so kudos to the openness there. And I also have to say they are smart like Maker too how they use them; mainly just meaning they don’t expect these things to be instantaneous.

Now for the last Defi projects with a bit of volume, you have Synthetic, Aave, bZx, and Set. These guys all use Chainlink. I know Chainlink has a billion partners, but for Defi with some volume, this is the A list right here. As a disclaimer, this is to my best knowledge how Chainlink works currently. It’s actually really hard to figure it out, which like the readability of Maker’s code, is sort of a negative in terms of transparency. But yes, Chainlink has a centralized whitelisting agency that gets nodes to report to various price feeds. I know they have a bunch of stuff on the roadmap, but this is what’s live now and it’s jsut a completely reputation of Chainlink based oracle, so use at your own risk.

So that’s it. Defi is basically using two oracle structures that are at best sort of decentralized. There are other projects out there, note I didn’t mention Augur or Gnosis, but in terms of Defi with some volume, this is about it.

Also I need to point out that just because you have a good method for getting data on chain, doesn’t mean that the data is a good fit for what you’re trying to do. Oracles and following some best practices are only half the battle, the other half is picking what data you should actually use. The number of derivatives projects out there that use a last traded price or some illiquid auction for their settlement price is ridiculous. This isn’t even a blockchain problem either. The traditional finance world has a lot of literature on what makes a robust settlement procedure and it’s definitely one part we shouldn’t throw away when putting products on chain. But that’s for a different talk.

Now onto why this actually matters.

So I’m sure you’ve heard it a million times, that we as a space are having an identity crisis. What is crypto built for, what is Ethereum built for, what is the purpose of defi. Are we removing middle men, banking the unbanked, making backends slightly more efficient, or are we creating something that is resistant to the current regulatory and power structures of current financial markets.

The big problem with using centralized oracles is that there’s a choke point. There’s a squeeze that the regulators can go after and all of this money is at risk. There’s a small group of individuals that can massively cash out or screw us all over if they so choose. We don’t have censorship resistant defi.

Now, I don’t mind if one group of token holders can censor you or if the Ethereum community or small group of thought leaders there is ultimately charge of the state of these systems. That’s a discussion we need to have on token distribution, transparency and governance, but it’s for another time. It’s in the open and everyone knows about it. What’s not being talked about is that right now, there are literally a handful of people who run these oracles that can shut down all of defi.

You’ll hear arguments that we rely on their reputation and the fact that they wouldn’t want to ruin their good standing. But this is the same argument you could make for letting a consortium of banks decide your settlement prices. We need to move away from this fast and we need to demand that new projects coming into the space don’t continue to centralize this risk.

Now for the solution.

Projects may not like me for saying this, but you have to make your UX worse. The current designs of oracles are centralized for a large part because they are shoehorned into products that don’t work with decentralized ones. We’re all in the crypto space. We know how it works to decentralize something. If your buddy has a finance application with a centralized server and he wanted to know what it would look like with a decentralized backend, what would you tell him?

First would be that he needs to really really think about whether he wants to do this. You would explain things like probabilistic finality, slow blocktimes, and congestion issues. If he still thought it made sense, you’d tell him to make sure to tell his users that they may have to wait a bit for confirmations and that they’ll actually have to pay a small amount called gas to do anything with this application.

This would not be a sales pitch of a plug and play server. There would be edge cases he’d need to handle and new procedures that would need to be put in place. This would not be a quick hack.

He’d probably come back to you and say something like “well what if we progressively decentralize”, aka move certain pieces Ethereum slowly over time? You’d rightly tell him that you’re only as strong as your weakest point and there’s no point to it other than a press release. Users and frontends would get built around the current fast and free design, and you’d have none of the benefits of decentralization.

Why then do we build on top of oracles differently? Why do we get it when it comes to layer 1 but not subsequent layers.

Right now it just feels as though many projects are adding crazy layers of complexity to hide the fact that they’re no different than their centralized counterparties when it comes down to it. As a space we need to realize that progressive decentralization and crazy levels of complexity doesn’t work when it comes to oracles and is dangerous when it comes to handling users money. If you’re building a derivatives project that needs an oracle queried and validated in real time, you’re out of luck. Hell even if you need sub-minute updates on Ethereum, you’re going to pay a lot and have a bad time during periods of stress. Don’t listen to someone that tells you they’ve built this.

This solution is both supply and demand based, but in both cases we need to supply and demand better. We need to build slower projects with a twinge more revolution in them. As someone building on Ethereum, we need to build things that make sense on Ethereum.

We continue to build financial products that mimic real world companies and all that’s changed is the backend and the regulatory protections. If we keep this up, we’ll ultimately either get regulated out of existence or simply fail to scale as our products have no meaningful differentiation from their centralized alternatives.

To conclude, if you’re building a project and need an oracle, give Tellor a look and at least go read some of our materials on best practices for oracles so you can think through your design and settlement procedure.

For more information on visit our website or reach out to us at info@tellor.io.