From Manipulation to Mitigation: Rethinking Oracle Security in 2025

DeFi Security Summit at Devconnect Argentina 2025 · November 2025 · 14:47

Bianca Buzea, head of developer relations at Chronicle Labs, notes that oracles power every DeFi protocol yet remain prime targets for attackers. The talk analyzes real-world oracle exploits and sets out actionable strategies for data integrity, freshness and resilient security, so that onchain applications relying on price feeds and other external data are safer.

Speakers

Topics

From DeFi Security Summit at Devconnect Argentina 2025, hosted by DeFi Security Summit.

Transcript

Thank you so much. All right. Uh how is everyone doing? Hope you're enjoying the five security summit so far. This presentation will be about oracles, oracle security in 2025. I want to start with the bit a bit of a disclaimer. When I first applied to this talk, I had in mind a bit of a different angle. I was planning to go to the different sort of exploits that you can have when it comes to oracles and how you can prevent those.

But in the meantime, I realized that there is something way more urgent that we need to tackle when it comes to oracle security in 2025. So, I will be focusing on that. Okay, the presentation is is up. Amazing. A few words about myself. My name is Bianca Buza, I'm head of devrel at Chronicle. Chronicle has been around since 2017. In 2023, it spun out of MakerDAO, now known as Kai.

And today it continues to power assets across the the DeFi as well as the tokenization space. Now, I want to take you a bit on a journey all the way back to DeFi summer. Back then, people weren't really talking about oracles unless something was going wrong. And every time you would read kind of the same headline, protocol hacked by millions because of XYZ oracle exploit. And the main culprits are the following: flash loan attacks, market manipulations, stale

prices, and so on. However, I would argue that since then, we have improved a lot as an ecosystem. It's true we haven't eliminated completely this sort of exploits, but they are way more contained and we learned a lot of important lessons, if you want. Here are some of those lessons. First and foremost, use decentralized oracles. Don't build your own oracle. And next I'm going to go through some of the other considerations, if you want, when it comes to choosing an oracle.

One of those is operational history. Has this oracle consistently secured funds over time? Here, of course, we're looking for longevity because it's it signals reliability, especially when the oracle didn't have any sort of exploits in the past. Another consideration is TVS or total value secured, and here we're thinking we're looking at how much value What's the value secured by the oracle? We're also looking at the level of decentralization.

We want to have multiple nodes run by independent validators, and those to use diverse data sources. Also important to look at who are those validators, who is running the the network. Are those validators trusted independent validators? And here, high-profile validators have a reputation to maintain. So, those bring higher levels of data integrity and network security.

Data sources are equally important. We want the oracle to use tier reputable reputable data sources with established credibility, high liquidity, and of course a track record. And also super important operational costs. Oracles are expensive and especially during times of network congestion, it's very important to make sure that they remind they remain accessible to users and protocols.

And definitely here um you want to make sure that this uh accessibility is the result of taking the right actions. And what do I mean by that? For example, if you're lowering the update frequencies, sure it's going to be more cost-efficient, but you end up with stale data. So, that's not really the path you want to take. Instead, you want to create mechanisms that reduce costs without compromising data freshness. For example, uh in our case, we're using Schnorr signatures to to bundle multiple signatures into one, reducing uh the gas.

Now, these are some of the lessons we'll we learn over time and some of the considerations for for protocols to keep in mind for what I like to call the version one of oracles. In and in a very very simplistic way, this version one of oracles is technically a data pipe. So, you go to the oracle, "Hey oracle, I would need this piece of data." And then you have the oracle that has its network of validators, those validators go to the different data sources, they um they gather the data, uh then they agree on the final data.

That final data gets uh pushed on chain, and then it's readily available for smart contract and protocols to um integrate. So, this is V1. Um and it's very important to keep in mind for that for this V1, we are talking about um crypto native assets. Assets that are available on chain and assets that have a lot of metadata to describe them. For example, if you want to know the liquidity of a Uniswap pool, you can just go to your

favorite block explorer and get details such what is the TVL, what's the trade volume, what's the supply, what are the fees. Everything is on chain, it's observable verifiable and programmable. And this is very important because you can actually, based on that information, you can build trust. But, I would argue the game has changed. We are in 2025 and it's the year of RWA expansions.

And here is what I mean by that. All the institutions are are going on chain. We have seen Robinhood um having tokenized uh sorry, Robin offering tokenized stocks on chain, Stripe offering payments via stablecoins, South Korea working on a legal bill to enable institutions to issue stablecoins um in one one denominated stablecoins, Shopify offering to its customers USDC payments and so on.

And the list continues. Um if you look at the screenshot, you can see that some of the largest institutions in the world are embracing on-chain the on-chain economy. You can see the Bank of America, BlackRock, City, and so on. And they're offering several services related to the on-chain economy such as crypto trading, crypto funds, crypto ETFs, crypto enabled payments, and different forms of tokenization.

This is the value of the RWA market last year in December, 13.9 billion. Anyone has a guess about this number today? >> Okay. >> 15. Anyone more? Okay, let's see the actual number. Today, this number is 35.54 billion. And if you do the math, that's a 155.8 increase in less than a year, really.

And this is only the the tip of the iceberg. If we're looking at the total market for gold, currencies, real estate, commodities, we're talking of over 40 trillion. So, what does it mean? It means that there is a great potential of expansion for tokenized assets. But it also means that we have a lot of responsibility. We have this responsibility to tackle asset tokenization the right way and to make sure that we integrate these assets securely into DeFi.

So, here I want to talk a bit about what I like to call Oracles V2. And I call them um Oracles with two big because they move past being simple uh data feeds to actually being real-world interoperability layers. So, this version of Oracles, they enable protocols to take way more complex decisions that uh the version one we've seen before. They enable users to know if they can trust a protocol they're interacting with. They enable um to determine if it's appropriate to have a financial

contract uh to execute. They also enable to know uh if a tokenized assets, for example, a stablecoin it's actually backed and so on. So, as you can see, those those are way more uh complex answers uh complex questions to answer. And that's because uh tokenized assets are not really uh crypto-native. Really, they are a representation of an asset that is off-chain. So, the problem we're seeing is that those uh assets are not inherently transparent.

And also, they lack liquidity verifiability. And that's why um that's because these assets, they reside in traditional financial systems and as we know, those are siloed, opaque, and off-chain. This also means that protocols can verify that uh these assets are actually uh backed. So, if you are a DeFi protocol and you want to um integrate, for example, a tokenized treasury fund, how do you know that the assets are uh the underlying assets are actually uh there?

Also, very important here, uh you need a lot more metadata in order to integrate those assets. And here are some of the examples of this metadata. So, you might want to know about the custody of the assets, its composition, liquidity, the level of collateralization, its yield. All this information you need in order to build meaningful solutions when it comes to define and also to make sure that you can take proper security mechanisms when it comes to these assets.

So, what's really needed? We We need an approach to We need to approach asset tokenization the right way. Otherwise Otherwise, we risk reintroducing the same systemic risk that we have seen in traditional finance. And this is where oracles come into play. They help verify off-chain creditworthiness of assets. They provide key data such as purchase dates, yields, maturity dates, and so on. And most importantly, they allow to sync the asset life cycle with the on-chain world. So, you can see how an asset moves through the different stages

such as issuance, transfer, settlement, and so on. So, this is why at Chronical we built a proof of asset oracle. This is our oracle for real-world assets. And really, what it allows to do um it allows DeFi protocols to handle tokenization the right way. So, first of all, it connects directly to the custodian. So, you have data source directly from the custodian, no middleman.

And it allows to have an independent tamper-proof attestation of the data. And based on that, protocols have the flexibility to take different mechanisms. For example, let's say that you want to verify that the underlying collateral of a stablecoin is actually there. And if the level drops, you can take some risk-appropriate measure. For example, you might want to do a circuit breaker, or you might want to do a liquidation, or some other mechanism that you can have

executed automatically. That's it on my end. I hope I I sparked some interest to approach asset tokenization the right way, securely and responsibly. And if you would like to learn more about what we're building or oracles in general, please feel free to connect. I dropped my my handle on X. I'm always very happy to talk about oracles.

Thank you. >> I see you again.