Oracle Extractable Value (OEV) through Order Flow Auctions

ETHBarcelona Talks · July 2024 · 23:55

Ugur Mersinlioglu explains oracle extractable value and how order flow auctions can capture it. The talk describes how oracle updates create MEV opportunities for searchers and how auctions can return that value to DeFi protocols. The speaker presents auctions as a mechanism to recapture value that would otherwise go to searchers. Presented at ETHBarcelona.

Speakers

Topics

From ETHBarcelona Talks, hosted by ETH Barcelona.

Transcript

our first Speaker as I already said uh is ug molu uh he's from API 3 and he's going to talk about Oracle extractable value through orderful auction so give a huge round of applause for uger thank you um perfect uh thank you for the turnup I know it's early but I hope that uh you will be able to follow me so so basically uh my name is ugar I was already introduced by Hannah thank you for that and I'm I am a product owner at API 3 and what we do is Oracles so before I get started I know we're not a

lot but does everyone here know how an oracle Works hand like raise your hands if you all right perfect so the next one or two slides might be boring then so um why Oracle uh we know that blockchains only have access to information that is already on them so you can't simply access the internet to for instance get prices you need somebody to bring that into you for you to consume it uh the typical example for that are price feeds everybody knows them from for instance chain link price feeds are typically maintained uh according to certain conditions in the chain link example it's push oracles meaning when the offchain price and the

onchain price for instance differ by 1% we update the onchain price to reflect the real world uh why we do that only under certain conditions is that we cannot update with every single block we can't simply pay so much gas to keep the real world onchain basically the entire time so what we do instead is create these conditions for instance 1% deviation or every hour or once a day to make it more affordable to reflect the real world on chain but we still got to ask ourselves who at the end of the day pays for this like who pays to bring price information for instance on chain and I know we're not a lot but I'm just going to ask into the

round uh who do you who do you think do do dabs pay for this like raise of hands if you think any dab pays for Oracle Services two two three Okay so in most cases uh I'm just going to bring up a slide from Adam Cochran I think uh is the name um basically what we dealt with in the last five years is that price feeds or any Oracle services are basically free for dabs and mostly subsidized by for instance the Oracle project in the case of chain link it was like that that basically you as a link holder uh were sub passively subsidizing

all of the price feeds that people were using on ethereum daps actually pay nothing and have almost never paid for Oracle services and in some cases chains actually pay but only like a niche cases for instance the ethereum foundation is not paying for Price feeds on ethereum they are mostly subsidized but some Niche chains might cover the cost but essentially we created this environment where we have a product that costs something but because it's so heavily subsidized dabs are used to not paying either the chain picks up the tab or the Oracle project picks up the tab and that's actually a quite interesting

Trend we see in the last couple of uh months where Oracle projects are slowly starting to um ask for money and dabs are not really used to paying chains are only used to paying the bare minimum so what happens is and we realize this uh a lot in our business development efforts in the last couple of months is people approach us because others actually dared to ask for money and that is a quite interesting Trend where you see that you you don't really make money providing price feeds if you start charging they will just go to somebody else who will reintroduce this cycle of subsidization because we've established

these grounds of oracles are not something you pay for they are just there for you to use and that is a very tricky thing or like a very tricky situation because at the end of the day you're running these things either in a minus through subsidization or at Cost where you basically just cover your grounds and your only hope of making or like generating value for your project is hoping that adoption leads to positive price action which if we look at Oracle valuations and what they actually enable it just isn't the case like the real value of what is enabled I think Oracle secure over 40 billion in the defi space but no Oracle project is even close to

coming to that valuation so if you as an oracle project are only providing quote unquote simple price feeds you're eventually going to fail somebody's always going to make that cheaper or for free so we as Oracle projects need to bring more to the table to be allowed to subsidize is for the most critical service in the blockchain space essentially and this brings me to today's topic which is Oracle extractable value Oracle extractable value is essentially a subset of me uh what is me all of you notice uh probably it's a hidden fee that is imposed on blockchain users by more

strategic third parties that extract value from their transaction a lot of words but you know what this means you buy for instance one 100 eth of Pepe on Unis swap somebody sees your transaction in the mempool they buy before you they sell after you sandwiching you in between and extracting value from you uh effectively then the question becomes what does this have to do with oracles uh like I mentioned dabs use oracles to determine the spot prices of their supported assets for instance a landing Market needs to know what their collateral is worth which then in effect means that any update to such a price or even the lack of such an update will create opportunities to extract value

this can be in in the form of front running uh for instance buying before an oracle update and then selling straight after uh it can be Arbitrage where the onchain price lags behind for instance a centralized exchange and you can ARP the difference or it can be in the form of liquidation so similar to meev oev just describes the value extraction by more strategic thir thir parties that is related to oracles um if we look at the me field out there uh what is typically being done to tackle this field uh are orderflow auctions so when you as a user have an uh intent to change the state of the blockchain that is effectively in order and we call a collection of these

order flow and if you auction this order flow off it's called an autoflow auction and autoflow auctions can be performed in various different stacks of the like in various different levels of the blockchain stack you can for instance do it directly at the daap level which is something like cow swap I'm not sure if you are aware of that you can do it on the Builder level where you route your transactions through something like me share or me blocker these people effectively use your orders extract any me that is related to it and return like 90% of that to you or you can uh do Oracle like orderflow auctions on the validator

level so then we basically ask ourselves why don't we take these valuable or Oracle transactions we have and just route them through one of these layers to create order flow for instance to the Searchers and the main issue of why we don't do this there's quite a few reasons but the main one is these auctions introduce mostly most of the times delays and this would mean that if you want to update a price feed because something important happened and you want to reflect that onchain now you kind of need to wait for the auction to be done see who pays you the most for the update and now your price feed is getting delayed by 10 15 20 seconds which is just not something acceptable

in most cases if we have a let's say 10% drop in like 15 seconds it's just not acceptable to do that so what we needed is then to think about how can we auction of these Oracle order flow and similarly to how I told you that there are different layers of where you can actually introduce orderflow auctions uh we thought we just bring the orderflow auctions to the Oracle layer and how we do that is that we have a base data feed uh that is maintained according to deviation and heartbeat similar to something like chain link so every time there's a 1% change we update the onchain price feed but add in addition to that order flow

Oracle orderflow like another update can be requested by somebody else by just asking the oracles for an update now in this moment because there is something onchain that you want to achieve and that costs you something that is associated essentially to an auction a simple example for this would for instance be and I have one later as well where the price of E is at 1,000 we know the next update will be at 990 or at 1,10 if it's 1% deviation but the offchain price actually is 999 and there is a liquidation possible on a at 999 so now there is value attached to

getting exactly that number from the oracles even though the oracles themselves won't necessarily update when that value is available so effectively the existing design the base feed is maintaining all of the security guarantees that we have in a data feed uh while we also allow value to be generated that can be auctioned off uh what makes this possible is something we call the oev relay so effectively it's a relay that collects data from all the Oracles in a data feed then these answers are auctioned off the winner fetches the answer and in that fetching process in that meta transaction they fetch they basically get exclusive rights to update

a data feed and and everything is attached to it like basically all the answers of all all the Oracle nodes which are cryptographically signed plus how much they bid to get that answer and now they can update a data feed and in the same transaction they need to pay to be order in order to be able to update it and we imply a very similar model here to what me share of flashboards or M blocker implies where we basically um take a 90 or like return 90% of this generated value to the dab in the form of the bid and take a 10% cut one issue that you still have is that when you update when you allow

anyone to update the base feed uh it might be that you update it because you see a Liquidation on a but at the same time that update now allows you to liquidate somebody on compound for instance which is a very big problem because now if somebody paid you for for it who do you associate that money to do you give it to a do you try to figure out how much each protocol should have gotten and it becomes very complicated so we can't allow anyone to update the base feed which is why we introduced effectively data feed proxies so instead of the dabs just reading the base feed each dab reads a proxy Instead This

proxy reads the base feed but can be updated on top of this so basically a Searcher instead of updating the base feed updates a specific proxy of a dab this way if you see a Liquidation on AA you bid to update the AA eusd feed and this has no implications on compound which means we can associate now the value that's been generated directly to a and a gets paid for it uh the end of this is basically uh a structure like this uh like I mentioned I'm going to start on the right side with the dab you have a dab this dab reads their dab specific proxy for instance AA eusd and this dab specific proxy is

being is mainly reading the base data feed this data feed is being maintained let's say by 30 Oracle nodes at 1% deviation so every time that this just reads there but now a Searcher sees hey apart from these 1% updates that the feed already does there is value right now that I need to extract so what they can do is effectively make bids to these Oracle nodes and get signed answers from all of them and then instead of updating this base feed update the dab specific proxy pay the dab for being allowed to do this and update it and essentially extract

all the value that is associated with it for instance liquidations obviously if somebody liquidates someone on there is a certain value attached for it if you liquidate half a million position there's like 10K to be made which means that there's $10,000 of value that can be auctioned off in this process and in the best case scenario people are so competitive with each other that most of that 10K actually flows back to a uh and this is a bit complex so I'll just try and give you a more precise example of what this allows uh the this was last June or July during that whole 3our arrows Capital uh disaster uh they

basically had a pretty big position on a uh and their health Factor was very low basically uh I think the E USD price feed of chain link was at 1,020 and the next update would have been at something like 1,0 and the three arrows Capital liquidation price was at at 104 so you know chain link would have only updated basically under 110 which as you can see on the graph on the right never actually happened the price dipped it would have been liquidated if we were on a centralized exchange and then it just went up again so basically three arrows capital in

that sense the position was saved simply by not uh the Oracle not updating due to the deviation uh configuration that is being made so if we instead uh if they instead used the OE share model that I described we would have still had the base feed at 1,20 but when the offchain price would have hit 104 Searchers would have been able to pay for that update and it was like a 1,000 Eve position like we're talking a lot of money here and they would have been able to compete for that update that has a lot of value attached to it update the proxy and thus net all of the

rewards that are attached to it obviously after the cost that they paid for the update in this instance three arrows Capital would have been liquidated right at that position AA would have made more fees because there's also a liquidation penalty attached to it and in addition to that Searchers actually would have paid a in order to be allowed to liquidate this position since this auction brings the money back to them most of it so why OE share uh the gist of why you should use oev share is very similar to why people use something like me blocker or Flash BS M share uh order flow that you create uh has potential value attached

to it and there are parties that are willing to pay for this like you if you route through flashboards if you route through M blocker people actually pay for your transactions and dabs that use oracles are pretty much in the same position like you using an oracle means that any Oracle update potentially creates value and currently that is just being ignored typically similar to how your transaction has value to it and can be auctioned off you using an oracle as a dab actually create value where you should get a so so to speak quick Kickback so we thought it is only uh natural to bring this auction process onto the Oracle layer and allow dabs to

actually take control over their transactions um and I think that is pretty much it I'm sorry for the slides uh I was a bit under time pressure but I hope everyone got the gist of it that's pretty much it if you have questions shoot otherwise uh and I can't see if there's like something in the chat room that is not on here yes sorry I didn't hear I mean uh it kind of depends if

there is value attached to it Randomness is a bit trickier because you don't really like I wouldn't say it works for Randomness but I don't also want to just restrict it to for instance a price feeds it could for instance be that there's anything else in the world where there's value attached to it so basically anytime the Oracle update actually creates some type of value where it might be beneficial to update earlier than just the preset conditions because like what what people typically do or like in this push chain link scenario or in this typical push Oracle scenario scenario is somebody just decides what is the most economical

way to configure this which might be 1% because after that the costs get insanely high and then they just update at that 1% not really caring about if there might be something in between or what might what their updates might do so we kind of need to introduce a way to allow other people to also update if there's value to it so you basically oracles need to in addition to maintaining the security guarantees allow or acknowledge that there might be additional cases to update like any update is always good and if people are willing to pay for it that's even

better vulnerabilities in the sense here for this model what vul abilities it can happen so what do you think basically uh in in our way somebody like somebody for instance needs to run this relay which is very centralized so basically where you ask and pay for that is something run by a centralized entity which we try to mitigate by having the base feed that is decentralized like for instance this OE additional these additional updates can be gone for instance if we are removed from the equation but the base feed will always be there so there are essentially ways how the how should I say this it's

basically currently a centralized service slapped on top of something that is decentralized and maintains the security guarantees which makes it ex which is the only reason why it makes it acceptable like essentially the value add comes from something more efficient similar to l2s currently like l2s create all of these value but all of them are centralized and it is kind of okay and accepted because they share share the security guarantees of the base layer and in the same case here OE on top of these base layer of Oracle feeds is accepted to be centralized because if everything goes wrong the Oracle the base feed doesn't die it still continues to operate sorry it looks like the new way

to earn on flash BS yeah it it is it is L that that's why I say like oev is a subset of meev like it is me but just related to everything oracles so this is essentially flash Bots for oracles do you have this product already or it's just a project uh we currently are in Alpha Testing with like five deps we have developed it in the last like six months and we're going to release it sometime this year or like maybe even the quarter thank you for for the presentation um

the fact that you can update different proxy oracles will it allow for Arbitrage in terms of like if you have a position hedge with another position and two people update the two different proxies with different prices you might not be hedged is that yeah like obviously it depends on your uh on on what what type of product you have for instance uh I wouldn't potentially recommend a push Oracle for something like um derivatives platforms like they are derivatives platforms currently are thriving on the pool model so what you're describing where you mostly have the Arbitrage if you look at something like lending protocols it

won't make that much of a diff difference and what we're talking about here is also mostly very small differences for instance most price feeds are already operating on very low low uh deviations so it's when when we're talking like difference in what compound reads and what other reads and you take like let's say the base feed is at 1,000 ala might be at 1,1 and compound might be at 1,2 so to speak and that Arbitrage opportunity again creates a potential auction where you can essentially now somebody else is inclined to take a loan their update this and pay it you know what I mean

like it it continuously creates opportunities to be auctioned off does that make sense thank you I think that's it thank you so much great job