Oracles Got Boring. How Did We Get Here?
Oracles power DeFi, yet innovation has stalled. Why do oracles remain outdated and what’s needed to make them truly decentralized and trustless?


Let’s be honest: oracles have become one of crypto’s most stagnant pieces of infrastructure.
When DeFi summer hit in 2020, oracles were the hottest thing. The market valued them for their critical role in the blockchain landscape—connecting smart contracts to real-world data, enabling complex financial products, and fueling the explosion of on-chain use cases beyond trading, creating the awaited open financial ecosystem.
Fast forward to today, and nothing has changed. The same old primitive data feeds power most of DeFi, with almost no fundamental innovation in how data is sourced, verified, or delivered. Aave, Uniswap, Morpho, Euler, Aerodrome—these protocols have iterated and evolved, but oracles? Still running on the same dusty infrastructure.
So how did we get here?
Why Oracles Stopped Evolving
There are a few reasons why there’s been almost no innovation in the oracle space:
If It Ain’t Broke, Don’t Fix It
Oracles just work. And that’s the problem.
When you’re dealing with price feeds that power billions of dollars in on-chain transactions, the last thing you want is unreliability – one bad oracle update can lead to mass liquidations, protocol insolvency, or outright exploits (see: Mango Markets, Venus, and countless oracle-based attacks).
Developers know this, so most don’t even try to improve or replace oracles. They stick with what’s been battle-tested, even if it’s centralized, intransparent, and outdated.
No Incentives for Real Innovation
The real issue? There’s no economic reason to build a better oracle.
Sure, oracle providers get paid for deploying oracles for X feeds on Y chains, but because of point #1, oracles have no reason to develop their architecture further. They have a working model, so why take risks by decentralizing further? Oracle users generally prefer battle-tested, reliable oracles.
To draw a similarity: nobody wants to transition to electric cars simply because your trusted gas-powered Toyota works fine and takes you to work every day.
As a result, today we’ve ended up in a classic crypto paradox: we build decentralized systems on top of centralized infrastructure because it’s easier and safer.
The Off-Chain Bottleneck
Unlike most blockchain-native protocols, oracles live in a weird limbo between on-chain and off-chain.
A lending protocol like Aave exists entirely on-chain—every deposit, borrow, and liquidation is triggered and recorded immutably. But oracles? They require data from external or off-chain sources, such as market data from APIs and centralized exchanges. That’s when things get complicated.
This dependency on off-chain data makes oracles harder to decentralize. Early solutions tackled this problem by creating a network of nodes (third-party and/or own) that fetch data pre-aggregated off-chain.
Unfortunately, not enough attention was given to the fact that these off-chain environments for sourcing and aggregation were complete black boxes. And, by doing so, they created a single point of failure for the entire ecosystem.
How Do We Fix This? The Oracle Renaissance
The only way to break the current paradigm is to rethink oracle design from first principles and leave the 2020-based oracle design behind.
Here’s what needs to happen:
Cryptography-First Oracles
The future of oracles is much more than nodes fetching data—it’s cryptographic verification.
Instead of trusting centralized data sources, we should use zero-knowledge proofs (ZKPs) and multi-party computation (MPC) to verify data integrity. zkTLS, for example, allows an oracle to fetch data from an HTTPS website and prove its validity on-chain without trusting a middleman.
This eliminates the need for centralized oracle networks entirely. If cryptographic proofs can verify price data, you don’t need to trust a network of centralized nodes.
Fully Decentralized Data Feeds
Current oracles rely on private, off-chain data providers, which means prices are determined by centralized sources (e.g., Kaito, CoinMarketCap, and CoinGecko). Instead, we need open-source data aggregation, where oracles pull prices directly from order books, AMMs, and DEXs rather than relying on opaque off-chain APIs.
This would eliminate hidden attack vectors like front-running and data manipulation.
Restaking as Oracle Security
Right now, oracle security is based on reputation—node operators are trusted because they have a history of providing accurate data. But this is not crypto-native security—it’s just a Web2 trust model slapped onto Web3 infrastructure.
Instead, oracles should use restaking incentives. Validators should have to put real economic value at stake, which can be slashed if they provide incorrect or manipulated data.
Permissionless Oracle Networks
If you want to run an oracle node today on a popular oracle platform, good luck—it’s mostly not permissionless. You need to be whitelisted, meaning oracle entities ultimately control who gets to be a data provider.
This is not decentralized.
The next generation of oracles needs to be open-participation, allowing anyone to contribute data as long as they meet cryptographic security thresholds. This would make oracle networks truly open and decentralized and break the current oracle cartel, promoting real competition in the space.
Final Thoughts: Who Will Build the Next Oracle Standard?
Oracles shouldn’t be boring – they should be one of the most exciting areas of innovation in crypto.
Instead, we’re stuck in a stale, centralized system where a single provider controls most of the industry. DeFi has evolved in every way – yield strategies, liquidity models, governance mechanisms – but oracles remain a bottleneck.
The solution isn’t another black box oracle solution – it’s a fundamentally different way of thinking about how blockchains interact with real-world data.
DIA Lumina: Building the v2.0 of Oracles in 2025
The future of oracles demands a fundamental shift in design – a move toward trustless, verifiable, and on-chain-native architectures. At DIA, we are working relentlessly to build this next-generation oracle infrastructure, reimagined from the ground up, and it’s coming to Mainnet very soon.
Introducing DIA Lumina: the first fully on-chain oracle network.
- Decentralized data sourcing: Data is sourced via an open network of ‘Feeder’ nodes. Anybody can run a Feeder, bring data to the Lasernet chain, and earn rewards for the work. The network operates in a fully open and permissionless fashion.
- Unmatched asset support: With Feeders, any data source can be integrated, therefore any asset can be supported. DIA currently supports over 3k assets– thousands more than the runner-up with centralized systems.
- On-chain data storage & aggregation: At the core of Lumina is Lasernet, a layer-2 rollup that acts as an on-chain environment for data to be stored & aggregated openly, and verifiable. This is done via smart contracts that anyone can deploy and remain immutable.
- Two-level security: We are currently building the first oracle with such a setup (coming later this year), to disrupt the oracle security landscape:
- Cryptographic: integrating zk-proofs and zkTLS for data integrity at scale. This will be particularly useful for off-chain data (like stocks, forex, CEX, RWA and other web2 data.
- Cryptoeconomic: running an active validated service to leverage the security of the Ethereum network via restaking.
DIA is setting the foundation for the next decade of oracle innovation, ensuring that oracles evolve into truly decentralized, verifiable, and scalable infrastructure for DeFi and beyond.
Let’s make oracles exciting again.