Roadmap - Rated

Show the USD value of rewards on operator page

If it is possible, it would be useful to have a hover/toggle on the rewards section for validator/operator/pool that shows the dollar value of the eth in rewards.

hello

thong

21.246.584-0001/50

thongchai The Only

Weigh attestation correctness in Raver Score

The attestation correctness score is currently calculated by taking the average of the source, target and head score. These scores already include lateness metrics. To calculate the attestation effectiveness this average correctness is multiplied with the participation rate and divided by the inclusion delay: Correct target votes receive double the rewards of head or source votes. I propose reflecting this in the attester effectiveness rating by changing the formula to: This would better reflect the total attestation effectiveness as it places the weight intended by Ethereum on the specific parts of the attestation.

Florian Winkler

Enable EL client distribution on a per operator & pool basis

The latest Nethermind bug reveals a user need for this. Though not as straightfwd to track as CL client, it might be worth the pain to put something together. https://x.com/drjasper_eth/status/1749301844558422407?s=46

Add 'number of validators' column for pools and node operators views

with a % of the total 🙏 Best, @fran6brg

fran6.eth

Seeking a secure audit on up dated

Seek newly acquired knowledge about holding s

whatsonbrian14

Rated list updated in github

Hi team! This is Jay from Four Pillars! I want to ask when EthStaker SoloStaker list is updated! - ( I believe it is Rated’s list in github) We have to submit ICS application for Lido at 12th - but we’ve noticed that the list is not updated yet. Thank you so much. Jay

Jay Jeong

Where can I find info on the slashing rates and nodes for fortisX

I want more info on fortisX its a staking platform

huntdownnn

In Progress

Actively being built

No In Progress issues

Completed

Recently shipped

Updating Ethereum EL mev-boost rewards attribution methodology to capture additional payment patterns between Builders & Proposers

We recently found that there are two payment patterns between builders and proposers related to mev-boost blocks that we weren't tracking. The effect was that we ended up understating the execution layer rewards received by proposers. This affected ~23,000 blocks which represents ~0.6%% of all blocks since the Merge (September 15, 2022). Pattern 1: Builder uses a different address to pay the proposer through an end-of-block transaction. One of the main ways builders pay proposers when proposing mev-boost blocks is through a transfer at the end of the block, which we’ve been tracking, as detailed in our docs. The builder first sets its own address to receive the block’s transaction fees and then uses the same address to pay the proposer. However, we have observed instances where the builder employs a different address to remunerate the proposer in the end-of-block transaction, from the one they used to receive the block’s transaction fees. This pattern was not previously tracked by us. Example: Block 18048751 | Slot 7236061 Problem We missed mev-boost blocks where the builder's address that received the block's transaction fees was not the one that sent the payment at the end of the block. Solution We updated our methodology to remove the strict condition that the sender address of the end-of-block transaction must be the same address that received the transaction fees of the block. Pattern 2: Builder pays the proposer through an end-of-block transaction initially transferring the amount to an alternate address, which then initiates an internal transaction to send the funds to the proposer. Similarly, there are also cases wherein while the sender of the end of block transaction is the builder, the receiver is a different address (example: a smart contract). This address then makes the payment to the proposer fee recipient through an internal transaction. Example: Block 18901160 | Slot 8095796 Problem We were already tracking internal transactions to proposers before but only if they were also the recipient of the block's transaction fees (i.e. builder pays proposer through a coinbase transfer). Solution We've updated our methodology to also account for internal transactions wherein the proposer's fee recipient was the receiver while the builder was the recipient of the block's transaction fees. Additionally, we are implementing an extra verification step to confirm that if a mev-boost relay identifies a block as a mev-boost block, it is also recorded as such in our database. 🚧 Note: We will apply these changes in production and do a refresh of our validator rewards database from September 2022. All API endpoints and fields that refer to rewards from the Ethereum execution layer, including its aggregations, and annual percentage return (APR) values shall be impacted. Acknowledgements: Rosa Karimi Adl and the Figment team for bringing this to our attention.

Sanjana Mehta

Pier Two incorrectly showing Numic Validators

We note that Pier Two now has the Numic validators on your website.. (which are no longer active and we never ran) - because we care about out performance a lot, this is very undesirable as we never actually ran those validators. It's knocked us from 3rd validator of all time to no longer in top 10. Can we have those validators removed from our profile?

Seamus McNab

Status of some page doesn’t update

Route: Node operators-aggregate-activition status

zzxxccvb1

Lido SDVT integration

Along with CSM integration within rated.network it would also be good to have Simple DVT metrics.

james.kempton

Solana delegator APY%

Hi, I'm going through your docs, the Solana delegator APY page to be specific and I cannot find a clear answer if the delegatorApy field from the /v0/solana/validators/ /summary endpoint response includes the MEV APR or not? Based on the value and compared to other API providers it seems like it does not cause the value is lower compared to other providers? If it does not include it, is there any API of yours that provides JITO MEV APR for delegators? Thanks!

Michal Baranowski

Wrong validator number for P2P.org x Ether.Fi

Hello everyone, Could you please assist with this? We have 2,400 validators in Ether.fi, but only 500 are showing up here. We’ve already posted them, but received a message stating that they are already indexed. I suspect they might be marked as SSV DVT, but that’s not an operator, and I believe some of these validators are the ones I tried to post. Thank you!

nikita.tumanov

Daily aggregated /blocks endpoint

Would be helpful to have an aggregated /blocks endpoint based on time, ideally daily. This would simplify the requirements to parse daily MEV and Rewards data.

Daniel Smith

we are trying to access the private set endpoints and getting a 403

Debug Info: URL: https://api.rated.network/v1/tags Headers: { "Authorization": "Bearer token", "Content-Type": "application/json", "X-Rated-Network": "mainnet" } Payload: { "name": "figment_test" } Response Status: 403 Response Headers: { "Date": "Mon, 28 Apr 2025 16:01:38 GMT", "Content-Type": "application/json", "Content-Length": "22", "Connection": "keep-alive", "server": "uvicorn", "x-request-id": "6d1436569b404102bac904e24dbfe780" } Response Body: {"detail":"Forbidden"} Error creating tag: 403 Client Error: Forbidden for url: https://api.rated.network/v1/tags Response: {"detail":"Forbidden"}

Dimiter Georgiev

Chainnodes - delete old solo staker validators

I brought this up a couple of times and it was partially fixed more than 1 year ago. But there are still remains of the old ether.fi solo staker cluster in the node operator account of Chainnodes. As a background, this happened because we manage the solo staker program and the bidding in 2023 was happening through the Chainnodes bidding account. Thought the validators were never operated by us, instead in a DVT setup with multiple solo stakers (home operators). Later, all those validators from the Chainnodes bidding were added automatically as ether.fi integrated with Rated directly. After a while some of the validators got removed, others didn’t. It’s pretty difficult to list the exact public keys as it’s been a back and forth and I don’t know the exact state. The only thing I know is that we (Chainnodes) have metrics from 2023, which we shouldn’t. The cutoff should be approximately January 2024, which is when we started operating validators for ether.fi on our infrastructure. https://explorer.rated.network/o/Chainnodes?network=mainnet&timeWindow=all&idType=nodeOperator As you can see in our all time metrics, there are some weird up and down metrics before 2024. This should be removed. A very weird thing is that listing Chainnodes as operator under ether.fi shows a different start of metrics (though also not start of 2024), as seen below: https://explorer.rated.network/o/Chainnodes%20-%20Ether.Fi?network=mainnet&timeWindow=all&idType=poolShare This does not make sense as we never added our other customers validators to Rated. Only from ether.fi as they wanted to list on Rated. What I would like to do is remove all validators metrics that were started in 2023 and recalculate our all time scores on our operator dashboard as well as the ether.fi Chainnodes operator dashboard. Please let me know if this is clear enough. I am available on Telegram for verification. We are in touch with multiple members from Rated but were asked to post this question on the Forum.

koraykoska_chainnodes