Chronicle, The First Oracle to Deliver on Scalability & Cost-Efficiency: An Interview with Founder, Niklas Kunkel

Chronicle Protocol is more than just the Oracle of MakerDAO. It stands for values such as verifiability and accessibility - but it’s the cost-efficiency angle that is piquing the interest of many in DeFi, and understandably so.

Via an in-house developed next-generation Oracle cryptographic primitive, called Scribe, Chronicle Protocol claims to have cut the gas usage of their Oracles by over 60% and up to 80% vs. Chainlink.

We talked to Founder, Niklas Kunkel, to understand how Chronicle has achieved this, but also how this compares with other Oracle protocols in the space, such as Redstone and Pyth, that have claimed to crack cost-efficient & scalable Oracles:

What is Scribe? And how does it deliver considerable gas savings for Oracles?

“Scribe is the culmination of over a year of diligent R&D in pursuit of a single goal, to solve the Oracle scalability problem. Unlike any other Oracle, Scribe has a constant O(1) update cost. In other words, Scribe has decoupled the fundamental Oracle trade-off between security and cost.

In the past, Oracles have had to limit the number of Feeds, also known as validators, in order to keep Oracle gas costs at sustainable levels. However, the end result is an Oracle that’s neither secure nor scalable. Scribe can sustainably scale to thousands of Feeds unlocking new use cases for dapps via secure high throughput data.

If you’re interested in the technical, Scribe achieves this breakthrough in scalability through a novel algorithm pioneered by Chronicle called Optimistic Schnorr. Schnorr signatures are a cryptographic signature aggregation scheme utilized to secure Bitcoin. This enables the compression of price data from any number of Feeds into a single Schnorr signature. This is perfectly suited to L2 blockchains whose transaction costs predominantly stem from the data they publish to Ethereum.

On the other hand, to achieve scalability on Ethereum where compute is expensive, Scribe makes the Oracle optimistic. An optimistic Oracle doesn’t verify the aggregated Schnorr signature to update the Oracle. Instead, it verifies a promise from a single Feed that the Schnorr signature is correct in the form of a standard ECDSA signature. The price is set as an optimistic price, and kicks off a challenge period during which anyone can verify the Schnorr signature to prove an optimistic price is fraudulent. Challenging an optimistic price successfully rewards the challenger with ETH and bans the Feed that issued the promise. To decentralize the challenge mechanism, MEV searchers scan every block for challenge opportunities out of their self-interest in the potential ETH reward.

By only verifying the promise, Scribe achieves a hyper-optimized Oracle update which only costs 66,350 gas. This is 60% - 80% lower than other Oracle protocols. Furthermore, because of Scribe’s aforementioned constant O(1) runtime, Scribe can achieve this cost reduction with many multiples of validators more than any other Oracle.

When you consider that a Chronicle Oracle costs less to update than a native ERC20 transfer, it’s truly remarkable what the team has achieved with Scribe.”

How is this different from those claiming to have already delivered cost-efficient Oracles?

“Looking at the Oracle landscape today, “pull”, or “on-demand” Oracles have emerged that claim to have solved scalability. In contrast to traditional “push” Oracles, in which the Oracle protocol pushes Oracle updates on a regular basis, pull Oracles have their Oracle updates bundled into a user’s transaction every time a user interacts with a dapp.

The benefit of this model is that the Oracle is updated to the real-time price at the exact moment a user completes an on-chain transaction on the dapp.

Proponents of this model present it as a solution for scalability. The reality is more nuanced. The Oracle update still costs exactly the same amount in gas; it’s just updated less frequently as a consequence of most dapps being rarely used, and the end user now shoulders the cost to update the Oracle rather than the Oracle provider or dapp.

We don’t define Scalability or Cost-Efficiency as, if you use it less, it will cost you less. In my opinion, this isn’t an innovation in scalability. This is a marketing gimmick to transfer costs from dapps to users. At Chronicle, we’ve addressed the underlying engineering challenges.”

Are there any risks associated with this model, why wasn’t it adopted by Maker and other original Oracle users from the outset?

“At first glance, pull Oracles may seem appealing to dapps as a cost-saving measure. However, it opens the door to a whole host of risks.

The most precarious risk for protocols is that as gas prices increase, so do their user’s costs. Eventually, this reaches a breaking point where dapps begin to cannibalize their userbase, hemorrhaging users due to the excessive fees they pay to update the Oracle each time they use the dapp.

This is completely antithetical to the startup bootstrapping ethos of subsidizing user costs to accelerate user acquisition. Rather than subsidizing costs, pull Oracles burden users with additional costs. Historically, that has not proven to be a successful strategy.

Furthermore, once users are responsible, Oracle costs become out of sight, out of mind for the protocol. This could easily lead to a scenario where protocols may not delegate the appropriate resources to optimizing their usage of Oracles because it no longer has a direct effect on their business (i.e., the gas fees they would usually pay to update their Oracles). Protocols are essentially driving blind behind the wheel. This is a flawed approach that inflicts real pain on users.

From the point of view of the broader ecosystem, the ‘pull’ model leads to unnecessary bloat in demand for blockspace, raising gas costs for everyone. Pull Oracles update independent instances within the dapps that utilize them. This means an ETH/USD pull Oracle used by dapp A is independent from an ETH/USD pull Oracle used by dapp B. Push Oracle are far more efficient as all users of an Oracle update and read from the same universal instance.”

As Scribe is a fundamental development, does this mean the optimization would carry over to Chronicle’s own version of a pull Oracle?

“Chronicle is leading our launch with push Oracles. They are significantly simpler to integrate for customers than pull Oracles and, due to Scribe’s scaling technology, can be updated frequently in a cost-effective manner that dapps can afford.

However, Chronicle is also developing a pull Oracle, one that removes the negative externalities plaguing pull Oracles today. Scribe’s optimization of the underlying Oracle update cost means it can be applied in both a push and pull configuration. A scribe-based pull Oracle has all of the benefits of real-time data while alleviating the pain point of overburdening users with expensive Oracle updates. Truly the best of both worlds.

Unlike existing pull Oracles, Chronicle pull Oracles update and read from a single universal Oracle instance. This means that all dapps can benefit from Oracle updates done by one another. Users of dapp A can benefit from an Oracle update done by users of dapp B.

This enables significant cost-savings for users, which when combined with Scribe’s already low cost on-chain, alleviates the problem of users fleeing dapps as gas prices rise. The univeral Oracle instance also reduces blockspace bloat, being a good citizen of the network and keeping gas prices lower for all.

Finally, where are Oracles going from here? More optimized? New verticals?

“Scribe is close to the limit in terms of scalability optimization. In general, it is getting to the point where it doesn’t make sense to devote the resources to squeeze out further improvement from here unless it is substantial.

I see the Oracle landscape evolving more in the direction of functionality. The scalability unlocked by L2s is enabling exciting new use cases for dapps, and Oracles need to evolve to meet their demands.

For example, the asymmetry of rates in DeFi, which are predominantly driven by demand for leverage, and rates in TradFi, driven by central bank monetary policy, has led to a unique product market fit for Real World Assets (RWA).

As TradFi institutions look to DeFi to obtain cheap credit, and DeFi protocols look to TradFi markets for higher yields, Oracle infrastructure needs to evolve to link together the TradFi and DeFi worlds with automation and trustless systems to enable RWA at scale. The Financial world is going to become more connected, and the lines of TradFi and DeFi will start to blur. Oracles are at the center of enabling this transformation.”

About Chronicle Protocol:

Chronicle Protocol is a novel Oracle solution that has exclusively secured over $10B in assets for MakerDAO and its ecosystem since 2017. With a history of innovation, including the invention of the first Oracle on Ethereum, Chronicle Protocol continues to redefine Oracles. A blockchain-agnostic protocol, Chronicle overcomes the current limitations of transferring data on-chain by developing the first truly scalable, cost-efficient, decentralized, and verifiable Oracles, rewriting the rulebook on Oracle data transparency and accessibility.

Learn more about Chronicle Protocol and its transformative Oracle solutions by visiting Chronicle Labs. Stay updated by following Chronicle Protocol on Twitter and join the community in Discord.