# What makes a relay trust-worthy?
**URL:** https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145
**Category:** Relays
**Tags:** brainstorming, question
**Created:** [August 23, 2022, 7:44pm UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145 "2022-08-23T19:44:45Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@guayabyte](https://collective.flashbots.net/u/guayabyte)
#### Post date: [August 23, 2022, 7:44pm UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145/1 "2022-08-23T19:44:45Z")
This is a brainstorming to collect more specific details of what does it mean for a relay to be trust-worthy. Please reply with your requirements. This topic will be updated to reflect the main findings.
# API
- Fully implement the [Relay API Specification v1](https://flashbots.notion.site/Relay-API-Spec-5fb0819366954962bc02e81cb33840f5).
- [Score blocks as the difference in the balance of the fee recipient account before and after the block execution](https://collective.flashbots.net/t/block-scoring-for-mev-boost-relays/202#h-1-block-level-scoring-3).
# Operation
- Operated by a reputable organization well-known in the Ethereum community.
- Open source code.
- Transparent deployment process.
- Data available to verify source code behavior.
- Clear statement of any filtering or censoring.
- Wait for 16 epochs after the merge to propose the first blocks.
- Treats all builders equally.
- Take down the server when a high-severity bug is found, so validators switch to local building and don’t miss slots.
- Publishes a post-mortem after every incident.
- In case of missing blocks, does not retroactively pay to the affected validators.
# Performance
- Always reply to the requests from the current slot proposer.
- Reply to a header request in less than 1 second.
- Reply to a block request in less than 1 second.
- Always serves valid blocks.
# Testing
- More than 90% unit test code coverage.
- Test relay running in Goerli.
- Pass a shadow fork test.
# Security
- Supports the [relay monitor](https://github.com/flashbots/mev-boost/issues/142).
- An indepedent security audit published.
- A bug bounty.
- Aware of the [risks of vertical integration](https://collective.flashbots.net/t/the-risks-of-vertical-integration-in-mev-boost/235), and willing to step-down if their role becomes risky.
* * *
With the current design of proposer/builder separation that will go live at the merge, the relay is still a trusted mediator between proposers and builders.
In particular:
- it can steal MEV opportunities from builders
- it can lie on the amount to be paid to the proposer
- it can withhold the block body after it has been signed by the proposer
- it can deliver an invalid block to the proposer
- it can filter out any transactions it dislikes
So a relay has to promise to do its best effort to avoid those situations, it has to promise to be trust-worthy.
For builders, see [How do I choose a good block builder?](https://collective.flashbots.net/t/how-do-i-choose-a-good-block-builder/150)
---
### Author:  [@ralexstokes](https://collective.flashbots.net/u/ralexstokes)
#### Post date: [August 23, 2022, 8:05pm UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145/2 "2022-08-23T20:05:16Z")
> - Reply with a valid block in less than 2 seconds.
this could broken down into the first round getting bids or the second round getting the full blocks
just want to point out there is a 1 second timeout at the moment for mev-boost to provide any available bids before clients will fall back to their local builder
---
### Author:  [@guayabyte](https://collective.flashbots.net/u/guayabyte)
#### Post date: [September 6, 2022, 2:16pm UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145/3 "2022-09-06T14:16:41Z")
I’ve updated the scoring of the proposer payment to block level scoring as discussed in [Block scoring for mev-boost relays](https://collective.flashbots.net/t/block-scoring-for-mev-boost-relays/202#h-1-block-level-scoring-3).
This now seems the easier, cheaper, and more forward-looking option. I’m aware this brings challenges to Lido and maybe some other node operators, so we have to continue building on top of it to come with a solution that is satisfactory for everybody.
cc @TheDZhon.
---
### Author:  [@tjd.im](https://collective.flashbots.net/u/tjd.im)
#### Post date: [October 31, 2022, 11:00pm UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145/4 "2022-10-31T23:00:06Z")
> [@guayabyte](#):
>
> - Transparent deployment process.
@guayabyte Could you elaborate here on what a transparent deployment process would look like? Open sourcing terraform code?
---
### Author:  [@guayabyte](https://collective.flashbots.net/u/guayabyte)
#### Post date: [November 1, 2022, 4:11pm UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145/5 "2022-11-01T16:11:18Z")
That would be perfect.
At the very least, it has to be documented. From there, the fancier the better. I imagine a system that when a tag is created, the source and the binaries are published, this triggers integration tests in staging, then canary deployment in production, and then full release. Everything automated with manual gates to move to the next stage.
This is, of course, hard. We have been improving our infrastructure, we are [hiring a second devops engineer](https://boards.greenhouse.io/flashbots/jobs/4049353005), and plan to share more about the way we run our relay. We have been supporting other teams that run relays, and I would be very happy to collaborate with them on improving our release processes.
---
### Author:  [@tjd.im](https://collective.flashbots.net/u/tjd.im)
#### Post date: [November 4, 2022, 9:33pm UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145/6 "2022-11-04T21:33:20Z")
Amazing. Looking forward to see how Flashbots illuminates their deploy/release processes.
---
### Author:  [@tjd.im](https://collective.flashbots.net/u/tjd.im)
#### Post date: [November 4, 2022, 9:43pm UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145/7 "2022-11-04T21:43:37Z")
> [@guayabyte](#):
>
> # Performance
>
> - Always reply to the requests from the current slot proposer.
> - Reply to a header request in less than 1 second.
> - Reply to a block request in less than 1 second.
> - Always serves valid blocks.
When it comes to performance I think we should add uptime here. However, I do think it is important that the `/eth/v1/builder/status` endpoint be dynamic and return the last block number/header or a timestamp. Otherwise there’s nothing preventing a relay from setting their `/eth/v1/builder/status` endpoint to a statically served page to created artificial uptime. Curious to hear thoughts on this.
---
### Author:  [@metachris](https://collective.flashbots.net/u/metachris)
#### Post date: [November 5, 2022, 11:34am UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145/8 "2022-11-05T11:34:47Z")
Agree, returning highest slot would make sense (timestamp is too easy to game with a simple nginx lua script). To push this forward, the next step would be creating an issue at [GitHub - ethereum/builder-specs: Specification for the external block builders.](https://github.com/ethereum/builder-specs) - which is where this payload would be defined.
On the other side, why not just look at the delay on the `getHeader` call? You can do that on every slot.
---
### Author:  [@tjd.im](https://collective.flashbots.net/u/tjd.im)
#### Post date: [November 7, 2022, 7:33pm UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145/9 "2022-11-07T19:33:53Z")
> [@metachris](#):
>
> On the other side, why not just look at the delay on the `getHeader` call? You can do that on every slot.
Yeah that’s a good idea. Would you look at the latest slot or call some past slot though? And what would the delay threshold be?
If we looked at the latest slot we’d need to update these values every new slot: `/eth/v1/builder/header/{slot}/{parent_hash}/{pubkey}`
---
### Author:  [@metachris](https://collective.flashbots.net/u/metachris)
#### Post date: [November 8, 2022, 8:15am UTC](https://collective.flashbots.net/t/what-makes-a-relay-trust-worthy/145/10 "2022-11-08T08:15:51Z")
Only the latest slot is reliable, many relays don’t provide bids for past slots. You ask for the bid 12 seconds after the head-slot event.
You can get all the required url args from the beacon node. See here for details: [relay-monitor/collector.go at 587a4e3ccefacc89a688155b6da6031c847a8971 · ralexstokes/relay-monitor · GitHub](https://github.com/ralexstokes/relay-monitor/blob/587a4e3ccefacc89a688155b6da6031c847a8971/pkg/data/collector.go#L39)