We are in a unique situation with regards to MEV Relayers effecting our overall APR calculations and aggregated view. We have 2 scenarios for our Eth Nodes:
B. We don’t control our MEV relays - As seen in our non-Lido pool. Rated Network Explorer
Problem: For scenario B our users/clients choose to use MEV or not, they also choose which relayer they want to use, Allnodes has no hand in this. As you can see above, 45.1% are still using vanilla blocks. This skews our APR in relation to most ever other validator, since they do not give their users a choice, thus they have more control over the APR.
We cannot force our users to choose a MEV relayer, and since this APR is not optimized as we see fit (like our Lido pool) it’s having a negative effect on user choice, this is especially true if a 3rd party is using rated.networks’ APR via API.
Solution:
Split the Operator Pools into MEV Relayer enabled vs Vanilla Blocks. This enables 3rd parties to also query a MEV enabled API for correct data set.
Smooth the results of vanilla blocks across all validators to a fixed percent (2-3%)
Open to ideas and discussion on how to solve for this, ty !
I think we can break the problem definition you outlined in two parts:
Allnodes APR as it reflects on the Rated API
Allnodes APR coming from the Network Explorer
Regarding (1) and integrations that reference from it, the solution is pretty simple–whoever integrates should query for the pool-share of Allnodes that is full mev-boost enabled (in this case the Lido set). See below for an example query on the 30d window.
This should give folks what you are looking for. I’m also not opposed to the idea of adding a mev-boost flag on operators, so an integrator can get aggregate data for that partition of an operator’s set. Adds granularity and flexibility to the whole, and I can’t really see any downsides.
On the flipside, regarding (2) I’d be more hesitant to introduce hard changes. The interface already makes a segregation between Allnodes under Lido and Allnodes (see here), with clear demarcation of where the blocks come from.
Fixing the APR% methodology to a fixed representation of vanilla blocks in the population, is a different methodology to what the “Backwards Looking APR%” is trying to achieve.
Fully appreciate that there’s a user education piece that’ part of this conversation, but perhaps it should be. On our part, we’ve kickstarted a workstream to add more 101 content to our docs.
Agree that fixing the APR is a slippery slope, a mev-boost flag is a good route in my opinion and would be more clear for anyone doing an API integration. Can we take this further in the UI as a user toggle? This way, with the aggregate views, the user can compare mev-boost enabled vs vanilla , with mev-boost being default on load?