Oracles, originally invented to deliver price feed data, have grown to enable much more, including cross-chain token bridges, random number generation, and cross-chain messaging. Yet the commercial landscape remains relatively undeveloped.
Most people in the on-chain space have heard of an Oracle, but fewer people know how integral Oracles are to many of the products and protocols we use every day. Even fewer know what it costs to build or use an Oracle.
The current landscape is fragmented, the quality of the Oracles at your disposal can feel like a gamble. Even from the ‘leading’ providers, there are cases of poorly designed and supported Oracles leading to illegitimate liquidations of DeFi users.
A Pyth Oracle reported the BTC price as low as $5402 when BTC was trading over $40,000
Moreover, particularly for price feed Oracles, the service level agreement between Oracle provider and user is either unclear or non-existent. Many of the original price feed Oracles were designed to be permissionless. This sounds great, but in practice, it means anyone can read the value the Oracle reports on-chain for free, meanwhile, the Oracle provider is paying the, sometimes large, gas cost to update the value the Oracle reports regularly.
This incentivizes Oracle providers to operate as leanly as possible, providing little guidance on how to safely and securely utilize the Oracle or technical support for when
things go wrong. Oracles are ‘mission critical’ infrastructure securing billions of dollars of value, end users need more support from Oracle providers.
An unsustainable model
Protocols still operating legacy permissionless Oracles have little alternative to spending fundraising capital, or market-selling their token to cover the Oracle operating costs (chiefly gas & devs). There are even stories emerging of providers issuing ‘requests’ to dapps using the Oracle permissionlessly to sign a contract and start paying, despite the Oracle being permissionless.
In the medium-long term, this model is not commercially viable. It’s also not transparent & forecastable, nor preparing the market of business users for the eventual switch to a pay-to-access model that will inevitably come as the sector matures.
This is already the case with most more recently developed Oracle utilities, such as verifiable randomness and cross-chain messaging, where access is gated by paywalls.
Security vs. Operational Cost
Much of the current Oracle business model and commercial landscape is a symptom of the limitations of the technology. Oracles are resource-intensive to build safely, and exorbitantly expensive to operate on-chain due to gas fees, particularly on chains like Ethereum.
This has led to many being highly centralized, with a broad variety of levels of security. Why? Oracle security derives from the validator set, the more validators (or actors) you have attesting to the truth of an Oracle-reported value, the safer the Oracle is from that value being manipulated. Much like Ethereum, any attacker would need to gain control of the majority of validators to manipulate the consensus and convince the Oracle to report an illegitimate value.
For context, there is a lot of value for a hacker to manipulate the value reported by an Oracle, as it would effectively allow them to drain the liquidity of a DeFi protocol secured by the Oracle.
This is true for every Oracle provider, as all use the same ECDSA signature scheme to secure the Oracle. 1 validator = 1 signature, and each ECDSA signature costs gas to verify on-chain. As a result, all Oracle providers limit the number of validators and, therefore, signatures, in order to manage the operational cost of their Oracle. Overall, this reduces the security of the Oracle protocol. In some cases, the number of validators can be dangerously low, such as 3.
A fundamentally different approach
As a primitive that underpins everything from crosschain bridging to DeFi and DePIN, this security and decentralization tradeoff with cost is severely limiting the future upside of Oracles.
However, there is light at the end of the tunnel. A new Oracle primitive debuted by the recently spun out Oracle team of MakerDAO,
Chronicle, utilizes a signature aggregation scheme called Schnorr to solve the security vs operational cost tradeoff.
The Chronicle Labs team has created a new type of Oracle called Scribe, which tackles the ‘Oracle problem’ at a cryptographic level and can scale to any number of Validators, without increasing operational cost.
Furthermore, Scribe has also unlocked huge gas savings, bringing the Oracle update cost down by a huge margin on L1 & L2. In comparison to other providers, that equates to a 6x improvement on Chainlink, a 3.5x improvement on Pyth, and a 2.7x improvement on Redstone.
Schnorr signature cryptography has been utilized in Bitcoin for a number of years. The Chronicle Labs team are the first to implement Schnorr to create this new and novel Oracle. If you’re interested in the technical detail of how this is achieved, Messari covered it
here.
Furthermore, as Scribe has been designed as a single implementation across the EVM, new Oracles can be rolled out quickly and efficiently on any EVM chain, allowing Chronicle to charge a far lower deployment cost than the leading providers.
Unlocking the commercial model of the future
The alleviation of the technical problems that have long plagued blockchain Oracles has unlocked a much-needed and fresh business model for Oracle providers, without compromising on security or decentralization. A fully serviced, supported, and premium Oracle service with a SaaS-like implementation. I.E., Subscribe to the Oracles you need and pay for them only as long as they’re required. Permissioned but cost-predictable.
This approach is further embellished by Chronicle’s unique attention to verifiable data through the construction of an
on-chain dashboard that allows any user to track the Oracle-delivered data end-to-end and cryptographically verify the signature of each reported Oracle update.
The overall result of this approach is a professional and predictable service designed to secure billions of dollars of value in a
verifiable way. If the ‘future of finance’ is going to be on-chain, then financial providers are going to require a more transparent and supported option for the delivery of data.
