Adam Sadowski, Llamarisk | Accelerating RWA Adoption in DeFi With Risk-Managed Oracles
Stable Summit·Thu, Apr 9, 2026, 12:00 AM
RWAs are moving onchain, but reliable data remains a bottleneck. In this session, Adam Sadowski (Llamarisk) explores how oracle design can support the growth of real-world assets in DeFi, and what risk-managed data infrastructure is required to scale adoption. — Stable Summit IV Cannes · 27-28 March ➣ Follow Stable Summit on X Link: https://x.com/stable_summit ➣ Follow Stable Summit on Linkedin Link: https://www.linkedin.com/company/stable-summit/ ➣ Listen to the Stable School Podcast Link: https://stableschool.org/podcast
Transcript
Hey everybody. So I'm Adam Sidowski. I am the founder and CEO of Llamarisk. Lamarisk is a DeFi risk manager and we work with some of the biggest names in DeFi like a curve, a horizon and Athena. Uh so today I'm going to be talking about this topic of riskinformed oracles and how this is an essential piece of infrastructure that is going to allow the safe onboarding of RWAs into DeFi.
And I'll be talking about this topic in the context of our solution Lamagard NAV. So we're at an inflection point of our industry right now where RWAS are poised to redefine DeFi. We've been seeing unprecedented growth of different financial products that are coming on chain right now over the past year. And in the face of that immense growth, we still have a total addressable market that is astronomical compared to what's been tokenized so far. So the upside continues to be huge.
But we despite this this rosy picture, we have to look headon at the the persisting challenges that are continued barriers to adoption for RWAs into DeFi. And this stems generally from a problem of composability. But for the purpose of this talk, I'm going to focus in on one aspect of this, which is that of asset issuer reported nav. So that's how we value these uh these assets as collateral in DeFi. If we have a mispricing in DeFi, that means that borrowers can be instantly liquidated.
It means that the D5 protocol can expose itself to insolveny. So this is a critical dependency that we can't allow any mispricing to occur. And in the case of these RWA assets which are highly regulated and have little to no secondary market liquidity, it means that we're forced to rely on the asset issuer themselves as the single source of truth for the fair value of that fund. And of course, this is a single point of failure and we have observed that there have been anomalies in pricing that have occurred in the past and we can be certain that this will continue to be a problem in the future. So here's uh some examples of um historical pricing anomalies that we've seen.
We've seen occasional zero values that have been pushed as updates. We have seen instances where there have been extreme dislocations uh in pricing updates that far exceed the behavior of the underlying assets of that given fund. So this is why I come to you today with my thesis that risk oracles are the future of oracles and how my my bold thesis for you is that within the next two years we're going to see that the vast majority of the ways that D5 protocols are are ingesting external data is going to be through this mechanism I'm about to describe. If we look at how the Oracle stack has been constructed over uh the past handful of years and how it exists today, there's basically two layers to this. So the first layer is the raw data, the data provider supplying the data and that could be an exchange or a data aggregator combining multiple data sources.
And almost always that is market price data because that is what has most direct utility to power DeFi today. And that data gets fed into the Oracle network which is handling data transport and it may be uh taking inputs from multiple data sources and it's doing validation and achieving consensus. Maybe it has a decentralized network of nodes that's achieving consensus and it needs to maintain the level of integrity that is expected of onchain finance. So then those values get pushed on chain and can be consumed by the D5 protocol. What we're seeing now is that there is an immense need for a third layer.
So that is the risk layer here. And you can see right away that when you introduce the risk layer, the categories of raw data that you can consume greatly expands. So there is an ocean of data available for us that has not yet been harnessed. That includes things like liquidity and volatility data, macroeconomic data, derivatives, it could be credit ratings, it could be fundamental information about the underlying assets of a fund. There's so much potential out here.
And what the risk layer is doing, it is ingesting all of those diverse data points and it is interpreting risk signals from them that can be used as an actionable response that affects change on the DeFi protocol. So the risk layer can define one or more trigger conditions that are pushed on chain and that can be riskmanaged pricing and it can be riskmanaged responses. So things like circuit breakers or uh protocol parameter modifications. So with that brief introduction of risk oracles I'm proud to be introducing you today our work on Lamagard Nav. Lamagard Nav is already live in production and it's powering the A horizon lending markets.
A horizon you're probably familiar with. It is the platform where the convergence of DeFi and Tradi is happening today. It's a lending platform where users can supply a variety of RWA collateral types and borrow stable coins against them. And it has a total supplied value something in the order of $450 million. And all of that TVL is being powered by Lamagard nav feeds right now.
So, let's just uh do a little thought experiment and imagine if we were to build a proprietary risk oracle. What would that look like? Well, [clears throat] we'd probably have to build a homegrown solution with our own backend service. So, we would probably use Amazon AWS and we would have all of our logic and data pipelines sitting there and uh we would probably have redundancy across geographies for uptime guarantees. is we would uh select our data input sources and then how what are our trigger conditions?
How are we delivering that on chain? It would be a fully encapsulated proprietary solution. So if I came to you with a solution like that and I said I have this great risk oracle would you like to integrate it into your protocol? You would take one look at that and you would say, "Well, I don't know what it's doing under the hood and I don't know if I can trust you uh to operate that fairly and reliably and honestly, so get the hell out of my office." And you would be completely right to have that attitude about it.
But there is something that is changing the game for this right here. There's a critical piece of infrastructure that we are building Llamagard on and that is this right here. This is the chainlink runtime environment. So chainlink CR is the same chain link infrastructure that has powered data feeds uh since 2019 and is trusted by the majority of DeFi. It is uh validated by a decentralized network of chainlink nodes and what it offers that is a very powerful feature for teams like llamarisk is it is an open development environment where we can encode our risk management methodologies on its off-chain computation.
We can have access to the vast ocean of data that is made available through the chain link IO network. We can distill that into an actionable way that can be used by the D5 protocol. And what is the real paradigm shift of what we're able to accomplish with Lamagard built on chain link CR is that for the first time ever off-chain dependencies that D5 protocols rely on to operate safely and reliably don't have to be delegated to a third party service provider. The D5 protocol itself actually has full transparency and control over the entire stack onchain and offchain from the integration to the the logic that lives off-chain to all of the data sources that are encompassed in that solution. So this becomes an extension of the D5 protocol to the off-chain environment.
There is no other solution on the market that is offering this level of transparency and control to the D5 protocol than what can we can accomplish here. So let's look at what the actual architecture of Laguard Nav looks like. We have two key inputs that we use. So firstly we have of course the asset issuer reported nav and secondly on chain we have a parameter registry and that has unique configurations uh depending on the underlying assets of the fund that we have a lamagard nav feed for and those configurations are governing how the logic runs in CR in the off-chain computation. So when we have those two pieces of input, we run a bounding logic within CR and that assigns an upper and a lower bound that are safe uh nav values.
And if we receive a nav value that is outside of those those upper or lower bounds, then we consider that an anomaly that requires riskmanagement action. So one of two things can happen here. If we receive a a a good safe nav value, we simply pass that on chain just like uh any other price feed. It's read by the the uh D5 protocol. If in the unhappy case we receive a nav value that is outside of safe bounds.
Firstly, we'll bound the nav feed according to the allowable bound and push the bounded value on chain. And secondly, we push a bounds breach state update. So back on chain, a horizon has a unique capability here. It can delegate risk management to a third party. In this case, it's delegating freeze functionality to the Lamaguard workflow.
So when it receives that bounds breach state update, it interprets it as a market freeze event. So no more supplying collateral to the market, no more borrowing stable coins against that collateral. And that allows us to have a manual review process and determine what was the root cause for the an for the anomaly that happened and how do we uh handle the market going forward. Can we reopen the market? Do we need further risk mitigating action against that particular collateral type?
So if we look a little closer at the bounding logic that we use, we have dynamic bounds here because we're interested in funds that are yield bearing debt instruments and they fluctuate in value over time. We need our bounds to be able to fluctuate with the change in value of the underlying assets. We want to set the bounds such that they're wide enough that they allow for this organic fluctuation, but we want to set them tight enough that we have a strong assurance of pricing stability. So users can supply their assets to a horizon and have a strong assurance that their assets are safe. There's not going to be influenced by any mispricing event on the protocol.
And similarly, the protocol team, A Labs in this case, they can have a strong assurance about pricing stability. So they can push exposure of that collateral type far more than they would otherwise and make their venue the preferred choice more competitive than than venues that aren't using a sophisticated riskmanagement strategy. And this right here is a screenshot from uh from our our dashboard on our website where you can see all of the historical uh bounds values that we've generated any bounds breach events and all kinds of metadata including the parameter registry and and contracts associated with Lamagard now for all the feeds that we support. So you can check that out on our website. So what is next for Lamagard?
I think what I've described here is a very straightforward problem that is in need of a solution and we found a good solution for it with Lagarduard Nav. But actually the Lamagard suite of tools is an expansive set of tools that are solving real bottlenecks in our industry. So those can be broken up into two major categories. Firstly, we're using Lamagard to create riskmanaged price feeds like what we've done with Lamagard Nav. We want to onboard new categories of financial products into our industry.
things like equities, long duration credit, commodities, custodial accounts, new types of well for for our industry, new types of financial products that require knowledge about certain uh fundamental information about the underlying assets in order to generate risk signals that allow them to be safely onboarded into DeFi. And then over here we have DeFi risk automations. So you can imagine that uh a defi lending platform like a as it's growing it could potentially have hundreds of assets across dozens of chains. So when you have a protocol that is scaling in breadth and in the amount of value it's securing you need to have risk management that scales with that. You need to be able to affect change in real time based on real-time input data on uh certain parameters on the protocol such as the supply and borrow caps, liquidation parameters like loan to value and liquidation threshold, the interest rate model adjustments and using P as kind of a solveny check and circuit breaker for those markets.
So I really want to emphasize that what Llamaguard can accomplish by introducing the risk layer to the Oracle stack is access to the vast ocean of data types that are available in the world and converting them into risk signals that are usable in DeFi. And what's more is that we're able to accomplish this in a way that isn't delegating management to a trusted third party out there. the D5 protocol itself actually becomes an extension to the off-chain environment and has full transparency and control over the off-chain processes, the logic that's running and and all of the data sources that they're ingesting. I got into this industry because I saw that DeFi represents a fundamental upgrade to the financial system and I wanted to live long enough that I could see that come to fruition. And I think that for whatever the details of the reasons that everybody here came to this room, we're all bound by that same vision.
So Llama Risk exists to support the builders in our space to make this a reality. To the asset issuers, to the DeFi builders, come talk to us about how riskmanagement plays a role in helping you to achieve your mission and talk to us about how scalable and sophisticated risk management tooling can help you to achieve growth, to achieve scale, to achieve trust so that we can work towards the convergence of DeFi and tradi together. Thank you.
Automatic transcript — names and jargon may be misspelled.