Stephane

Last January, I prepared a document outlining a set of proposed [mev-boost security features](https://hackmd.io/@flashbots/r1CuVl86Y) that aim to address potential relay faults which can lead to liveness issues. mev-boost in its...

I think there an interesting case to be made for each client to implement mitigation as they see fit rather than the entire network adopting the same mitigation technique. Diverse...

Something important to keep in mind is that it's important for builders to find out if relays are prioritizing their payloads correctly. I expect relays to be incentivized to publish...

How the relay landscape evolves over time is difficult to predict. We believe the ideal will have relays as independent 3rd parties who are not actively profiting from the private...

Builders setting their own address as the feeRecipient in the block header and including a transaction to the proposer is the correct implementation approach. The gas overhead is warranted and...

Here is some additional context on the various payment methods which can be used in mev-boost. For clarity, lets refer to the fee recipient address set by the block builder...

I created a forum post to discuss defining a standard for block scoring: https://collective.flashbots.net/t/block-scoring-for-mev-boost-relays/202

The design I initially proposed was 3) where mev-boost can call `relay_getRelayStatusV1` on the relays to obtain fraud proofs for the last 64 blocks. Main reason for selecting this approach...

I think the model can be refined slightly: builders would send to the relays the header + a signed payment. The relay sends the header to the validator and escrows...

> Nonetheless, the fault is still not clearly attributable, because the relay is supposed to withhold the payment if the proposer sends them a signed header too late for the...