What do you mean by „Searchers know when to request oracle order flow because there are designated API endpoints for each node operator they can query off chain“.
This sounds a lot like you want to expose the api fully so anybody can monitor values. This is going to be a major issue if this is the intend, since you’re effectively exposing the provider data and allowing anybody to access said (probably gatekept) data for free.
The way Ashar explained this to me is that you intend to expose the median value of a data feed, so that searchers know when they can update each individual beacon to get the exposed beacon-set value on-chain.
If this is not the case, and you’re going to be exposing each individual data provider via an API, you’re effectively going to make it possible for anybody to acquire said data without paying for it (ever) and do with it what they want.
I can most definitely already tell you that providers like Amberdata will not willingly expose their 6 figure API to everybody.
My suggestion here would be that only the aggregated value is being exposed to searchers, so they know when it’s lucrative to update the underlying beacons and then the beacon set to receive the value they want to e.g. liquidate somebody.
Here you still allow them to bid on what they want without exposing each API directly to the entirely world.
I guess I wasn’t clear sorry, the searchers would be responsible for making their own deals with data providers, we won’t expose data to searchers that haven’t won an auction and agreed payment for that datapoint. So this could be as simple as searchers buying regular api access or some type of special deal for the specific beacon endpoints like you suggest. This way the data providers remain in full control, but we can assist them as much as they would like.
If the data providers prefer we create an API to expose of aggregated values from the beacons then I don’t see a problem with that.
It definetely won’t just be exposed to anyone, it will be a permissioned system we just have to keep low barriers to entry. So we can still charge an appropriate fee to compensate the providers if we have to create an aggregated API.
What happens if API3 points the dAPI that a dApp uses to another set of providers?
That’s the only way i see it working tbh. Expose the median value and show the searcher that it is profitable to update all underlying beacons to get that median value. But then anybody can effectively read that value from us and “resell” it however they please.
Interested in hearing more about how exaclty you were thinking.
What happens if API3 points the dAPI that a dApp uses to another set of providers?
We could reasonably expect searchers to monitor for those events on chain and respond accordingly in an emergency, and communicate as much as possible otherwise. Remember that this operates as a sidecar to the underlying feed so downtime is acceptable.
But then anybody can effectively read that value from us and “resell” it however they please.
I dont understand this argument really. Data providers will expose this data for the same reason they put their data on blockchains where anyone can read and resell it, they believe that it will return them enough revenue.
Interested in hearing more about how exaclty you were thinking.
Each searcher has an api key, for instance we can see if a searcher is only reading values but not participating in the auctions and revoke access. The simple solution is just charging some base fees to view an aggregated API that compensates the providers enough right?
Sorry. Lost track but def wanted to continue here.
I think this approach will be too inconvenient overall for potential searchers as it assumes a lot of things (don’t take this wrong, I’m very bullish and making these comments because I want it implemented)
each data feed can have different and ever changing sources. Can we reasonably expect searchers to buy a new subscription or up to 5 completely different ones depending on the sources used in a given feed?
this approach also assumes that we will somehow always communicate if we change a feed somehow. I believe that this is unreasonable to assume given how many different feeds on various different chains we will operate
data providers won’t make an API gateway publicly available to allow searchers to update underlying beacons. It undermines their entire actual API business in the hopes that they will generate revenue. The only way I see this working is if only the aggregated value of a data feed is publicly available and searchers can, on the basis of that, update underlying beacons and the beacon set, without knowing what each individual providers answer will be at any given time.
how do you intend to distribute the resulting revenue? I guess it’s trivial if only one dapp is using the feed and getting the OEV, but what if you have like 10 dApps that all want their share of OEV on the same feed? How will this be maintained and operated?