Oracles Shouldn’t Be Able to Pick Winners

Blockchains act like immutable single sources of truth. But they are unaware of the world around them. So where does this ‘truth’’ come from? Oracles.

Oracles are a crucial piece of infrastructure that informs blockchains and the apps built on top of them by giving them specific pieces of external information. In this context, many think of oracles as pipes that move data from the outside world (or from a different network) onto a specific blockchain. Price data from, say, GOLD/USD in, on-chain transaction out. Seems simple enough.

However, this analogy hides an important caveat. Since oracles deliver data to blockchains and their applications, Oracles are basically a control point for what is considered to be ‘true’ by the chain. And wherever there’s a control point, there is power.

“Power tends to corrupt, and absolute power corrupts absolutely” — Lord Acton

Centralized power introduces conflicts of interest, which can inevitably lead to disaster. Having suffered the effects of centralized control, every blockchain builder should ask themselves: Is my access to data controlled by anyone? And if so, can I be throttled, delayed, deprioritized, or blocked?

Dependencies Break Neutrality

In theory, blockchains are neutral systems. Whether you’re submitting a transaction, deploying a contract, or participating in governance, there is one set of ‘rules’ that applies equally to all participants. In practice, this neutrality can break down at the edges, like where off-chain systems impact on-chain execution. While blockchains and protocols might be decentralized, they inherit the single points of failure of the centralized infrastructure they depend on.

Oracles are one of those dependencies.

If an oracle operator can decide which users’ feeds update faster, delay or throttle updates for certain users, selectively degrade service during volatile periods, or quietly withdraw support from ‘undesirable’ users, then neutrality is gone. Even if the data itself is accurate.

This isn’t about malicious intent (although without neutrality, there is no protection from that either). It’s about incentives. Centralized systems create conflicts of interest that fester. An oracle doesn’t need to falsify data to influence a market, for example. Control over when data is published on-chain is often enough. Selective latency or different levels of prioritization might make sense economically if an oracle operator depends on a small set of high-value customers, is strategically aligned with certain protocols, has exposure to a specific trade, or simply observes prices before pushing them to the chain.

This isn’t necessarily corruption. It’s just an actionable misalignment of incentives. And as long as those incentives exist, neutrality can be broken. To boil it down, if permissioned oracles can control access to data, it’s only a matter of time until they do.

Neutrality is only a guarantee when discrimination is structurally impossible, not when a provider promises not to exercise it. In other words, “trust us” should not be a satisfying answer for builders.

Trust vs Verify

“Doveryai, No Proveryai” — Classic Russian Proverb

“Trust, but verify,” or better adapted to blockchain: Don’t Trust, Verify. Most oracle systems ask users to trust that latency is consistent among users and that no one is getting special treatment behind the scenes.

“Behind the scenes” is the perfect description because the problem is that this layer of trust is opaque by design. You literally can’t verify it.

If two protocols use the same oracle to receive the same price feed, but one consistently gets updates earlier during market stress, how would you prove it? If an oracle provider sees a sharp price movement, they could delay publishing that update on-chain just long enough to let affiliated traders exploit a stale price on another protocol. If an oracle can take a look at your data feed before delivering it to you, what’s stopping them from frontrunning your app or letting someone else do so? You wouldn’t know if they did.

Most oracles are black boxes. Without transparency, there is no verifiability. And without verifiability, there’s no way to guarantee that your app or chain is not relying on centralized dependencies.

On-chain Verifiability

When oracles publicly show the work behind each price update they become auditable. Anyone can see:

• who requested the update
• when an update was produced
• when it landed on-chain
• how often updates occur

Knowing this, it’s possible to verify whether or not different users are getting different treatment. Latency also becomes publicly measurable, so users are able to verify the speed at which they (and other users) are getting oracle updates. In other words, preferential treatment becomes impossible to hide, and an oracle becomes provably neutral, inheriting the trustlessness of the chain.

Why Neutrality Matters More Than You Might Think

Oracle neutrality, or lack thereof, directly affects market outcomes in DeFi.

In lending markets, price differences decide who gets liquidated and who doesn’t. A manipulated price could be catastrophic. In perps and derivatives, milliseconds matter. Your oracle provider could throttle your feed and give you extra latency to benefit your competitor. In emerging permissionless markets, like those powered by HIP-3, oracle access can determine which protocols survive at all. Imagine your oracle provider randomly takes your feed down…

But neutrality doesn’t (and shouldn’t) mean everyone gets the same speed for free. It means the rules for accessing data and the speed it is delivered in are public and programmatic, not decided behind closed doors by a sales team that doesn’t give two shits about decentralisation.

If an oracle can quietly ‘pick winners’ by prioritizing certain users over others, a market stops being permissionless, even if everything else is on-chain. That’s a systemic risk for DeFi.

A Different Way to Think About Oracle Features

So how do you pick between oracles? Data accuracy and uptime should be the bare minimum. Speed, or minimized latency matters too. But, a more important question is: Can this oracle prove it treats everyone the same?

If the answer has to do with reputation, off-chain contracts, or anything involving trust, that should be a red flag. The answer you want is “yes, and you can check the chain yourself.”

Infrastructure Should Preserve the Nature of the Blockchain

Neutrality has to be built into the architecture of an oracle.

If your oracle systems are on-chain, transparent, and verifiable, they don’t just deliver data, they preserve the underlying features and core promises of blockchains.

For readers interested in what fully on-chain, neutral, real-time data delivery looks like in practice, look no further than Switchboard’s On-Chain Subscriptions.