Thanks for the questions! Leaving some replies inline. Would also reiterate that this is just a first update to address the user feedback we’re hearing — open to other changes down the line.
Could you confirm which relays fit the criteria you outlined?
Ultra Sound and Bloxroute meet the performance criteria so far. The median latencies we see over landed blocks in the last 3d are: Ultra Sound (1ms), Bloxroute (3ms), Aestus (190ms), Agnostic (193ms), Flashbots (279ms).
Would Titan relay be able to make the websocket top bid stream public? Right now our measurements are quite slow (300ms+) but anticipate the websocket is faster. Would be great to integrate if we can get access to a faster feed.
What exact computation needs to be completed within this 10 ms?
We’re measuring the delta between:
- The time when a relay displays an updated header over its public bid feed — using the fastest publication method, so websocket if available
- The time when a relay reports that it received a block — we’re assuming that relays use the time after deserialization, so optimistic v2 isn’t needed
Would you consider operating a buildernet instance and a relay a conflict of interest, considering that some of the infra (and all for relays) is run outside of TEEs? An interesting point here could be, what happens if an independent relay operator also wishes to join buildernet?
Really what matters is that third parties don’t use their privileged position or access to private pre-trade data to degrade the user experience in BuilderNet. It doesn’t strike me that running a node in BuilderNet would give a relay (independent or otherwise) an incentive to harm BuilderNet users. The risk stems more from sharing pre-trade data with parties that operate non-TEE block builders.
How do you think about the potential centralisation risk if only one relay meets your criteria over the majority of slots?
We’re thinking a lot about how to balance better guarantees in block building with the risk of consolidation in the relay market. On the one hand, we want to raise the bar for pre-trade privacy and give users great execution. If only a few relays are able to meet this bar then it would be a disservice not to prioritize them. At the same time, we’re very sensitive to how this could impact consolidation in the relay market. So we’re making a compromise to send some blocks to relays that operate their own block builders — which is not ideal from a privacy standpoint, but avoids fully entrenching a single provider. Open to iterating on this (suggestions welcome). Long term, we’re working to mitigate a lot of these concerns by removing or reducing BuilderNet’s dependence on relays altogether (eg. TEE-Boost).
QQ: Would other teams be open to running their relays in TEEs? If non-independent relays can attest to their execution and treatment of user data then this reduces the risk of submitting to them.
how is BuilderNet planning to handle optimistic block submissions?
There’s a section on this in the docs 
See “relay submission keys”.
Or does BuilderNet itself check proposer payment in blocks before releasing them to relays? Could make the argument that sufficient trust in the TEEs to verify payment could make collateralization unnecessary
Fun question. There aren’t any additional checks on top of rbuilder today but we’re definitely excited about using TEE attestations to enhance or replace relay integrity guarantees (eg. TEE-Boost).