The Oracle is Dead

Part I: Stork announces the death of the traditional oracle model.

The old model of onchain pricing oracles has surpassed its useful life. In its place, we offer up a new approach to data provisioning: The Open Data Market.

But first…

Oracle V1 - The Old Gods

Limits.

The first wave of oracles emerged in a nascent blockchain landscape with limited applications. Their singular focus was putting spot prices onchain. While this was a crucial service at the time, the blockchain ecosystem has rapidly outgrown this simplistic model.

When we began building Stork in May 2022, we found the oracle landscape stagnant—little had changed since the initial launch of oracles in 2017. Early entrants established a near-monopoly, which stifled all competition and innovation. Their approach was straightforward but costly: node operators fetched off-chain data, signed it, and sent it to a smart contract – a process which suffers from many inefficiencies:

• Blockchain projects wait 12-18 months for an integration
• Integrations cost millions of dollars
• System only supports the spot price for a handful of cryptocurrencies

It was an open secret that many builders found the top oracle protocols to be lacking. Yet the power of the monopoly persisted, and the tired dogma remained: "You need an oracle, and this oracle will be seen as a public stamp of approval."

However, the onchain landscape has exploded. With the emergence of dozens of new blockchains, hundreds of new primitives, and thousands of applications with diverse needs, "just the spot price" and a "one-size-fits-all approach" are woefully inadequate.

This inadequacy in the oracle market has led to interesting behavior. Some protocols, especially perpetual futures DEXes, engaged in what we call “oracle theater.” They would mention an oracle provider in their documentation while actually using in-house price feeds.

This kind of theater further highlighted the concerns about the centralization of data provisioning as well as the immediate need for more flexible and diverse oracle solutions in the rapidly evolving blockchain ecosystem.

In House Oracles - The Disillusionment

Risk.

One way to bypass the limitations of the old model was for protocols to build their own in-house oracle. Though potentially more flexible than the old oracle solutions, this also proved problematic in the following ways:

• Trust: Protocols can lose user trust when incentives are misaligned, e.g. ability to profit from manipulating their own price feeds.
• Expertise: The burden of sourcing data, finding node operators, and handling development work falls entirely on protocol teams who usually aren't experienced with building pricing infrastructure.
• Reliability: In-house solutions often rely on single data sources. If these sources unexpectedly change, it can lead to protocol outages or inaccurate pricing. Even minor changes can cause major disruptions without proper redundancies.

Time and time again these in house efforts have been  abandoned due to these difficulties – or worse, suffer an exploit stemming from a fatal misconfiguration or implementation error. 

Data Walled Gardens - The False Idols

Suppression.

The alternative to in-house solutions was engaging newer oracle providers. While these offer improved speed and a broader range of assets, they still fall short of market needs. 

These new oracle providers act as “data gatekeepers” who are unresponsive unless substantial fees are paid. They may have built networks of publishers but these oracles aren't incentivized to truly open up access to that data. Their goals are fundamentally misaligned. They will alway prioritize their own profits over allowing truly decentralized innovation.

Onchain innovation needs open market dynamics – not centralized, walled gardens of data.

Most importantly, high-quality data must be fully customizable to builders' needs.

No more gatekeepers. No more limits.

Conclusion

It's time to reimagine our approach to onchain data to create more nuanced and effective solutions.

Check out Part II to learn about Stork's solution: The Open Data Market.