Option for dApps to make OEV auction access permissioned

Many of the platforms where there is significant demand for oracles currently are ethereum L2s, one property of L2s as they stand is that a centralized sequencer is responsible for producing all of the blocks. This means that there isn’t a public mempool, and thus no ability for searchers to frontrun transactions. While L2s all plan to decentralize the sequencer eventually, this could take a while.

So normally on L2s oracles cannot be frontrun, but if a dApp uses OEV data feeds then they would enable frontrunning. Over the long term if the searcher market was sufficiently competitive this wouldn’t be such an issue because most of the frontrunning value would go back to the dApp through the auction, but the auction may not be very competitive to start. For this reason I believe the DAO should consider giving dApps the option to make participating in the OEV auction permissioned, so that if a searcher chooses to frontrun the oracle their access can be swiftly revoked.

Outside of rollups or in a post decentralized sequencer world dApps may also choose this option for other reasons such as the fact that it could remove the need for a % of searcher staking and make the process more capital efficient, or maybe an application specific need to prevent frontrunning alltogether.

Who makes that call though? What stops dApps from only allowing themselves to do updates? In that case they could be bidding the minbid amount and get the “freshest” data at cost and also keep all proceeds.

There is already the issue that we can’t control what a dApp (or rather the person setting up OEV for the dApp) does with the proceeds of auctions and we’d have to trust that they use it in a way that benefits the dApp. With this we would additionally give them the option to actually monopolize OEV entirely?

Permissioned auctions are common practice for MEV, see Cowswap, ROOK, Kolibrio.

Why should we force all dapps to have frontrunning of OEV just because of the highly unlikely offchance one of them wants to monopolize it, which would be the dapp and users choice in any case?

This essentially provides dApps with a backdoor where they can extract OEV without being noticed. Whether they sell off access permission or extract OEV for cheap themselves (same thing), they will effectively be eating into API provider revenue. Also, unlike OEV revenue, this revenue flow will be very non-transparent and will likely go into dApp insider pockets, which is why I think anyone would push for this and this is something we should capitalize on (though I wouldn’t speak more about this until this is more concrete).

It will probably be somewhat more difficult to identify frontrunning of oracle trades by a malicious searcher than frontrunning of AMM trades for instance within flashbots. This is due to the fact that OEV doesn’t use bundles so searchers can frontrun and backrun with different EOAs, and likely do so across multiple blocks. I still think it would be a worthwhile experiment though.

To pose my position more openly, with the permissionless design, the dApp will openly receive a lot of OEV kickback. Then, either by contract design or operationally, what happens to the kickback will have to be accounted for. Permissioned access allows the kickback to be reduced in favor of searcher profit to an arbitrary degree. Whoever decides who gets access can now redirect however much of the OEV kickback they want into their pockets in the form of searcher profit.

The point above hurts the dApp stakeholders, but it also hurts other OEV stakeholders (i.e., API3 DAO members and API providers), which I care more about. Imagine a case where someone from the dApp team and someone from the OEV operations team collude to pick someone they know as the designated searcher for that dApp. This will effectively result in less API3 being bought back and burnt. I believe that the legacy DeFi is riddled with these kinds of shenanigans and as an API3 token holder I’d demand an impenetrable tokenomic design.

To sum up, I don’t see permissioned access as a valid solution to unproductive OEV because it destroys our tokenomics. I think we should aim to solve that at the OEV design level instead by parameterizing auctions (as I’ve mentioned before, I believe the minimum bid amount to be a very powerful tool here). I’m not ruling out redirecting some of the OEV to strategic parties (and I’m mentioning this because I expect that users will in general request this feature as a convoluted way of achieving that) as that would be an incredibly strong catalyst for adoption, but it needs to happen in an accountable way for it to improve API3 tokenomics.

Permissioned access doesn’t mean one designated searcher, and CowSwap is a very successful example of permissioned searching not resulting in the collusion you describe.

There is a very clear tradeoff to permissioned searching in this case of less kickbacks to the dApp (which you point out), but also less value extracted from the dApp. We cannot know if the frontrunning value that could be prevented from being extracted is greater or less than the reduction in kickbacks, which is why I thought this could be a valuable experiment.

In any case, as you say min bids can prevent some unproductive OEV, and I realized frontrunning could be difficult to enforce against. The pull oracle protocol used by Synthetix is the true solution to unproductive OEV anyway so maybe this isn’t worth the effort.

CowSwap is a very successful example of permissioned searching not resulting in the collusion you describe

No offense to them specifically but I don’t see how it can proven that there hasn’t been any collusion/bribery in that process

The pull oracle protocol used by Synthetix is the true solution to unproductive OEV anyway

For the public record, I think this is flat out wrong and the schemes that don’t allow OEV to be extracted are vastly inferior to OEV+fair incentive mechanisms. The benefit of OEV is that it allows one to estimate the value add of an oracle service, which can then be used to reward strategic parties that made that possible in proportion. As soon as such a mechanism exists, the strategic parties will stop enabling the alternative that lacks OEV.

I mean it’s not perfectly provable but anyone can go through the process of registering as a searcher for cowswap to check themselves that it’s free and without collusion. The data also seems to clearly show efficient competition.

Do you have any technical debates for why pull oracles don’t prevent the majority un productive OEV?

Thinking of OEV as a way to assess the value of an oracle is way off I think. For instance Chainlink pull feeds caused lots of OEV for synthetix, but they switched to Pyth which reduces OEV significantly because that drives more value to their dapp. Even if Chainlink were to have offered OEV auctions to reduce the value extracted, Synthetix still would have chose Pyth because it results in even less value extraction and driving value to LPs is the only sensible method to compete with CeFi. OEV is simply a subset of MEV, and no MEV researchers will tell you that MEV shouldn’t be minimized. It just doesn’t make sense to maintain such an in-efficiency in a DeFi application simply to try and value an oracle service, the way an oracle service should be valued is by the revenue a dapp is generating (protocol fees + LP profit). This is now supported by the two largest perp dapps by far moving to pull, lending protocols are a different conversation because they don’t suffer from un productive OEV. If DeFi is going to succeed there just isn’t room for inefficiencies, and Pyth and Chainlink have shown they will monetize without OEV auctions (CL through taking a % of fees and Pyth on a # of calls).