Strengthening Oracle Security in 2026: Key Principles for Builders

Transcript

All right. Anyone? I'm not asking you about the price of it. I wouldn't dare. I'm asking you about the question behind the price. In 2017, answer this question, you couldn't build a stable coin. Nine years later, this question is still being answered multiple times per day. And the answer to that holds up billions in value. My name is Bianca Buza, I'm head of DevRel at Chronicle.

The team of Chronicle is behind the very first Oracle on Ethereum back in 2017. In 2023, it spun out of Maker and now it serves the whole Web3 ecosystem. And in this presentation, I want to tell you how that question and the infrastructure behind it got a lot more complex. So, in 2017, Chronicle was building the first Oracle on Ethereum to power Sai, which was preceding Dai, the decentralized stablecoin.

And we all know that in order to have DeFi, you need stablecoins, but to have stablecoins, you need Oracles. So, if you think about it, the whole DeFi ecosystem depended on a price feed. Not exactly the stuff of Greek fables. It took us a very long time as an industry to realize why we can't do our own Oracles and why Oracles are such a key piece of infrastructure. I mean, why not do it yourself? You can pull data from an API, write a little contract, push the price on chain.

Really, how hard can it be? Well, it turns out that building your own Oracle is the DeFi equivalent of I'm going to do my own electrical repairs. Technically possible, occasionally fatal. The lessons we learned as an ecosystem were real and quite expensive. Centralized Oracles turn out to be single points of failure. We've seen price manipulation exploits, flash loan attacks targeting weak Oracle setups.

Protocols across the ecosystem lost real money because the data layer was the weakest link. But we did learn. Slowly painfully through a lot of hacks and a lot of postmortems as we've seen earlier, and a lot of people on a lot of stages saying, "Please stop doing this." We learned that the minimum is decentralized Oracle infrastructure, that we need data from uh multiple data sources and distributed validators.

It took us years. It was hard-won, I would say, but it's a real achievement. But also, that was V1. V1 answered the following question: What does this crypto-native asset cost right now on chain reliably? And we answered it through distributed infrastructure, multiple validators, multiple data sources. However, the assets have changed. And when the assets changed, the question naturally changes well.

BlackRock, Apollo, Janus Henderson, the biggest names in tokenized finance and traditional finance are tokenizing assets, whether we're talking about treasuries, credit funds, equities. You can see on the right side some of the predictions for the total size of the tokenization market. Some of them are more optimistic than others, but the consensus is clear. In the next few years, the tokenization market market will be a multi-trillion dollar market.

So, we went from V1 from what's the price of this all the way to please perform a full portfolio x-ray on chain continuously. The Oracle problem didn't get solved. It just got a lot more complex. So, now in V2, you don't only need to know about a price, but actually you want to know about what's actually backing the underlying assets. What's the portfolio composition? What's the NAV? The yield? The liquidity profile?

And most importantly, in my opinion, you need to know if there is anything that is deteriorating quietly. But here's what worries me. We've seen this before. In V1, it took us years to learn why you can't cut corners when it comes to the most important pieces of infrastructure that everything else depends on. In V2, the assets are much bigger and the potential downside it's exponentially higher. Here's an example. Let's say we have a lending protocol that accepts as collateral a tokenized fund.

The NAVs look good, the issuer is solid. In this example, the Oracle just gives you the NAV. So, you know the price. However, after after a while, the fund composition drifts. Maybe it goes to longer duration or riskier credit. But the problem is that on chain, no one knows about this change. Collateral is still marked at par. And when a a rate shock hits, positions become under collateralized. Liquidations happen too lost too too late and money is lost.

We've seen this mistake in V1. We don't want to repeat this. And look, part of the issue is access. So, if you want to know the composition of your fund, what are you going to do? Are you going to call your fund manager? Hey, yes, this is Pump King 420, that's P U M P capital K. But that's actually not funny. We build a financial system that's supposed to be permissionless and the most important information is not accessible.

The way I think about is there are two type of feeds. And the difference between them is not technical. It's the nature of the data themselves of the assets themselves. So, we've seen with V1, we have feeds for on-chain native assets. And the risk here is price manipulation. So, we need to have a price that it's accurate and manipulation resistant. And we solve this through decentralized Oracle infrastructure. In V2, however, we have feeds for real-world assets.

Think about tokenized treasuries, credit funds equities. And here, the distinction is that data lives with custodians, with fund admins, in all different off-chain sources. So, the risk is not only if the price is not only price manipulation, but actually information asymmetry. You need to know what's actually inside a thing and you need to prove it. So, back to my previous example, same conditions, except this time, the Oracle provides the full picture of your tokenized asset.

So, not only the price, but also reserves composition and any other details. So, in this case, the protocol is able to detect the fund composition shift. And you can have automatic triggers, for example, such a circuit breaker, and the positions are protected. No human being needs to know about this before everything takes care on chain for smart contracts. So, this is really the scenario when we get it right.

So, V1 we saw it's a one-dimensional price feed. V2 is an independent x-ray. Think about reserves, composition, characteristics, verified cryptographically on chain to anyone continuously. And we call this x-ray proof of asset. Here is what Chronicle proof of asset powers today, the different use cases across asset classes. We have government securities, such as US TB from Superstate. Last week, we announced BlackRock Biddle.

Private credit, such as Acredix from Apollo. CLOs or collateralized loan obligations, such as securitized stack. And stablecoins. Here is M Zero, one of our partners. With M Zero, you can create your stablecoin backed by real-world assets. And what's really interesting is that before any minting takes place, proof of asset verifies that there is actual collateral backing it. Here is proof of asset dashboard. I want to give you a brief overview of what to expect.

Here, we have the Janus Henderson and Moi Treasury Fund and some key characteristics. We have the holdings. This is very important because you can actually see what's backing the asset. You can have the different maturity dates, the distribution, the yield, all the information that you would have in traditional finance. You can see the Oracle events. So, you can keep track how fresh the the data is, when it was last updated.

And you can see the token distribution across different chains. This is only part of the the dashboard, but I want to I wanted to give you an overview of the most important views. So, if you're building anything that touches tokenized assets, lending aggregation tooling, the Oracle you pick determine determines what your users can trust and what your protocol can verify. So, here are three questions to keep in mind.

Can your Oracle verify a reserve's composition and characteristics? Is the data verifiable end-to-end? And also an important one, does the cost model scale? If you remember one thing from this talk, I hope it's not a joke about pumpkin 420 calling a manager fund. Instead, I would love you to walk away with the following question. When it comes to tokenized assets, instead of asking if the Oracle gives you a price, ask yourself if it shows you what's underneath it and if you can verify it.

Don't trust, verify. Here's the QR code of the dashboard I mentioned earlier. Feel free Feel free to scan it and play around with the different data. And if there are any questions, always happy to talk with builders and help with integrations. Thank you. That wasn't me.

So, we're just to make this quicker. Okay. Hello. Um You talked about the data feeds. Data feeds are whole infrastructure that is decentralized. How do you get your information about the reserves um that are collateralized and stuff like that? Um where does it come from? Directly from the custodian. That That's actually a key differentiation that we get the data from the custodian. We validate it through our validator uh network and then it gets pushed on chain.

Okay. So, you don't go too far into decentralizing the infrastructure when you're tokenizing stuff. You go directly to the information. You get You need to get it from the custodian cuz the custodian secures it, but then it still goes through the validator network and that's distributed. Do you guys work with any DEXes already? For the For the for the >> tokenized assets or for the regular data feeds?

>> yeah. Uh not at the moment. We're seeing different assets being integrated into DeFi. We for I think yeah, A credit was one of them. But yeah, we're we're seeing more and more momentum in that direction integrating these assets into DeFi because at the end of the day this is where you get the real benefits of the tokenization. So, I think it's expected to to increase. And do you see any current dangers in how DEXes are currently operating or providing the RWAs with or relying on on Oracles that are not safe yet?

Uh do you have a an example in mind with that? Um no. Uh That's why I'm asking the question. Um yeah. No, not really. Yeah, we we haven't seen the the DEX integration yet. That was with A credit, it was more for market. Okay. Yeah. Okay, cool. Can I ask you? Yeah. Um Trying to wrap my head around like So, it's like for instance like those kind of off-chain real world asset and you're basically deciphering the the the composition behind and then so you're verifying it. And how do I trust your

verification? So, it's like on top of rep reputation because like it's a it's a it's an incumbent uh incumbent here. But like on top of the reputation, what kind of things that I can trust? Don't trust, verify. So, that's the beauty of it. You don't trust You don't have to trust us. Uh the data is saved on IPFS and there was I can't really go back, but like there was that lock sign next to each data row and you can press that and see what's the data actually on chain recorded and you can verify yourself uh that it's the same data, that no one touched it.

>> What about before on chain? Before the data going on chain? The How do you make sure that the data going on chain is correct? You see for the validators, the the answer is recorded at each validator level and then you can compare it with what you have on the dashboard. Yeah. Yeah, I'm curious. What are the validators actually validating? What is a statement that is being validated? It's the data pulled from the custodian. They they verify the data and push it on chain.

Okay, so they do that by actually verifying themselves the data that you provide to them and comparing it to the value from the custodian, right? >> Mhm. Okay. So, it's the the custodian data that we collect, right? Yeah. Can we trust the custodian data to the validator? So, it's like I'm Yeah. The custodian, yeah, needs to to to do their their job. Yeah. Yeah. I get it. Yeah. Thank you.

I think that's it for now. >> are like real regulation and there is We still have time for We still have time for one more question. >> at the end of the day? Anyone with the last question? Since you guys built one of the first Oracles for Ethereum itself, right? The first. The first, yes. So, that's blockchains, but we we built an Oracle for social media handles. So, I was wondering if this could function in the similar way like you guys do it because it's just the information

like the numbers and the information which are stored there. I mean, technically you can put on chain any sort of data you want assuming you have reputable data what we've seen over the years, the main use case is financial data. So, does it make sense to build this? I don't know. You You figure out. You see if there is market fit and if there is market fit, yes, you can put it on chain. Exactly. If there is a market fit. And there is big time market fit, yes. But thank you.

I think that's it. Thank you so much, Bianca. Thank you guys. >> [applause]