Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Niklas Kunkel: Chronicle – Ethereum's First-Ever Oracle

Episode Date: October 6, 2023

Back in 2017, there was no DeFi as we know it today, yet MakerDAO were already envisioning and building towards what they thought to be a certainty. The backbone of DeFi is represented by stable coins, and MakerDAO quickly understood this: they set out to build a decentralised stable coin, $DAI (and its precursor $SAI). Being collateral-backed, the smart contract needs to know the value of that collateral, but any off-chain price data is not readily available on-chain. This is where oracles come in and provide data feeds on-chain. MakerDAO’s internal oracle has been active since 2017 on Ethereum and has recently branched out, forming Chronicle. By using aggregated Schnorr signatures, Chronicle solves the problem of oracle cost-efficient scaling.We were joined by Niklas Kunkel, founder of Chronicle, to discuss the challenges and tradeoffs that oracles regularly face, and how Chronicle is solving them, continuing the ethos of early MakerDAO.Topics covered in this episode:Niklas’ background and the early days of MakerDAOHow MakerDAO evolved over time and the adoption of DAIMakerDAO’s core principlesWhy Chronicle branched out from MakerDAOOracle challenges & tradeoffsOracle validatorsBusiness model for oraclesProviding oracle services to different blockchainsSchnorr signaturesChronicle’s supported chains and oracle offeringsReal-world assets (RWA) and credit delegationEpisode links: Niklas Kunkel on TwitterChronicle on TwitterMaker DAO on TwitterThis episode is hosted by Sebastien Couture & Felix Lutsch. Show notes and listening options: epicenter.tv/516

Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Sebastian. I'm here with Felix. Today, we're speaking with Nicholas Kunkel. He's the founder of Chronicle. Chronicle is an Oracle protocol providing data for blockchain applications. And it's also a spin-out of the Maker protocol. So Nicholas and his team were basically heading the Oracle team at Maker. and that team has now spun out to form Chronicle as a standalone product. So we'll be diving into Chronicle today, understanding how it works, and also talking about the Oracle market more broadly. Nicholas, thanks for joining us today.

It's a pleasure. Thanks for having me. So you've been in the space for some time. Obviously, you were part of the Maker team and heading the Oracle team there. how did you get involved with Ethereum and how do you start working with the Maker team? Actually quite funny. I was at IBM in the research department and we were actually working on Hyper Ledger, which was this permissioned ledger. And then the future of blockchain. Yeah. Yeah. It was the future. Effectively, IBM had missed the boat on cloud completely. They were very upset. and they said the next thing that comes along, like we're going big and we're going early.

And to their credit, they were very, very early on blockchain. They just got the public private ledger kind of equation wrong. And so the Ethereum white paper kind of came out and I read this and I was like, oh, wait, like, you know, public general compute layer. That's the thing. You know, I go to my boss and like, all right, you know, we should we should throw away everything we did, right? we should just use this Ethereum stuff and they're like, no, that's just vaporware. I think somewhere like, I think like a year later, like a main net actually launches and we're like, I'm like, look, it's real.

Like, let's go. Like, and I was quickly told, you know, shut up, get in line. Right. So I made my way over to the Ethereum community. And while like the community was great, there were not actually that many, like, like real, let's say like protocols to, uh, to work and contribute to. There was a lot of kind of kind of like hobbyist stuff going on, but, uh, and with with grand ideals, but not a lot of people just working full time on building something. Um, and I think back then there were kind of like

the three big teams were like, uh, I think Auger, Digixtow and, uh, and Maker. Um, and so out of those, uh, I, I kind of chose Maker because, uh, I, I kind of chose Maker because, uh, It just seemed like a circle of like these individuals where I felt like the dumbest person in the room. And that always seemed like a very productive environment for learning. Yeah, that's super interesting. I think also like interesting to hear like these three teams, essentially all defy applications, if you want to say it like that, right? Digi Star was about tokenizing gold.

So interesting that the early teams were already working on like, I guess what became the the biggest use case. Sure. I mean, if you think about what Digixtow was, I think it was just a matter of like, you know, wrong timing, right? Today, like a Digixtow would be an RWA, right? A token that is like a stable coin backed by a gram of, you know, physical gold in the real world, like that's a real world asset.

You've brought gold onto the blockchain, right? That would be huge in the RWA narrative, right? now. Right. So also, like of these three, I guess, like you said, the timing was wrong there, maybe. And also like Augur, sort of the projection market thing didn't turn out like that well, let's say. Or it's still like sort of, it's kind of still around, I guess, more so than with Polly Market maybe, but also I guess, yeah, Maker definitely is the most successful out of the stream, maybe because of you also. But yeah, or maybe can you tell us a little bit about what, about the early days at Maker

and sort of, yeah, what was so special about it? Yeah, I mean, in the early days of Maker, like, there was nothing, right? There were no dexes. Like, this was way before an ether delta or anything. So

we were like, well, we want to make die, but in order to make die, we have to build all this other stuff first, right? So we made the first decks. There were no Oracle So, you know, conceptually they existed, but no one had actually made like an Oracle protocol that anyone could use. No one was planning to make one.

So we made the first Oracle. We deployed that in, I want to say, June of 2017, in conjunction with like the prototype for SAI. I think it was called ProCi. And that protocol, I mean, one was like the first oribles on Ethereum. But two, if you think about how long that that was running, I mean, it's been running consistently since then. And like six years at this point on Ethereum, I mean, that makes it one of like the oldest kind of almost like a grandfather-like protocol, if you will. So we're quite proud to have built something that really lasted and withstood the test of time. What were the early visions for Maker and what were they trying to achieve at the time?

And contrast that with what Maker has become now. How different has that vision played out? Sure. So I think with any kind of startup with a great, with a grand vision, you always have to make kind of adjustments over time. You have to imagine, right? When the idea for Maker was conceived, when the Maker white paper came out, there was no defy.

The thing that I give like, you know, Runa and Nikolai, the two co-founders of Maker Dow so much credit for is that to them, it wasn't like a possibility that this like vibrant defy ecosystem would exist, right? it was a certainty. And they were building, you know, for this like puzzle piece in that certain future that they envisioned, right? And, you know, I think founders always have kind of visions of the future. But like, you know, Runa and Nikolai were really acute and really kind of got it right.

But even, you know, within that, right, you can say, okay, well, in the future, there's this vibrant defy ecosystem. there's going to need to be some way to transact value that is stable, right, because people don't want to transact in something that's volatile, right? Like if you're a merchant, you don't want to accept something that's volatile, right? You have thin margins. If you don't get paid in something stable, your margins blow up, right? And you don't have a sustainable business.

As a customer, you don't want to hold anything volatile, right? because you don't want to see your wallet your wallet like value like fluctuate right you want to have like a stable purchasing power so i think the the need for a for a stable coin was quite clear from a theoretical perspective um but it what you know i i i think there were kind of uh this idea that the consumer side of using crypto right like in their everyday lives for spending and for earning, that that would kind of keep in pace with the more, let's say, financial infrastructure, right? And I think as we've seen the past couple of years,

while there has been consumer adoption of crypto, defy has just like outscaled that type of adoption massively. Yeah, certainly. I mean, I think that the role of maker in early defy, I think a lot of people who maybe are using defy now, I don't want to say it's forgotten, but because Stap of Corners are such an important part of Defi and obviously USDC has taken up the larger part of the market,

it's something I think it's worth remembering that in the beginning, when we didn't have USC, we had Dye and Dye was the only real way to get stability, like to get get out of risk assets in early defy and play like a tremendously important role. So I think it's like a very important public good and also something that allowed defy to basically be spawned into existence. I kind of think like the inflection point, what really hit for me was that, you know, in back in 2017, right, when we when we release Sai. the moment after we released it, Maker internally started paying everybody inside. And it wasn't like planned that way beforehand. It was just kind of like, well, like, you know, if we actually built what we said we built,

you know, if we actually like believe that like it works, like you wouldn't mind being being paid in it. Right. And I remember Andy, Andy Millennius, who was the CTO of the time, just being like, okay, we're going to start paying everybody inside. side, everyone was kind of like shrug, okay? And that's really cool, right? That's when you go from like theoretical product, you know, with like, oh, it's going to be used in the future for all of this stuff to like, no, you're like using it yourself, right? You have so much confidence in this thing you've built, right, that you're willing to, you know, kind of like stake your livelihood on it. And, and, you know, that continues today. Like even at Chronicle, like, we still pay our team and die.

Even at Maker, teams are still paid and die. Like it's a, you know, there's a lot of teams across crypto, right, that get paid and die or are willing to accept payment and die. You know, we work with auditors. We're like, can we pay you and die? And they're like, yeah, no problem. Right. So it's really beautiful that there's like, really the generalized, like, economy built around the whole thing. I think, yeah, that's really cool.

is also like something that you see in the like maker community in general, I guess we were noticing that it's often seen as like one of these most like decentralized or like pushing for decentralization in a lot of ways. I guess dye being like the most decentralized stable coin arguably maybe to the stay and that being used there is also a sign of that. But maybe you can also like expand, you know, how else this is like taking shape in in like sort of the spirit of people working on Maker and how it led you essentially to,

I guess also like now become chronicle and your own spin out from Maker. Sure. I mean, so from the beginning in Maker, there was always this focus on quality, on doing something right. You know, and you can, I think there's like this tradeoff right in the development space

where you know, you can do something fast, you can do something cheap, or you can do something with very high quality, right, and like choose to. And I think Maker was very much always maxing out on, you know, doing something at a very high quality, right, regardless of how much time it took, right? And I think we got a lot of pushback at the time, right, for being very slow to release things. but I think our vision was always, you know, that defy would scale to the billions, the tens of billions, to the hundreds of billions. So, you know, when we were thinking about like the financial mechanisms and backing for die, right, that was always the standard to what we were building to. And I think that was that was very prescient.

So I think like that ethos, you know, at this point we've kind of had like generations of like core developers that make. There's just been like several several different different kind of waves of people. But I think that that attitude towards this like we kind of like to call it like Maker Grade. I think that attitude towards doing something right, you know, that kind of has really prevailed. Especially when you see like all of the ex-developers of Maker Dow right to branching off, you know, to start. their own projects, right? You know, you see it with the Ashtna guys. You see it with the summer phi guys, right?

You see it with sense. You know, I think that prevailing attitude of kind of like maker grade has really like pollinated to those projects as well. And Chronicle is definitely, definitely among, counts that among like one of our values internally as well. let's talk about Chronicle more specifically why did you guys choose to spin out

the Oracle from from Maker as a different product and we were talking about this before the show Felix and I and I think this isn't the first like I feel like Pithe also spent out of some project I know that

in Cosmos like there's this Umi protocol, which is lending protocol, they're spinning out their Oracle as well as a product. Is this a trend or is, or are we like, is there like an Oracle spin out trend happening here? Well, so in terms of our journey out of Maker, I think it was like a very like natural and organic transition, right? You know, Maker really took this path of, you know, gradual decentralization, It did have a foundation at one point that helped bootstrap the protocol. And then the foundation said, and now our mission is done. And they really handed over the entire protocol right to the Dow.

And Maker is actually like a true Dow now, right? Like there's governance votes to onboard teams, to give teams budget, right, to approve or reject different projects. Like it's truly decentralized in every way. And so that kind of transition into the Tao, I think, was very, was like a big milestone for Defi in general. You kind of saw people have Daos, but they were always backed by these foundations that were kind of like shepherding the Tao in a certain direction. And Maker was the one to truly like, you know, like go of the wheel and let the Tao kind of lead. itself. And they should be commended for that. But I think the problem that we kind of ran into

is that the Dow was trying to do too much and it kind of was pulled in too many different directions. And so that's kind of what the end game was all about. It was about simplifying the Dow, right, narrowing its scope, right, and targeting it more towards like a smaller set objectives. And this led to like a very natural kind of like spin out of protocols from Maker, right? You see like Spark Protocol developed by Phoenix Labs, right? And Chronicle on the Oracle front. So there was a, so there's still like a very, very close partnership with Maker, right? But these are, these are independent entities, right? And they kind of just like count themselves like among like this, this maker ecosystem.

I'm also as like a partner to to Maker, but they are independent, right? They have their own independent set of objectives. And I think, you know, from an Oracle protocol perspective, like, it's great that you can, that you can have a partner like Maker where you can prove, you know, this infrastructure, this Oracle infrastructure, right, is rock solid, right? It's secured, you know, during the bull market, like Maker had, I think, around 20 billion

TVL. you know, like this Oracle infrastructure is like really battle tested, right? And then to use that, right, to bootstrap your credibility, right, to go and bring this Oracle to everyone, right? I think there's a very, there's a very natural kind of like product market fit and transition there. Yeah, we're definitely want to talk a bit about that. Like, you know, your plans of expanding sort of from being the harder for Maker to like onboard. other protocols, but I think initially, let's maybe talk about technically oracles in general, you know, and you maybe explain a little bit first what the role of the Oracle actually is in Maker,

maybe for listeners that, because we're like, I'm not talking 20 minutes, but just assuming everyone knows, maybe a lot of people know, but maybe just to refresh the memory, we go like that and you explain the role of the Oracle and Maker and, yeah, we sort of dive a bit into the tech. Sure. So in Maker and, you know, in general in DFI, right, oracles are kind of used as the like canonical source of truth, right, for any kind of data, right? And that can be, you know, that's usually like expressed in terms of like prices. So in Maker, right, if you lock up some ETH to open up a die position against, right? The protocol needs to know what the value of ETH is, right, in order to, you know, decide how much

die are you allowed to borrow, right? It needs to know what the price of ETH is, right, in order to determine which loans are, you know, at risk of liquidation, right? So, oracles are kind of like, like this critical infrastructure. You can almost think of them as like the Achilles heel of a protocol because if an Oracle ever prints, you know, eth is zero or if an Oracle ever prints like eth is $100 trillion, right? In, you know, a second the protocol pretty much blows up and goes in solid, right? So they're really like this mission critical type of infrastructure like a like the way I tell it my team is that building an Oracle is like building a spaceship. There's no room for air,

right? Like if you have a bug on a spaceship, right, you know, like people's lives could be lost, right? If you have a bug in an Oracle, right, you know, you could lead to billions of dollars just evaporating, right? So it's one of those things where you really have to be very deliberate in how you design an Oracle, right? And from a from a data, perspective, you have to be very deliberate in choosing the right Oracle, right? So, yeah, maybe like you already mentioned one challenge here in running an Oracle, right? Like a lot is at stake. Can you maybe dive deeper into, you know, some other challenges of running an Oracle? And then we, you know, go into like how Chronicle solves them hopefully.

Sure. So I think the big tradeoff. that every Oracle Protocol has is this trade-off between kind of security and decentralization and cost. And traditionally, the way this plays out is that you can, as an Oracle Protocol, choose the number of validators that you have. Do you have a lot of validators?

Do you have a very small number of validators? And that will affect the cost of the Oracle. And the cost of the Oracle, right, is like a very important part of creating a sustainable Oracle product, right? Because of gas prices multiply. I think we've been very blessed with, you know, nine-gwe, 10-gway, 15-gway kind of average gas prices. But if you think back to even just a year and a half ago, right, two years ago during the peaks of the bull market, right, there was a day where we hit 7,000 way, right? And, you know, can you imagine the costs, like the cost to operate your product, right,

literally going up, you know, 500X, right? That's incredibly difficult to deal with from a service provider perspective, but also incredibly difficult to deal with, right, from a users of oracles, right? So typically what Oracle providers have kind of done is aired on the, side of like, okay, smaller number of validators, right? Kind of good enough security to kind of keep those costs in check, right? Not updating the Oracle as frequently, right? If you do less updates of the Oracle, right, you can save on costs even more. And these are not real fixes, right? These are kind of just like Band-Aid fixes, right? What you really need to do is kind of solve

the underlying engineering problem of this linear relationship between the number of validators, right, and the costs of the transaction. And so I think that's kind of what Chronicle kind of has solved. You know, it's certainly not the entire Oracle problem,

but it's a very, very significant chunk of it that was kind of holding back the Oracle space. And I think that's what makes Chronicle quite unique. in that we have this constant time oracle verification mechanism. So that means that you can have any number of validators, right, and the cost stays exactly the same.

And the beautiful thing about this is that, you know, we have some incredibly smart people on the team who have some very good experience with gas optimizing. And so we've actually gotten the gas cost of an orciful. update, you know, again, with any number of validators, right? Could be one, could be hundred, could be a thousand. We've gotten it down to 66,000 gas, which is, to put that into perspective of how incredible that is, that is less than an ERC20 transfer. The cheapest transaction you can do on Ethereum, right, is sending eth to someone. That's 21,000 gas,

right? This is the equivalent of three of those. You know, when you compare this, to like to put this in reference to other Oracle protocols, chain link with like 10 validators costs about 280,000 to 300,000 gas. So not only have we gotten this down the cost of time to have, you know, a multiple of those number of validators, but we've even gotten the costs down like 80% compared to some of these other some of these other Oracle providers. So when you say validators, I mean, I think a lot of people think of validators as network participants that are securing a chain in the context of, say, a layer one, like Ethereum or an app chain.

What does a validator look like in the context of Chronicle or like another, like you mentioned chain link also has validators? How are these participants interacting with the chain? What kind of infrastructure are they running? What are they securing exactly? So I think the easiest way to think about oracles sometimes is like a good layer of abstraction is like a multi-sick. You have a certain number of signers, right? That's your validators. And you need like a subset of those to reach consensus around something. So in terms of what that looks like from the tech side, it's you get a bunch of, you know, actors to, you know, hopefully that, you know, have some kind of reputation attached to them, to run a client.

And they essentially, right, have their own keys, right? And what they're doing is essentially querying all of the data, processing the data themselves, right? Modeling it and then spitting out like an answer. I mean, like, okay, ETHUSD, I think it's this, right? And they sign that with their key, and then they push it to kind of a peer-to-peer layer. And so now you kind of have like all of these kind of gossiped price attestations kind of like floating around and like a big like primordial soup of like a, of, you know, like attested to information. And now you can start aggregating all of those together. And once you have enough aggregated information, right, across enough participants to reach a quorum, right?

Now this information can be pushed on chain to the Oracle. The Oracle will process all of the attested to data, right, and then publish that piece of data, right? Or publish that price. So typically, it's very, very important, right, or not. I shouldn't say typically, no, it is very, very important that the validators you choose are very credible, right? And this is something that, you know, some protocols are very open about, right? Who are the validators or in cases of some oracle protocols, who is the validator? So in terms of Chronicle, right, we've kind of gone to this approach of saying, look, there is a whole ecosystem of DAPs that people use every day, right? Maybe you have a NOSIS safe. Maybe use Masha swap to trade, right? Maybe you have like an Argent mobile wallet, right? Maybe you use a defy saver, right, to manage all of

your defy positions. And so people have built up like an implicit trust into these protocols. And so who better to run the validators for an Oracle protocol powering defy than all of the, you know, actors in the ecosystem, all of these protocols themselves. So we have like, so Chronicles validator set, right, consists of, you know, people like zero X protocol or DYDX or Gick coin, uh, Ether scan, infura, nois, and a handful of others, right? And we want to keep expanding that validator set and kind of like what we're going for is that we want to be able to go to the community and be able to say, here's an Oracle and you can trust it because it's like powered by the community. right and even though you know in theory right you can always have an oracle attack right you can always

have the the validators kind of try to do a malicious attestation right attesting to to incorrect data it kind of in practice if you have enough of the if you have a big enough validator set of all of the biggest actors in crypto you kind of just negate anything like that ever happening, right? Because it would be like the industry kind of just like cannibalizing itself and like swallowing its own tail. So our kind of mission, right, is just to kind of onboard everyone that, you know, feels very strongly, that we need to have like a truly decentralized Oracle that we can, that we all

don't have to worry about, you know, this this Oracle attack vector anymore. and that want to be a part of that. And I would say, you know, come talk to us. Let's add you. Let's, you know, have you become a Chronicle validator. And, you know, you can even use Chronicle yourself in your own protocol, right? And dog food it. Yeah, that's actually very interesting.

Like speaking also from experience, like running chain link operator with KOROS and like sort of this model of where more the infrastructure providers are more like professional validators or like. staking companies that run like infrastructure for on the daily basis versus like this model of letting the dabs run it. And I think in Pith actually a lot of their sort of validators, I guess initially at least, where like actually the data feed, the providers that actually generate, let's say the price data. So literally the exchanges and things like that. So I guess there's like different like participants you can choose. Can you maybe speak a bit about, you know,

are there issues maybe with like availability if it's like run by you know people that don't run infrastructure as their core business or you know how how are you thinking about these things or should you have like maybe validators from all these different constituents or you know I guess yeah curious to hear what you think so so I think you really want to just design a protocol that's resilient um so you know the protocol is designed that it's fine if like a handful of validators go offline, right? It's designed to expect that kind of scenario. Now, in terms of like, do we actually see that happening very often?

No, not really. These protocols run an enormous amount of infrastructure internally, and they're very good at running infra, and they have entire DevOps teams to monitor this infra and keep everything online. in practice, right, we don't really see that happening very often. They're very adept. But what I would caution is like, why do people necessarily trust infrastructure companies

as validators? Sure, they're good at running infra that stays online, but from a trust requirement, what like the security of your Oracle is relying on these entities that are your validators to be good, honest actors that, you know, the user, either the DAP or, you know, the end user that's using the Oracle or the end user of that DAF, right, that they have some kind of, you know, trust relationship with. And I would argue that these infrastructure companies are relatively unknown and they don't really have like a reputation for integrity. And it kind of seems strange to me that we would

like, you know, build these like decentralized Oracle protocols and then outsource the security to these like relatively unknown validators, right? That don't really have any reputation to protect. What kind of like are you talking about like a service company specifically or some other sort of of actor here?

So what Felix was alluding to is that there's a ton of like like entities in the space that just run infrastructure, right? Maybe it's staking infrastructure, maybe it's RPC infrastructure, maybe it's just like hosting in general, or they just run validators for a bunch of different chains, right? Yeah, like a figment or a chorus or a, you know, kiln or any one of these companies, yeah. Sure. And so you think that these companies have generally low reputation

and can't be trusted to run infrastructure? I think as a user, you should be always questioning, like, who are the validators? Like, that should be your first question when trying to choose a protocol, right? And I think it's quite clear that if you compare, you know, like the amount of implicit trust that a user has in, you know, top leaders in the space, like someone like Nosis or DydX or Gidcoin or Ether scan, right? that, you know, that reputation and that need to protect that reputation by those, by those different protocols is much higher than, you know, an infrastructure company that seems like are just spinning up by the dozen. Nobody really knows who they necessarily are. They're not very public facing. And they could just kind of like spin up. If they do, you know, run into any

reputational problems, right? They just rebrand, spin up a new entity somewhere else, right? And back to business as normal, right? The incentives like us being a validator, right, and being an honest validator, right, are really tied to, do you have a reputation to protect? And in the case of many of these validators, right, I don't think they do. I mean, I don't know if I would fully agree with that. Maybe you feel like you have a different view on this. I mean, or certainly you have a view on on this. You know, you work for first one. But I feel I feel like validator infrastructure companies do place a lot of, at least in, well, from the perspective of like where I know infrastructure validate companies, right? So like in Cosmos, we, we have a lot of infrastructure

companies that run infrastructure that run validators and other sorts of infrastructure. And they do place a whole lot of importance and their reputation, certainly through their involved. They're involvement in governance, being good stewards of the ecosystem in terms of like contributing to open source software, et cetera. Like sure, there are lots of maybe, you know, less reputable companies or individuals or like semi-professional validators that are running infra. But by and large, I feel like infrastructure companies, I mean, their businesses right. So like their long term, their long-term incentive is to build a company. And so build reputation and maintain that reputation. Yep. So I think in the end, the point that we can all agree on is that like the validator set matters, right? And that's absolutely. For any Oracle protocol, right, from a technology perspective, right, you can always fork the technology, but you can't fork the network. Right. And so the really differentiating factor that you will have as an Oracle protocol is like, you know, what is, you know, what is.

the value of your validators set, right? How expansive is it? You know, what is the, like, you know, both the individual reputation and the aggregate reputation and the number of validators in this set, right? And that's really your remote. Right. And that's why, you know, at Chronicle, we're kind of placing like a huge value on just, you know, onboarding more and more of these highly credible validators. Yeah, I think it's really interesting. this discussion for sure. I guess in general, the interesting thing I think for you guys in a way seems to be lying also in that the complexity of the protocol or also like that it's possible to run

potentially like relatively easily for these other actors or like can you maybe describe a bit because like I guess from experience running a bunch of different networks at some point becomes like a big issue and you have to have to focus on that and obviously all these companies you're mentioning they have products to build and like other things to focus on and I don't I wonder

I guess maybe because they're like building on this protocol they're running it and the Oracle is important enough or maybe it's easy enough to run I guess yeah curious to to hear how you're achieving that so from the validator perspective is

they're very they're blockchain agnostic right. Remember earlier I was saying like what does a validator or in Chronicle lingo? What does the feed do? They're just querying data and then they're signing it and they're pushing it to this peer to peer pool. Right. That's all they do. Right. So they're not even interacting with a particular chain. Right. So if Chronicle wants to expand to, you know, 20, 30 different blockchains, it doesn't mean that the validator actually needs to run 20 or 30 different blockchain notes, right? they're agnostic from from their point of view and so that really limits the complexity of what they need to run right and so really it's the relay kind of side of okay taking all of this data from this peer to peer pool and pushing it all chain right and a relay only needs to support the chains that it wants to support right so if it just wants to do

polygon ZK EVM it can do that if it wants to do Ethereum ZK EVM and I don't know something like mantle or base chain right it can do that right so there's like actually a second sort of role with the relay more or less

and then you have to I guess that makes a lot of sense and then in terms of the E model or like I guess business model which is I think in the Oracle space generally quite a interesting topic since, you know, a lot of the protocols run on these oracles, a lot of value rides on them, but kind of no one wants to pay for it, more or less. So you sort of have to finance it or like, and yeah, I would be curious to hear your thoughts, how it's kind of good thinking about this, how you feel this play out in the future also.

Is it ever always going to stay as it is right now that it needs to be like sort of subsidized? or yeah how do you see this going i i think that's an amazing question uh because it's uh it's so creative like what we what we do in the oracle space so after kind of uh going through the right we talked earlier about right in the bull market you had these uh these crazy high gas prices right and the oracle protocols who were not making any money right were just kind of like bleeding VC cash, right, we're spending millions of dollars a year just on the gas, right? And so everyone kind of collectively noticed, oh, well, this is not sustainable, right? And started introducing those measures that we talked about earlier, right? You know, reducing the number of validators,

right, to make the transaction cost cheaper, reducing the frequency with which the Oracle updates, all to try to kind of keep the cost down. And so in particular when it comes to like monetizing oracles, I think there's a pretty clear path to monetization, right, in terms of just a subscription, right? It's an Oracle as a service, right? And you can pay on some cadence, right? Either on a monthly, you can have some kind of monthly deal,

an annual deal, I don't know, per block, right? to have access to this Oracle. So that part's not very complicated. I think what is kind of complicated is like the meta game surrounding the constantly

changing context of the crypto macro environment. So, you know, you can imagine right during the bull market, right, when VCs are funding a bunch of companies, right? All of these companies are

protocols. have a lot of cash, right? They're very much willing to pay the sometimes exorbiting costs of these oracles. You look at kind of the current environment, right, where the VC funding market has been rather tight

and you're seeing teams and protocols needing to tighten up the belts, you're seeing them do things like layoffs, right, to extend their runway. And they really are looking for a way to reduce costs, right? And one of those areas that they look at is oracles. And so there's kind of two interesting effects I think we've seen in the past year.

So one is Oracle protocols kind of recognizing that their potential customers don't necessarily have the money to pay for this stuff. And the Oracle Protocol may or may not have the capital right to subsidize this, this like in the red for for some period of time. And so what you really saw was this proliferation of like pull oracles, which were, right? So instead of the Oracle protocol pushing the data to this Oracle and now someone can just use the Oracle, it becomes the protocol itself that is using the Oracle that is like doing the actual push updates to the Oracle, right? So still using the same data from the validators.

it's just instead of the Oracle protocol pushing it, right, it's the protocol that's using the Oracle. But what's really happening is that what the protocol that's using the Oracle Protocol will do is offload that cost to their users, right? So like if you use a protocol, right, it's almost like a hidden tax. Like you get an Oracle update like bundled into your transaction,

right? And as a user, you may or may not even know that you're paying for this, right? And so from an Oracle provider perspective, this is attractive because now you don't have to have this volatility in gas prices, which is determining if you're like in the green or in the red. From a DAP point of view,

it's great because you're getting oracles but you're not actually paying for them. And then from the user perspective, kind of you're getting screwed, but you maybe don't even know it. So and then from a marketing perspective, this is all kind of dressed up as like, it's an on-demand Oracle, you know, there's no wasted updates.

It only, the Oracle only updates exactly when a user wants to like use your protocol, right? Like it's seen as very like no waste or something. But it's mostly just marketing spit, right? It's really just a way for everyone to kind of like just be like, pass the buck around in terms of I'm not paying for that. And then the second, and I will say like a little prosoromark, I think this is very short-sighted. I think in the startup world, typically the business model is you want to subsidize the

cost that your users or your customers have to accelerate growth. If you look at the early days of Uber, right, they were using V.C. cash to sell you rides for less than it costs them, right? And that's how you bootstrap product market fit for a new product, right? Same thing with all of these like food delivery apps, right? They got a lot of traction because at the beginning they were really cheap. And now that they're charging you for the actual cost, right? Everyone's like, why am I paying $40 for like delivery of a pizza and like some cheesy bread or something, right? And this is like the antithesis of that, right? This is like these pull oracles are like you're adding like attacks to those users, right?

And while maybe at the current gas prices, it's not very noticeable. When gas prices start to increase again, and they will, when you start getting back to 100, 200, 200, 200, 200, way, it's really going to start to cannibalize the user base of these protocols. Because the users are just going to be like, this is too expensive to use, right? The cost to use this protocol is more than the utility than that I'm getting from it. And so I think these polarables are kind of like a forbidden fruit in that sense. And that it seems like a magical solution with no downside, but it can be very dangerous kind of going forward. And so the second, I did mention that there's two kind of things that we've seen change in the meta.

The second one is that Oracle protocols have gone from, you know, after having this realization of saying, well, the DAPs themselves don't necessarily have the money to pay for oracles. Who has money right now? And they look at like all of these new chains, right? They look at all of the L2s. They look at all of the ZK roll-ups, the optimistic roll-ups, the maybe alternative layer ones, right? And they acknowledge that this is what money has been shoveled into in the past few years. These chains are very cash and token rich but don't necessarily have an ecosystem and they need to spend money to bootstrap that ecosystem. And so it's actually much easier, right, to go to chains and to sell them on the Oracle services and being, you know, rightfully so saying that look,

you want to start up an ecosystem. But all of these DAPs on your chain are going to need oracles. And they're going to have to bear those costs, right? And so if you want to be like a catalyst for teams being able to build on your chain, you should pay for the oracles yourselves. And so essentially the chains become the customers and the DASHC, and the DAPs that are using the Oracle become the users, right? So it's interesting that you have like this user customer kind of split.

Ultimately, I don't think the chains want to be in this position where they are permanently kind of paying for Oracle infrastructure. So I don't think long term it makes sense anyway. But in the end, right, someone is always deriving value from the Oracle. And so someone will be willing to pay for it. Ultimately, I do think that will be the DAPs once they do find traction. I want to ask you about the use of articles in app chains. I don't know to what I think you follow this, but in, say, like in a cosmos SCK chain,

there have been some changes to essentially the protocol where the protocol where the the consensus talks to the application, this protocol called ABCI. And so validators are now able to effectively add oracle data, price feed data in their blocks, and the other validators in consensus also vote on this data along with the block information. And so effectively what this means is that app chains can now

kind of run their own oracles. they can sort of like ask their validators to provide price feed data and not have to rely on an external third-party service. Is this something you guys are thinking about and how do you see the use of oracles and, you know, Ethereum smart contracts versus roll-ups versus, you know, app chains? Sure. So I think what's important like to convey, right, is that as an Oracle provider, you don't, like, I have my own personal views of like, you know, what. chains or, you know, or kind of chain types I'm bullish on or bearish on. But as an Oracle provider, right, we don't really make those kind of bets, right? In terms of who will succeed or who will lose, you kind of just try to support everybody, right? So it doesn't matter, right? Who

wins and loses, right? So from that perspective, right, you always want to think of Oracle protocols from like a general mechanism point of view. Like what is an implementation that basically is general purpose that scales across every chain, right? Every user base, every ecosystem of DAPs that is out there. And so I definitely do think that there are interesting synergies like within certain chain ecosystems, right? Like in terms of like what you mentioned right with Cosmos IBC, right?

validators being able to send and attest to data, right? In the EDM world, right, you have like these native message bridges. And there's interesting applications that you can do on those specific chains or on those specific chain types. But as an Oracle provider, like,

you really want to stay as general as possible and just kind of support one implementation. because the moment you start to try to support multiple different implementations, things start to get really dangerous. The context of different chains in terms of how their environments work and what like the gotchas are in terms of even simple things like overflows and underflows or the implementation. You can have, for example, multiple EVM chains that say that they're all EVM. But under the hood, the implementation is different. And if you're not aware of these minute differences, you can really get yourself into trouble.

And so you really want to have one implementation that you're extremely confident in, right, that you can devote kind of your entire security budget to audit it. to doing, right, bounties, pen testing, rather than this dangerous game of like, oh, well, we have this Oracle that's specific for Cosmos. And we have this one that's specific for Solana. And we have this one that's specific for EVM. And we have this one that's specific for like the move-based ecosystem of chains.

And starting to like port features, right, and implementing them like multiple times across all of these. implementations, it's a recipe for disaster. And so while we would love to take advantage of some of these like really unique and really powerful primitives of these chains, the game theory calculus just doesn't really play out that way. And we have to think much more, much more general. So let's talk about the technical aspects of Chronicle a little bit.

So you leverage Schnorr signatures. So maybe it, we wanted to talk a little bit about how you're using Schnor. But maybe first we could start by just reminding, getting a reminder of like, what are snore signatures, how different they are from ESE, ESA, and maybe you could use that to lead into how you're leveraging Schnor in the signing scheme. Sure. So snore signatures are a signature aggregation scheme. So that is to say you can have one signature.

that is representative of multiple signatures. And so, you know, in contrast to ECDSA, where you have like, it's like a one-to-one relationship, right? One validator sign, you know, attests, and it generates one signature. And so if you have N validators, you have N signatures. With your signatures, you can have N validators and it always ends up as one signature. And what's like incredibly powerful about this property, right, is that it leads to an enormous amount of data compression. And when you look at some of the constraints of blockchains, right, the amount of data is one of the primary drivers of cost, right? if you look at the composition of what a transaction on layer two costs, the innovation of

layer two is that compute is incredibly cheap. But data, like the data that you pass to a smart contract is incredibly expensive. And the reason for that is because all of that data needs to be essentially pushed to a data availability layer like Ethereum layer one. So that, right, in the event of, you know, like fraud, that all of those transactions can be replayed, right? And provably, you know, you can prove that whether fraud or non-existed, right, in the case of, in the case of these roll-ups. So if you can compress the data in the way that shore signatures do, right, you get enormous, enormous cost productions on layer two for using short signatures. And so that was, that's kind of like the primary driver of the gas savings that we did right that allows us to have like

these 80 to 90% gas savings compared to some of these other Oracle protocols awesome I think we also could still go into I guess the optimistic sort of verification and how these challenge protocol works at another time potentially since we're already quite quite deep in the episodes but maybe like more interestingly for the listeners that, you know, are potentially working on project and want to integrate oracles themselves, can you maybe expand, you know, where Chronicle, like, sort of is deployed right now or like, where can people use Chronicle data and, you know, what sort of data do you have available at this point and kind of what are you working towards? Is it, you know, is it just Eith? Is it going to, like, other directions? I think that would be a good place

to sort of start wrapping it up. So in terms of chains that we support today, we launched this new kind of Oracle architecture with this short signature innovation. We just recently launched this on Ethereum, Mainnet, and on Polygon ZKVM, but we're effectively doing like a layer two strategy or we're just going to be onboarding

all of the layer tubes. So when it comes to anything really that you've heard of, right, in terms of what like arbitram, optimism, mantle, base chain, right? Even something like noses chain.

We're going to be onboarding these types of layer twos incredibly quickly. So I would expect by the end of the year, right, we'll basically be supporting all of the, all of the main ones. So, you know, I would encourage you to reach out to us, right? Go to our website, chroniclelaps.org. And from there, right, you can find our Discord.

You can find our Twitter, right? Get in touch with us. You know, let us know what you need. And we can get you set up. In terms of, you know, what we offer, I think there's an enormous amount of product market fit in D5 for price oracles. So we definitely offer this. But really, like, our oracles are built to be generalized.

So we can do any kind of data. So we're even delving into like the RWA space and doing like real world attestations of like, you know, even assets that are held by custodians, right, in a bank. So we can get really crazy with it. And it's all backed by the same underlying, you know, secure Oracle architecture that is securing like the billions of dollars a maker. Let's maybe just spend a few minutes talking about the real world assets up because I think that's probably one of the things that a lot of people interested in. And certainly it's one of the areas that is highly anticipated in terms of bringing more liquidity and more value. onto blockchains.

Can you talk a little bit more about some of the work you're doing there and why you're so bullish on real world assets? Sure. And I should probably preface this by saying I'm bullish on real world assets in a very narrow context. Like I'm going to a lot of conferences at the moment on panels about RWA and there's a lot of people pretending or saying, talking about some far-flung future.

when I'm talking about real world assets, I'm talking about what they look like right now in terms of the product market fit that they have achieved right now. So the context here is, right, that you have this divergence of rates between the real world and between defy because in traditional finance,

rates are driven by monetary policy and to an extent liquidity. and in Defi, rates are driven by speculative demand for number go up. And so number has not gone up for quite some time. People are relatively bearish, and so yields in Defi are very low.

And so this prompted a lot of protocols in Defi with very large treasuries, right, or credit protocols like MakerDAO to look elsewhere, right, to effectively say, look at the calculus of saying like, well, if we loan, die on chain, we can get 1.75%, we can get 2%. Or we can loan die off-chain, right, and get like 5, 6, 7, 8%. And so I think MakerDAO was very early in recognizing this and making moves.

And so at this point, I think cumulatively, MakerDAO is allocated something like between I think almost like three at this point, $3 billion, into different real world assets, predominantly treasury bills, right? Because treasury bills are a very safe asset, right? That if, as long as you don't have liquidity problems, you can just kind of hold to maturity and earn like a very, very high yield, right, on the order of five plus percent.

And so, you know, from the perspective of Chronicle, right, When we look at real world assets, we're really building for what we see, where we see like the pain points today. Maker is kind of not just talking about real world assets or planning to do them in the future. Maker is doing them right now at scale. And if you think about what is the entire real world asset market in terms of like capital delegated, I think Maker probably has somewhere between like 80 to 90 percent market. at the moment, right? And so we obviously work, we're the Oracle for Maker, right? We work very closely with Maker to solving the problems. And so, you know, we think we're going to have like a

very big piece of the actual practical side of real world assets and then use our practical experience, right, to expand that, right, and offer those services to everyone trying to get into real world assets. Because I think very few people understand like the boots on the ground problems associated with real world assets. And it fundamentally boils down to that protocols, right, on blockchains, right, don't really have any insight to what's happening off chain. And they have very few kind of recourse mechanisms off chain, right? Maybe you have like a foundation that can serve as a legal entity as the face, but they are not the protocol. So it's very difficult for a protocol to act like autonomous.

in the real world. And so especially when it comes to credit delegation, right? You know, what recourse do you have when someone runs off with your money? That is like the big question when it comes to credit delegation. And so the pain point here for a real world asset is how do you, how does a protocol delegate, you know, something on the scale of billions of dollars into a real world type of infrastructure where it doesn't necessarily have the same capacity right for liquidating in the next block like it does on chain. And so really what you have to do is deconstruct, what does this web of entities look like in the real world

to create a real world asset? And typically you'd have something like a trust, which is kind of like the representative of the protocol in the real world. So you can kind of have the trust be subservient to messages from that have been ratified by a doubt, right, by by governance. So the protocol would extend, you know, the money to this trust, right? The trust then interacts with the broker, right? What securities or structured products are you trying to buy, right?

So you could have a broker, right, like someone like Block Tower or I think in the past, someone like Genesis before they blew up. So the broker, right, will buy and sell, you know, whatever, whatever kind of structured products or securities you want to purchase, right? And then you have a custodian, right? The custodian is frequently someone like a bank, right? Then you may have like an auditor, right, who is like auditing the activities of what the bank has in custody or maybe auditing the activities of the broker, right? And so individually, you don't want any. You don't want any. You know, you don't want to trust any of the data that any of these different actors kind of report because they kind of all have moral hazard. If, you know, Maker turns off the tap in terms of credit delegation, right? All of them will not make any more money, right, and the party's over, right? So you don't want to trust any of them individually.

But as a set, you can kind of overlap and like phase shift all of their individual reporting on top of each other in a real-time kind of automated fashion. And then you can actually derive a high confidence in the consensus of what actually is in the real world and give that representation on chain in the form of an Oracle. So in terms of the messages like of instructions that Maker Governance gave to the trust, right, those should be symmetrical with the orders that the trust gives to the broker. right. Those instructions that were given to the broker, right, should be symmetrical with the actual purchase and sell orders that the broker executed, right? With respect to what the bank holds in

custody, those should be symmetric to what the broker, you know, confirmed, right, that they purchased and sold, right? Same thing with the data that the auditor is reporting, right? And so as you collectively aggregate all of this information, you can define, you can determine what the kind of consensus view is in a decentralized fashion. And so now you can have this data on chain. But what's interesting here is it's not necessarily price that is the most interesting, right? You may be interested in, you know, what is the yield of this RWA bucket? You may be interested in, you know, what is the, what is like the term of a lot of these securities, right? Especially if you're holding like treasury bills, right?

Treasury bills, but sure, right? And then what do you do? Do you like roll those back into new treasury bills? Or do you say, hey, you know, we want to have some more liquidity in the maker protocol, right? Let's recall some of that, some of that money. Yeah, in blockchain, we kind of take those sort of credit because that data is usually available on chain or right.

like writing the contract. You may be interested in the composition of the portfolio with respect to exposure to certain sectors or certain types of securities, right? And so now once you have all of this data on chain, the protocol can react in like an automated fashion, right? It can like extend more credit or it can, you know, cut off credit. It can determine, oh, well, this bucket that we have over here in real world assets is generating significantly more yield than this one, let's reallocate some of that capital to here.

And so it enables this enormous amount of automation that crypto protocols are kind of known for, but now in a real world context. And I think that's extremely powerful. And that can be applied, you know, in a general case at scale to way more things than what we see today, right, which is just treasury bills, right? And it can be expanded to way more context than and write just the Defy protocols extending credit. In this case, a real world asset Oracle is really this bridge from piping in data from the outside world onto a blockchain.

So now we can kind of achieve this cross automation. And that's where the real value is going to be. It's not going to be that DFI replaces traditional finance or traditional finance like, you know, kills defy. It's going to be this hybrid system where this. where they both of those realms are able to interact and leverage the strengths of the other. I think that's a great note to end on.

Thanks for expanding on real-world assets. I think it's one of the things that I'm really hopeful that we'll start coming into DeFi protocols, where you can open up, say, something like an AVE, or uniswap and and be able to swap like your SDC or your ETH for like treasury bills for instance.

I think that that will be a huge accomplishment for the space if that were to happen. Nicholas, thanks so much for coming on and extending our minds about oracles and Chronicle and all the important work you guys are doing. And hopefully we can get you back on some more in the future.

Yeah, it's been really great. guys. Thank you. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners,

you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.