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 10 days ago
Explorer
💡 Feature Request
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 10 days ago
Explorer
💡 Feature Request
Completed
Remove as Node Operator
How can I remove my company’s listing as node operator? https://explorer.rated.network/o/Northstake?network=mainnet&timeWindow=1d&idType=nodeOperator
tommyvd 12 days ago
💡 Feature Request
Completed
Remove as Node Operator
How can I remove my company’s listing as node operator? https://explorer.rated.network/o/Northstake?network=mainnet&timeWindow=1d&idType=nodeOperator
tommyvd 12 days ago
💡 Feature Request
Completed
Error when calling endpoint
Hi team, I am getting the following error when calling 'https://api.rated.network/v1/eth/entities/Liquid%20Collective/attestations?entityType=pool&fromDate=2025-02-01&toDate=2025-02-28&granularity=month&limit=100' [ { "loc": [ "sumSyncSignatureCount" ], "msg": "Field required", "type": "missing" } ] Please take a look, thanks
Dimiter Georgiev 19 days ago
API
🐞 Bug Reports
Completed
Error when calling endpoint
Hi team, I am getting the following error when calling 'https://api.rated.network/v1/eth/entities/Liquid%20Collective/attestations?entityType=pool&fromDate=2025-02-01&toDate=2025-02-28&granularity=month&limit=100' [ { "loc": [ "sumSyncSignatureCount" ], "msg": "Field required", "type": "missing" } ] Please take a look, thanks
Dimiter Georgiev 19 days ago
API
🐞 Bug Reports
Completed
Consensus Client Distribution for "Lodestar"
Previously, the Rated explorer would be able to detect Lodestar clients on the network. As of today, this is no longer the case as we know with certainty that ChainSafe is running 100% Lodestar as part of its staking setup: https://explorer.rated.network/o/ChainSafe%20-%20Lido?network=mainnet&timeWindow=30d&idType=poolShare If Rated uses Sigma Prime’s Blockprint API to identify client usage, there was a bug that was fixed when graffiti standards changed by default via https://github.com/ethereum/execution-apis/pull/517 and the regex detection mechanism was fixed on Blockprint via https://github.com/sigp/blockprint/issues/36. We want to ensure coverage of Lodestar is accurately represented on your explorer, thanks!
Philip Ngo About 1 month ago
🐞 Bug Reports
Completed
Consensus Client Distribution for "Lodestar"
Previously, the Rated explorer would be able to detect Lodestar clients on the network. As of today, this is no longer the case as we know with certainty that ChainSafe is running 100% Lodestar as part of its staking setup: https://explorer.rated.network/o/ChainSafe%20-%20Lido?network=mainnet&timeWindow=30d&idType=poolShare If Rated uses Sigma Prime’s Blockprint API to identify client usage, there was a bug that was fixed when graffiti standards changed by default via https://github.com/ethereum/execution-apis/pull/517 and the regex detection mechanism was fixed on Blockprint via https://github.com/sigp/blockprint/issues/36. We want to ensure coverage of Lodestar is accurately represented on your explorer, thanks!
Philip Ngo About 1 month ago
🐞 Bug Reports
Completed
Add logo
https://explorer.rated.network/v/EsSodfiCfuM4ANfpPAunwj3wo8RaoRrZR9yY79CoXoUV?network=solana&timeWindow=1d How to add logo to validator and place it in a solana validator list?
info About 2 months ago
💡 Feature Request
Completed
Add logo
https://explorer.rated.network/v/EsSodfiCfuM4ANfpPAunwj3wo8RaoRrZR9yY79CoXoUV?network=solana&timeWindow=1d How to add logo to validator and place it in a solana validator list?
info About 2 months ago
💡 Feature Request
Completed
APR shows N/A for Serenita
Hey team, The APR for Serenita shows up as N/A for the “All” time window. I believe this started around the beginning of the year when we migrated validators (exited → re-entered) so that could be related. Could you please look into/fix it? Thank you! See e.g. https://explorer.rated.network/o/Serenita?network=mainnet&timeWindow=all&idType=nodeOperator and also on the overview: https://explorer.rated.network/?network=mainnet&view=nodeOperator&timeWindow=all&page=1&pageSize=15
luca About 2 months ago
🐞 Bug Reports
Completed
APR shows N/A for Serenita
Hey team, The APR for Serenita shows up as N/A for the “All” time window. I believe this started around the beginning of the year when we migrated validators (exited → re-entered) so that could be related. Could you please look into/fix it? Thank you! See e.g. https://explorer.rated.network/o/Serenita?network=mainnet&timeWindow=all&idType=nodeOperator and also on the overview: https://explorer.rated.network/?network=mainnet&view=nodeOperator&timeWindow=all&page=1&pageSize=15
luca About 2 months ago
🐞 Bug Reports
Request to remove a validator
I reported an incorrect validator. It’s not ran by StakeCat. Validator: 1477207 pub key: 0x8436ec29d944d3183426e10997a16e3f7aca05ad300e051e4622cec4c9ec3ff9a13b73878f2a3c2962905960c46536f8 Could this be removed from the StakeCat Node Operator profile?
knightsemplar 4 months ago
🐞 Bug Reports
Request to remove a validator
I reported an incorrect validator. It’s not ran by StakeCat. Validator: 1477207 pub key: 0x8436ec29d944d3183426e10997a16e3f7aca05ad300e051e4622cec4c9ec3ff9a13b73878f2a3c2962905960c46536f8 Could this be removed from the StakeCat Node Operator profile?
knightsemplar 4 months ago
🐞 Bug Reports
Completed
Ethernodes and Stader Permissioned validators
Hello, on the permissioned pool on stader we appear with a wrong name(EtherNodesPermissioned). And we cant register the permissioned validators to our Ethernodes node operator account. On the permissionless side all is ok.
talinito 4 months ago
Explorer
🐞 Bug Reports
Completed
Ethernodes and Stader Permissioned validators
Hello, on the permissioned pool on stader we appear with a wrong name(EtherNodesPermissioned). And we cant register the permissioned validators to our Ethernodes node operator account. On the permissionless side all is ok.
talinito 4 months ago
Explorer
🐞 Bug Reports
Completed
Lido SDVT integration
Along with CSM integration within rated.network it would also be good to have Simple DVT metrics.
james.kempton 6 months ago
💡 Feature Request
Completed
Lido SDVT integration
Along with CSM integration within rated.network it would also be good to have Simple DVT metrics.
james.kempton 6 months ago
💡 Feature Request
Completed
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 6 months ago
API
🗣️ Forum
Completed
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 6 months ago
API
🗣️ Forum
Completed
"validatorCount" is number earning rewards on the first day of the "granularity"?
The "validatorCount" you return always gives the number of validators that did earn rewards on the first day of the "granularity" (e.g. "week/month"), correct? When doing some calculations for periods where the number changed during the week, this led to some confusion at first. https://api.rated.network/v1/eth/sets/SETID/proposals?fromDate=2024-06-03&toDate=2024-08-15&granularity=week&limit=100&offset=0 Internally, we are now resorting to an “"avg" number of reward- earning vals" if we are comparing different groups. Obviously this also has drawbacks like not being integer etc.
Freddy-from-Germany 7 months ago
🗣️ Forum
Completed
"validatorCount" is number earning rewards on the first day of the "granularity"?
The "validatorCount" you return always gives the number of validators that did earn rewards on the first day of the "granularity" (e.g. "week/month"), correct? When doing some calculations for periods where the number changed during the week, this led to some confusion at first. https://api.rated.network/v1/eth/sets/SETID/proposals?fromDate=2024-06-03&toDate=2024-08-15&granularity=week&limit=100&offset=0 Internally, we are now resorting to an “"avg" number of reward- earning vals" if we are comparing different groups. Obviously this also has drawbacks like not being integer etc.
Freddy-from-Germany 7 months ago
🗣️ Forum
Planned
Ethereum leaderboard all-time
Hello, can you please check if Stakin2 is correctly shown on Top 10 - All time effectivenes. When I click on Stakin2 to the detail page it shows 97,8% Thanks Tomas Eminger
tomas.eminge 7 months ago
🐞 Bug Reports
Planned
Ethereum leaderboard all-time
Hello, can you please check if Stakin2 is correctly shown on Top 10 - All time effectivenes. When I click on Stakin2 to the detail page it shows 97,8% Thanks Tomas Eminger
tomas.eminge 7 months ago
🐞 Bug Reports
Completed
CU/Billing cycle
when does monthly billing cycle begin and when do monthly CUs reset? Thanks
Dimiter Georgiev 7 months ago
API
💡 Feature Request
Completed
CU/Billing cycle
when does monthly billing cycle begin and when do monthly CUs reset? Thanks
Dimiter Georgiev 7 months ago
API
💡 Feature Request
Completed
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 7 months ago
🐞 Bug Reports
Completed
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 7 months ago
🐞 Bug Reports
Completed
API Error message
Hi, we have received this error message in updating our profile, how we can avoid it? It’s just an error on the pool name? "detail":[{"loc":["body","poolTag"],"msg":"The name of the pool must match exactly one of the names listed on the Explorer. If this is a pool we aren't currently tracking, please let us know.","type":"value_error"}]}
Andrea 7 months ago
🐞 Bug Reports
Completed
API Error message
Hi, we have received this error message in updating our profile, how we can avoid it? It’s just an error on the pool name? "detail":[{"loc":["body","poolTag"],"msg":"The name of the pool must match exactly one of the names listed on the Explorer. If this is a pool we aren't currently tracking, please let us know.","type":"value_error"}]}
Andrea 7 months ago
🐞 Bug Reports
Completed
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 7 months ago
🐞 Bug Reports
Completed
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 7 months ago
🐞 Bug Reports
Planned
Is there something like an average age of a set/operator that could be queried somehow?
In order to quantify/qualify the “all time” data range a bit, as currently it could be anything between 31 days and >3 years… In more detail/visually it could be like a time series of active validators over time in a chart.
Freddy-from-Germany 7 months ago
Explorer
💡 Feature Request
Planned
Is there something like an average age of a set/operator that could be queried somehow?
In order to quantify/qualify the “all time” data range a bit, as currently it could be anything between 31 days and >3 years… In more detail/visually it could be like a time series of active validators over time in a chart.
Freddy-from-Germany 7 months ago
Explorer
💡 Feature Request
Completed
Too many requests error
i get the "Too Many Requests" error when i try to call the API. Example: 'https://api.rated.network/v1/eth/entities/Liquid%20Collective/effectiveness?entityType=pool&fromDate=2024-07-01&toDate=2024-07-31&granularity=day&limit=100'.
Dimiter Georgiev 8 months ago
API
🐞 Bug Reports
Completed
Too many requests error
i get the "Too Many Requests" error when i try to call the API. Example: 'https://api.rated.network/v1/eth/entities/Liquid%20Collective/effectiveness?entityType=pool&fromDate=2024-07-01&toDate=2024-07-31&granularity=day&limit=100'.
Dimiter Georgiev 8 months ago
API
🐞 Bug Reports
Completed
Method of blockspace distribution detection
Dear Rated team, I am a contributor to the NOM workstream of the Lido DAO and thus especially interested in your dashboards concerning our modules. In the overview of the Curated Module I noticed that you listed severals NOs who the explorer claimed had obtained blocks from unvetted Titan relay in the past 30 days. I was able to confirm this for all but one NO by comparing the slots in which the blocks had been proposed with the relay’s API. Normally such blocks stick out in our own Fees Monitoring Dashboard as being from slots of an “unknown relay”. What was unique for the NO in question, is, that unlike for the other NOs, for none of this NO’s unknown relay slots I could produce a query that was responded to by the proposer_payload_delivered endpoint of the Titan - or by any other of the APIs of widely known relays - making me fairly certain we are looking at locally built “vanilla blocks”. But then, where does the Titan relay blockspace you listed for the NO come from? We got in touch with them - Kiln - and were told that while they do not call the getHeader methode for Titan for blocks available on multiple and ultimately obtained by a different than Titan relay. They do, however, systematically send signatures to all relays, including Titan, to improve the propagation time. Some examples of such slots that then produce responses from several relays are: 9590392, 9589936, and 9589912 Is it possible that this approach is messing with your methode of collecting the blockspace distribution, listing the blockspace for all of the responding relays?
sssngth 8 months ago
Explorer
🗣️ Forum
Completed
Method of blockspace distribution detection
Dear Rated team, I am a contributor to the NOM workstream of the Lido DAO and thus especially interested in your dashboards concerning our modules. In the overview of the Curated Module I noticed that you listed severals NOs who the explorer claimed had obtained blocks from unvetted Titan relay in the past 30 days. I was able to confirm this for all but one NO by comparing the slots in which the blocks had been proposed with the relay’s API. Normally such blocks stick out in our own Fees Monitoring Dashboard as being from slots of an “unknown relay”. What was unique for the NO in question, is, that unlike for the other NOs, for none of this NO’s unknown relay slots I could produce a query that was responded to by the proposer_payload_delivered endpoint of the Titan - or by any other of the APIs of widely known relays - making me fairly certain we are looking at locally built “vanilla blocks”. But then, where does the Titan relay blockspace you listed for the NO come from? We got in touch with them - Kiln - and were told that while they do not call the getHeader methode for Titan for blocks available on multiple and ultimately obtained by a different than Titan relay. They do, however, systematically send signatures to all relays, including Titan, to improve the propagation time. Some examples of such slots that then produce responses from several relays are: 9590392, 9589936, and 9589912 Is it possible that this approach is messing with your methode of collecting the blockspace distribution, listing the blockspace for all of the responding relays?
sssngth 8 months ago
Explorer
🗣️ Forum