The first meeting of the Data Transparency Working Group was held during EthCC at the OFA Salon hosted by Flashbots. During this meeting (see notes here for more details) it became clear that:
- we need a way to share with the transaction originator what is happening or has happened (post-inclusion) to their transaction
- we need to make the block market more transparent and foster innovation (partial block building, negotiation between builders and searchers, pre-confirmation)
- we need to bring the same level of transparency we have at the Relay level (thanks to the relay API) further up the MEV supply chain (Builders and OFAs)
- we know this to be important as the community is trying to define what Best Execution for the tx originator is and how to measure it
- to achieve this we need builders and OFAs to adopt transparency endpoints which means creating a public API
- next steps should be discussing what such API would look like and how to best design it so the data can be used to illuminate further the MEV supply chain
Several people have reached out from various orgs upon notes release, there is now a telegram group to continue the conversation async, a meeting will follow in couple weeks.
I’d like to thank Flashbots for bringing the group together during the salon. The contribution of the Data Transparency Working Group is aligned with the effort of further decentralizing the order flow. As stated in the fair market principles of the DOWG, there is an expectation for builders to be transparent about how orderflow is processed. We hope a public API at builders and OFAs level will make this easier.
If you operate software as part of the MEV supply chain (validator, relay, builder, searcher), if you represent tx originators, if you are a researcher, or if you are working on bringing visibility through explorers or analytics to the community, feel free to join the working group and share your thoughts!
To join the telegram group DM @sajidaz
Next suggested steps:
- Discuss how to design the APIs for OFAs and Builders respectively - there may be different considerations for each
- Work async to specify further the design goals and target data for each
- Spec the APIs and identify any associated tooling that could be relevant