Chronicle’s oracle stack was born within Maker in 2017 as part of the engineering effort behind the DAI stablecoin. That year, the team developed Ethereum’s first onchain oracle. Originally built to serve the early architecture of what is now Sky Protocol, Chronicle has since undergone several iterations. In September 2023, it spun out to operate independently, continuing to power the Sky ecosystem while expanding into the broader web3 space. This interview with Paweł Zaremba, Senior Engineer at Chronicle, explores the evolution of Chronicle and its different oracle designs.
Can you tell us a bit about the history of the different versions of Chronicle Oracles?
The first iteration of Chronicle contracts used a medianizer contract that relied on price submissions from a set of validators. A validator is essentially a price submitter—they collect data from various sources and submit it onchain. Each validator sent their price as an individual transaction, and once enough data was collected, the contract sorted the values and computed the median directly onchain.
While this model guaranteed decentralization, it was costly and not very efficient. Onchain sorting is an expensive operation and doesn’t scale well with an increasing number of validators.
What changes were introduced in the second iteration to improve scalability?
To address these scalability limitations, the second iteration of Chronicle’s oracle system was introduced. Instead of submitting prices directly onchain, validators began broadcasting signed messages over a gossip network. These messages were collected and aggregated offchain by relays, which then sorted the data and submitted a single transaction to the medianizer. This significantly reduced the number of transactions and onchain computation required.
Additionally, this architecture was blockchain-agnostic, allowing the protocol to expand more easily across different networks. However, while gas costs were reduced, one of the major remaining expenses was the use of the ecrecover function—used to recover Ethereum addresses from digital signatures. In both the first and second iterations, each validator’s signature needed to be verified separately, meaning one ecrecover operation per validator.
On top of that, there was the issue of calldata costs. Every validator’s signature, value, and timestamp had to be included in the transaction’s calldata. While this isn't particularly expensive on Ethereum mainnet, it becomes costly on L2s—where execution is cheap but calldata is expensive due to the way L2s post data to L1.
This challenge led to the implementation of Schnorr signature aggregation, which formed the foundation for the third iteration of Chronicle oracles: Scribe.
Scribe shifts the burden of signature computation offchain, using Schnorr aggregated signature (MuSig2) to combine multiple validator signatures into a single compact "super-signature" submitted onchain. This dramatically reduces calldata size.
For Ethereum mainnet, Scribe Optimistic was introduced—applying principles similar to optimistic rollups. In this model, a single validator vouches for the entire data aggregation and submits the update using just one ecrecover. A challenge period follows during which anyone can permissionlessly verify the data. If someone finds an issue, they can submit an onchain challenge. If the challenge is correct, the original validator is banned (removed), the challenger is rewarded, and the bad data is discarded. If no valid challenge occurs within the period, the data is finalized.
This approach significantly reduces gas costs and makes updates infinitely scalable: we can add more validators without increasing the cost of optimistic updates. Only the offchain verification and onchain challenge processes become more expensive—and those costs are only incurred if someone tries to submit a bad update, which should rarely, if ever, happen. And if it does, there's a 1 ETH bounty for challengers to stop the finalization of the incorrect price.
Looking Ahead
Each iteration of Chronicle’s oracle architecture has been a step toward greater efficiency, scalability, and adaptability. From fully onchain medianizers to aggregated signatures and optimistic validation, the journey reflects a deep commitment to innovation. As new use cases and ecosystems emerge, Chronicle continues to evolve—pushing the boundaries of what’s possible in decentralized data infrastructure.
