1,014 or 1.014: what breaks in tokenized asset feeds
Devcon 8 · 3 Nov 2026 · 9:04
Chronicle's Bianca Buzea examines how tokenized-asset price feeds fail differently from feeds for onchain-native assets. She uses decimal errors and fund-administrator data to explain why sourcing, freshness checks, and failure handling need different assumptions when protocols integrate assets priced by custodians.
Speakers
Topics
From Devcon 8, hosted by Ethereum Foundation.
Transcript
It's a bit too much. Okay. Hi everyone. My name is Bianca Buzza. I'm doing developer relations at Chronicle. Chronicle is the team behind the very first Oracle on Ethereum. Today we're building the data verification layer for tokenized assets. And I'm mentioning that because in the next few minutes I want to give you an overview on what is important when it comes to evaluating oracles for tokenized assets. But before that I want to do a small exercise together. So let's say you are about to build to to buy your very first apartment in Mumbai and you found two
options flat A and flat B and both of them are the same price. I would like to see a show of hands of those of you who would prefer flat A. Okay. Now let's see flat B. Wonderful. I see some of you are looking confused at me and rightfully to do so because the single information I provided to you was the price of the flat. I didn't give you any sort of details about uh how big is the flat, which part of the city is it? Is it the east? Is it the west? Can you resell it easily if you change your
mind? How old is the building? Or who are you buying it from? All I gave you was the price. But to evaluate this properly, you need a lot more information. And once you compare this and you have these data side by side, you can easily see that in this case fad A is a better option. However, to do so, you need the full picture. Similarly, when evaluating tokenized assets, you need the full X-ray on chain. You can't make a decision only based on a price. Price is only one
dimension. So, here is what people usually uh look at when it comes uh to a tokenized assets. Here is the example of a tokenized fund. You want to know details about the fund uh who runs it, how is it being managed. You want to know about the custodian because that's the entity that holds the assets. You want to know about the portfolio and what are the underlying assets, the legal structure. You want to know if there are certain jurisdictions where you can use that product and the redemption.
And it's important that the same level of information that one would look at in the real world is reflected on chain as well in order to build useful onchain products and to have risk mechanism that are suited for those products. My point with this is that a tokenized assets uh a tokenized asset it's multi-dimensional and because of that the oracle that is powering that asset and it's verifying the data also needs to be multi-dimensional.
For those of you that have been in the space for a while uh you might remember the very first version of oracles back in 2017. Those were one-dimensional and rightfully so because back then the oracles um were powering onchain native assets. You would have the oracle, you have different data sources, onchain data sources such as decentralized exchanges or off-chain data sources such as centralized exchanges. The oracle would aggregate that take the final value put it on chain.
Now with version two of oracles, we're talking about tokenized assets. Those are multi-dimensional. We need a lot more information about those assets. And that's why it's important uh when we are evaluating the different type of oracles that we keep this in mind. uh what's the asset that the oracle is powering and how are we evaluating that because there are different ways to evaluate an oracle for onchain native assets versus one for tokenized assets and I want to leave you with three important questions for evaluating such
an oracle. There are a lot more questions that a builder uh should ask and details uh they should get before building with such an oracle. But given the time constraint of this talk, I want to give you what what I consider are three of the most important ones. The first one is about the data sourced. Uh you should ask where is the data sourced from? And ideally you want the data to be sourced directly from the fund admin and the custodian. The next one is about what sort of information is on chain. And as we saw there are a lot of dimensions that need to be reflected.
And finally and probably you you remember the title of my talk and this points in that direction. You want to make sure that there are enough protective mechanism that the oracle has. For example, for tokenized assets, a very popular one are circuit breakers. Um, a use case here would be against fat fingers. So for example, if the difference changes significantly from one update to the other, you would like to have a circuit breaker and see with the stakeholders check if uh everything looks right or if data needs to be evaluated further.
That's it on my end uh for this session. I would love to continue the conversation in the room with those of you interested about learning more about putting onchain data for tokenized assets. Thank you so much. >> Yeah, thank you. And we can do maybe one quick question if there is one in the audience. >> Perfect. Actually I believe the common questions here.
Who do you believe might be the right source of truth for digital assets? Is it government? Is it owners of the buildings or uh who might be the source? >> I think the the source of truth is the the entity that actually holds the asset. And uh in that case we're talking about the custodian and the fund admin. That's the ideal setup you would want to have for tokenized assets. When it comes to taking that data and putting it on chain, >> how do we prove they give you correct information? Like custodian is giving you correct information about that holdings.
>> There needs to be of course a certain level of trust based on regulation. We're talking here about an industry that is regulated and extra regulated and functions uh on certain verifications. Uh we need to take those into account. Uh what I'm describing here is the process of putting that data uh on chain. But uh that infrastructure is built on layers of uh verifications and regulation. Can I challenge your data also like onchain?
>> Sorry. >> Can I challenge your data on chain? Like if you put the data on chain and I see it is not correct. >> Can I challenge it too? >> You can you can see uh the the data you can see that what uh the the price uh and the the data that is on chain it's actually the same uh to what has been uploaded. And you can yeah you can verify against the two but uh if the data is not correct it's not going to be uploaded going back to the circuit breakers I was mentioning at the beginning.
>> Thank you so much Bianca. Thank you and