**Topic: Data and transparency**


> Participants: Felix (CowSwap, MEVBlocker), Anatoly (Kolibrio), Eren and his colleague, Jake (Goldsky), Mateusz (FB), [?] (0x), Ayaz/Blair/Lukasz/Sajida (Blocknative), Dan (FB)
>
> Moderator: Dan
>
> Notes: Sajida

There is now a telegram group for the working group. DM @sajidaz for more info.

**Context**

- Relay Data API is a good example of how much more transparent DeFi and its supply chain is, compared to TradFi. How can we transpose it to the builder and OFA interfaces?
- Can we make block markets more transparent?
- How can we provide visibility post inclusion: retro analysis, was I sandwiched? How to help users/tx originators better parameter?
- OFAs can leak info (ie tx leaked to mempool). Some users might not be aware and submit to all OFAs expecting them to behave the same way and offer the same guarantees - which in practice is not the case
- Can builders share info about why tx was or was not included?
- Can users be promptly alerted so that they know how to correct their config if tx reverts?
- Incentive for builders to adopt a transparency endpoint

**Relevant data identified**
- Currently we don't always have (except FB builder) the bundle ID in the block.
- Pattern we see = { target tx ; backrun ; kickback} + approval tx
- TX may be seen at different time (timestamps) in the process by different builders

**Monitoring**
- MEV Blocker is testing builders to flag searching activity
- Group was unclear re: do tx searching and block backrunning sit on the same level?
- ZeroMEV collab?
- Need tooling to monitor OFA and check inclusion time and compare amongst builders.
- Figure out intra block slippage. Detect if there is behavior harming user XP (ie *best execution*). For example: was the user tx positioned by the builder in the best possible way in the block to minimize slippage?
- Builder audits. FB could provide grants for this.
- CallData privacy
- A mevboost.org for OFA/RPC
- Consideration: requests sent to builders could be handled by a proxy and not reveal real timestamp the tx was processed by builder. It just says it was received. It could then show that the builder is always up when in fact the actual building process is down.There was a short convo re what info is sufficient here? MEV Blocker was saying arrival timestamp with tx hash is enough, Blocknative was saying if you do not get some additional info from the builder showing you its actually trying to include your tx, you might be blind on what's actually going on there. This issue can be seen in the transparency pyramid.

**Transparency Pyramid**
1. Tx Received by OFA (hash, timestamp)
2. Tx Distributed by OFAs to Builders (hash, 200 OK timestamp)
3. Inner builder process (? - it is a black box currently from an observability standpoint)

We might want to add components to this pyramid in the future so consider it a starting point for brainstorming.

**Who are the users?**
- similar to mev boost (in general)
- data scientists
- tx originators (wallets, users)
- regulators

**Best execution**

In the US there is NBBO (National Best Bid and Offer), what about an EBBO (Ethereum Best Bid and Offer)?
How would that be defined and calculated?
Can we check the difference in price within a block for a given token? If delta is big, then we could say that the execution XP is worse for the user.

**Data study**
- slippage study - 0x would need data re top block, 1st detection, execution price
- transparency - MEV Blocker says a minimal set would be {1st seen timetstamp + tx hash}

**Privacy**
- How and *when* do we show private tx info? (for ex on Dune)
- Bundle data sharing? several searchers or builder/searchers don't seem to align with this

**Final thoughts**

- The cultural shift here (more transparency, more data sharing, especially around bundle data) is going to require higher effort than the actual tooling design and implementation
- We need to address decentraliztion of order flow by building metrics that can helps us measure if we are making progress on that front
- Partial block building, negotiation between builders and searchers, pre-conf = all this would benefit from higher visibility into the block building process
- We can already move forward with a first design of this Block market transparency initiative

**Next 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 can be relevant
- Schedule follow up DOWG (Decentralized Orderflow Working Group) data transparency meeting