BloXroute Validator Gateway Testing by NOs

As per the post in the call for relays thread and communications between bloXroute and various Node Operators who utilize the Lido protocol, there has been an interested expressed by some NOs to try out using the bloXroute validator gateway (blog post) [docs] products. Due to this interest, I’ve created this post so that NOs who are keen to test these services can post below in order to inform the community of the possible usage of these services and results from the testing.

There are essentially two components / use cases here:

Both tools are open sourced [1][2], and as per bloXroute’s blog are currently free to try (for a limited time) but will require payment.

Usage of the the first service is covered via the Block Proposer Rewards Policy since it functions essentially as a relay (i.e. test first on testnets → vet → RMC would add to allow list → NOs may use).

Usage of the second (essentially the addition of static peers to help with network discoverability, attestations, etc.) is something that is not addressed by any policy. As such, the suggestion is that any NO who wants to do so express their interest/intent in this thread and follow up with the results of their testing. I would suggest that each NO stipulate:

  1. which network (mainnet/holesky/goerli), clients (EL/CL/EL+CL), and sub-set of an NO’s validators it’s being used for, and

  2. be able to share their testing/assessment results of the efficacy of the services (especially w.r.t. improving duty performance in undersaturated geographies) so that the community may have further discussion on the utility of such tooling.


If you are a Node Operator who is interested in getting started please fill out this form to streamline the BDN Gateway peering process:

If you have any questions please comment here or you can message us on TG group or our Discord.


Attestant proposes to connect a number of its consensus nodes to the BDN gateway for peering. Our plan is to gather stats on the arrival time of blocks (via the consensus node block events over the SSE eventstream) and provide approximately 1 week of block times prior to the introduction of the peers and 1 week after.

The collected data should be able to form the basis for an analysis of the impact that adding BDN peers to our nodes provides.


Thanks for the heads up Jim! I think it makes sense to try this service out on a sub-set of validators to see if it helps!

It would be great if you could share this data/conclusions with the rest of the NOs, so that we can figure out where the most value/utility for using this service may be (e.g. harder to reach geographies).


We at RockLogic have been keeping an eye on the conversation about bloXroute’s validator gateway for Ethereum staking. After some thought, we’ve decided it’s not possible to test it out on our infrastructure.

  • The client versions that bloXroute supports aren’t the same as what we’re running. Changing everything to match would result in unnecessary downtime of validator keys.
  • Our setup for failover doesn’t really work with how bloXroute works. We’d end up exposing too many validators for a test run, and that’s a risk we’re not comfortable taking.
  • bloXroute only supports a couple of stable mainnet execution and consensus clients. We think having a diverse range of clients is super important for a healthy blockchain network, so this is a bit of a dealbreaker right now.

So, while we see the upsides of bloXroute, these concerns are our top priority. Of course, we’ll keep an eye on how things evolve and are open to revisiting this in the future.