Who Controls Economic Truth on Ethereum?

Transcript

Hello everybody, welcome to my talk. I am Brenda. I am one of the founders of Teller. And today Teller is a decentralized oracle. We're probably one of the very over the probably only oracle that I can actually pass the walk away test. We've been live since 2019. Um staking, disputes, requesting data all happens on chain. And we've been doing that since the beginning. Um but today I'm not here to talk about Teller. I'm here to talk about who holds the truth on Ethereum. So, we're going to talk a little bit about how data flows through the system because ultimately that's what ends up dictating what kind of outcomes we get on chain.

And the way that data flows depend also ends up uh creating sometimes unintended consequences because the data can be and and is and has been sometimes manipulated. So, if I spend too much time on the on that aspect of the of the presentation, um just somebody wave at me because it's super interesting, but it's actually what makes the point of what is like how how this actually works. So, first we're going to talk a little bit about how data actually flows into the system because um I realized yesterday that maybe the flow needed to be improved.

So, in general when you're trying to observe the vulnerabilities of your system, you do this map where you actually see where data moves. And then based on that map, which is generally a lot more complex than this. This is a very simplified version of that. You can identify based on how it moves where are the vulnerabilities and the weaknesses or the places where you can actually be attacked. So, this is a very very big overview uh of it uh where we are I'm just looking at data definition. So, like all of us here know uh blockchains can't really access data from off chain, so they have to get it from somewhere. But before it even gets there,

um there's got to be some sort of definition for it. So, generally for pricing information or even for an event, like did Zelenskyy wear a suit, you have to ask a question and there's got to be some sort of definition that defines what a suit is or some sort of interpretation that maybe people might take and it could be different than what was intended. But in general for pricing, you're going to have these three main uh main parts of that definition. Is there enough liquidity liquidity? You're making an assumption on that.

Um you you prescribe a type of aggregation. And then you also assume that it's going to be this asset is going to be listed on all of these different exchanges or it's going to be available on all of these different sources. And those are the initial assumptions that you might make and then you go to an oracle provider and you're like, "This is what I want." Or maybe you just use some um random feed that a lot of the oracle providers will provide a lot of free feeds on chain. A lot of them are for uh blue chip assets mostly. And people sometimes they just use it because it's free. They're already on chain and they already have a sort of a cycle of time they're loaded.

So, it's cheap. But if you want something more custom, this is generally what you would do. You come up with a definition, you tell them what you want. And then the second part of as you're designing your protocol, obviously you're excited about the great things that you're doing within your protocol. And then at some point you do think really hard about how to implement your oracle within your system. And when you go through that, you can actually choose from a wide array of oracles. We have everything from centralized oracles to decentralized oracles and there's always a trade-off.

There is no right or bad bad answer to this or choosing wrong. It just depends on what are your priorities and what you are willing to trade off. If you go for a more centralized oracle, you're assuming or you're accepting the the the choke points. If you go with a more decentralized oracle, you're accepting that it's going to be a bit slower because this just takes longer to reach to it's the trilemma applies to to change just like it applies to oracles. So So that's where you have to to make your trade-offs there. You choose something, you choose someone, and then you implement this function that is generally allows you to get data, whether you pull

data from a contract from one of the oracles or they push data onto your contract. And basically there you're making the decision of who gets to decide how often and when you get data. And you can reach agreements, you know, either off-chain or maybe run some infrastructure to make sure that it gets updated when price change happens or if you have a heartbeat on it, but ultimately, you know, these functions just determines who gets to decide when that information comes. And well, we'll go through some examples of how that can have an an impact on what happens on your protocol.

But then after that, the data is like, okay, you get data from the outside world, there's some aggregations that happen, then the oracle protocol relays it onto chain, and then you actually get to consume it. So that's the other portion where like, okay, so when you consume, what kind of triggers um what kind of kind of things are triggered and what kind of outcomes come out of that, right? And then and then that's pretty much where your data ends up being, and from there you can decide or you can start seeing where things can start to break down.

And for us, it's actually very difficult because we operate on the on an open system, so we don't always know all the parties that are participating and there's no there's not always the possibility of suing somebody to get your money back. TradFi operates in a closed system and it's very easy to find out where the money went, who's you know, who's at fault. And if you can recover it, they can always go to jail. For us, as we've seen year after year and a hack after hack, that is not always the case. We just don't have that available to us. It's not part of the our current infrastructure. And so, every little decision that you make from are you going to wait use a

decentralized oracle or a centralized oracle? So, you want something fast, you want something slow. You're making a trade-off. It's not that it's some there is wrong or it's right. You're making a trade-off. So, if you wait too long for get to get information that is more more robust, then you risk settling on more stale information. And if you act very quickly, then you risk having the asset being manipulated. Also, then depending on your on your definition, you know, you might use choose to have a market price or a fundamental or a fixed price like we've seen in a couple of recent cases where prices of uh an expected stable coin have been

hardcoded to one and then that expectation broke and it caused all sort of havoc. Um so, it's a lot harder for us to actually do what TradFi does. So, with that in mind, I'm just I'm going to go through a couple of examples that we've seen in the last couple actually last year actually these are all from last year, but there's plenty of other examples from other years as well. But, these just really exemplify how there's really no easy answer of um one size fits all.

So, last October when they announced the tariffs in the US, it caused all sorts of economic uh waves around the world including in crypto. And in crypto, what ended up happening for some reason, everything moved but Ethereum which acts as a stablecoin as well, they had a de-pegging but they work I mean, they work as they're supposed to as expected. They have liquidations, redemptions, and minting and the mechanism went back and rebalanced itself pretty quickly.

Everywhere except in Binance. So, in this example, they acted very siloed. In within Binance for some reason that I have cannot comprehend, they decided to use their order book as their oracle. And it was a very it had very little liquidity and they ended up experiencing a lot more liquidations than anywhere else in the system. And this if you think about it, that's also a very centralized oracle. It was a choice that they made but it was a choice that obviously made it very very clear that there was something wrong and something different in the system and they went

back and gave most people their money back but I think that that was probably the reason that they did that is because it was so obvious that everything was fine outside of their system that they they had to. The second example is an example where they actually talked to each other too quickly or not too quick or as expected but but having that connection be that quick actually ended up causing an unintended consequence. So, Elixir is dead now but last summer at the beginning of last summer, they had a manipulation attack where somebody found a curve pool with really low liquidity and did a 210k trade that moved the price of that

liquidity pool and even though they were using an an aggregated price of different sources, um, it was it managed to move the price and Jane got it. They did what they needed to do. They did it they they did exactly what they were expected to do. They relayed that information to Avalanche where then um more than half a million were liquid liquidated. And so, in this case they just used a prop basically a market price that it was ultimately manipulated. But then, to kind of fix that, they went back, uh, so Morpheus, Euler and Elixir actually, uh, fixed xUSD to be equal to one on their systems and sort of mitigate this kind of attack

because now if there was a flash loan, well, or a a flash crash, that wouldn't affect their system, right? And so, something external to on-chain happened. Uh, their fund manager actually reported a three 93 million loss and so, they obviously de-pegged in the real world because they just didn't have the money anymore. But because they were hard-coded at one, only redemptions were allowed and liquidations weren't. So, all the LPs were left with really bad debt. And then Elixir died. That was pretty much it for them.

Um, this is these two examples I think just really really exemplify like how there is no right or wrong answer and it is a hard problem to solve. Uh, Moonwell, I think, uh, they ended up getting like a really high price for Ethereum, like 2 million or something like that instead of like 3,000 or something along those lines and apparently there was a conversion issue. Th- It wasn't super clear as to what happened and then resolved. Uh, unfortunately, they had somebody, um, get access to one of their private keys through an AWS server. They minted a bunch of USR and ended up

um basically Um so what two things happened here? So the private key then the role that the that that private key held, the service role, was allowed to actually input the conversion. So even though the attacker only did like um deposits of about 100 and 200k they were able to mint instead of one to one uh I think I I think that I'm minting about 80 million and then running away with about 23. And because a lot of the the vaults on uh I think it was Morpho and Fluid had it USR hardcoded to one.

Um they were also able to just run away with a bunch of money. But this is this just happened last week. So I need to go back and and really dig uh read the deep dive, but that was basically what I found so far. Um and all this to say that uh the way that they operated, you know, they have a data definition, they had their oracle, they had uh their protocol you know, the data flew properly, but ultimately there were a a few places where where this data flow failed. And so when we talk about who holds the truth, well, that's that that depends on how it flows as well, right? So right here uh and in

proba- in the Binance attack was low liquidity or it's not it wasn't I don't know that it wasn't an attack, but on the deep on the faulty mechanism on the um on the Elixir one, that was low liquidity. Uh when you make a when you have a definition for information that you're absorbing or um consuming there's got to be monitors to those assumptions because things change. Um you know, chains get compromised, um private keys get compromised, uh assets get delisted. So, it's not a thing that you just do once and you don't look back. It's something that you have to continue to monitor day and

night pretty much to make sure that those assumptions continue to hold. Another place where they actually didn't do a good job was with their fallbacks. Um There's There's different fallbacks that you can have for different types of of uh I don't know. Of Of not of hacks or or defaults um They're not but they're not things that you implement after the fact. These are things that you have to think about way before when you're actually designing your protocol as part of your oracle implementation because your oracle implementation is not just that one function that absorbs information, but it's all of that that we just saw as how

how data flows. So, you can limit the the change on the asset. Obviously, that has a trade-off because then now you're limiting losses, but you're also limiting gains. You have to be very very good at disclosing those kinds of of things to your consumers. Um You can have an oracle delay. You know, we have OEV, MEV. So, there's there's another trade-off that you're doing there, but then again, you make sure that when the information comes in by the time that you use it, it's actually good information. Maker had a 1-hour delay for many many years. I don't know if they still have it with Sky, but they are one of the biggest uh DeFi protocols out there that has survived uh time after time and they were able to afford that. I think that was a very very good

thing to do. Uh you can also pretend like nothing happens unless there's a um pretend like like nothing happens and um just hold withdrawals. Sure, like, you know, we'll we'll say that this is real, but you can't withdraw for an hour. Then if there's a dispute, maybe you can do some some something behind something to to address it. And like that, you can, you know, you have to think about all of this way way before. Monitors, you really just have to be constant and in evaluating whether your aggregation is still valid. And for that, it's just it's very easy monitors, to be honest.

Or you could even do even if they were the the most basic monitors, it could actually give you a hint when something's going wrong. To put it all together, this is basically the flow of the data and ultimately the the ultimate backstop that we actually have of who controls what what happens is your community because ultimately you can fork, especially if you structure your protocol in a way that you can you can like freeze balances and things like that, but you have to think about those in advance. There's a lot of other hacks out there and they continue to happen.

It's kind of sad then we continue to make the same mistakes again. A lot of them make are pretty much the same things over and over. But something else that I want to talk about is how maintaining or or losing credible neutrality can be a very dangerous thing to do. Obviously, I am not saying Hyperliquid did anything wrong when they actually overrode their oracle to protect their their their users with the JLY attack. Basically, a one of their markets was manipulated and and it was getting to the point where it was going to start eating into their vault.

And then Binance and a few other big exchanges decided to add to the fire by listing that asset on their chain. And so Hyperliquid said, "No, we're going to defend our ecosystem." They and they backtracked everything. We didn't know they could do that until then. Um and this this is really dangerous because things that can happen or they can be coerced into now we can we could think that they could be coerced into doing something that a government wants. Um this specific example here with USDC coin actually uh depegged in 2023 was because um at the at that time the US government was doing like Operation Choke Point 2.0

where they were pretty much uh trying to uh take away any banking uh services to crypto founders. And they managed to close down Silvergate and um Silicon Valley Bank. And when And Silicon Valley Bank held a lot of the reserves, or not a lot actually, it was actually not that much of the reserves of USDC, but they held some. And just because of that people panicked and started selling because they thought they weren't going to be able to get their money out of the system into fiat.

So, this really matters because whether we want to accept it or not, it is um what happens politically inside and outside of the ecosystem actually can have an effect on what actually controls the truth on Ethereum. And as we see institutions come into Ethereum and become a bigger part than they already are, um it's going to that that tension is is going to be felt more because they are too big to fail for governments to let them fail.

And I wonder if we're going to be able to maintain our credible neutrality to make sure that they are also um or that they are not counted as too big to fail. That balance need to be there between the community, the validators, the oracles, the decentralized protocols, uh but it is very difficult to say that as they come in and they take over the majority of the market or a big portion of the market that they're not going to have a say on what happens. And this is what makes it even more important that we as a community and with the infrastructure technically as well, the technical technical infrastructure, we make it so that that is not possible because there's always going to be somebody trying to pull those levers

when something goes wrong. And so who holds the true economic truth on Ethereum? You know what? That's a really loaded question. I think there's a lot of things that we could do to make sure that the truth is actually reflected. Try to find I know that's a picture is not that great, but it's it actually has a hierarchical system. You have courts, you have you know how the system works. In DeFi, you're always trying to figure out how to make it work. And I think it's a it's a question that is worth asking no matter what you're building to make sure that we build with that kind of mindset moving forward and that we continue to survive governments whether they're

friendly or not as a an an industry overall. And with that I ran out of time I believe. So if you guys have any questions, happy to So what do you do uh when you have a lending protocol and say you have a reliable oracle and there's volatility the price crashes the oracle is reporting the good price, but the gas prices are so

high so no liquidator is liquidating and you end up with bad debt anyway. Yeah, so that actually happened on Black Thursday. Um it's it's it it at that point, I think it was a mishap. Uh one of the things that you could have done with teller is you could have paid more, tip higher, so that it you would cover the gas cost, and then you would have gotten the information. But, a lot of oracles is is automated infrastructure. So, if they can't get in, they can't get in. But, if you are able to have a mechanism to actually tip them on top so that they you can pay the cost of that gas cost, you could probably get in some some information in.

But, that same attack vector was recreated on Levana protocol on Osmosis chain, because that's one of the tradeoffs that we do when we go to a chain that's also cheaper. It's also cheaper to attack. It's also It's also cheaper to do a DDoS attack. And I've only observed it once at the Levana protocol. I imagine that that's going to happen a lot more often, but I haven't heard of any other similar ones. But, yeah, they basically recreated Black Thursday. And yeah, it's it's one of those things that you just have to have infrastructure in place. All righty. Well, thank you so much,

everyone.