-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Orderflow Data API #4
Comments
To kick off discussion here are some ideas:
Even with this small list there's already tension here between Originator Order Transparency and Searcher Bidding Privacy. If we make searcher bids maximally private, that is we only reveal the tx hashes of all back runs for a given order, then the public does not have a view into the bidding process, only the result. The searcher builder market as it exists today operates in a similar fashion where searcher's don't see the auction results until it's onchain. This can be contrasted with the relay where all bids during a slot are publicly available and almost real-time out of necessity, and as a consequence a common strategy is to constantly monitor these endpoints. Despite the bundle privacy in the searcher builder market today, many searchers have found/find equilibria on opportunities where 99.99%+ of profits are given to the validator for inclusion. Therefore it may be best to optimize for Searcher Bidding Privacy as it's historically the most welfare maximizing for the user. But maybe we can still find some way to express the competition to the user? Some ideas could be to post aggregates like how many back runs an order received or a count of unique searcher addresses bidding on an opportunity. Another view to ground the discussion, what are the things a user is most likely to care about?
If the Data API answers question related to an order's confirmation onchain, it will need to track each order which is a bigger lift than simply forwarding to a builder. This directly increases the cost to run an implementation of mev-share, but maybe it's worth it? |
Thanks @dmarzzz for pointing out this thread to me! Based on my experience so far working both with relay data api + mevblocker's recently released api at An incomplete wishlist: 🧚
response (most desired fields) My main use case would be to create a monitoring dashboard to answer questions like: (keeping in mind that OFA will penetrate the entire ecosystem eventually)
I have some prototypes already for mevblocker data. But would love to add mevshare in there too. 💖 |
The relay data API was extremely successful at illuminating the mev-boost block market by enabling sites like mevboost.org, relayscan, and many more. Let's enable something similar for mev-share!
There's really only so many options for what the underlying data allows us to present, but it's a useful exercise to come to an agreement on some design principles.
The list of potential actors interacting with mev-share to consider are:
What should the dashboards that will soon fill our twitter feeds look like?
The text was updated successfully, but these errors were encountered: