flashbots
Orderflow Data API
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:
- tx originators (signers)
- wallets
- dapps
- bundlers/paymasters (?)
- matchmakers
- builders
- sequencers
What should the dashboards that will soon fill our twitter feeds look like?
To kick off discussion here are some ideas:
- Originator Order Transparency - any decision which affects an order's execution should be available data.
- Searcher Bid Privacy - Shield information revealing bidding strategies from the public.
- Submission-to-Chain Traceability - an originator should be able to see information on their order at each step of the mev-share life cycle including at order receipt, builder forwarding, and time on chain.
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?
- Was my order sent to a builder?
- Did my order land onchain?
- If my order never landed onchain, what happened?
- How much was I given back for my order?
- How did my order execution compare to other options?
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 https://rpc.mevblocker.io/backruns and https://rpc.mevblocker.io/tx/{your_tx_hash}
An incomplete wishlist: 🧚
/backruns - a list of txs going through the OFA
parameters:
slot (optional)
txHash (optional)
limit default set to something like 100...max to be at maybe 10000 ? :)
response (most desired fields)
txHash
numberOfBundlesTargeting - could be 0 if no bundles targeted them
refundAmount
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)
- Which builder/relay combination picks up the most OFA bundles?
- What % of total tx, contract volume does each OFA bundle consist of?
- How much value is being passed to the originator?
- How much value has been generated in total across all originators?
I have some prototypes already for mevblocker data. But would love to add mevshare in there too. 💖
