The Oracles Secure the Data — But Who Secures the Oracles?

It is time to pull back the curtain on blockchain oracles — before someone else pulls the rug.

The original promise of Web3 was a dream come true for technologists and freedom fighters alike — unstoppable code. Software that can’t be stopped, censored, hacked or manipulated in any way.

But what if I told you that there’s a hidden layer of tech that is breaking that unstoppability? A piece of infrastructure that we are constantly looking away from. A silent vulnerability that undermines Web3’s original promise.

I’m the decentralized oracles guy. Of course I’m referring to blockchain oracles!

In this post, my goal is to bring some light on this obscure topic and the bad practices surrounding it. I want to speak up before it becomes too late. I feel forced to pull back the curtain — before someone else pulls the rug.

So Wait… What Is an Oracle, Actually?

A quick Google search will give you a thousand articles on “the oracle problem” and how important oracles are for the security of smart contracts.

So I will run away from repeating that same old story. Instead I’ll try to give you a fresh new interpretation, and a twist!

Understanding Determinism

Your typical explanation would start by saying that the real world is full of random stuff and inconsistent behavior (indeterminism). And then go into saying that smart contracts, on the contrary, require consensus: the outcome of their execution must be the same across the multiple computers they run on (determinism).

Determinism, however, is nothing but a fancy way to say that we expect the same results every time we apply the same process to the same raw materials.

You throw some fruit into your blender, let it run for a couple of minutes, and you get fresh smoothie. Sweet! But throw your iPhone instead of fruit, run the blender again, and… I think you get my point — the outcome of a process is largely affected by its input.

Garbage In, Garbage Out

That principle (“the quality of the output is determined by the quality of the input”) often receives the name of “Garbage In, Garbage Out”.

💩 + Code = 💩

When we go and apply this to smart contracts, we realize that it doesn’t matter how good your code is — you can be the best Solidity or Rust developer — but still your smart contracts will only execute correctly if they operate on correct data.

The Gap Between The Blockchain And The Real World

When the clever engineers behind Ethereum, Polkadot, Solana, etc. designed their platforms, they made sure to build a big firewall between the blockchain and any piece of data coming from the real world. At the end of the day, they didn’t want inconsistent data polluting the chain state. They wouldn’t let indeterminism creep into your contracts and jeopardize consensus.

As a consequence, blockchains are pretty much isolated from the real world. This clearly limits the uses cases that we can build, and reinforces the perception that Web3 is only for self-referential speculation and that it can have no real transformative impact on society.

This is the so-called *“oracle problem”*: how do we build determinism from indeterminism, or more specifically, how can we introduce data into smart contracts without breaking their security properties**.

Meet The Blockchain Oracles

The solution to this oracle problem could be no other than — rather unsurprisingly — blockchain oracles.

Pretty much like the oracles in ancient times would be the connection between the human and the divine, a blockchain oracle connects the on-chain to the off-chain.

You use a blockchain oracle every time that your smart contract needs to operate on the price of an asset, or on any piece of information that you normally get from an API (market indicators, temperatures, weather data, sport results, AI outputs, etc.)

The Twist

But as I promised, there’s a twist. Ladies and gentlemen:

Oracles are not what they seem.

I’ve been building oracles for last 8 years. And if I had to summarize all the things I’ve learnt during these years into a single lesson, this would be it:

How people imagine oracles, vs. reality.

While it is technically right that oracles are “something that pushes data into your contracts”, this view is also utterly wrong from the human perspective of what motivates a builder to use an oracle.

When you look for an oracle, you are not shopping for data — you are buying peace of mind.

When founders and teams come to us looking for an oracle, what they really want is to offset the liability of making sure that data won’t go wrong. Somebody else to take the blame. As builders, they just want to feel safe to move forwards. Because builders gonna build.

So two key questions we need to make ourselves are: how do oracles achieve that peace of mind? and is it related to who is securing the oracles?

Different Oracle Models

We already stated that a blockchain oracle is something that pushes data into your contract and buys you some peace of mind. But that’s quite broad.

In practice, you can find all kinds of things of very different nature being called an oracle. Just like a chihuahua and a dobermann are both dogs — they have four legs, one tail, they bark, they leave little gifts everywhere — but that’s where the similarities stop.

Would you trust them both to guard your house?

#0: Noracles

In their simplest approach, you can find those that I call “noracles”. This is the situation where data is centrally introduced by an authorized entity. Most often, this is either the deployer of the smart contract itself; or a trusted, reputable data source or institution.

Because of its simplicity, this pattern can be quite effective. But of course it introduces a very evident point of failure as well as a very central point of trust. It will only work as long as that one single actor makes sure that the data is correct, and it doesn’t get hacked, corrupted, blocked or just stops working for any physical, technical, economical, or regulatory reason.

By adopting this pattern — which is surprisingly common in many protocols and dApps even nowadays — you are basically defeating the purpose of using a smart contract in the first place. By introducing trust in that central actor, you break liveness, censorship resistance, and the core security properties you expected your contracts to inherit from the blockchain. Instead, you only inherit the vulnerabilities that the noracle may have.

When we evaluate noracles under the “who secures the oracle?” perspective, the answer is pretty straightforward — a trusted party to whom you are basically handing the keys to your safe.

Some famous instances of noracles where:

• Oraclize.it and some other early oracle solutions.
• ChainLink VRF, as it uses a single coordinator model that can stop feeding randomness at any time.
• Most recently pretty much every project in the RWA space.

#1: Multiparty Oracles

Next in line you have multiparty oracles.

These can take the form of pure multisigs, or some kind of onchain aggregator contract. In both cases, they rely on a closed set of reporters to agree or vote on a on a common result, often off-chain or through proprietary coordination systems.

So when compared to the noracles, this model offers some degree of trust mitigation and at least it puts some more checks and balances in place before garbage gets into your contracts.

This model often offers no real verifiability, still relies on named entities, corporate partnerships, curators, and pretty much trust and reputation at multiple levels.

If anything goes wrong, any remedy or any enforcement happens on the phone, not onchain, because there’s no real cryptoeconomics involved — there’s no such thing as slashing.

Some relevant examples are:

• Early versions of MakerDAO, Augur, Gnosis, Curve and many other popular protocols.
• Pretty much every utility in the ChainLink offering, where there’s a closed set of whitelisted and KYCed node operators who interact through an aggregator; either onchain or through their rather opaque offchain reporting system.

So, I’m very sorry to bring you bad news here: everything out there using ChainLink probably falls into this category just as well, and may be subject to the same vulnerabilities and risks.

Again, from the perspective of “who secures the oracle?”, in this case you are not trusting a single actor, but rather a collective or a committee. But the integrity of the data still depends on those behaving as expected, and largely piggybacks on their reputation and on the ability of some central “curator” to decide who belongs in those committees.

#2 Decentralized Oracles

Finally, you have proper decentralized oracles.

I only include in this category those oracles that truly live up to the same security standards as the blockchains they serve. They must not introduce any single points of failure or any additional trust assumptions.

Once you post a query to a decentralized oracle, you can rest assured that:

• You will timely get a response.
• This response is a true representation of the data that you wanted.
• It hasn’t been tampered with or manipulated in any form by any actor involved in process — be it the nodes that conform the oracle or the data sources themselves.

This is also the only category of oracles that will pass the “walkaway test”. If the team behind your oracle disappears tomorrow, will it still work? Will it stay secure? If the answer is yes, ok, that’s what we’re talking about. If your oracle requires some “babysitting”, well, it’s time to find a new one.

And here’s the nice thing about decentralized oracles: they’re not about the “who secures the oracle?”, but rather how they do it. Data integrity will not come from trust or reputation, but rather from the specific mechanisms and the incentive design that they implement for leveraging trust mitigation and accountability, all in real time, at a protocol level, and protected by cryptoeconomic guarantees (staking, slashing, etc.)

In the Web3 world, “protocol-level peace of mind” is the ultimate form of peace of mind—and the only one that really works.

There are a number of different projects building oracles that I can confidently put in this category. Of course, as far as I can tell, none of them are perfect to this date, and there are always some trade-offs and compromises. But — despite having very different designs and properties — some of those that come quite close are probably:

• Tellor
• UMA
• And obviously, the Wit/Oracle

Meet The Wit/Oracle (aka Witnet protocol)

Anyone who looks at the design, implementation and track record of the Wit/Oracle can acknowledge that it is indeed the most sophisticated, complete and proven embodiment to date of what I mean by decentralized oracle.

But the Wit/Oracle didn’t exactly come out of nowhere — is rooted in classic literature on game theory, incentive design and more in particular, focal points; as well as on research from other builders who have pioneered decentralization in the blockchain space. Some of the strongest influences are:

• *The Strategy of Conflict* (T. Schelling, 1960)
• *Schellingcoin* (V. Buterin, 2014)
• *Filecoin: A Decentralized Storage Network* (J. Benet et.al., 2014)
• *Truthcoin: Peer-to-Peer Oracle System and Prediction Marketplace* (P. Sztorc, 2015)
• *Algorand* (J. Chen et.al., 2016)

We stand on the shoulders of giants (here quite literally 😆)

All this research lead to the publication of the original Witnet Whitepaper in 2017. This rather dense and technical paper came to describe an oracle whose integrity was powered by the concept of crowd-attestation.

Crowd-Attestation Oracles

A crowd-attestation oracle is based on a completely open and permissionless network of validator nodes.

Every query that you send to a crowd-attestation oracle is randomly assigned to a subset of validators. They will resolve your query independently, and then commit to that result through a cryptographic commitment.

Once those eligible validators have submitted their commitments, there’s a reveal phase where the commitments are validated, and the revealed values get aggregated into a single data point that will get reported back as the true result of your query.

Most importantly, if a validator’s committed and revealed value matches that of the majority, it will earn a reward paid by the requester. On the contrary, validators who are found to be outliers get immediately slashed.

The beauty of this design is that it builds trust mitigation at every single layer. First by sourcing the data from multiple sources, filtering outliers, and aggregating them together; then also applying similar filtering and aggregation techniques to the reported data points that the validators revealed; to finally arrive to a single result that nobody in the process was able to manipulate.

The Wit/Oracle Chain And The $WIT Coin As Public Goods

All this mechanism is made possible by the Wit/Oracle chain — a one-of-a-kind, single-purpose, Layer-1 oracle chain.

While this Layer-1 chain really resembles Bitcoin in its minimalist design, it features transaction types and data structures that are extremely tailored and optimized for the oracle use case. The commitment and reveal scheme that is core to the crowd-attestation mechanism is truly a first-class citizen of this chain.

There are good reasons for the oracle to run on its own *appchain*, not only from an efficiency perspective, but also to achieve sovereignty and independence from any smart contract platform in particular.

However, this chain independence does not hinder access to those data-hungry smart contracts — on the contrary, it made it even easier to **integrate the oracle with more than 50 EVMs**, where smart contracts can conveniently and natively post oracle queries, even paying with their own native token.

Support for non-EVM chains like Solana is also on the table. Additionally, we also explored support for the Polkadot ecosystem through our own Substrate pallet, although more recently we are leaning towards integrating with PolkaVM.

All ot this wouldn’t be possible without the incentivization provided by the **$WIT coin — anyone can spin up a validator node at any time and start to [earn it right away through staking](https://staking.witnet.io/)**. No permission or whitelisting needed.

And most importantly, this type Proof of Stake is what I like to call useful staking, because in addition to receiving some yield (the APY is close to 20% as of writing), by running a validator you are contributing to the security of the chain, to the security of the oracle, to the security of the projects that are using the Wit/Oracle in production, and therefore to the security, reliability and the future of the broader Web3 ecosystem as a whole. You become part of a decentralized public good.

Why Securing The Oracles Matter

At this point, you may think that I’m just exaggerating and that I’m claiming that decentralized oracles are needed because I have a fetish for decentralization (which I obviously have, of course). But that’s not the only reason.

The truth is that shit happens. It has happened in the past, and it will happen again.

If I was asked to cover in detail all the crypto protocols that got their users’ money stolen because of attacks on their oracles — or because they weren’t using oracles at all — it wouldn’t take me another 10-minute Medium post, believe me that it would be closer to a Bible-long report.

When we look at those “oracle hacks”, the most immediate impact was monetary loss, but there’s also reputational damage. Users lose their money, and the founders behind a certain protocol lose their credibility.

But that’s not where the story ends.

When we look at Web3 we have this beautiful layering and interconnection between protocols and dApps. The famous “money legos” enabling all kind of composability among protocols.

So when a protocol pays little attention to their oracle policy they’re not only shooting themselves in the foot, but also creating systemic risk. Because the wrong execution of a certain protocol might have an impact on other protocols that rely on it.

We as builders need to be aware about all of this, and act responsibly. Because in those hacks that we’ve seen in the past, that monetary loss and reputational damage very easily spread like wildfire across the whole ecosystem, and dragged the adoption of Web3.

We Can’t (Afford To) Look Away

When I started working in this space some 10 years ago, I remember that we had the vision that crypto would serve as the technological and economical foundation for the future. Infrastructure for freedom.

During these years… we had a hell of a great time! We made some money (and lost some money) with ICOs, DeFi, NFTs, memecoins, and all the funny things that this space brings.

But all of that fun, maybe got us distracted from one key fact:

We can’t look away from infrastructure.

I’m talking oracles, but also JSONRPC providers, validator nodes, hardware wallets — all kinds of infrastructure that we often overlook, that we give for granted.

I totally get it, oracles don’t make the headlines. No one becomes a “KOL” on Crypto Twitter discussing data integrity. Oracles are not “degen enough”.

But oracles are a key piece of blockchain infrastructure. And when infrastructure breaks — then everything breaks. Your dApp, your DAO, your lending protocol, your stablecoin — it all collapses like a house of cards.

Remember: we cannot afford to look away from infrastructure only because it’s boring. Sometimes, it’s the boring stuff what makes the magic possible. Sometimes it’s the unsexy that matters most.

A Brighter Future For Web3

But hey, it’s not all bad news. There are actually very positive signs right now in the space, where more and more builders are starting to take oracles and infrastructure seriously.

Talks on these topics are now taking the main stage (*I even presented this myself at Web3Summit!*). We are seeing L1s and infra projects turning the heads of VCs again. Projects like PoolTogether and many others are embracing the Wit/Oracle in a smart move towards improving the reliability and unstoppability of their decentralized applications.

So there’s hope. There’s a bright future ahead for Web3. I think that we are still in time to build the Web3 that we were promised. But only if we dare to also build — and use — the oracles that it deserves.

From where I stand at the Witnet project and the Witnet Foundation, we have always been committed to this vision of radical technologies that set us free.

We pride ourselves on being at the forefront of that movement. And our hope is that more organisations and builders join us in this journey to make a safer, brighter future for Web3.

**Website | X | Telegram | Discord | LinkedIn | Newsletter | YouTube | Reddit**