Oracle Extractable Value (OEV) through OF-Auctions / Ugur Mersinlioglu

Transcript

[Applause] thank you test one two perfect uh hi I'm ugur I'm a product owner at API 3 and I'm gonna be presenting something that we've been working on for quite some time uh Oracle extractable value through order flow auctions before I get started I typically like to ask how much do you know about oracles does everyone here know how an oracle Works rays of hands if you do perfect quite some people so the next slides then will be pretty boring but I'll go over them anyway so why oracles are pretty short blockchain is essentially isolated in itself you can simply make API calls so if you need some type of information like the

weather you need some entity bringing that in for you um I typically like to take the example of price feeds how is data being brought on chain uh price feeds are essentially price information that is maintained on chain according to certain conditions and it is according to certain conditions because we have a cost limitation we cannot simply update data each and every single block imagine in ethusd data feed on ethereum mainnet you simply cannot pay that much money to update it with every single block and there are two dominant architectures namely Poland push oracles that are currently being used to consume price information I'm gonna go into the first one uh push

oracles uh people might know this from chain link so data points are essentially updated according to certain triggers namely deviation and heartbeat so for instance every one percent move if we have an on-chain price of 1000 if we know the next update will be 1010 or 990 or heartbeat if there hasn't been an update in the last hour please update the price the goal of push oracles effectively is to reflect the real world on chain whenever it matters to save costs and whenever it matters is typically defined as a certain price move or no update in a while the good thing about push oracles is that a price is maintained on chain you can simply consume it you

don't need to think about getting it or whatever you simply read price from Storage problems with push oracles everybody always wants the latest price and it is because of that that they are pushing for very low deviations like you want to be as close to the real world as possible but that low deviation threshold is increasing uh cost exponentially so you're basically the lower you go you're striving for every block which again makes it unaffordable to do so so we got to ask ourselves who pays for that granularity is it the change themselves which some do as it adapts rarely the apps pay for oracles is it the oracles themselves that subsidize it another major disadvantage is that a typical push architecture the

update is only triggerable by the oracles that are defined in a data set for instance again if you look at something like chain link there are 30 nodes in the ifusd price feed and they update according to one percent and one hour you cannot pay them you cannot do anything to force an update that is what you live with which brings me to Paul oracles so Paul oracles something like piff does this they maintain essentially the price somewhere else on their own chain and you can pull it onto the chain that you want to consume it on whenever you need it for instance a user could be opening a leveraged position 20x long on Eve on quenter and for that they want the latest price and they pull the price on chain with opening their position

or a Searcher could be updating a price to liquidate somebody on a lending Market the goal here is similar to push oracles is to reflect the real world on chain whenever it matters just that whenever it matters here is defined differently we actually take the actual interactions when a user uses the protocol when the Searcher wants to liquidate someone that's when the Oracle events happen uh which basically brings me to the bottom point the data is not being maintained on chain and needs to be written every time it is needed but anyone can do so as long as you pay for the transaction costs the problems with protocols so since there's no maintenance of price

information on chain you literally have to pay every time you want to use it so you pay every time for the Oracle who pays for this namely users and Searchers and there was a really interesting discussion about this in the other forums lately where one of the core developing teams of other basically said that from a technical standpoint it's not really possible for them to change Ave from a push to a pull model because it has two great implications on ux and the protocol just imagine you want to take a loan on Ave and not only paying for the contract interaction now you also have to update the price every time funnily enough I think one of the

solutions that was suggested is that somebody just runs a quote-unquote price pusher to take the price from there and update according to 30 minute heartbeats and 0.25 deviation which effectively just turned this polar architecture into a centralized push architecture which makes little sense which effectively brings me to the this major disadvantage it's it's this is a new architecture that is not as proven as push oracles yet and requires major changes to the protocol designed ux so people simply currently don't want to do it um which brings me to what is Mev so all of you probably know Mev stands for

maximum extractable value and it is a hidden fee that is imposed on blockchain users by more strategic third parties that are extracting value from their transactions the best example for this is probably the sandwich attack on the decentralized exchange you want to buy 50 if worth of Pepe somebody sees that in the mempool they buy before you they sell after you they extract value from you what does this have to do with oracles so Oracle extractable value is basically a subset of Mev that is related to how oracles function the apps use oracles to determine prices and on their supported assets which means that any update to a

data feed or even the lack of such an update can create opportunities for Value extraction this could be front running this could be front running for instance you do something before an oracle update and after it could be Arbitrage The off-chain Exchange is further ahead than the on-train equivalent so you ARP the difference or liquidations so effectively similar to Mev oev just describes the value extraction by more strategic third parties but related to oracles a quick example I think that everybody here will understand uh this was last October uh the GMX front running Oracle updates example which triggered them to make some changes to their protocol so

effectively GMX for those of you who don't know is a uh derivatives protocol that is based on oracles instead of an order book so you can open a position directly at Oracle price and close directly at Oracle price uh the problem is you can monitor the mempool for Oracle prices so you know when an update occurs you can buy before the update you can sell after the update you profit and you can repeat this indefinitely there's nothing they can do to stop you and that effectively led to approximately 10 of their entire protocol revenue or profits being extracted by Mev Bots over 40 days which led to 260 000 being essentially just siphoned off

so ouv awareness most of the blockchain industry acknowledges oev we've been talking about it I think for two or three years uh however neither Oracle Solutions or dapps today are really oev aware and what I mean by that is that they don't do anything significant to stop losing value to third parties a Band-Aid solution typically is ask for more granular feeds but as I explained in the push Oracle scenario you can't do every block on every asset there's just simply not enough money in this ecosystem to pay for that so how do we solve this problem we need a solution that effectively eliminates or retains most of the oev that we lose

to third parties while at least maintaining current user experience what I mean by that is there is reluctance to switch from the known push models by simply reading data to something like a poll model while we also do not jeopardize the Integrity of data feeds um we were effectively building uh such a solution for quite some time and we looked what is currently already out there in the Mev industry and the typical thing are order flow auctions you as a user can redirect your order flow if you create transactions they might be related or they might create Mev and you can route your transactions effectively to a private mempool that

promises not to gossip transactions extract the oev uh Mev and distribute it back to you good examples for this are Mev blocker or flashbots Mev share uh the problem mainly is and there are quite a lot why we can't route Oracle updates through there uh the biggest one is that these auctions introduce latency and Oracle updates can't really shouldn't deal with latency because that is jeopardizing the Integrity of the data feed you can't just effectively update the data feed 30 seconds later because you're waiting for an auction result so what we needed was an order flow auction that is specialized for oev so

we were thinking that we need the Oracle notes that effectively updates the data feed based on deviation thresholds on the public mempool so there's no delay there's no auction nothing we need to wait on so the classic Model that maintains it but in addition to that we run an order flow auction basically oracle's getting updates and allow Searchers to bid for these updates so effectively whenever there's something some value that they can extract they make a bid for it they get it through a meta transaction and then they're allowed to update the data feed this design effectively uh maintains the security guarantees that the data feed has while allowing to generate value

that Oracle order flow generates to be auctioned off what allows this is what we call the oev relay so this right here and what that does is if it's effectively collecting signed data from all oracles that are within a data feed and then the auctions are auctioned off in a sealed bid auction seal bit means somebody makes an offer of 900 but they don't see what everybody else bids so everybody bids what that update is worth for them the winner then gets a meta transaction with uh that contains the information of how much they bid and all the signed information and they can use that to update the data feed and net all of the rewards that come with that

one big issue that we still had with that is if somebody updates because they can liquidate somebody on Ave that price update might actually also cause oev for instance on synthetics how do we deal with that um which effectively brought us to data feed proxies so instead of everyone reading a base data feed we thought it might be wise that every dab has their own data feed proxy these proxies are effectively reading the base data feed but are updatable through the oev relay an update is only accepted when the meta transaction and the payment are made to the proxy and since each step has its

own proxy you know precisely where the oav was generated so for instance a Searcher makes a bid on ifusd specifically for Ave that has nothing to do with what happens on synthetics so they can exactly know their bidding to update for Ave the big picture is then effectively this I'm going to start on the right side we have the dab the dab reads their dab specific proxy and that proxy underlying reads the base data feed that I talked about this data feed similar to something like chain link is updated by a bunch of Oracle nodes on the basis of deviation so this could be at 1000 and we know the next update will be at 1010 or 990.

but if there's a Searcher that says it's 999 and I want an update now because I can locate somebody that can make a bit get signed data from all of these and update this dab specific proxy and this proxy essentially prefers the more recent update which is determined on timestamp so they then essentially pay directly to this contract update it and with that update that can extract everything that they want simple example which makes it maybe more appealing to everyone everyone knows Ave I hope other uses oracles to determine the value of assets and borrowers are for instance liquidatable on the basis

of that data one big issue that dabs face or let's say one big thing that the apps do is they give people a liquidation incentive to liquidate somebody and the typical problem we faced there because there are a lot of lending apps trying to optimize for this is this incentive is typically percentage based so when there's a one thousand dollar liquidation and you liquidate somebody the Searcher gets like twenty dollars for it uh you have to keep this rather high in order to be incentivized enough to do this on low amounts of money but when we are looking at something like this you suddenly are paying somebody 10K for simply

liquidating somebody which when we spin larger gets pretty inefficient not only uh is are you essentially like giving them too much credit you are taking away more collateral from the borrower than you should be which brings me to other push the classic however currently works with push oracles imagine we have an if USD price feed with a one percent deviation and the on-chain price is currently one thousand dollars we know as I said five times probably already the next update will be 990 or 1010 but there's a user position that is liquidatable at 995.

in this current other model we need to wait for the Oracle update to occur in order to liquidate the position we can't do anything we just wait for the oracles once updated the value is essentially being extracted by external players nothing flows back to other the user gets essentially liquidated and the value just goes to the external people monitoring for such liquidations and to top it all off due to this update mechanism the user is actually not getting liquidated at 995 they are getting liquidated at 990. so they are losing more collateral in the process than they should be what if we use the pull Oracle model on Ave a polorical art model would actually

be better when it comes to liquidations because liquidations can occur directly at 995. the user gets efficiently liquidated directly when they should be but the big issue is that the value is still being lost to these third parties and we're speaking more of the bigger liquidations so you're effectively because somebody is liquidating them having to give them 10K out of your pocket if we talk about a half million liquidation and like I mentioned in the slides as well the overall ux implications of switching from a push to a pole model are currently simply too high which brings me to uh Ave on an oev data feed model that we are have been working

on so with the oev data feed model we focused on maintaining the typical push infrastructure that is out there however it doesn't need to do anything different they simply read price the users don't need to bring Oracle updates on chain the protocol doesn't need to change anything you simply read from Storage on top of that liquidations can occur at 995 because Searchers can simply go to the oev relay make bids take those signed data updates update the Oracle and effectively liquidate the person the user gets like I mentioned effect efficiently liquidated because they are getting liquidated at 995 instead of 990. and because Searchers actually compete

Searchers already compete when we talk about Mev but the main difference is that these proceeds go to validators with oev auctions we actually bring the auction process itself to the Oracle and we as API 3 similar to Mev blocker or flashbots Mev share have a 9010 model where we redistribute 90 of the proceeds back to the DAP so effectively Apple retains more value through competition among the Searchers the value doesn't go to the Searchers and validators that they bribe the Searchers are actually paying back the dab for the value that they bleed so uh why use oev data feeds I've been on vacation in the last two weeks I have

been told it is now called oev share if I'm correct yes so similar to Mev user the users demand that Mev that there are solutions to Mev extraction we know about Mev Blocker we know about stuff like cow swap we know about flashbot's Mev share and oev is actually nothing different just like users want something to block Mev being extracted from them dabs are slowly and more frequently demanding that value that they're bleeding away due to Oracle updates gets minimized or eliminated entirely and with oev data feeds we effectively wanted to create a

opportunity for sustainable revenue for the oracles while helping dapps users and chains retain value that they're bleeding away currently due to oracles that simply update without thinking about what actually happens due to their updates and that is pretty much it we have a Bounty today so just check out the hacker manual I believe it is and there are also some T-shirts for everyone that wants some and otherwise I am open for questions if there are some foreign all right thank you oh I think there was

one we do okay thank you um just one question if um we have uh yeah trading protocol for example our Landing protocol which relies on Oracle data and we want to avoid that value is extracted based on updates and we know that the update is every 0.25 for example wouldn't it be then the easiest way to adjust charge as much fees so that the update if it's only by that value

will basically cause the the loss for for the difference for for the Searcher for example for the Searcher that the problem is uh if you're charging money you're making your protocol in one way or another more inefficient due to the fact that the Oracle is not optimized for your use case so what you're going to do is you're going to charge the Searcher more which in effect might they endanger smaller liquidations like smaller liquidations are already a big problem because you have to incentivize Searchers to actually take them on because there's nearly no money in it but while doing so you're making the larger liquidations way too attractive so if you're going to charge something

on top you're just gonna make the problem on the smaller and bigger and people are just not going to liquidate those people anymore or barely okay makes sense thank you all right last question okay so how large is this problem I mean you gave an example saying that uh 250k was kind of dragged out of GMX and like Mev is a really big problem like is there a way to kind of quantify how large is the opportunity and the problem here um but basically anything that in one way or another uses an oracle is somehow creating oev and uh in some cases it is just accepted for instance the

liquidation example and in some cases uh there are protocols effectively running their own Searchers and limiting who can liquidate on their platform or who can Arbitrage on their platform because there's Mev Bots and others coming in and simply taking value out of it and we're not talking only about like front running Oracle updates or or liquidations like there are bigger market makers or entities are being the difference between off-chain and on-chain values and there's nothing that the protocol alone without the Oracle helping can do about that and maybe also like one thing we're currently in the alpha with this and we have like I believe currently five dabs that are alpha testing this with a bunch of Searcher groups where they can

essentially do that and what happens is just that like the value is not eliminated it is still there you're just making it so that these Searchers similar to uh something like Mev blocker or whatever they're competing with each other and instead of this money that they are currently paying to validators for priority they're actually paying to the auction host in this case the Oracle operator but we effectively similar to Mev blocker redirect almost all of it back to the dab so it's not gone we're just making it so that the money stays in your pocket like I think our co-founder likes to say imagine you have a leaky pocket and when you walk there's something falling off and like every 90 cents you drop or

every 100 cents you drop we give you 90 back and we keep 10. perfect thanks [Music]