# Introduction
Source: https://docs.rated.network/rated-api/api-reference/introduction
Resources dedicated to exposing and explaining the various endpoints that the Rated API supports.
You can also access our API's Swagger documentation via [api.rated.network/docs](https://api.rated.network/docs)
## Making sense of the API input
The standard form of the Rated API looks something like this:
`https://api.rated.network/version/network/entity/resource`
At the highest level, here's how you should interpret the class of instructions you are passing to it:
| Parameter | Description |
| :--------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `version` | The version of the API you are on. Currently the API is in `v0` |
| `network` | The network you are querying |
| `entityId` | The class of entity you are querying for. This could be either of [Validators](/rated-api/api-reference/v0/ethereum/validators), [Operators](/rated-api/api-reference/v0/ethereum/operators) and [Network](/rated-api/api-reference/v0/ethereum/network) |
| `resource` | The specific resource you are querying for |
## How time works
### For Ethereum
All rewards and performance metrics are hosted under the "effectiveness" endpoint.
By default, the API returns data in daily chunks (24h / 225 epoch / 7200 slot increments), starting from Beacon Chain genesis. As such, `Day 0` encompasses the 225 epoch period between epochs \[0, 225), and maps to datetime `2020-12-01 12:00:23 UTC` to `2022-12-02 12:00:11 UTC`. The reasoning for this is to make sure that days are always equal in terms of included epochs (i.e. guaranteed to have 225 epochs each).
That being said, for `performance` and `rewards` v1 endpoints, we have enabled a `utc` parameter which users the option retrieve data based on UTC time. The epochs are partitioned into days based on the starting timestamp of an epoch (i.e. timestamp of the first slot in an epoch). This means epochs belong to the (UTC) day they were started in. The rewards partitioned this way instead of at the slot-level, as doing so by the latter would make accounting around midnight quite complicated (especially attestation rewards where the rewarded action and the actual reward have a time lag). Thus, validator activity that occurs between 23:57 and 00:03 will be accounted for in the previous day. This way all days will have 225 epochs as with the default timing.
**As an example for Ethereum mainnet:**
Day 0 would be from:
* Slot 0 to 3615
* Epoch 0 to 112
* Time period: `2020-12-01 12:00:23` (genesis) to `2020-12-02 00:03:23 UTC`
Day 1 would be from:
* Slot 3616 to 10815
* Epoch 113 to 337
* Time period: `2020-12-02 00:03:35` to `2020-12-03 00:03:23 UTC`
* Epoch 337 started on `2020-12-02 23:57:11 UTC` so despite ending on `2020-12-03 00:03:23 UTC`, it still counted under Day 1 (which is `2020-12-02`).
Subsequent days would follow the same pattern as Day 1. Excluding Day 0, there will always be 7200 slots and 225 epochs in a day.
### For Solana
The "rewards" and "performance" endpoints, which contains validator rewards and performance data respectively, returns data in daily chunks, indexed on UTC days, epochs, or 20 minute intervals.
The "latency" endpoint, which mainly contains data on validator voting latency, returns real-time data over the last 20 minutes.
## Entity granularity
### For Ethereum
The Rated API supports querying for rewards, performance and metadata at the validator pubkey level, all the way up to a pre-configured operator (list of pubkeys) or pool (list of operators).
We have the capability to aggregate statistics on an arbitrary number of keys, and can pre-configure entity aggregations that follow continuously updated registries (e.g. [rated.network/o/Lido](https://rated.network/o/Lido)).
If that's relevant to your use case, get in touch with us via [hello@rated.network](mailto:hello@rated.network).
## Time window aggregation
### For Ethereum
The Rated API also supports aggregation, so days can be rolled up in weeks, months, quarters, years and even all time on Ethereum.
To use this feature, the `granularity` query parameter can be used. For example, to obtain monthly aggregates for validator index `100` on Ethereum:
```sh theme={null}
curl -X 'GET' \\
'[]' \\
-H 'accept: application/json' \\
-H 'X-Rated-Network: mainnet'
```
# Report Validators
Source: https://docs.rated.network/rated-api/api-reference/v0/ethereum/self-report/report-validators
post /v0/selfReports/validators
Here's how to interpret the inputs required to operate it:
| Parameter | Context |
| :----------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `validators` | Array of validator pubkeys associated with the node operator |
| `poolTag` | String for pool name, must match exactly to the pool name listed on the [Explorer](https://www.rated.network/?network=mainnet\&view=pool\&timeWindow=1d\&page=1\&poolType=all). |
And here's how to you might go about implementing it:
```sh Curl theme={null}
curl -v -X 'POST' \
'https://api.rated.network/v0/selfReports/validators' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
-d '{"validators": ["0x01...", "0x02..."], "poolTag": "Lido"}'
```
```python Python theme={null}
import requests
from typing import Dict, List
YOUR_TOKEN: str = "ey..."
PUBKEYS: List[str] = ["0x001...", "0x002...", ]
HEADERS: Dict[str, str] = {
"Authorization": f"Bearer {YOUR_TOKEN}",
"X-Rated-Network": "mainnet",
}
try:
response = requests.post(
"https://api.rated.network/v0/selfReports/validators",
# important! use the json parameter not data
json={"validators": PUBKEYS, "poolTag": "Lido"},
headers=HEADERS,
)
response.raise_for_status()
except requests.exceptions.HTTPError:
print(response.headers["x-request-id"])
print(response.json())
```
#### Please note the following:
* You can self report on Ethereum Mainnet and Hoodi.
* Do not pass your operator name as pool name. If you're not getting delegations via a pool or pool share, please leave the "poolTag" empty.
* Each request has a strict limit of 1,000 validator public keys. Please submit multiple requests if you need to report more than 1,000 validators.
* We cannot assign a key to your entity if it has already been reported by another operator. In case of false attribution, please contact us at [hello@rated.network](http://hello@rated.network), and we will address the issue.
* As this API is self-reported, it relies on the honest behaviour of all participants reporting their validators. Any instances of misconduct may lead to the exclusion of the entity from our platform.
* It typically takes about 24 hours for the reported keys to appear on [rated.network/explorer](http://rated.network/explorer). Please note that your keys need to be activated (ie not in the activation queue) for them to show up on the Explorer.
* If your activated keys have not shown up after the 24h period, please contact us at [hello@rated.network](http://hello@rated.network), and we will investigate the issue.
# Self report
Source: https://docs.rated.network/rated-api/api-reference/v0/ethereum/self-report/self-report
Self-serve API for node operators to report validator operations.
This endpoint is the gateway for node operators to "upload" their sets on the Rated Network Explorer. We now have a streamlined way in place for Node Operators to track their validator sets on the Rated Explorer, in a live way.
**You must have an Account with Rated to access this endpoint.** Please head to [rated.network/apis](https://rated.network/apis) or [console.rated.network](https://console.rated.network) to create one.
In order to prevent abuse and reduce the risk of legitimising bad actors, you must be approved by Rated in order to access this endpoint. Please head to our [Rated Node Operator Onboarding](https://ihrjiko6lmv.typeform.com/to/FxJpSeXf) form to request access.
## Reporting a validator set
# Blocks
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/blocks/blocks
Querying into Ethereum blocks and the associated validator metrics
The Blocks endpoint allows one to dig into the individual slots and blocks in Ethereum since the Merge (*Slot* `4700013`*, Block* `15537394`). Metrics include validator rewards from the consensus and execution layers, MEV data, and missed reward estimates. See the [blocks glossary](/rated-api/glossary/ethereum/blocks) for the complete set of metrics.
### Get slots and blocks on the Ethereum network
The Builder Payments endpoint surfaces data on payments/value transfers made by block builders to proposing validators for specific slots and blocks. Specifically, it lists the corresponding transaction hash/es where the builder made this value transfer to the validator. Data is available from *Slot* `13061952`, *Block* `23834125`.
### Get information for block builder payments by slot
# Block builder payment transaction hashes
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/blocks/get-information-for-block-builder-payments-by-slot
get /v1/eth/builderPayments
This endpoint returns transaction hashes in which block builder payments are made.
This endpoint gives a paginated list of all slots and blocks, and the corresponding transaction hashes where block builders made payments to proposing validators where relevant. The results can be filtered across a range of slots (`from` and `to` parameters).
# List of slots and blocks
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/blocks/get-slots-and-blocks-on-the-ethereum-network
get /v1/eth/blocks
This endpoint returns comprehensive information on slots and blocks on the Ethereum network
This endpoint gives a paginated list of all slots and blocks. The results can be filtered across a range of slots (`from` and `to` parameters) and/or a specific proposing validator based on its `validator_index`.
# Get APR information for Pools, Operators and Addresses.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/metadata/get-apr-information-for-pools-operators-and-addresses
get /v1/eth/entities/{entity_id}/aprs
This endpoint returns windowed APR information for a single pool, node operator or deposit/withdrawal address.
This endpoint is available only to annual commitment and custom Enterprise plans. Get in touch with [hello@rated.network ]()to learn more.
This endpoint returns historical data on the returns of an entity. What's really exciting about this one, is the ability to dig deep into the components of the aggregate return (e.g. returned earned on the execution layer vs the consensus layer etc).
`window` refers to the time window of the aggregation, with `1d`, `7d`, `30d` and `all` being the supported values.
A validator must be active throughout the time window for the value to be produced. For `all` time the last 90 days are considered.
# Get APR information for Validators.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/metadata/get-apr-information-for-validators
get /v1/eth/validators/{validator_index_or_pubkey}/aprs
This endpoint returns windowed information about the APRs for a single validator.
This endpoint is available only to annual commitment and custom Enterprise plans. Get in touch with [hello@rated.network ]()to learn more.
This endpoint returns historical data on the returns of a validator index or pubkey. What's really exciting about this one, is the ability to dig deep into the components of the aggregate return (e.g. returned earned on the execution layer vs the consensus layer etc).
`window` refers to the time window of the aggregation, with `1d`, `7d`, `30d` and `all` being the supported values.
A validator must be active throughout the time window for the value to be produced. For `all` time the last 90 days are considered.
# Get consolidations for Validators.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/metadata/get-consolidations-for-validators
get /v1/eth/validators/consolidations
This endpoint returns information about validator consolidations. Use this endpoint to retrieve consolidations information for a source or target validator.
# Get metadata on the Rated Ethereum API endpoints
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/metadata/get-metadata-on-the-rated-ethereum-api-endpoints
get /v1/eth/apiMetadata
This endpoint returns information about the latest data available from Rated's Ethereum API endpoints.
This endpoint is available only to annual commitment and custom Enterprise plans. Get in touch with [hello@rated.network ]()to learn more.
# Get Pool and Operator mappings for all Validators.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/metadata/get-pool-and-operator-mappings-for-all-validators
get /v1/eth/validators/mappings
This endpoint returns information about the pools and operators mapped to validators. Use this endpoint to retrieve pool and operator mapping information for all validators.
This endpoint is available only to annual commitment and custom Enterprise plans. Get in touch with [hello@rated.network ]()to learn more.
# Get Pool and Operator mappings for Validators.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/metadata/get-pool-and-operator-mappings-for-validators
get /v1/eth/validators/{validator_index_or_pubkey}/mappings
This endpoint returns information about the pools and operators mapped to a validator. Use this endpoint to retrieve pool and operator mapping information for a single validator.
This endpoint is available only to annual commitment and custom Enterprise plans. Get in touch with [hello@rated.network ]()to learn more.
# Get Slashings information for all Validators.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/metadata/get-slashings-information-for-all-validators
get /v1/eth/validators/slashings
This endpoint returns information about the slashings for all validators.
This endpoint is available only to annual commitment and custom Enterprise plans. Get in touch with [hello@rated.network ]()to learn more.
# Get validator consolidations information for Pools and Operators.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/metadata/get-validator-consolidations-information-for-pools-and-operators
get /v1/eth/entityConsolidations
This endpoint returns information about validator consolidations per entity. This includes the count of consolidated validators and the consolidated balances.
# Get Validator mappings for Pools and Operators.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/metadata/get-validator-mappings-for-pools-and-operators
get /v1/eth/entities/{entity_id}/mappings
This endpoint returns information about the validators mapped to a pool or an operator. Use this endpoint to retrieve validator indices or pubkeys that belong to a pool or an operator, as well as their deposit and withdrawal addresses.
This endpoint is available only to annual commitment and custom Enterprise plans. Get in touch with [hello@rated.network ]()to learn more.
# Metadata
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/metadata/metadata
A series of endpoints that drill down on metadata-related metrics for both entities and validators.
Metadata endpoint is available only to annual commitment and custom Enterprise plans. Get in touch with [hello@rated.network ]()to learn more.
## Entity Metadata
The entity metadata endpoints inform you about how validators are mapped to entities, their APRs, and slashing metrics.
Please head to our [Glossary](/rated-api/glossary/ethereum/) to understand what individual metrics refer to.
### Get Validator mappings for Pools and Operators
### Get APR information for Pools, Operators and Addresses
### Get validator consolidations information for Pools and Operators
***
## Validator Metadata
The validator metadata endpoints provide information about validator mappings, APR, and slashing history.
### Get Pool and Operator mappings for all Validators
### Get Pool and Operator mappings for Validators
### Get APR information for Validators
### Get Slashings information for all Validators
### Get consolidations for Validators
***
## API Metadata
Information about the Rated API endpoints and their specifications.
### Get metadata on the Rated Ethereum API endpoints
***
# Get an overview of Ethereum performance.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/network/get-an-overview-of-ethereum-performance
get /v1/eth/effectiveness
This endpoint returns a network-wide overview of Ethereum performance metrics.
# Get an overview of the Ethereum network.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/network/get-an-overview-of-the-ethereum-network
get /v1/eth
This endpoint returns a network-wide overview of Ethereum.
# Get information on the per entity validator consolidation churn capacity of Ethereum.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/network/get-information-on-the-per-entity-validator-consolidation-churn-capacity-of-ethereum
get /v1/eth/consolidationCapacity/entity
This endpoint returns summarized information on the validator consolidation churn limit of the Ethereum network, broken down per entity.
# Get information on the validator consolidation churn capacity of Ethereum.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/network/get-information-on-the-validator-consolidation-churn-capacity-of-ethereum
get /v1/eth/consolidationCapacity
This endpoint returns summarized information on the validator consolidation churn limit of the Ethereum network.
# Get information on various staking processing queues on Ethereum
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/network/get-information-on-various-staking-processing-queues-on-ethereum
get /v1/eth/queues
This endpoint returns key information on the validator activation, exit, and withdrawal processing queues on Ethereum.
# Get reward metrics of the Ethereum network.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/network/get-reward-metrics-of-the-ethereum-network
get /v1/eth/rewards
This endpoint returns a network-wide overview of Ethereum reward metrics.
# Get the geographical distribution of the Ethereum network.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/network/get-the-geographical-distribution-of-the-ethereum-network
get /v1/eth/geographicalDistributions
This endpoint returns information about the geographical distribution of validators in Ethereum.
# Get the host distribution of the Ethereum network.
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/network/get-the-host-distribution-of-the-ethereum-network
get /v1/eth/hostDistributions
This endpoint returns information about the host distribution of validators in Ethereum.
# Network
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/network/network
A series of endpoints that provide network-level metrics about performance, rewards, and distributions.
## Network Overview Endpoint
These endpoints allow querying into a collection of stats that provide an overview of the whole network in historical states—which can be as recent as the last 24h.
For a materialized view of most of the metrics on this page, see [https://explorer.rated.network/network?network=mainnet](https://explorer.rated.network/network?network=mainnet)
### Get an overview of the Ethereum network
## Network Performance Endpoint
### Get an overview of Ethereum performance
## Network Rewards Endpoint
### Get reward metrics of the Ethereum network
## Geo and Host Distribution P2P Endpoints
The P2P endpoints give a view into the Ethereum Beacon Chain's peer-to-peer networking layer. Using our in-house peer-to-peer probe, we are able to pinpoint IP addresses of nodes, and resolve those addresses to their geographical locations and other network metadata.
### Get the geographical distribution of the Ethereum network
### Get the host distribution of the Ethereum network
## Network Consolidations Churn Capacity Endpoints
### Get information on the validator consolidation churn capacity of Ethereum
### Get information on the per entity validator consolidation churn capacity of Ethereum
## Network Staking Queues Endpoints
### Get information on the staking queues (e.g activations, exits) of Ethereum
# Get a list of validators
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/overview/get-a-list-of-validators
get /v1/eth/validators
This endpoint returns an overview of all validators on the Beacon Chain with details on its activation, withdrawal and exit epochs.
# Get summary stats on individual Pools, Operators and Addresses
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/overview/get-summary-stats-on-individual-pools-operators-and-addresses
get /v1/eth/entities/{entity_id}/summaries
This endpoint returns summary statistics for a specific pool,operator or withdrawal/deposit address that Rated has pre-materialized views on––commensurate to the output you might see on the Rated Explorer.
# Get summary stats on Pools, Operators and Addresses
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/overview/get-summary-stats-on-pools-operators-and-addresses
get /v1/eth/entities/summaries
This endpoint returns summary statistics for all the operators Rated has pre-materialized views on––commensurate to the output you might see on the Rated Explorer. Filter by entityType to view the stats for a specific type of entity i.e. by pools, operators and withdrawal/deposit addresses.
# Get validator
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/overview/get-validator
get /v1/eth/validators/{validator_index_or_pubkey}
This endpoint returns a single validator index on the Beacon Chain with details on its activation, withdrawal and exit epochs.
# Ethereum Overview
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/overview/overview
A series of endpoint that provide a high level overview of all the different pools, operators, withdrawal/deposit addresses and validator indexes that form the infrastructure layer of Ethereum
## Entity Summaries
The Rated API enables users to query into key metrics of pre-materialized entities. This works pretty much as hinted by the Rated Explorer, but with a much higher degree of flexibility in terms of time-frames, and granularity in terms of metrics.
### What do you mean by "pre-materialized entities"?
The shortest way to put it, in an Ethereum context, is "groups of validators bound together by agency". This could be:
1. a pool (e.g. [Lido](https://www.rated.network/o/Lido?network=mainnet\&timeWindow=1d\&viewBy=operator\&page=1))
2. a node operator (e.g. [Allnodes](https://www.rated.network/o/Allnodes?network=mainnet\&timeWindow=1d\&viewBy=aggregate))
3. a fraction of a node operator's fleet that maps under a specific pool (e.g. [Stakefish under Lido](https://www.rated.network/o/Stakefish%20-%20Lido?network=mainnet\&timeWindow=1d))
4. a group of validator indices mapped to a specific deposit address (e.g. [0xdd192...](https://www.rated.network/o/0xdd19274b614b5ecacf493bc43c380ef6b8dfb56c?network=mainnet\&timeWindow=1d))
5. a group of validator indices mapped to a specific withdrawal address (e.g. [0xdd192...](https://www.rated.network/o/0xdd19274b614b5ecacf493bc43c380ef6b8dfb56c?network=mainnet\&timeWindow=1d))
If you want to get your entity tracked on Rated, head to [https://bit.ly/RatedPoolOnboarding](https://bit.ly/RatedPoolOnboarding) to onboard as a pool or head to [Self Report](/rated-api/api-reference/v0/ethereum/self-report/self-report) to onboard as a node operator.
### Get summary stats on Pools, Operators and Addresses
### Get summary stats on individual Pools, Operators and Addresses
## Validator Summaries
The validators class is the lowest order of aggregation that the Rated API supports.
### What is a "validator"?
A validator is a virtual entity that lives on Ethereum and participates in the consensus of the Ethereum protocol. Validators are represented by a balance, public key, and other properties.
### Get a list of validators
### Get a validator summary
# Get aggregated effectiveness for validators
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-aggregated-effectiveness-for-validators
get /v1/eth/validators/effectiveness
The Rated API enables the aggregation of all the metrics that live under effectiveness across an arbitrary number of validator indices or pubkeys, at the endpoint level. You can use this endpoint to either aggregate data per validator across a time window or aggregate data for multiple validators per time period.
# Get attestation duties metrics for a private set
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-attestation-duties-metrics-for-a-private-set
get /v1/eth/sets/{set_id}/attestations
This endpoint returns drilldowns on performance metrics around attestation duties for all validators belonging to a private set.
# Get attestation duties metrics for group of validators
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-attestation-duties-metrics-for-group-of-validators
get /v1/eth/validators/attestations
This endpoint returns drilldowns on performance metrics around attestation duties for validators. You can use this endpoint to either aggregate data per validator across a time window or aggregate data for multiple validators per time period.
# Get attestation duties metrics for Pools, Operators and Addresses
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-attestation-duties-metrics-for-pools-operators-and-addresses
get /v1/eth/entities/{entity_id}/attestations
This endpoint returns drilldowns on performance metrics around attestation duties for a single pool, node operator or deposit/withdrawal address.
# Get effectiveness for a private set
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-effectiveness-for-a-private-set
get /v1/eth/sets/{set_id}/effectiveness
This endpoint returns a bunch of useful information about the historical performance of all validators belonging to a private set. Use this endpoint to retrieve top level metrics on proposer effectiveness, attester effectiveness and overall effectiveness.
# Get effectiveness for Pools, Operators and Addresses
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-effectiveness-for-pools-operators-and-addresses
get /v1/eth/entities/{entity_id}/effectiveness
This endpoint returns a bunch of useful information about the historical performance of a single pool, node operator or deposit/withdrawal address. Use this endpoint to retrieve top level metrics on proposer effectiveness, attester effectiveness and overall effectiveness of an entity.
# Get proposer duties metrics for a group of validators
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-proposer-duties-metrics-for-a-group-of-validators
get /v1/eth/validators/proposals
This endpoint returns drilldowns on performance metrics around proposer duties for validators. You can use this endpoint to either aggregate data per validator across a time window or aggregate data for multiple validators per time period.
# Get proposer duties metrics for a private set
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-proposer-duties-metrics-for-a-private-set
get /v1/eth/sets/{set_id}/proposals
This endpoint returns drill-downs on performance metrics around proposer duties for all validators belonging to a private set.
# Get proposer duties metrics for Pools, Operators and Addresses
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-proposer-duties-metrics-for-pools-operators-and-addresses
get /v1/eth/entities/{entity_id}/proposals
This endpoint returns drill-downs on performance metrics around proposer duties for a single pool, node operator or deposit/withdrawal address.
# Get validator attestation duties metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-validator-attestation-duties-metrics
get /v1/eth/validators/{validator_index_or_pubkey}/attestations
This endpoint returns drilldowns on performance metrics around attestation duties for a single validator index.
# Get validator effectiveness
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-validator-effectiveness
get /v1/eth/validators/{validator_index_or_pubkey}/effectiveness
This endpoint returns all the useful information you will ever need on the historical performance of a single validator index. Use this endpoint to retrieve top level metrics on proposer effectiveness, attester effectiveness and overall effectiveness of a validator index or pubkey.
# Get validator proposal duties metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/get-validator-proposal-duties-metrics
get /v1/eth/validators/{validator_index_or_pubkey}/proposals
This endpoint returns drill-downs on performance metrics around proposal duties for a single validator index.
# Performance
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/performance/performance
A series of endpoints that drill down on performance related metrics for both entities and validators.
## Entity Performance
We have structured the performance endpoints around three main pillars,
1. the **avg effectiveness** of an entity
2. drilldown of performance associated with **attestation duties**
3. drilldown of performance associated with **proposer duties**
You will find that this is similar to how we defined [Rated Effectiveness Rating](https://docs.rated.network/methodologies/ethereum/rated-effectiveness-rating) (RAVER), which is a measure of how well an entity has been performing its deterministic duties - attestations and proposals, over time.
### Get effectiveness for Pools, Operators and Addresses
### Get attestation duties metrics for Pools, Operators and Addresses
### Get proposer duties metrics for Pools, Operators and Addresses
***
## Validator Performance
At validator level, the same structure persists ie the performance endpoints are centered around three main pillars,
1. the **effectiveness** of a validator index
2. drilldown of performance associated with **attestation duties**
3. drilldown of performance associated with **proposer duties**
Validator performance endpoints can further be grouped into individual validator index or pubkey endpoints and aggregate endpoints. Find more details below 👇
### Individual Validators
#### Get validator effectiveness
#### Get validator attestation duties metrics
#### Get validator proposal duties metrics
***
## Aggregating Validator Indices
Unlike the entities endpoint, validators can be aggregated across all the metrics that live under the performance endpoints across an arbitrary number of validator indices or pubkeys. This aggregation is available over a time window or over validator indices.
#### Get aggregated effectiveness for validators
#### Get attestation duties metrics for group of validators
#### Get proposer duties metrics for a group of validators
***
## Sets Performance
Sets or Private Sets, helps organizations group validators into custom, private, sets enabling use-cases such as executing controlled experiments and analyses to assess various aspects of their validators' cluster performance. Head to [Private Sets](/rated-api/api-reference/v1/ethereum/private-sets/private-sets) to learn more about the different endpoints you'll need to call as a precursor to calling the endpoints below.
Note that the set performance endpoints behave identical to the entities performance endpoints with the caveat that (i) only the org that creates a set can view performance metrics for that set (hence ***private*** sets) and (ii) sets data does not surface on the Rated Explorer.
#### Get effectiveness for a private set
#### Get attestation duties metrics for a private set
#### Get proposer duties metrics for a private set
***
# Add validators to a tag
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/private-sets/add-validators-to-a-tag
post /v1/tags/{id}/validators
This endpoint allows you to add validators to a tag. You must pass an array of validator pubkeys in the body.
You can add upto 1,000 validators at a time with an upper bound of 15,000 validators per tag. If you'd like to add more than that per tag, please reach out to us at [hello@rated.network](mailto:hello@rated.network)!
# Create a new tag
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/private-sets/create-a-new-tag
post /v1/tags
To call a private set's effectiveness, you must first create a tag which acts as a unique identifier for the set. This endpoint allows you to create a new tag. You must give your tag a name. The response will contain the tag id which you will then use to add validators using the add validator endpoint.
Build tier orgs can create upto 4 tags while Growth tier orgs can create upto 20 tags.
# Delete private set tag
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/private-sets/delete-private-set-tag
delete /v1/tags/{id}
This endpoint removes all validators from a private set then deletes the private set tag itself.
# Get all tags
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/private-sets/get-all-tags
get /v1/tags
This endpoint returns all the tags that are associated with your organization.
# Get all validators in a tag
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/private-sets/get-all-validators-in-a-tag
get /v1/tags/{id}/validators
This endpoint allows you to get all the validators associated with a tag. It returns a paginated list of pubkeys along with their metadata.
# Get details about a tag
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/private-sets/get-details-about-a-tag
get /v1/tags/{id}
This endpoint will return the details on a tag including its name, id and when it was created.
# Private Sets
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/private-sets/private-sets
Private Sets enable users to put together arbitrary groupings of Ethereum validators, and to easily track aggregated statistics of these persistent clusters.
Private sets endpoints are available to Build \[4 sets], Growth \[20 sets] and Enterprise plans on the Rated API. Head on over to [Plans](/rated-api/pricing/plans) to learn more.
## Introducing Private Sets
Private sets empower organizations to implement sophisticated monitoring strategies, including A/B testing, performance benchmarking, and multivariate analysis.
By organizing validators into private sets, orgs can execute controlled experiments and analyses to assess various aspects of their validators' performance. This strategic grouping not only enhances the understanding of individual and collective validator efficiency but also informs decisions aimed at optimizing overall performance.
Head to our [Private Sets](/rated-api/guides/use-cases/private-sets) guide to get a detailed walk through on how to create and manage tags and call the sets performance and rewards endpoints.
### Get all tags
### Create a new tag
Build tier orgs can create upto 4 tags while Growth tier orgs can create upto 20 tags.
### Get details about a tag
### Update a tag
### Get all validators in a tag
### Add validators to a tag
You can add upto 1,000 validators at a time with an upper bound of 15,000 validators per tag. If you'd like to add more than that per tag, please reach out to us at [hello@rated.network](mailto:hello@rated.network)!
### Remove validator pubkey from a tag
### Remove group of validator pubkeys from a tag
Note that removing a validator key from a tag has the same impact on the historical performance of the private set as exiting your key from a cluster would ie, the exited key still impacts the historical view of the set's perfomance.
### Delete private set
This endpoint removes all validators from a private set then deletes the private set tag itself.
***
As a reminder, note that this page only walks you through the creation and management of your tags, which is a precursor to calling the set's performance and rewards endpoints. You can find the effectiveness endpoint for sets [here](/rated-api/api-reference/v1/ethereum/performance/get-effectiveness-for-a-private-set), and rewards endpoint for sets [here](/rated-api/api-reference/v1/ethereum/rewards/get-rewards-metrics-for-a-private-set) or head to our [Private Sets](/rated-api/guides/use-cases/private-sets) user guide!
# Remove multiple validator pubkeys from a tag
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/private-sets/remove-multiple-validator-pubkeys-from-a-tag
post /v1/tags/{id}/validators/remove
This endpoint allows you to remove multiple validators from a tag by passing a list of validator pubkeys in the request body.
Note that removing a validator key from a tag has the same impact on the historical performance of the private set as exiting your key from a cluster would ie, the exited key still impacts the historical view of the set's perfomance.
# Remove validator pubkey from a tag
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/private-sets/remove-validator-pubkey-from-a-tag
delete /v1/tags/{id}/validators/{pubkey}
This endpoint allows you to remove a validator from a tag by passing the validator pubkey as a path parameter.
Note that removing a validator key from a tag has the same impact on the historical performance of the private set as exiting your key from a cluster would ie, the exited key still impacts the historical view of the set's perfomance.
# Update a tag
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/private-sets/update-a-tag
patch /v1/tags/{id}
This endpoint allows you to update the name associated with your tag.
# Get aggregated penalty metrics for validators
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/rewards/get-aggregated-penalty-metrics-for-validators
get /v1/eth/validators/penalties
This endpoint aggregates penalty metrics across multiple validators.
# Get penalty metrics for a private set
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/rewards/get-penalty-metrics-for-a-private-set
get /v1/eth/sets/{set_id}/penalties
This endpoint returns a bunch of useful information about the historical penalties accrued by all validators belonging to a private set.
# Get penalty metrics for Pools, Operators and Addresses
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/rewards/get-penalty-metrics-for-pools-operators-and-addresses
get /v1/eth/entities/{entity_id}/penalties
This endpoint returns a bunch of useful information about the historical penalties accrued by a single pool, node operator or deposit/withdrawal addresses.
# Get rewards metrics for a group of validators
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/rewards/get-rewards-metrics-for-a-group-of-validators
get /v1/eth/validators/rewards
This endpoint returns aggregated rewards metrics for validators. You can use this endpoint to either aggregate data per validator across a time window or aggregate data for multiple validators per time period.
# Get rewards metrics for a private set
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/rewards/get-rewards-metrics-for-a-private-set
get /v1/eth/sets/{set_id}/rewards
This endpoint returns a bunch of useful information about the historical rewards earned by all validators belonging to a private set.
# Get rewards metrics for Pools, Operators and Addresses
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/rewards/get-rewards-metrics-for-pools-operators-and-addresses
get /v1/eth/entities/{entity_id}/rewards
This endpoint returns a bunch of useful information about the historical rewards earned by a single pool, node operator or deposit/withdrawal address including drill-downs on consensus layer and execution layer rewards.
# Get validator penalty metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/rewards/get-validator-penalty-metrics
get /v1/eth/validators/{validator_index_or_pubkey}/penalties
This endpoint returns a bunch of useful information about the historical penalties accrued by a single validator index.
# Get validator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/rewards/get-validator-rewards-metrics
get /v1/eth/validators/{validator_index_or_pubkey}/rewards
This endpoint returns a bunch of useful information about the historical rewards earned by a single validator index.
# Rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/rewards/rewards
A series of endpoints that drill down on rewards related metrics for both entities and validators.
## Entity Rewards
The rewards endpoints give you a breakdown of all rewards earned and penalties accrued by an entity over time. Please head to our [Glossary](/rated-api/glossary) to understand what individual metrics refer to.
### Get rewards metrics for Pools, Operators and Addresses
### Get penalty metrics for Pools, Operators and Addresses
***
## Validator Rewards
### Individual validators
Similar to the entity rewards endpoints, the validator rewards endpoints provide a breakdown of all rewards earned and penalties accrued by a single validator index or pubkey over time. Please head to our [Glossary](/rated-api/glossary/ethereum/validators) to understand what individual metrics refer to.
### Get validator rewards metrics
### Get validator penalty metrics
### Aggregating Validator Indices
Unlike the entities endpoint, validators can be aggregated across all the metrics that live under the rewards endpoints across a number of validator indices or pubkeys (150). This aggregation is available over a time window or over validator indices.
#### Get aggregated rewards for validators
#### Get aggregated penalties for validators
***
## Sets Rewards
Sets or Private Sets, helps organizations group validators into custom, private, sets enabling usecases such as executing controlled experiments and analyses to assess various aspects of their validators' cluster performance and rewards metrics. Head to [Private Sets](/rated-api/api-reference/v1/ethereum/private-sets/private-sets) to learn more about the different endpoints you'll need to call as a precursor to calling the endpoints below.
Note that the set rewards endpoints behave identical to the entities rewards endpoints with the caveat that (i) only the org that creates a set can view rewards metrics for that set (hence *private sets*) and (ii) sets data does not surface on the Rated Explorer.
### Get rewards metrics for a private set
### Get penalty metrics for a private set
# Get withdrawal metrics for individual validators
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/withdrawals/get-withdrawal-metrics-for-individual-validators
get /v1/eth/validators/{validator_index_or_pubkey}/withdrawals
This endpoint returns withdrawals by validator index or pubkey
# Get withdrawal metrics for Withdrawal Addresses
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/withdrawals/get-withdrawal-metrics-for-withdrawal-addresses
get /v1/eth/entities/{withdrawal_address}/withdrawals
This endpoint returns withdrawals by address
# Withdrawals
Source: https://docs.rated.network/rated-api/api-reference/v1/ethereum/withdrawals/withdrawals
A series of endpoints that drill down on withdrawals related metrics for both entities (withdrawal address) and validators.
## Entity Withdrawals
The withdrawals endpoint give you a breakdown of all withdrawals related to an entity's withdrawal address over time.
### Get withdrawal metrics for Withdrawal Addresses
***
## Validator Withdrawals
The withdrawals endpoint give you a breakdown of all withdrawals associated with a validator over time.
### Get withdrawal metrics for individual validators
# Overview
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/overview/overview
Get an overview of the Polygon network's current state and metrics.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
## Network Overview
The network overview endpoint provides high-level metrics about the Polygon network's current state, including total stake, active validators, and other key network statistics.
### Get Network Overview
# Get epoch metadata for an epoch ending on the day specified
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/metadata/get-epoch-metadata-for-an-epoch-ending-on-the-day-specified
get /v1/solana/epochMetadata
This endpoint returns epoch metadata for days on which an epoch ends.
# Get metadata on the Rated Solana API endpoints
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/metadata/get-metadata-on-the-rated-solana-api-endpoints
get /v1/solana/apiMetadata
This endpoint returns information about the latest complete daily data available from Rated's Solana API endpoints.
# Get the stake accounts associated to a validator.
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/metadata/get-stake-accounts-associated-to-a-validator
get /v1/solana/validators/{validator_id}/delegators
This endpoint returns all distinct stake accounts associated to a validator over a period of time when they were actively delegated.
# Get various metadata about validators.
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/metadata/get-various-metadata-about-validators
get /v1/solana/validators/{validator_id}
This endpoint returns information validators such as their geolocation, client, and associated accounts.
# Metadata
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/metadata/metadata
A series of endpoints which drill down on metadata-related metrics for validators.
## Validator Metadata
This endpoint provides detailed metadata about validators including their identity, configuration, and other relevant information.
### Get various metadata about validators
***
## Validator-Stake Account Mapping
This endpoint returns all distinct stake accounts associated to a validator over a period of time when they were actively delegated.
### Get the stake accounts associated to a validator
***
## API Metadata
Information about the Rated API endpoints and their specifications.
### Get metadata on the Rated Solana API endpoints
***
## Solana epoch metadata
Information about the Solana epoch metadata.
# Get Network Overview
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/overview/get-network-overview
get /v1/solana/network/overview
This endpoint returns a summary of key statistics for the whole network including effectiveness and its components, delegator and validator annual percentage yields (APY), staking metrics, and duty-specific rewards.
On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
# Get stake account summary metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/overview/get-stake-account-summary-metrics
get /v1/solana/delegators/stakeAccounts/{stake_account}/summary
This endpoint returns various metrics for a specific stake account aggregated across different time windows.
These endpoints return high level information about stake accounts over the time period such as their network penetration, rewards, annual percentage yield (APY), paid commissions, and the effectiveness of their validator delegate/s.
On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
# Get stake authority summary metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/overview/get-stake-authority-summary-metrics
get /v1/solana/delegators/stakeAuthorities/{stake_authority}/summary
This endpoint returns various metrics for a specific stake authority aggregated across different time windows.
These endpoints return high level information about stake authorities over the time period such as their network penetration, rewards, annual percentage yield (APY), paid commissions, and the effectiveness of their validator delegate/s.
On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
# Get summary metrics for multiple stake accounts
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/overview/get-summary-metrics-for-multiple-stake-accounts
get /v1/solana/delegators/stakeAccounts
This endpoint returns various metrics for all stake accounts aggregated across different time windows.
# Get summary metrics for multiple stake authorities
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/overview/get-summary-metrics-for-multiple-stake-authorities
get /v1/solana/delegators/stakeAuthorities
This endpoint returns various metrics for all stake authorities aggregated across different time windows.
# Get summary metrics for multiple validators
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/overview/get-summary-metrics-for-multiple-validators
get /v1/solana/validators
This endpoint returns various metrics for all validators or the ones staked to by a specified stake authority.
# Get validator summary metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/overview/get-validator-summary-metrics
get /v1/solana/validators/{validator_id}/summary
This endpoint returns various metrics for a specific validator aggregated across different time windows.
This endpoint returns high level information about validators over the time period such as their respective entity names, network penetration, annual percentage yield (APY), and effectiveness.
On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
# Overview
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/overview/overview
A series of endpoint that provide a high level overview of all validators, stake accounts, and stake authorities.
## Network Overview
These endpoints provide a summary of key statistics for the whole Solana network including effectiveness, APY, staking metrics, and duty-specific rewards.
### Get Network Overview
On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
***
## Validator Summaries
These endpoints provide high-level information about validators including entity names, network penetration, APY, and effectiveness.
### Get summary metrics for multiple validators
### Get validator summary metrics
***
## Delegator Summaries
### By Stake Account
These endpoints return high level information about stake accounts including network penetration, rewards, APY, paid commissions, and validator delegate effectiveness.
### Get summary metrics for multiple stake accounts
### Get stake account summary metrics
### By Stake Authority
These endpoints return high level information about stake authorities including network penetration, rewards, APY, paid commissions, and validator delegate effectiveness.
### Get summary metrics for multiple stake authorities
### Get stake authority summary metrics
On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
# Get daily vote latency across all geolocations
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/performance/get-daily-vote-latency-across-all-geolocations
get /v1/solana/network/geolocation/latency
This endpoint returns the median vote latency across all hosting providers/data centers for the specified date.
To use this endpoint, a day must be specified. The endpoint then returns all available median vote latency data across all data center/hosting provider locations for the specified date.
Earliest data available is from November 1, 2024.
# Get historical network level performance
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/performance/get-historical-network-level-performance
get /v1/solana/network/effectiveness
This endpoint returns historical performance metrics for the network.
This endpoint returns historical key performance metrics at the network level. You can choose the covered dates (`fromDate`,`toDate`) or \~20 minute slot intervals (`fromSlot`, `toSlot`) based on the `granularity`parameter. By default, it returns the latest daily data.
Earliest data available is from April 1, 2024.
# Get validator block insights
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/performance/get-validator-block-insights
get /v1/solana/validators/{validator_id}/blockInsights
This endpoint returns information about the composition of blocks produced by a validator. Use this endpoint to retrieve historical block insights for a specific validator.
You can query this endpoint by using the `vote_account` address of a validator as the `validator_id`. The granularity of results can either be daily or around 20 minute intervals (3,000 slots).
Earliest daily data available is from March 1, 2025.
# Get validator performance
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/performance/get-validator-performance
get /v1/solana/validators/{validator_id}/performance
This endpoint returns all the useful information you need on the historical performance of a single validator. Use this endpoint to retrieve top level metrics on block leader/proposal effectiveness, voting effectiveness, and overall effectiveness of a validator.
You can query this endpoint by using the `vote_account`address of a validator as the `validator_id`. The granularity of results can either be daily or around 20 minute intervals (3,000 slots).
Earliest data available is from April 1, 2024.
# Get validator state information
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/performance/get-validator-state-information
get /v1/solana/validators/{validator_id}/state
This endpoint returns information about a validator's state including active stake. Use this endpoint to retrieve historical state data for a specific validator.
You can query this endpoint by using the `vote_account`address of a validator as the `validator_id`. The granularity of the results are at a daily level.
# Get validator vote performance data
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/performance/get-validator-vote-performance-data
get /v1/solana/validators/{validator_id}/votePerformance
This is a live endpoint that returns information about the validator's most recent voting activity.Use this endpoint to retrieve live data for a specific validator.
# Performance
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/performance/performance
A series of endpoints that drill down on performance related metrics for validators.
## Validator Performance
You can query this endpoint by using the `vote_account` address of a validator. The granularity of results can either be daily or around 20 minute intervals (3,000 slots).
### Get validator performance
Earliest data available is from April 1, 2024.
***
## Validator block-level insights
This endpoint returns information about the blocks created by a validator, including average compute units, number of transactions, and reward levels. You can query this endpoint by using the `vote_account` address of a validator.
### Get validator block insights
Earliest daily data available is from March 1, 2025.
***
## Validator State
This endpoint returns information about a validator's state per day. You can query this endpoint by using the `vote_account` address of a validator.
### Get validator state information
***
## Geolocation Vote Latency
These endpoints provide vote latency data across different geographical locations and data centers.
### Get daily vote latency across all geolocations
Earliest data available is from November 1, 2024.
***
## Validator Vote Performance
This endpoint returns information about a validator's vote performance. You can query this endpoint by using the `vote_account` address of a validator.
### Get validator vote performance data
***
## Network Effectiveness
These endpoints provide network-wide performance metrics and historical data.
### Get historical network level performance
Earliest data available is from April 1, 2024.
# Get historical network level rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/rewards/get-historical-network-level-rewards
get /v1/solana/network/rewards
This endpoint returns historical rewards for the network.
You can query this endpoint using the `fromDate` and `toDate` parameters to set the date range returned by the data. Otherwise it will return the latest daily rewards in descending order.
Earliest data available is from March 24, 2025.
# Get stake account rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/rewards/get-stake-account-rewards-metrics
get /v1/solana/delegators/stakeAccounts/{stake_account}/rewards
This endpoint returns a bunch of useful information about the historical rewards earned by a single stake account.
# Get stake authority rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/rewards/get-stake-authority-rewards-metrics
get /v1/solana/delegators/stakeAuthorities/{stake_authority}/rewards
This endpoint returns a bunch of useful information about the historical rewards earned by stake authority based on its aggregated stake accounts.
These endpoints return information about the rewards received by a delegator (stake account or stake authority), including MEV rewards it has claimed, and commissions it has paid. The data can be broken down at a daily level.
Earliest data available is from April 1, 2024.
# Get validator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/rewards/get-validator-rewards-metrics
get /v1/solana/validators/{validator_id}/rewards
This endpoint returns a bunch of useful information about the historical rewards earned by a single validator.
You can query this endpoint by using the `vote_account`address of a validator as the `validator_id`. The granularity of results can either be daily or around 20 minute intervals (3,000 slots).
Earliest data available is from April 1, 2024.
# Rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/solana/rewards/rewards
A series of endpoints that drill down on rewards related metrics for validators.
Earliest data available is from April 1, 2024.
## Validator Rewards
You can query this endpoint by using the `vote_account` address of a validator. The granularity of results can either be daily or around 20 minute intervals (3,000 slots).
### Get validator rewards metrics
***
## Delegator Rewards
These endpoints return information about the rewards received by a delegator (stake account or stake authority), including MEV rewards it has claimed, and commissions it has paid. The data can be broken down at a daily level.
### By Stake Account
### Get stake account rewards metrics
### By Stake Authority
### Get stake authority rewards metrics
## Network Rewards
This network rewards endpoint gives you a breakdown of all rewards earned by active validators and their delegators over a specified period of time.
### Get historical network level rewards
# Authentication
Source: https://docs.rated.network/rated-api/authentication
Rated uses API keys that represent bearer tokens to access API endpoints. These API keys can be generated via [console.rated.network](https://console.rated.network/).
The API keys are added as an `Authorization` key in the API request headers with the value `Bearer `
Your API keys carry many privileges, so be sure to keep them secure!
Do not share your secret API keys in publicly accessible areas such as GitHub, client-side code, and so forth.
All API requests must be made over [HTTPS](http://en.wikipedia.org/wiki/HTTP_Secure).
Calls made over plain HTTP will fail. API requests without authentication will also fail.
```sh curl theme={null}
#Authenticated Request
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/operators/Kiln/effectiveness?idType=nodeOperator&granularity=day&from=2023-08-31&size=31&filterType=datetime&include=sumEarnings&include=day&include=sumEstimatedRewards&include=sumEstimatedPenalties&include=sumPriorityFees&include=sumBaselineMev&include=sumMissedExecutionRewards&include=sumConsensusBlockRewards&include=sumMissedConsensusBlockRewards&include=sumAttestationRewards&include=sumAllRewards&include=sumMissedAttestationRewards&include=sumMissedAttestationPenalties&include=sumWrongTargetPenalties&include=sumLateTargetPenalties&include=sumWrongHeadPenalties&include=sumLateSourcePenalties' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
```
```python python theme={null}
import requests
url = "https://api.rated.network/v0/eth/operators/Coinbase/effectiveness"
params = {
"idType": "nodeOperator",
"granularity": "day",
"from": "2023-08-31",
"size": 31,
"filterType": "datetime",
"include": [
"sumEarnings", "day", "sumEstimatedRewards", "sumEstimatedPenalties",
"sumPriorityFees", "sumBaselineMev", "sumMissedExecutionRewards",
"sumConsensusBlockRewards", "sumMissedConsensusBlockRewards",
"sumAttestationRewards", "sumAllRewards", "sumMissedAttestationRewards",
"sumMissedAttestationPenalties", "sumWrongTargetPenalties",
"sumLateTargetPenalties", "sumWrongHeadPenalties", "sumLateSourcePenalties"
]
}
#Authenticated Request
headers = {
"Content-Type": "application/json",
"X-Rated-Network": "mainnet",
"Authorization": "Bearer "
}
response = requests.get(url, params=params, headers=headers)
data = response.json()
```
# Errors summary
Source: https://docs.rated.network/rated-api/errors/errors
Semantics around error messages that you might stumble upon when working with the Rated API.
Rated API utilizes standard HTTP response codes to communicate the outcome of an API request. It is essential to note that:
* Response codes in the 2xx range signify successful execution of the request.
* Response codes in the 4xx range indicate a client-side error, arising from insufficient or incorrect information provided (e.g., missing required parameters, invalid values types, etc.).
* Response codes in the 5xx range signify a server-side error, indicative of an issue with Rated's servers. These are uncommon.
| HTTP Code | Description |
| :------------------------------------------- | :------------------------------------------------------------------------------------------------ |
| **200** Ok | Everything worked as expected. |
| **400** Bad Request | The request was unacceptable, often due to a missing required parameter or an invalid value type. |
| **401** Unauthorized | No valid bearer token provided. |
| **403** Forbidden | The bearer token doesn't have permissions to perform the request. |
| **404** Not Found | The requested resource doesn't exist. |
| **429** Too Many Requests | The number of requests to the Rated API is too high. Back-off and try again later. |
| **500, 502, 503** Server Errors | Something failed on our servers. |
# Handling errors
Source: https://docs.rated.network/rated-api/errors/handling-errors
Catch and respond to invalid requests, authentication issues and more.
When using our API, it is crucial to anticipate and handle errors effectively.
To aid in this process, our API utilizes a standardized format for returning error messages.
These error responses provide detailed information on the nature of the error, by adhering to this format, developers can easily identify and resolve issues when they arise, improving the overall reliability and efficiency of the API integration.
## Errors in responses
Rated API's errors will always be returned as JSON
Errors will always come in a dictionary containing a `detail` key and its value can be either a list of dictionaries or a string describing the error message.
### 400 Bad Request
```json Wrong body theme={null}
{
"detail": [
{
"loc": ["body", "email"],
"msg": "value is not a valid email address",
"type": "value_error.email",
}
]
}
```
```json Wrong query parameters theme={null}
{
"detail": [
{
"loc": [
"query",
"pubkeys",
0
],
"msg": "Invalid public key",
"type": "value_error"
}
]
}
```
### 401 Unauthorized
```json theme={null}
{"detail": "Not authenticated"}
```
**Reason:** You forgot to send the `Authorization` header with a `Bearer` token.
```json theme={null}
{"detail": "Could not validate access token."}
```
**Reason:** The token you are using is not from us. You need to get and use valid token.
```json theme={null}
{"detail": "Expired token."}
```
**Reason:** Self-explanatory, you need to get a new token at [console.rated.network/apiKeys](https://console.rated.network/apiKeys).
```json theme={null}
{"detail": "Unknown token."}
```
**Reason:** The token might be valid before but we don't know it anymore. Most likely, it was invalidated after a password reset.
### 403 Forbidden
```json theme={null}
{"detail": "You don't have permission to do that."}
```
**Reason:** The token you are using does not have enough permission to perform the request.
### 404 Not Found
```json theme={null}
{"detail": "Not found."}
```
**Reason:** The resource you requested was not found. Double check the [API Reference](/rated-api/api-reference/introduction).
### 429 Too many requests
```json theme={null}
{"detail": "Too many requests"}
```
**Reason:** You have hit too quick too many times the API. Back-off and retry later.
### 500, 502, 504 Server errors
```json theme={null}
{"detail": "Internal server error."}
```
**Reason:** Something went wrong on our side, these are rare. In case you need assistance contact us and provide the [Request ID](/rated-api/interacting-with-api/request-ids) and we will gladly help you.
# Networks supported
Source: https://docs.rated.network/rated-api/getting-started/networks-supported
A list of networks that you can access with the Rated API.
## Testnets
The API is functional on Ethereum Mainnet and Hoodi under the same schema. All you need to do to access each, is specify `X-Rated-Network` in the query structure as `mainnet` or `hoodi`.
# Welcome
Source: https://docs.rated.network/rated-api/getting-started/welcome
Context around the state of the Rated API, as well as prompts to useful resources regarding the Rated API.
To access Rated APIs, head on over to [console.rated.network](https://console.rated.network)
[Rated Python SDK](https://github.com/rated-network/rated-python) is now available to help fastrack your integration with the Rated APIs!
## Background
Blockchain infrastructure data is hard to parse and contextualise, yet of increasingly vital importance to the well functioning of the broader ecosystem. The Rated API has been designed to make accessing this wealth of data and building on top of it, easy as pie.
The Rated API has been live since July 2022, and is currently adopted for rewards tracking, performance monitoring and benchmarking, as well as a source of truth, by the likes of Lido, Metamask, Kiln, Chorus One, Stakefish, Obol, Nexus Mutual and an additional 30+ regular enterprise users. 🥳
Deploy precise accounting in a few simple calls, with granular tracking of validator rewards earned.
Accurately track, improve and benchmark your current and historical validator fleet performance.
Help users make informed decisions around staking with access to rich metadata about an operator's useful life.
## What the Rated API can do for you
We've built the Rated API to be the most powerful and flexible way out there, to work with infrastructure layer data. With it we serve pools, node operators and referential applications that leverage staking layer data to build delegation, index, insurance, credit and other financial products.
Here's some of the most common ways we see the Rated API being used:
Generalised validator active set management, granular rewards accounting, performance benchmarking, deciding levels and enforcing SLAs, monitoring and benchmarking, powering interfaces for constituents.
Rewards accounting, performance benchmarking, redundancy layer for internal monitoring, powering and/or enhancing owned user interfaces.
Powering interfaces for delegation products, rewards accounting, pricing insurance and credit, powering information products.
Downstream integrators growing to love the Rated API, as besides being a precise, unbiased and easily accessible source of truth (e.g. see [Stakefish v Lido](https://research.lido.fi/t/reimbursement-for-stakefish-2023-02-17-ethereum-incident/4034)), it enables integrators to do things like aggregate validator indices on the fly, get answers about when withdrawals are about to land in their wallet, and pre-materialize validator sets for easy access to all the granular data that Rated offers.
## How to navigate the Rated API documentation
This documentation hub aims to be your trusty resource to getting up to speed with all you need to know to make the most out of using the Rated API.
In this hub, you will find information about:
* Common [Errors](/rated-api/interacting-with-api/errors) and how to handle those
* How [Pagination (v1)](/rated-api/interacting-with-api/v1/pagination) works
* Full [API reference](/rated-api/api-reference/introduction) together with explainers on each of the main pillars of the schema
* A [Glossary](/rated-api/glossary/) with definitions and context on all the variables that the Rated API returns
* Details on the different Pricing [Plans](/rated-api/pricing/plans) available for the Rated API
Let's dive in!
## At a glance
A detailed breakdown of the full set of functionality the Rated API offers.
Embed the Rated API in your Prometheus and Grafana environments.
Information on the main consumption metric for API requests
# Pagination
Source: https://docs.rated.network/rated-api/pagination/v1/pagination
How pagination works on the Rated API v1.
All top-level API resources have support for bulk fetches through API methods that respond with a list. These list API methods share a common structure and accept, at a minimum, the following two parameters: `limit` and `offset`.
## Pagination limits and page size
Rated API v1 uses offset based pagination through the `limit` and `offset` parameters. Both parameters accept an existing object ID value (see below) and return objects in chronological order. The `limit` parameter specifies how many records to fetch per page. The `offset` parameter indicates where to start fetching data or how many records to skip, defining the initial position within the list.
See details on the parameters below:
| Parameters | Description |
| :--------- | :-------------------------------------------------------------------------------------------------------------------------------------------- |
| `limit` | Limit specifies how many records to fetch per page. Default value is 10. |
| `offset` | Offset indicates where to start fetching data or how many records to skip, defining the initial position within the list. Default value is 0. |
In the response, you will get the total number of `pages` which signifies how many pages of data we have for the requested information.
For example, if you call `https://api.rated.network/v1/eth/entities/Lido/effectiveness?entityType=pool&sortOrder=desc` you will get about 120 pages of data which signifies about 1,200 days worth of data.
```json theme={null}
{
"previous": null,
"next": "http://api.rated.network/v1/eth/entities/Lido/effectiveness?entityType=pool&sortOrder=desc&limit=2&offset=2",
"pages": 119,
"results": [
{
"hour": null,
"day": 1216,
"startDay": null,
"endDay": null,
"startEpoch": 273600,
"endEpoch": 273824,
"startDate": null,
"endDate": null,
"date": "2024-03-31",
"validatorCount": 297904,
"avgInclusionDelay": 1.038763630790519,
"avgUptime": 0.9992577027051225,
"avgCorrectness": 0.9876840011118172,
"avgProposerEffectiveness": 99.36076243607621,
"avgValidatorEffectiveness": 95.17034897418644,
"avgAttesterEffectiveness": 95.1591781211266
},
{
"hour": null,
"day": 1215,
"startDay": null,
"endDay": null,
"startEpoch": 273375,
"endEpoch": 273599,
"startDate": null,
"endDate": null,
"date": "2024-03-30",
"validatorCount": 298294,
"avgInclusionDelay": 1.0294108088847345,
"avgUptime": 0.9993213691520342,
"avgCorrectness": 0.9880952559065563,
"avgProposerEffectiveness": 99.65690759377856,
"avgValidatorEffectiveness": 96.04556135704149,
"avgAttesterEffectiveness": 96.0357475833673
}
]
}
```
Depending on the request, you can also get more than one page of results. You can navigate between these pages using the `previous` and `next` URLs. Just use the URL in `next` to continue fetching the rest of the data. You will also get a url in `previous` as you navigate throught pages 2,3,4... and so on. When there's no more data left, the Rated API will stop giving you the link and show `next: null`.
## Sorting and Filters
We have also introduced the ability to sort the response based on the day or date. You can use the sorting parameters `sortBy` and `sortOrder` to retrieve the response in chronological or reverse chronological order.
See details on the parameters below:
| Parameters | Description |
| :---------- | :--------------------------------------------------------------------------------------------------------- |
| `sortBy` | sortBy specifies what parameter you'd like to order your response by. Default value is `day` for Ethereum. |
| `sortOrder` | sortOrder indicates how the sorting will be order. Can be `desc` or `asc` and defaults to `asc`. |
Additionally, you can filter what date range you wish to get your response for using the `fromDate` and `toDate` or `fromDay` and `toDay` query parameters. To see how time works, head [here](/rated-api/api-reference/introduction#time-window-aggregation) for Ethereum.
See details on the parameters below:
| Parameters | Description |
| :--------- | :-------------------------------------------------------------------------------------------- |
| `fromDate` | The inclusive start date for the query in the format `YYYY-MM-DD`. Cannot be after `toDate`. |
| `toDate` | The inclusive end date for the query in the format `YYYY-MM-DD`. Cannot be before `fromDate`. |
| `fromDay` | The inclusive start day for the query. Cannot be after `toDay`. |
| `toDay` | The inclusive end day for the query. Cannot be before `fromDay`. |
Depending on the endpoint and [time window aggregations](/rated-api/api-reference/introduction#time-window-aggregation-on-ethereum) you set using `granularity`, the response will contain a list of items with `startDate`, `endDate`, `fromDay` and `EndDay` that collectively correspond to the filter you applied over a particular granularity.
See details on the parameters below:
| Parameters | Description |
| :---------- | :-------------------------------------------------------------------------- |
| `startDate` | The inclusive start date for the item in a list in the format `YYYY-MM-DD`. |
| `endDate` | The inclusive end date for the item in a list in the format `YYYY-MM-DD`. |
| `startDay` | The inclusive start day for the item in a list. |
| `endDay` | The inclusive end day for the item in a list. |
For example, if you call `https://api.rated.network/v1/eth/entities/Lido/effectiveness?fromDate=2024-03-01&toDate=2024-03-31&granularity=week&entityType=pool&limit=2` you will get a paginated list of two items per page, with weekly aggregates of effectiveness for Lido (pool) from 1st March 2024 to 31st March 2024 with weekly start date/day and end date/day.
```json theme={null}
{
"previous": null,
"next": "http://api.rated.network/v1/eth/entities/Lido/effectiveness?fromDate=2024-03-01&toDate=2024-03-31&granularity=week&entityType=pool&limit=2&offset=2",
"pages": 3,
"results": [
{
"hour": null,
"day": 1186,
"startDay": 1186,
"endDay": 1188,
"startEpoch": 266850,
"endEpoch": 267524,
"startDate": "2024-03-01",
"endDate": "2024-03-03",
"date": null,
"validatorCount": 307230,
"avgInclusionDelay": 1.0148401909467175,
"avgUptime": 0.9991621137562569,
"avgCorrectness": 0.9942351947995315,
"avgProposerEffectiveness": 99.73424219448532,
"avgValidatorEffectiveness": 97.9455545121116,
"avgAttesterEffectiveness": 97.94053939240182
},
{
"hour": null,
"day": 1189,
"startDay": 1189,
"endDay": 1195,
"startEpoch": 267525,
"endEpoch": 269099,
"startDate": "2024-03-04",
"endDate": "2024-03-10",
"date": null,
"validatorCount": 307299,
"avgInclusionDelay": 1.018166812052602,
"avgUptime": 0.9990804092593188,
"avgCorrectness": 0.9940622570239258,
"avgProposerEffectiveness": 99.70565569238833,
"avgValidatorEffectiveness": 97.6359636193607,
"avgAttesterEffectiveness": 97.6302452977211
}
]
}
```
# Compute Units
Source: https://docs.rated.network/rated-api/pricing/compute-units
All you need to know about the fundamental unit of account Rated API v1.
Compute Units are a metric reflecting the computational resources utilized by each API request. Some queries, like `/apr`, are quick and lightweight, while others, such as `/operators/{operator_id}/effectiveness`, may be more resource-intensive.
Compute Units for each endpoint are determined using the following formula:
$$
\left(\frac{\text{Content Length Bytes}}{\text{Weight}}\right) + \left(\text{Item Count} \times \text{Business Value} \times \text{Parameter Multiplier}\right)
$$
## Why use Compute Units?
We wanted to find an approach that guarantees fairness and scalability, ensuring that the costs align with the real value our users get from the APIs. By basing costs on compute units, we ensure that you receive the most transparent and equitable pricing. As we continue to innovate and evolve, we remain focused on delivering both top-notch services and clear, fair pricing that benefits our users.
## How to Monitor Your Compute Unit (CU) Consumption
You can track your compute unit usage in two ways:
1. **API Response Headers**:
Every API request you make includes the `x-rated-compute-units` header in the response. This header displays the exact number of CUs consumed by that specific request.
2. **Rated Console Dashboard**:
* View your overall CU usage on the main [Dashboard](https://console.rated.network/)
* See detailed CU consumption per endpoint in the [Usage Limits](https://console.rated.network/settings/usageLimits) page (navigate via *Settings → Usage Limits*)
## Weights per Endpoint
This represents the weight component of compute unit calculation used per endpoint. Note that your specific averages compute units per endpoint will vary based on your usage patterns of the endpoints and the kinds of aggregations you perform.
| Endpoint | Weight | Business Value | Parameter Multiplier | Multiplier |
| :----------------------------------------------------------------- | :----- | :------------- | :------------------- | :--------- |
| `/v1/eth` | 8 | 5 | | null |
| `/v1/eth/effectiveness` | 8 | 5 | | null |
| `/v1/eth/rewards` | 8 | 5 | | null |
| `/v1/eth/geographicalDistributions` | 8 | 10 | | null |
| `/v1/eth/hostDistributions` | 8 | 10 | | null |
| `/v1/eth/entities` | 8 | 5 | | null |
| `/v1/eth/entities/summaries` | 8 | 2 | | null |
| `/v1/eth/entities/{entity_id}/summaries` | 8 | 2 | | null |
| `/v1/eth/entities/{entity_id}/effectiveness` | 8 | 10 | | null |
| `/v1/eth/entities/{entity_id}/attestations` | 8 | 10 | | null |
| `/v1/eth/entities/{entity_id}/proposals` | 8 | 10 | | null |
| `/v1/eth/entities/{entity_id}/rewards` | 8 | 10 | | null |
| `/v1/eth/entities/{entity_id}/penalties` | 8 | 10 | | null |
| `/v1/eth/entities/{entity_id}/mappings` | 2 | 10 | | null |
| `/v1/eth/entities/{entity_id}/aprs` | 2 | 10 | | null |
| `/v1/eth/entities/{entity_id}/slashings` | 2 | 10 | | null |
| `/v1/eth/validators` | 4 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/effectiveness` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/attestations` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/proposals` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/rewards` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/penalties` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/withdrawals` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/mappings` | 2 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/aprs` | 8 | 10 | | null |
| `/v1/eth/validators/effectiveness` | 4 | 10 | | null |
| `/v1/eth/validators/attestations` | 4 | 10 | | null |
| `/v1/eth/validators/proposals` | 4 | 10 | | null |
| `/v1/eth/validators/mappings` | 2 | 10 | | null |
| `/v1/eth/validators/slashings` | 4 | 10 | | null |
| `/v1/sets/{id}/effectiveness` | 4 | 10 | | null |
| `/v1/sets/{id}/attestations` | 4 | 10 | | null |
| `/v1/sets/{id}/proposals` | 4 | 10 | | null |
| `/v1/sets/{id}/rewards` | 4 | 10 | | null |
| `/v1/sets/{id}/penalties` | 4 | 10 | | null |
| `/v1/solana/delegators/stakeAccounts/{stake_account}/rewards` | 8 | 5 | | null |
| `/v1/solana/delegators/stakeAuthorities/{stake_authority}/rewards` | 8 | 5 | | null |
| `/v1/solana/network/overview` | 8 | 5 | | null |
| `/v1/solana/network/validatorDistributions` | 8 | 5 | | null |
| `/v1/solana/network/effectiveness` | 8 | 5 | | null |
| `/v1/solana/validators/{validator_id}/rewards` | 1 | 5 | | null |
| `/v1/solana/validators/{validator_id}/performance` | 1 | 5 | | null |
| `/v1/solana/validators/{validator_id}/performance/latency` | 1 | 5 | | null |
| `/v1/solana/validators/leaderboard` | 8 | 5 | | null |
| `/v1/solana/validators/{validator_id}` | 8 | 2 | | null |
| `/v1/solana/validators/{validator_id}/delegators` | 25 | 2 | | null |
| `/v1/solana/validators` | 8 | 5 | | null |
| `/v1/solana/validators/{validator_id}/summary` | 8 | 2 | | null |
| `/v1/eigenlayer/delegators/{address}/delegations` | 1 | 500 | | null |
| `/v1/eigenlayer/entities/{entity_id}/delegations` | 1 | 500 | | null |
| `/v1/eigenlayer/eigenpods/{address}/rewards` | 1 | 500 | granularity=week | 5 |
| `/v1/eigenlayer/delegators/{address}/rewards` | 1 | 1200 | granularity=week | 5 |
| `/v1/eigenlayer/entities/{entity_id}/rewards` | 1 | 1200 | granularity=week | 5 |
| `/v1/eigenlayer/eigenpods/{address}/state` | 1 | 500 | | null |
| `/v1/eigenlayer/operators/{address}/state` | 1 | 1200 | | null |
| `/v1/cosmos/validators/{validator_address}/rewards` | 2 | 10 | | null |
| `/v1/cosmos/network/rewards` | 2 | 10 | | null |
| `/v1/avalanche/validators/{node_id}/rewards` | 2 | 10 | | null |
| `/v1/avalanche/network/rewards` | 2 | 10 | | null |
| `/v1/celestia/validators/{validator_address}/rewards` | 2 | 10 | | null |
| `/v1/celestia/network/rewards` | 2 | 10 | | null |
| `/v1/cardano/validators/{pool_id}/rewards` | 2 | 10 | | null |
| `/v1/cardano/network/rewards` | 2 | 10 | | null |
| `/v1/polkadot/validators/{validator_address}/rewards` | 2 | 10 | | null |
| `/v1/polkadot/network/rewards` | 2 | 10 | | null |
For the endpoint `/v1/tags/{id}/validators`, we will calculate compute units as 128 pubkeys reported
| Endpoint | Weight | Business Value |
| :----------------------------------------------------------------- | :----- | :------------- |
| `/v0/eth/network/overview` | 8 | 5 |
| `/v0/eth/network/stats` | 8 | 1 |
| `/v0/eth/network/capacity` | 8 | 5 |
| `/v0/eth/network/capacity/pool` | 8 | 5 |
| `/v0/eth/p2p/geographical` | 8 | 5 |
| `/v0/eth/p2p/hostingProvider` | 8 | 5 |
| `/v0/eth/operators` | 8 | 5 |
| `/v0/eth/operators/percentiles` | 8 | 1 |
| `/v0/eth/operators/{operator_id}` | 8 | 5 |
| `/v0/eth/operators/{operator_id}/effectiveness` | 8 | 10 |
| `/v0/eth/operators/{operator_id}/apr` | 8 | 5 |
| `/v0/eth/operators/{operator_id}/summary` | 8 | 2 |
| `/v0/eth/operators/{operator_id}/stakeMovement` | 8 | 1 |
| `/v0/eth/operators/{operator_id}/clients` | 8 | 1 |
| `/v0/eth/operators/{operator_id}/relayers` | 8 | 1 |
| `/v0/eth/validators/effectiveness` | 8 | 10 |
| `/v0/eth/validators/{validator_index_or_pubkey}` | 8 | 10 |
| `/v0/eth/validators/{validator_index_or_pubkey}/effectiveness` | 32 | 10 |
| `/v0/eth/validators/{validator_index_or_pubkey}/apr` | 32 | 1 |
| `/v0/eth/blocks` | 32 | 10 |
| `/v0/eth/blocks/{consensus_slot}` | 32 | 10 |
| `/v0/eth/relayers` | 32 | 1 |
| `/v0/eth/relayers/recent` | 32 | 1 |
| `/v0/eth/relayers/stats` | 32 | 1 |
| `/v0/eth/trending/effectiveness/operators` | 32 | 5 |
| `/v0/eth/trending/mev/operators` | 32 | 5 |
| `/v0/eth/trending/effectiveness/validators` | 32 | 5 |
| `/v0/eth/trending/slashings/operators` | 32 | 5 |
| `/v0/eth/slashings/overview` | 32 | 1 |
| `/v0/eth/slashings/leaderboard` | 32 | 1 |
| `/v0/eth/slashings/cohortAnalysis` | 32 | 5 |
| `/v0/eth/slashings/timeseries` | 32 | 5 |
| `/v0/eth/slashings` | 32 | 5 |
| `/v0/eth/slashings/{validator_index_or_pubkey}` | 32 | 1 |
| `/v0/polygon/network/overview` | 8 | 5 |
| `/v0/polygon/validators` | 8 | 5 |
| `/v0/polygon/validators/{validator_id}` | 8 | 5 |
| `/v0/polygon/validators/{validator_id}/effectiveness` | 8 | 10 |
| `/v0/polygon/validators/{validator_id}/summary` | 8 | 2 |
| `/v0/polygon/delegators` | 8 | 5 |
| `/v0/polygon/delegators/{delegator_address}/summary` | 8 | 10 |
| `/v0/polygon/delegators/{delegator_address}/rewards` | 8 | 10 |
| `/v0/solana/delegators/stakeAccounts/{stake_account}/rewards` | 8 | 5 |
| `/v0/solana/delegators/stakeAuthorities/{stake_authority}/rewards` | 8 | 5 |
| `/v0/solana/network/overview` | 8 | 5 |
| `/v0/solana/network/validatorDistributions` | 8 | 5 |
| `/v0/solana/network/effectiveness` | 8 | 5 |
| `/v0/solana/validators/{validator_id}/rewards` | 1 | 5 |
| `/v0/solana/validators/{validator_id}/performance` | 1 | 5 |
| `/v0/solana/validators/{validator_id}/performance/latency` | 1 | 5 |
| `/v0/solana/validators/leaderboard` | 8 | 5 |
| `/v0/solana/validators/{validator_id}` | 8 | 2 |
| `/v0/solana/validators` | 8 | 5 |
| `/v0/solana/validators/{validator_id}/summary` | 8 | 2 |
# Rate limits
Source: https://docs.rated.network/rated-api/rate-limits
Learn about API rate limits and how to work with them.
The Rated API employs a number of safeguards against bursts of incoming traffic to help maximise its stability. Users who send many requests in quick succession may see error responses that show up as status code `429 Too many requests.`
For Free tier users, Rated allows up to 2 requests per second with a 10,000 Lifetime request safeguard.
For paid tiers, rate limit details can be found at our [Plans](/rated-api/pricing/plans) page.
Once you get rate limited you can use `Retry-After` and `Age` headers to compute how long you need to wait before being able to continue using the API.
## Handling Rate Limits
When you receive a `429` status code, check the response headers:
* `Retry-After`: Number of seconds to wait before making another request
* `Age`: How long the current rate limit window has been active
### Examples
```python Python theme={null}
import time
import requests
response = requests.get('https://api.rated.network/v0/eth/network/overview')
if response.status_code == 429:
retry_after = int(response.headers.get('retry-after', 1))
print(f"Rate limited. Retry after {retry_after} seconds")
# Wait before retrying
time.sleep(retry_after)
# Make your request again
```
```javascript JavaScript theme={null}
if (response.status === 429) {
const retryAfter = response.headers['retry-after'];
console.log(`Rate limited. Retry after ${retryAfter} seconds`);
// Wait before retrying
setTimeout(() => {
// Make your request again
}, retryAfter * 1000);
}
```
```bash cURL theme={null}
# If you get a 429 response, check the headers
curl -i https://api.rated.network/v0/eth/network/overview
# Response headers will include:
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Age: 15
# Wait 30 seconds then retry
```
```go Go theme={null}
if resp.StatusCode == 429 {
retryAfter := resp.Header.Get("retry-after")
fmt.Printf("Rate limited. Retry after %s seconds\n", retryAfter)
// Convert to duration and wait
if seconds, err := strconv.Atoi(retryAfter); err == nil {
time.Sleep(time.Duration(seconds) * time.Second)
// Make your request again
}
}
```
We may reduce limits to prevent abuse, or increase limits to enable high-traffic applications. To request an increased rate limit, please [contact us](mailto:hello@rated.network).
# Request IDs
Source: https://docs.rated.network/rated-api/request-ids
How to find those, and code examples.
Each API request has an associated request identifier. You can find this value in the response headers, under `X-Request-Id`.
If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution.
```curl Curl theme={null}
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/validators/69/effectiveness' \
-H 'accept: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
...
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< access-control-expose-headers: X-Request-ID
< content-length: 45
< content-type: application/json
< date: Wed, 19 Apr 2023 19:32:56 GMT
< server: envoy
< www-authenticate: Bearer
< x-request-id: 4b07649d-a553-4f1a-8be9-9a7a514ffcf9
< x-envoy-upstream-service-time: 11
<
* Connection #0 to host api.rated.network left intact
```
```python Python theme={null}
# my_token contains a JWT you got previously from console.rated.network/apiKeys
import requests
response = requests.get(
"https://api.rated.network/v0/eth/validators/69/effectiveness",
headers={"Authorization": f"Bearer {my_token}"},
)
try:
response.raise_for_status()
except requests.exceptions.HTTPError:
print(response.headers["x-request-id"])
```
# Introduction
Source: https://docs.rated.network/rated-api/api-reference/introduction
Resources dedicated to exposing and explaining the various endpoints that the Rated API supports.
You can also access our API's Swagger documentation via [api.rated.network/docs](https://api.rated.network/docs)
## Making sense of the API input
The standard form of the Rated API looks something like this:
`https://api.rated.network/version/network/entity/resource`
At the highest level, here's how you should interpret the class of instructions you are passing to it:
| Parameter | Description |
| :--------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `version` | The version of the API you are on. Currently the API is in `v0` |
| `network` | The network you are querying |
| `entityId` | The class of entity you are querying for. This could be either of [Validators](/rated-api/api-reference/v0/ethereum/validators), [Operators](/rated-api/api-reference/v0/ethereum/operators) and [Network](/rated-api/api-reference/v0/ethereum/network) |
| `resource` | The specific resource you are querying for |
## How time works
### For Ethereum
All rewards and performance metrics are hosted under the "effectiveness" endpoint.
By default, the API returns data in daily chunks (24h / 225 epoch / 7200 slot increments), starting from Beacon Chain genesis. As such, `Day 0` encompasses the 225 epoch period between epochs \[0, 225), and maps to datetime `2020-12-01 12:00:23 UTC` to `2022-12-02 12:00:11 UTC`. The reasoning for this is to make sure that days are always equal in terms of included epochs (i.e. guaranteed to have 225 epochs each).
That being said, for `performance` and `rewards` v1 endpoints, we have enabled a `utc` parameter which users the option retrieve data based on UTC time. The epochs are partitioned into days based on the starting timestamp of an epoch (i.e. timestamp of the first slot in an epoch). This means epochs belong to the (UTC) day they were started in. The rewards partitioned this way instead of at the slot-level, as doing so by the latter would make accounting around midnight quite complicated (especially attestation rewards where the rewarded action and the actual reward have a time lag). Thus, validator activity that occurs between 23:57 and 00:03 will be accounted for in the previous day. This way all days will have 225 epochs as with the default timing.
**As an example for Ethereum mainnet:**
Day 0 would be from:
* Slot 0 to 3615
* Epoch 0 to 112
* Time period: `2020-12-01 12:00:23` (genesis) to `2020-12-02 00:03:23 UTC`
Day 1 would be from:
* Slot 3616 to 10815
* Epoch 113 to 337
* Time period: `2020-12-02 00:03:35` to `2020-12-03 00:03:23 UTC`
* Epoch 337 started on `2020-12-02 23:57:11 UTC` so despite ending on `2020-12-03 00:03:23 UTC`, it still counted under Day 1 (which is `2020-12-02`).
Subsequent days would follow the same pattern as Day 1. Excluding Day 0, there will always be 7200 slots and 225 epochs in a day.
### For Solana
The "rewards" and "performance" endpoints, which contains validator rewards and performance data respectively, returns data in daily chunks, indexed on UTC days, epochs, or 20 minute intervals.
The "latency" endpoint, which mainly contains data on validator voting latency, returns real-time data over the last 20 minutes.
## Entity granularity
### For Ethereum
The Rated API supports querying for rewards, performance and metadata at the validator pubkey level, all the way up to a pre-configured operator (list of pubkeys) or pool (list of operators).
We have the capability to aggregate statistics on an arbitrary number of keys, and can pre-configure entity aggregations that follow continuously updated registries (e.g. [rated.network/o/Lido](https://rated.network/o/Lido)).
If that's relevant to your use case, get in touch with us via [hello@rated.network](mailto:hello@rated.network).
## Time window aggregation
### For Ethereum
The Rated API also supports aggregation, so days can be rolled up in weeks, months, quarters, years and even all time on Ethereum.
To use this feature, the `granularity` query parameter can be used. For example, to obtain monthly aggregates for validator index `100` on Ethereum:
```sh theme={null}
curl -X 'GET' \\
'[]' \\
-H 'accept: application/json' \\
-H 'X-Rated-Network: mainnet'
```
# Report Validators
Source: https://docs.rated.network/rated-api/api-reference/v0/ethereum/self-report/report-validators
post /v0/selfReports/validators
Here's how to interpret the inputs required to operate it:
| Parameter | Context |
| :----------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `validators` | Array of validator pubkeys associated with the node operator |
| `poolTag` | String for pool name, must match exactly to the pool name listed on the [Explorer](https://www.rated.network/?network=mainnet\&view=pool\&timeWindow=1d\&page=1\&poolType=all). |
And here's how to you might go about implementing it:
```sh Curl theme={null}
curl -v -X 'POST' \
'https://api.rated.network/v0/selfReports/validators' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
-d '{"validators": ["0x01...", "0x02..."], "poolTag": "Lido"}'
```
```python Python theme={null}
import requests
from typing import Dict, List
YOUR_TOKEN: str = "ey..."
PUBKEYS: List[str] = ["0x001...", "0x002...", ]
HEADERS: Dict[str, str] = {
"Authorization": f"Bearer {YOUR_TOKEN}",
"X-Rated-Network": "mainnet",
}
try:
response = requests.post(
"https://api.rated.network/v0/selfReports/validators",
# important! use the json parameter not data
json={"validators": PUBKEYS, "poolTag": "Lido"},
headers=HEADERS,
)
response.raise_for_status()
except requests.exceptions.HTTPError:
print(response.headers["x-request-id"])
print(response.json())
```
#### Please note the following:
* You can self report on Ethereum Mainnet and Hoodi.
* Do not pass your operator name as pool name. If you're not getting delegations via a pool or pool share, please leave the "poolTag" empty.
* Each request has a strict limit of 1,000 validator public keys. Please submit multiple requests if you need to report more than 1,000 validators.
* We cannot assign a key to your entity if it has already been reported by another operator. In case of false attribution, please contact us at [hello@rated.network](http://hello@rated.network), and we will address the issue.
* As this API is self-reported, it relies on the honest behaviour of all participants reporting their validators. Any instances of misconduct may lead to the exclusion of the entity from our platform.
* It typically takes about 24 hours for the reported keys to appear on [rated.network/explorer](http://rated.network/explorer). Please note that your keys need to be activated (ie not in the activation queue) for them to show up on the Explorer.
* If your activated keys have not shown up after the 24h period, please contact us at [hello@rated.network](http://hello@rated.network), and we will investigate the issue.
# Self report
Source: https://docs.rated.network/rated-api/api-reference/v0/ethereum/self-report/self-report
Self-serve API for node operators to report validator operations.
This endpoint is the gateway for node operators to "upload" their sets on the Rated Network Explorer. We now have a streamlined way in place for Node Operators to track their validator sets on the Rated Explorer, in a live way.
**You must have an Account with Rated to access this endpoint.** Please head to [rated.network/apis](https://rated.network/apis) or [console.rated.network](https://console.rated.network) to create one.
In order to prevent abuse and reduce the risk of legitimising bad actors, you must be approved by Rated in order to access this endpoint. Please head to our [Rated Node Operator Onboarding](https://ihrjiko6lmv.typeform.com/to/FxJpSeXf) form to request access.
## Reporting a validator set
# Get network rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/avalanche/rewards/get-network-rewards-metrics
get /v1/avalanche/network/rewards
This endpoint returns the historical rewards earned by the network and potential rewards.
# Get validator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/avalanche/rewards/get-validator-rewards-metrics
get /v1/avalanche/validators/{node_id}/rewards
This endpoint returns the historical rewards earned by a single validator and their potential rewards.
Using this endpoint, you can query the historical daily rewards of a validator by their unique `node_id`. In Avalanche, rewards are distributed at the end of validation periods for validators (`VALIDATOR` and `VALIDATOR_FEE` reward types) and delegation periods for delegators (`DELEGATOR` reward type). This is how we match the rewards to a particular date. We match delegator rewards to the validator where delegators have staked/delegated to in order to give a full picture of rewards related to a validator.
As mentioned earlier, there are different reward types but Avalanche also computes the maximum potential reward a validator can receive at the end of validation and delegation periods. This is based on a validator having 100% uptime for its validation period (i.e. receiving the maximum rewards possible). In the response, this is given by the prefix `potential_` and is specified per reward type, wherein we return these potential rewards as of a particular date.
# Rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/avalanche/rewards/rewards
A series of endpoints that drill down on rewards related metrics for validators and the network.
These rewards currently only include rewards from the [Primary Network](https://build.avax.network/docs/quick-start/primary-network).
The historical daily rewards are available from October 1, 2024.
## Validator Rewards
Rewards on Avalanche are very straightforward as it is only based on a validator's uptime as observed by its peers. There are no other reward mechanisms on the Avalanche Primary Network, mostly due to the fact that all transaction fees are burned.
A validator is considered “up” if it responds to queries promptly (e.g. preference sampling and block proposals). Every validator on Avalanche keeps track of the uptime of other validators, with each validator being weighted by its stake. The more stake a validator has, the more influence they have when validators vote on whether a validator should receive a staking reward.
The validator is then rewarded if its uptime is above the [uptime-requirement threshold](https://docs.avax.network/nodes/configure/avalanchego-config-flags#--uptime-requirement-float), which is currently set to 80%. These rewards are denominated in AVAX.
## Reward Types
There are different types of rewards that a validator receives based on its uptime performance:
* `VALIDATOR`: rewards paid to the validator for their own committed stake
* `DELEGATOR`: rewards paid to the delegator for their committed stake.
* `VALIDATOR_FEE`: rewards paid to the validator as its cut/commission from the delegators' rewards (depends on the commission rate set by the validator)
These rewards are distributed at different periods depending on the type. Delegator rewards are distributed at the end of the delegation period set by the delegator. Validator and validator fee rewards are distributed when a validator completes its set validation period (i.e. at the end).
### Get Validator Rewards metrics
### Get Network Rewards metrics
# Get the delegators associated to a validator
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/metadata/get-the-delegators-associated-to-a-validator
get /v1/babylon/validators/{validator_address}/delegators
This endpoint returns all distinct delegators associated to a validator over a period of time when they were actively delegated.
# Metadata
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/metadata/metadata
## Validator-Delegator Mapping
This endpoint returns all distinct delegator addresses associated to a validator over a period of time when they were actively delegated.
### Get the stake accounts associated to a validator
# Get BTC delegator state information
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/performance/get-btc-delegator-state-information
get /v1/babylon/btcDelegators/{delegator_address}/state
This endpoint returns information about a BTC delegator's state including active stake. Use this endpoint to retrieve historical state data for a specific delegator.
Using this endpoint, you can query the historical daily stake balance of a delegator by their unique Babylon Genesis address. The results are per individual finality provider that the delegator has staked to.
You can use the `fromDate` and `toDate` parameters to query a range of days.
# Get delegator state information
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/performance/get-delegator-state-information
get /v1/babylon/delegators/{delegator_address}/state
This endpoint returns information about a delegator's state including active stake. Use this endpoint to retrieve historical state data for a specific delegator.
Using this endpoint, you can query the historical daily stake balance of a delegator by their unique address. The results are per individual validator that the delegator has staked to.
You can use the `fromDate` and `toDate` parameters to query a range of days.
# Get finality provider state information
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/performance/get-finality-provider-state-information
get /v1/babylon/finalityProviders/{finality_provider}/state
This endpoint returns information about a finality provider's state including active stake. Use this endpoint to retrieve historical state data for a specific finality provider.
Using this endpoint, you can query the historical daily stake balance of a finality provider by their unique `finality_provider` identifier/s. This identifier can be their Babylon address, BTC public key, or BTC address. The data is aggregated by finality provider across all of their respective delegators based on the latter's Babylon Genesis addresses.
You can use the `fromDate` and `toDate` parameters to query a range of days.
# Get validator state information
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/performance/get-validator-state-information
get /v1/babylon/validators/{validator_address}/state
This endpoint returns information about a validator's state including active stake. Use this endpoint to retrieve historical state data for a specific validator.
Using this endpoint, you can query the historical daily stake balance of a validator by their unique `validator_address`. The data is aggregated by validator across all of their respective delegators.
You can use the `fromDate` and `toDate` parameters to query a range of days.
# Performance
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/performance/performance
## Validator Stake State
Using this endpoint, you can query the historical daily stake balance of a validator by their unique `validator_address`. The data is aggregated by validator across all of their respective delegators.
## Delegator Stake State
Using this endpoint, you can query the historical daily stake balance of a delegator by their unique address. The results are per individual validator that the delegator has staked to.
## Finality Provider Stake State
Using this endpoint, you can query the historical daily stake balance of a finality provider by their unique `finality_provider` identifier/s. This identifier can be their Babylon address, BTC public key, or BTC address. The data is aggregated by finality provider across all of their respective delegators.
## BTC Delegator Stake State
Using this endpoint, you can query the historical daily stake balance of a BTC delegator by their unique Babylon Genesis address. The results are per individual finality provider that the delegator has staked to.
# Get BTC delegator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/rewards/get-btc-delegator-rewards-metrics
get /v1/babylon/btcDelegators/{delegator_address}/rewards
This endpoint returns the historical rewards earned by a single BTC delegator.
Using this endpoint, you can query the historical daily rewards of a delegator by their unique `delegator_address` across finality providers they have delegated to.
`delegatorRewards` are the Babylon rewards, with its denomination specified by the `token` field, which delegators are entitled to receive from the finality provider they have staked to. The finality provider they have staked to is given by the `finality_provider_address` field.
You can use the `fromDate` and `toDate` parameters to query a range of days.
# Get delegator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/rewards/get-delegator-rewards-metrics
get /v1/babylon/delegators/{delegator_address}/rewards
This endpoint returns the historical rewards earned by a single delegator.
Using this endpoint, you can query the historical daily rewards of a delegator by their unique `delegator_address` across validators they have delegated to.
`delegatorRewards` are the Babylon rewards, denominated in the network's native token, which delegators are entitled to receive from the validator they have staked to. The validator they have staked to is given by the `validator` address field.
You can use the `fromDate` and `toDate` parameters to query a range of days.
# Get finality provider rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/rewards/get-finality-provider-rewards-metrics
get /v1/babylon/finalityProviders/{finality_provider}/rewards
This endpoint returns the historical rewards earned by a single finality provider.
Using this endpoint, you can query the historical daily rewards of a finality provider by their unique `finality_provider` identifier/s. This identifier can be their Babylon address, BTC public key, or BTC address.
`totalDelegationRewards` are the rewards, with its denomination specified by the `token` field, which delegators are entitled to receive from the finality provider they have staked to. The rewards from the commission a finality provider charges are given by the `totalCommissionRewards`.
You can use the `fromDate` and `toDate` parameters to query a range of days.
# Get network rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/rewards/get-network-rewards-metrics
get /v1/babylon/network/rewards
This endpoint returns the historical rewards earned by the network.
Using this endpoint, you can query the total historical daily rewards at the network-level for the specific day.
`totalDelegationRewards` are the Babylon rewards, denominated in the network's native token, which delegators are entitled to receive from the validators they have staked to. This includes the rewards towards validators that have self-staked/self-bonded. The rewards from the commissions validators charge are given by the `totalCommissionRewards`.
You can use the `fromDate` and `toDate` parameters to query a range of days.
# Get validator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/rewards/get-validator-rewards-metrics
get /v1/babylon/validators/{validator_address}/rewards
This endpoint returns the historical rewards earned by a single validator.
Using this endpoint, you can query the historical daily rewards of a validator by their unique `validator_address`.
`totalDelegationRewards` are the Babylon rewards, denominated in the network's native token, which delegators are entitled to receive from the validator they have staked to. This includes the rewards towards a validator if they have self-staked/self-bonded. The rewards from the commission a validator charges are given by the `totalCommissionRewards`.
You can use the `fromDate` and `toDate` parameters to query a range of days.
# Rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/babylon/rewards/rewards
A series of endpoints that drill down on rewards related metrics for validators and the network on the Babylon Genesis chain.
## Validator Rewards
Using this endpoint, you can query the historical daily rewards of a validator by their unique `validator_address`.
## Delegator Rewards
Using this endpoint, you can query the historical daily rewards of a delegator by their unique `delegator_address`.
## Network Rewards
Using this endpoint, you can query the total historical daily rewards at the network-level for the specific day. This is based on the validator and delegator rewards.
## Finality Provider Rewards
Using this endpoint, you can query the historical daily rewards of a finality provider by their unique `finality_provider` identifier/s. This identifier can be their Babylon address, BTC public key, or BTC address.
## BTC Delegator Rewards
Using this endpoint, you can query the historical daily rewards of a finality provider delegator by their unique `delegator_address`, which is based on their address in the Babylon Genesis chain.
# Get network rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/cardano/rewards/get-network-rewards-metrics
get /v1/cardano/network/rewards
This endpoint returns the historical rewards earned by the network.
Using this endpoint, you can query the historical daily rewards at the network-level for a specific day.
`totalRealizedDelegatorRewards` and `totalRealizedValidatorRewards` refer to rewards already distributed to the members/delegators and stake pool owners/validators respectively based on the epoch when they were distributed. Meanwhile, `totalEarnedDelegatorRewards` and `totalEarnedValidatorRewards` refer to the rewards earned for an epoch but not yet distributed. These rewards are already net of the 20% cut that the treasury takes. These rewards are denominated in ADA.
In terms of timing, we align these rewards according to the day when an epoch ended.
# Get stake pool/validator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/cardano/rewards/get-validator-rewards-metrics
get /v1/cardano/validators/{pool_id}/rewards
This endpoint returns the historical rewards earned by a single stake pool/validator.
Using this endpoint, you can query the historical daily rewards of a stake pool/validator by their unique `poolId`, which is a hash in the form of `pool` + 52 characters (ex: `pool12vx0utf438rpxskmvwm870vpz6qnurdqekzjea39jzl7gs3hhhl`) or `poolHashId` which is the hashed version of the `poolId`. These rewards are denominated in ADA.
`totalRealizedDelegatorRewards` and `totalRealizedValidatorRewards` refer to rewards already distributed to the members/delegators and stake pool owners/validators respectively based on the epoch when they were distributed. Meanwhile, `totalEarnedDelegatorRewards` and `totalEarnedValidatorRewards` refer to the rewards earned for an epoch but not yet distributed. These rewards are already net of the 20% cut that the treasury takes.
In terms of timing, we align these rewards according to the day when an epoch ended.
# Rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/cardano/rewards/rewards
A series of endpoints that drill down on rewards related metrics for stake pools (validators) and the network.
Historical rewards are available from November 1, 2024.
## Validator Rewards
### Rewarded Duties
In Cardano, validators are referred to as stake pools. Stake pools are server nodes that combine the stake of various stakeholders into a single entity (i.e. a single stake pool). These stake pools have the responsibility of validating and producing blocks, and processing transactions. As such, the rewards that these stake pools receive are based on these duties.
### Calculation and Timing
The rewards are calculated and distributed on a per epoch basis, with each epoch being 5 days. Once the rewards are calculated, they are held by the Cardano treasury at the end of the epoch when they are earned. After the treasury takes a 20% cut, the rewards are then locked up for 2 epochs before they are distributed to stake pools.
### Commission and Distribution
With the rewards being distributed to the stake pools, the leader (i.e. stake pool owner/validator operator) first takes a "fixed fee" (`poolFlatFee`) from the rewards which is usually a static amount, then takes their "margin fee" which is a percentage commission (`poolFee`). The remaining rewards are then split proportionally between the leader and the members (i.e. delegators) depending on how much they have staked in the stake pool.
## Network Rewards
This network rewards endpoint gives you a breakdown of all rewards earned and realized/received by stake pools over a specified period of time.
# Get network rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/celestia/rewards/get-network-rewards-metrics
get /v1/celestia/network/rewards
This endpoint returns the historical rewards earned by the network.
Using this endpoint, you can query the total historical daily rewards at the network-level for the specific day. `totalDelegationRewards` are the Celestia rewards, denominated in TIA, which delegators are entitled to receive from the validators they have staked to. This includes the rewards towards validators that have self-staked/self-bonded. The rewards from the commissions validators charge are given by the `totalCommissionRewards`.
# Get validator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/celestia/rewards/get-validator-rewards-metrics
get /v1/celestia/validators/{validator_address}/rewards
This endpoint returns the historical rewards earned by a single validator.
Using this endpoint, you can query the historical daily rewards of a validator by their unique `validator address`. `totalDelegationRewards` are the Celestia rewards, denominated in TIA, which delegators are entitled to receive from the validator they have staked to. This includes the rewards towards a validator if they have self-staked/self-bonded. The rewards from the commission a validator charges are given by the `totalCommissionRewards`.
# Rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/celestia/rewards/rewards
A series of endpoints that drill down on rewards related metrics for validators and the network.
Historical rewards are available from December 1, 2024. We are actively working to backfill this up to October 1, 2024.
## Validator Rewards
Validators on Celestia are rewarded through two duties: block signing and block proposals. Given that Celestia is primarily a [data availability network](https://docs.celestia.org/learn/how-celestia-works/overview), validators are also expected to provide data availability services such as serving proofs of block and transaction data availability when queried. However, there is no explicitly separate validator rewards for this.
### Block Signing
Celestia validators are expected to sign every block (i.e. attest) that is proposed when they are in the active validator set. As long as a validator is not slashed for downtime or double signing, they will receive their full share of block signing rewards. This is paid for by the chain through inflation of the TIA token. For more information on TIA inflation, see [here](https://docs.celestia.org/learn/staking-governance-supply#inflation).
### Block Proposals
Validators are also expected to propose blocks. They receive rewards from proposals through transaction fees paid by users of Celestia, which are [mainly payments for blobspace by other rollups/chains](https://docs.celestia.org/learn/paying-for-blobspace) using Celestia as a data availability layer.
### Validator Rewards and Commission
Validator set a specific commission rate on the rewards received by their delegators. Through delegating their stake, delegators receive rewards based on successfully fulfilled duties by their chosen validator/s. Validators take a cut on these rewards based on their set commission rate.
### Get validator rewards metrics
### Get network rewards metrics
# Get network rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/cosmos/rewards/get-network-rewards-metrics
get /v1/cosmos/network/rewards
This endpoint returns a bunch of useful information about the historical rewards earned by the network.
Using this endpoint, you can query the total historical daily rewards at the network-level for the specific day. `totalDelegationRewards` are the Cosmos Hub rewards, denominated in ATOM, which delegators are entitled to receive from the validators they have staked to. This includes the rewards towards validators that have self-staked/self-bonded. The rewards from the commissions validators charge are given by the `totalCommissionRewards`.
# Get validator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/cosmos/rewards/get-validator-rewards-metrics
get /v1/cosmos/validators/{validator_address}/rewards
This endpoint returns a bunch of useful information about the historical rewards earned by a single validator.
Using this endpoint, you can query the historical daily rewards of a validator by their unique `validator address`. `totalDelegationRewards` are the Cosmos Hub rewards, denominated in ATOM, which delegators are entitled to receive from the validator they have staked to. This includes the rewards towards a validator if they have self-staked/self-bonded. The rewards from the commission a validator charges are given by the `totalCommissionRewards`.
# Rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/cosmos/rewards/rewards
A series of endpoints that drill down on rewards related metrics for validators.
These rewards currently only include Cosmos Hub rewards and excludes any rewards from Cosmos' Interchain Security model (i.e. rewards from other chains for the shared security provided by the hub).
The historical daily rewards are only available from November 22, 2024.
## Validator Rewards
This validator rewards endpoint give you a breakdown of all rewards earned by a validator entity over a specified period of time.
### Get validator rewards metrics
## Network Rewards
This network rewards endpoint gives you a breakdown of all rewards earned by bonded validators over a specified period of time.
### Get network rewards metrics
# Get delegations by delegator
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/metadata/get-delegations-by-delegator
get /v1/eigenlayer/delegators/{delegator_address}/delegations
This endpoint returns the delegation history by delegator address
Using this endpoint, you can query per delegator using its delegator address, and you will see that particular delegator's delegation history per operator. Returned information includes the start date (`fromDate`) and end dates (`toDate)` of the delegation. If `toDate` is `None`, it means the address is currently delegated to that operator.
# Get delegators by operator address
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/metadata/get-delegators-by-operator-address
get /v1/eigenlayer/entities/{operator_address}/delegations
This endpoint returns the delegation history of delegators to an operator address
This endpoint behaves similar to [`GET /v1/eigenlayer/delegators/\{delegator\_address}/delegations`](/rated-api/api-reference/v1/eigenlayer/metadata/get-delegations-by-delegator) endpoint, except that is acts at an operator level. By querying the endpoint using an operator's specific address, you can see the history of delegators that have delegated to this operator. Delegations wherein `toDate` is `None` means those are active.
# Get metadata on the Rated Eigenlayer API endpoints
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/metadata/get-metadata-on-the-rated-eigenlayer-api-endpoints
get /v1/eigenlayer/apiMetadata
This endpoint returns information about the latest complete data available from Rated's Eigenlayer API endpoints.
Use this endpoint to know the latest freshness of the rewards endpoints and the stake state API endpoints for Eigenlayer.
# Get Stake state by delegator.
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/metadata/get-stake-state-by-delegator
get /v1/eigenlayer/delegators/{delegator_address}/state
This endpoint returns the daily stake state of a delegator
This endpoint allows you to query the daily stake and shares balance of a specific delegator based on their delegator address, given by the `earner` field in the response.
# Get Stake state by Eigenpod.
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/metadata/get-stake-state-by-eigenpod
get /v1/eigenlayer/eigenpods/{eigenpod_address}/state
This endpoint returns the daily stake state of an Eigenpod
This endpoint allows you to query the daily stake and shares balance of a specific eigenpod based on their operator address, the specific strategy, and token address.
# Get Stake state by Entity.
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/metadata/get-stake-state-by-entity
get /v1/eigenlayer/entities/{operator_address}/state
This endpoint returns the daily stake state of an Entity
This endpoint allows you to query the daily stake and shares balance of an operator based on their operator address, the specific strategy, and token address.
# Metadata
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/metadata/metadata
A series of endpoints that drill down on metadata-related metrics for both delegators and entities (operators).
## Eigenlayer Delegations
These endpoints return information about the delegation history on Eigenlayer.
### Get Delegations by Delegator
### Get Delegations by Operator Address
## Stake State
### Entity Stake State
### Get Stake State by Entity
### Eigenpod Stake State
### Get Stake State by Eigenpod
### Delegator Stake State
### Get Stake State by Delegator
## API Metadata
### Get metadata on the Rated Eigenlayer API endpoints
# Get rewards by Delegator.
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/rewards/get-rewards-by-delegator
get /v1/eigenlayer/delegators/{delegator_address}/rewards
Returns the rewards of a Delegator with specified granularity (day or week)
Using this endpoint, you can query per delegator using its delegator address, and you will see that particular delegator's rewards history, broken down per token. It gives the amount per token, the date when they were distributed (`date`), and the date when they are claimable (`activatedAt` given in milliseconds). The ETH and USD prices of the token are also given based on the day when the rewards are claimable. Pricing data is provided by [Coingecko](https://www.coingecko.com).
Based on the `granularity` parameter, the rewards can be aggregated on a weekly (`week`) or daily (`day`) basis.
# Get rewards by Eigenpod.
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/rewards/get-rewards-by-eigenpod
get /v1/eigenlayer/eigenpods/{eigenpod_address}/rewards
Returns the rewards of an Eigenpod with specified granularity (day or week)
Using this endpoint, you can query it using the [eigenpod address](https://api-docs.rated.network/rated-api/glossary/eigenlayer/delegations#eigenpod_address) and you will see the particular rewards related to that eigenpod, broken down per token. It gives the amount per token, the date when they were distributed (`date`), and the date when they are claimable (`activatedAt` given in milliseconds). The ETH and USD prices of the token are also given based on the day when the rewards are claimable. Pricing data is provided by [Coingecko](https://www.coingecko.com).
Based on the `granularity` parameter, the rewards can be aggregated on a weekly (`week`) or daily (`day`) basis.
# Get rewards by Operator.
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/rewards/get-rewards-by-operator
get /v1/eigenlayer/entities/{operator_address}/rewards
Returns the rewards of an Operator with specified granularity (day or week)
Using this endpoint, you can query per eigenlayer operator using its operator address, and you will see that particular operator's rewards history, broken down per token. It gives the amount per token, the date when they were distributed (`date`), and the date when they are claimable (`activatedAt` given in milliseconds). The ETH and USD prices of the token are also given based on the day when the rewards are claimable. Pricing data is provided by [Coingecko](https://www.coingecko.com).
Based on the `granularity` parameter, the rewards can be aggregated on a weekly (`week`) or daily (`day`) basis.
# Rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/eigenlayer/rewards/rewards
A series of endpoints that drill down on rewards metrics for both entities (operators), delegators, and eigenpods.
## Entity Rewards
This entity rewards endpoint give you a breakdown of all rewards earned by an entity over a specified time period across all networks that they are involved in, broken down per token.
### Get rewards by Operator
### Get rewards by Delegator
### Get rewards by Eigenpod
# Get network rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/polkadot/rewards/get-network-rewards-metrics
get /v1/polkadot/network/rewards
This endpoint returns the historical rewards earned by the network.
Using this endpoint, you can query the historical daily rewards at the network-level for a specific day. In terms of timing, we align these rewards according to when these rewards were claimed by validators and nominators.
# Get validator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/polkadot/rewards/get-validator-rewards-metrics
get /v1/polkadot/validators/{validator_address}/rewards
This endpoint returns the historical rewards earned by a single validator.
Using this endpoint, you can query the historical daily rewards of a validator by their unique `stashAccountAddress`, which is the address that manages the staking operations of a validator. The rewards are denominated in DOT and are attributed to a specific day when rewards were claimed.
# Rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/polkadot/rewards/rewards
A series of endpoints that drill down on rewards related metrics for validators and the network on the Polkadot relay chain.
Historical rewards are available from November 1, 2024.
Only the top 500 validators (by stake weight) are considered active on Polkadot. As such, these are the only ones we track on a per-era basis.
## Validator Rewards
### Rewarded Duties
In Polkadot, time is mainly referenced through *eras* which are 24 hours each. These eras are subdivided into *sessions*, lasting 4 hours each. A session refers to a specific period of time where a fixed set of validators are active, meaning they can only join or leave the validator set at the transition between sessions. In a session, a particular group of validators are responsible for producing *blocks*. Blocks can be produced per *slot* although some slots can be empty with no block. In Polkadot, each slot is 6 seconds (*See* [*here*](https://wiki.polkadot.network/docs/maintain-polkadot-parameters) *for more information*).
Validators in Polkadot are expected to produce and propose blocks, be online in every session, and to actually participate in consensus in said session. End-users who wish to have their transactions prioritized for inclusion can send tips directly to validators. Each of these duties per era are rewarded in points which form the basis of the rewards distributed to each validator, denominated in DOT.
## Calculation and Timing
All of the rewards mentioned are calculated on a per era basis (every 24 hours), and validators and nominators (delegators) have 84 days to claim these rewards. Specifically, staking rewards that are meant to be received by nominators are to be directly claimed by the latter; these do not go to the validator first and then distributed after. In our rewards endpoints, we are tracking when these actual claims are made. This means that rewards for a certain day are based on what amount of rewards were claimed on that particular day.
## Network Rewards
This network rewards endpoint gives you a breakdown of all rewards received by validators and their respective nominators over a specified period of time.
# Get various metadata about validators
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/metadata/get-validator-metadata
get /v1/polygon/validators/{validator_id}/metadata
This endpoint returns various metadata for a specific validator.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
# Metadata
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/metadata/metadata
Get detailed metadata information about Polygon validators.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
## Validator Metadata
The validator metadata endpoint provides detailed information about specific validators on the Polygon network, including their configuration, status, and other relevant metadata.
### Get Validator Metadata
# Get Network Overview
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/overview/get-network-overview
get /v1/polygon/network/overview
This endpoint returns network-wide overview metrics for Polygon.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
# Get delegator state metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/performance/get-delegator-state
get /v1/polygon/delegators/{delegator_address}/state
This endpoint returns state metrics including stake information for a specific delegator.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
# Get validator performance metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/performance/get-validator-performance
get /v1/polygon/validators/{validator_id}/performance
This endpoint returns performance metrics (signing rates, proposal rates) for a specific validator.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
# Get validator state metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/performance/get-validator-state
get /v1/polygon/validators/{validator_id}/state
This endpoint returns state metrics including stake information for a specific validator.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
# Performance
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/performance/performance
Get performance metrics and state information for Polygon validators.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
## Validator Performance
The performance endpoints provide detailed metrics about validator performance on the Polygon network.
### Get Validator Performance
## Validator State
The state endpoints provide current state information for validators on the Polygon network.
### Get Validator State
## Delegator State
The delegator state endpoint provides information about delegators' current state on the Polygon network.
### Get Delegator State
# Get delegator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/rewards/get-delegator-rewards
get /v1/polygon/delegators/{delegator_address}/rewards
This endpoint returns rewards metrics for a specific delegator.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
# Get validator rewards metrics
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/rewards/get-validator-rewards
get /v1/polygon/validators/{validator_id}/rewards
This endpoint returns rewards metrics for a specific validator.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
# Rewards
Source: https://docs.rated.network/rated-api/api-reference/v1/polygon/rewards/rewards
Get rewards information for Polygon validators and delegators.
Polygon on the Rated API is under maintenance
Please check our [changelog](/changelog#july-8%2C-2025) for the latest updates.
## Validator Rewards
The validator rewards endpoint provides information about rewards earned by validators on the Polygon network.
### Get Validator Rewards
## Delegator Rewards
The delegator rewards endpoint provides information about rewards earned by delegators on the Polygon network.
### Get Delegator Rewards
# Authentication
Source: https://docs.rated.network/rated-api/authentication
Rated uses API keys that represent bearer tokens to access API endpoints. These API keys can be generated via [console.rated.network](https://console.rated.network/).
The API keys are added as an `Authorization` key in the API request headers with the value `Bearer `
Your API keys carry many privileges, so be sure to keep them secure!
Do not share your secret API keys in publicly accessible areas such as GitHub, client-side code, and so forth.
All API requests must be made over [HTTPS](http://en.wikipedia.org/wiki/HTTP_Secure).
Calls made over plain HTTP will fail. API requests without authentication will also fail.
```sh curl theme={null}
#Authenticated Request
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/operators/Kiln/effectiveness?idType=nodeOperator&granularity=day&from=2023-08-31&size=31&filterType=datetime&include=sumEarnings&include=day&include=sumEstimatedRewards&include=sumEstimatedPenalties&include=sumPriorityFees&include=sumBaselineMev&include=sumMissedExecutionRewards&include=sumConsensusBlockRewards&include=sumMissedConsensusBlockRewards&include=sumAttestationRewards&include=sumAllRewards&include=sumMissedAttestationRewards&include=sumMissedAttestationPenalties&include=sumWrongTargetPenalties&include=sumLateTargetPenalties&include=sumWrongHeadPenalties&include=sumLateSourcePenalties' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
```
```python python theme={null}
import requests
url = "https://api.rated.network/v0/eth/operators/Coinbase/effectiveness"
params = {
"idType": "nodeOperator",
"granularity": "day",
"from": "2023-08-31",
"size": 31,
"filterType": "datetime",
"include": [
"sumEarnings", "day", "sumEstimatedRewards", "sumEstimatedPenalties",
"sumPriorityFees", "sumBaselineMev", "sumMissedExecutionRewards",
"sumConsensusBlockRewards", "sumMissedConsensusBlockRewards",
"sumAttestationRewards", "sumAllRewards", "sumMissedAttestationRewards",
"sumMissedAttestationPenalties", "sumWrongTargetPenalties",
"sumLateTargetPenalties", "sumWrongHeadPenalties", "sumLateSourcePenalties"
]
}
#Authenticated Request
headers = {
"Content-Type": "application/json",
"X-Rated-Network": "mainnet",
"Authorization": "Bearer "
}
response = requests.get(url, params=params, headers=headers)
data = response.json()
```
# Errors summary
Source: https://docs.rated.network/rated-api/errors/errors
Semantics around error messages that you might stumble upon when working with the Rated API.
Rated API utilizes standard HTTP response codes to communicate the outcome of an API request. It is essential to note that:
* Response codes in the 2xx range signify successful execution of the request.
* Response codes in the 4xx range indicate a client-side error, arising from insufficient or incorrect information provided (e.g., missing required parameters, invalid values types, etc.).
* Response codes in the 5xx range signify a server-side error, indicative of an issue with Rated's servers. These are uncommon.
| HTTP Code | Description |
| :------------------------------------------- | :------------------------------------------------------------------------------------------------ |
| **200** Ok | Everything worked as expected. |
| **400** Bad Request | The request was unacceptable, often due to a missing required parameter or an invalid value type. |
| **401** Unauthorized | No valid bearer token provided. |
| **403** Forbidden | The bearer token doesn't have permissions to perform the request. |
| **404** Not Found | The requested resource doesn't exist. |
| **429** Too Many Requests | The number of requests to the Rated API is too high. Back-off and try again later. |
| **500, 502, 503** Server Errors | Something failed on our servers. |
# Handling errors
Source: https://docs.rated.network/rated-api/errors/handling-errors
Catch and respond to invalid requests, authentication issues and more.
When using our API, it is crucial to anticipate and handle errors effectively.
To aid in this process, our API utilizes a standardized format for returning error messages.
These error responses provide detailed information on the nature of the error, by adhering to this format, developers can easily identify and resolve issues when they arise, improving the overall reliability and efficiency of the API integration.
## Errors in responses
Rated API's errors will always be returned as JSON
Errors will always come in a dictionary containing a `detail` key and its value can be either a list of dictionaries or a string describing the error message.
### 400 Bad Request
```json Wrong body theme={null}
{
"detail": [
{
"loc": ["body", "email"],
"msg": "value is not a valid email address",
"type": "value_error.email",
}
]
}
```
```json Wrong query parameters theme={null}
{
"detail": [
{
"loc": [
"query",
"pubkeys",
0
],
"msg": "Invalid public key",
"type": "value_error"
}
]
}
```
### 401 Unauthorized
```json theme={null}
{"detail": "Not authenticated"}
```
**Reason:** You forgot to send the `Authorization` header with a `Bearer` token.
```json theme={null}
{"detail": "Could not validate access token."}
```
**Reason:** The token you are using is not from us. You need to get and use valid token.
```json theme={null}
{"detail": "Expired token."}
```
**Reason:** Self-explanatory, you need to get a new token at [console.rated.network/apiKeys](https://console.rated.network/apiKeys).
```json theme={null}
{"detail": "Unknown token."}
```
**Reason:** The token might be valid before but we don't know it anymore. Most likely, it was invalidated after a password reset.
### 403 Forbidden
```json theme={null}
{"detail": "You don't have permission to do that."}
```
**Reason:** The token you are using does not have enough permission to perform the request.
### 404 Not Found
```json theme={null}
{"detail": "Not found."}
```
**Reason:** The resource you requested was not found. Double check the [API Reference](/rated-api/api-reference/introduction).
### 429 Too many requests
```json theme={null}
{"detail": "Too many requests"}
```
**Reason:** You have hit too quick too many times the API. Back-off and retry later.
### 500, 502, 504 Server errors
```json theme={null}
{"detail": "Internal server error."}
```
**Reason:** Something went wrong on our side, these are rare. In case you need assistance contact us and provide the [Request ID](/rated-api/interacting-with-api/request-ids) and we will gladly help you.
# Networks supported
Source: https://docs.rated.network/rated-api/getting-started/networks-supported
A list of networks that you can access with the Rated API.
## Testnets
The API is functional on Ethereum Mainnet and Hoodi under the same schema. All you need to do to access each, is specify `X-Rated-Network` in the query structure as `mainnet` or `hoodi`.
# Welcome
Source: https://docs.rated.network/rated-api/getting-started/welcome
Context around the state of the Rated API, as well as prompts to useful resources regarding the Rated API.
To access Rated APIs, head on over to [console.rated.network](https://console.rated.network)
[Rated Python SDK](https://github.com/rated-network/rated-python) is now available to help fastrack your integration with the Rated APIs!
## Background
Blockchain infrastructure data is hard to parse and contextualise, yet of increasingly vital importance to the well functioning of the broader ecosystem. The Rated API has been designed to make accessing this wealth of data and building on top of it, easy as pie.
The Rated API has been live since July 2022, and is currently adopted for rewards tracking, performance monitoring and benchmarking, as well as a source of truth, by the likes of Lido, Metamask, Kiln, Chorus One, Stakefish, Obol, Nexus Mutual and an additional 30+ regular enterprise users. 🥳
Deploy precise accounting in a few simple calls, with granular tracking of validator rewards earned.
Accurately track, improve and benchmark your current and historical validator fleet performance.
Help users make informed decisions around staking with access to rich metadata about an operator's useful life.
## What the Rated API can do for you
We've built the Rated API to be the most powerful and flexible way out there, to work with infrastructure layer data. With it we serve pools, node operators and referential applications that leverage staking layer data to build delegation, index, insurance, credit and other financial products.
Here's some of the most common ways we see the Rated API being used:
Generalised validator active set management, granular rewards accounting, performance benchmarking, deciding levels and enforcing SLAs, monitoring and benchmarking, powering interfaces for constituents.
Rewards accounting, performance benchmarking, redundancy layer for internal monitoring, powering and/or enhancing owned user interfaces.
Powering interfaces for delegation products, rewards accounting, pricing insurance and credit, powering information products.
Downstream integrators growing to love the Rated API, as besides being a precise, unbiased and easily accessible source of truth (e.g. see [Stakefish v Lido](https://research.lido.fi/t/reimbursement-for-stakefish-2023-02-17-ethereum-incident/4034)), it enables integrators to do things like aggregate validator indices on the fly, get answers about when withdrawals are about to land in their wallet, and pre-materialize validator sets for easy access to all the granular data that Rated offers.
## How to navigate the Rated API documentation
This documentation hub aims to be your trusty resource to getting up to speed with all you need to know to make the most out of using the Rated API.
In this hub, you will find information about:
* Common [Errors](/rated-api/interacting-with-api/errors) and how to handle those
* How [Pagination (v1)](/rated-api/interacting-with-api/v1/pagination) works
* Full [API reference](/rated-api/api-reference/introduction) together with explainers on each of the main pillars of the schema
* A [Glossary](/rated-api/glossary/) with definitions and context on all the variables that the Rated API returns
* Details on the different Pricing [Plans](/rated-api/pricing/plans) available for the Rated API
Let's dive in!
## At a glance
A detailed breakdown of the full set of functionality the Rated API offers.
Embed the Rated API in your Prometheus and Grafana environments.
Information on the main consumption metric for API requests
# Network
Source: https://docs.rated.network/rated-api/glossary/avalanche/network
Glossary of terms found under /network
The count of actively validating validators for a particular day.
Total rewards received by delegators for their stake.
Maximum rewards that can be received by delegators for their stake based on 100% validator uptime.
Maximum rewards that can be received by validators for their own stake based on 100% validator uptime.
Total rewards received by validators for their own stake.
Total fees received by validators as their cut/commission from delegator rewards.
# Validators
Source: https://docs.rated.network/rated-api/glossary/avalanche/validators
Glossary of terms found under /validators
The unique identifier for a validator in a particular network.
Total rewards received by delegators for their stake.
Maximum rewards that can be received by delegators for their stake based on 100% validator uptime.
Maximum rewards that can be received by a validator for their own stake based on 100% uptime.
Maximum rewards that can be received by a validator as their cut/commission from delegator rewards based on 100% uptime.
Total rewards received by a validator for their own stake.
Total fees received by a validator as their cut/commission from delegator rewards.
The timestamp of the beginning of a validator's validation period as set by them.
The timestamp of the end of a validator's validation period as set by them.
The status of a validator, whether active(actively validating) or inactive (not actively validating).
A validator's public key. Also a unique identifier of a validator.
# BTC Delegators
Source: https://docs.rated.network/rated-api/glossary/babylon/btc-delegators
Glossary of terms found under /btcDelegators
The amount of stake in BTC that is actively staked by a a delegator to a finality provider/s.
The address of the delegator on the Babylon Genesis Chain.
The Bitcoin address of the delegator.
The Bitcoin public key address of the delegator.
The rewards which delegators are entitled to receive from the finality provider they have staked to.
The Babylon Genesis address of the finality provider to which the delegator is staked to.
The Bitcoin address of the finality provider to which the delegator is staked to.
The Bitcoin public key address of the finality provider to which the delegator is staked to.
The token which the rewards are denominated by.
# Delegators
Source: https://docs.rated.network/rated-api/glossary/babylon/delegators
Glossary of terms found under /delegators
The amount of stake in the network's native token that is actively staked by a a delegator to a validator/s.
The address of the delegator.
The rewards which delegators are entitled to receive from the validator they have staked to.
The address of the validator to which the delegator is staked to.
# Finality Providers
Source: https://docs.rated.network/rated-api/glossary/babylon/finality-providers
Glossary of terms found under /finalityProviders
The amount of stake in BTC that is actively staked to a validator.
The unique address on the Bitcoin chain of a finality provider.
The unique public key on the Bitcoin chain of a finality provider.
The commission rate charged by the finality provider to its stakers/delegators on the rewards the former generates from its duties.
The unique address of a finality provider on the Babylon Genesis chain.
The name of the entity running the finality provider.
The token which the rewards are denominated by.
The rewards from the commission a finality provider charges.
The rewards which delegators are entitled to receive from the finality provider they have staked to.
The number of delegators that are staked to a finality provider.
# Network
Source: https://docs.rated.network/rated-api/glossary/babylon/network
Glossary of terms found under /network
The average commission rate charged by all bonded validators to their respective stakers/delegators on the rewards generated from validator duties.
These are validators who have sufficient staked/bonded tokens to be part of the network's active set
The rewards from the commissions validators charge.
The rewards which delegators are entitled to receive from the validators they have staked to. This includes rewards toward the validators themselves if they have self-staked/self-bonded.
# Validators
Source: https://docs.rated.network/rated-api/glossary/babylon/validators
Glossary of terms found under /validators
The amount of stake in the network's native token that is actively staked to a validator.
The commission rate charged by the validator to its stakers/delegators on the rewards the former generates from validator duties.
The rewards from the commission a validator charges.
The rewards which delegators are entitled to receive from the validator they have staked to. This includes rewards toward the validator itself if they have self-staked/self-bonded.
The number of delegators that are staked to a validator.
The unique address of a validator.
The name of the entity running the validator.
# Network
Source: https://docs.rated.network/rated-api/glossary/cardano/network
Glossary of terms found under /network
The average pool fee or rewards commission rate that stake pools/validators charge at a network level to their delegators.
The average flat fee, denominated in ADA, that stake pools/validators charge to their delegators for staking with them.
The number of stake pools/validators that are active.
The total rewards earned by stake pool members/delegators. These are not yet distributed to said delegators.
The total rewards earned by stake pool leaders/validators. These are not yet distributed to said validators.
The total rewards that were received/distributed to stake pool members/delegators.
The total rewards that were received/distributed to stake pool leaders/validators.
# Validators
Source: https://docs.rated.network/rated-api/glossary/cardano/validators
Glossary of terms found under /validators
The pool fee or rewards commission rate that a stake pool/validator charges their members/delegators.
The flat fee, denominated in ADA, that a stake pool/validator charges to their delegators for staking with them.
The hashed address of the stake pool/validator.
The unique identifier of a stake pool/validator.
The name of a stake pool/validator.
The staking address of the owner of the stake pool/validator.
A short-form identifier/name of a stake pool/validator.
The total rewards earned by a specific stake pool's members/delegators. These are not yet distributed to said delegators.
The total rewards earned by a specific stake pool's leader/validator. These are not yet distributed to said validator.
The total rewards that were received/distributed to a specific stake pool's members/delegators.
The total rewards that were received/distributed to a specific stake pool's leader/validator.
# Network
Source: https://docs.rated.network/rated-api/glossary/celestia/network
Glossary of terms found under /network
The average commission rate charged by all bonded validators to their respective stakers/delegators on the rewards generated from validator duties.
These are validators who have sufficient staked/bonded tokens to be part of the network's active set
The rewards from the commissions validators charge.
The rewards which delegators are entitled to receive from the validators they have staked to. This includes rewards toward the validators themselves if they have self-staked/self-bonded.
# Validators
Source: https://docs.rated.network/rated-api/glossary/celestia/validators
Glossary of terms found under /validators
The commission rate charged by the validator to its stakers/delegators on the rewards the former generates from validator duties.
The rewards from the commission a validator charges.
The rewards which delegators are entitled to receive from the validator they have staked to. This includes rewards toward the validator itself if they have self-staked/self-bonded.
The unique address of a validator.
The name of the entity running the validator.
# Network
Source: https://docs.rated.network/rated-api/glossary/cosmos/network
Glossary of terms found under /network
The average commission rate charged by all bonded validators to their respective stakers/delegators on the rewards generated from validator duties.
The rewards from the commissions validators charge.
The rewards which delegators are entitled to receive from the validators they have staked to. This includes rewards toward the validators themselves if they have self-staked/self-bonded.
# Validators
Source: https://docs.rated.network/rated-api/glossary/cosmos/validators
Glossary of terms found under /validators
The commission rate charged by the validator to its stakers/delegators on the rewards the former generates from validator duties.
The rewards from the commission a validator charges.
The rewards which delegators are entitled to receive from the validator they have staked to. This includes rewards toward the validator itself if they have self-staked/self-bonded.
The unique address of a validator.
The name of the entity running the validator.
# Delegations
Source: https://docs.rated.network/rated-api/glossary/eigenlayer/delegations
Glossary of terms found under /delegations
An Ethereum address that uniquely identifies an Eigenlayer delegator.
Natively restaking on Eigenlayer requires one to set up an eigenpod which is the smart contract that a validator's withdrawal address points to (i.e. withdrawn staked ETH gets sent to the eigenpod). `eigenpodAddress` is the address of that smart contract.
An Ethereum address controlled by an Eigenlayer node operator which is used to interact with the Eigenlayer ecosystem (e.g. receiving delegations from delegators).
# Rewards
Source: https://docs.rated.network/rated-api/glossary/eigenlayer/rewards
Glossary of terms found under /rewards
The timestamp in milliseconds when the rewards are claimable.
Date when the rewards were distributed.
An Ethereum address that uniquely identifies an Eigenlayer delegator.
Natively restaking on Eigenlayer requires one to set up an eigenpod which is the smart contract that a validator's withdrawal address points to (i.e. withdrawn staked ETH gets sent to the eigenpod). `eigenpodAddress` is the address of that smart contract.
This is the timestamp in milliseconds when Eigenlayer takes a snapshot of the rewards.
# State
Source: https://docs.rated.network/rated-api/glossary/eigenlayer/state
Glossary of terms found under /state. Refers to stake state
The address of the specific eigenpod.
The address of the operator.
The name set/given by the operator for itself.
The address of the creator and owner of the Eigenpod.
The amount of Ether that is recognized by Eigenlayer as natively restaked in wei.
A strategy that a user has chosen for restaking. This is the contract address of the LST-specific vault for restaking
The contract address of the underlying ERC20 token used in a restaking strategy.
The total underlying token balance for a user within a strategy.
The total number of shares for a user within a strategy.
# Blocks
Source: https://docs.rated.network/rated-api/glossary/ethereum/blocks
Glossary of terms found under /blocks
The base fees paid to the network (i.e. burnt) per gas unit.
This metric is in wei.
The minimum MEV rewards calculated in the block, outside of any `priorityFees`. Read more about the calculation methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/baseline-mev-computation).
These are the public keys of the builder that built a particular block.
The timestamp of when the block was recorded on based on the genesis of the chain.
The hash indicating the specific consensus slot.
Indicates whether a proposer proposed a Consensus Layer slot (`proposed`) or missed a proposal (`missed`).
These are the proposal rewards from the Ethereum Consensus Layer (Beacon Chain).
The slot number in the Ethereum Consensus Layer (Beacon Chain).
The epoch number of a particular slot. Each epoch has 32 slots.
The hash indicating the specific execution block.
The block number in the Ethereum Execution Layer
Indicates whether a proposer proposed a block that contains transactions (proposed), a block with no transactions (empty), or completely missed a proposal (missed).
The rewards from the Ethereum Execution Layer.
This is the sum of `totalPriorityFeesValidator` and `baselineMev`.
The address that received the block rewards on the Ethereum Execution Layer.
The Consensus Layer rewards missed by a validator for not being able to propose a slot. Read more about how this is estimated [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation/consensus-missed-rewards-computation#consensus-missed-proposal-rewards).
The Execution Layer rewards missed by a validator for not being able to propose a block or by proposing an empty block. Read more about how this is estimated [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation/execution-missed-rewards-computation).
The mev-boost relays where a particular block was sourced from.
The gas fees burnt for the set of transactions in the particular block.
This metric is in wei.
The gas units used by the set of transactions in the particular block.
The transaction fees paid by the end-user to the block's `feeRecipient`.
The portion of the `totalPriorityFees` that were paid to the validator that proposed the block. Given that the `feeRecipient` of a block can be the builder (as opposed to the proposer itself), it is up to the builder how much they pay to the validator in terms of the priority fees the former captured from building the block.
The sum of `consensusRewards` and `executionRewards`.
The sum of `missedConsensusRewards` and `missedExecutionRewards`.
The count of transactions that involve one or more addresses (i.e. in `to` and `from` addresses) that are in any sanctions lists by government bodies.
The total count of transactions in the particular block.
The count of type0 transactions.
Type0 Ethereum transactions are legacy transactions; this was the main transaction type before the [EIP-1559 upgrade](https://eips.ethereum.org/EIPS/eip-1559). Despite being referred to as "legacy", these are still in use after the upgrade.
The transaction fees generated by `type0Transactions`.
This metric is in wei.
The count of type1 transactions.
Type1 transactions are transactions that contain an access list, which is a list of addresses and storage keys that the transactions plan to access.
The transaction fees generated by `type1Transactions`.
This metric is in wei.
The count of type2 transactions.
Type2 Ethereum transactions were introduced with the [EIP-1559 upgrade](https://eips.ethereum.org/EIPS/eip-1559).
The transaction fees generated by `type2Transactions` less any `burntFees`.
The index of the validator assigned to propose for that particular slot/block.
# Effectiveness
Source: https://docs.rated.network/rated-api/glossary/ethereum/effectiveness
Glossary of terms found under /effectiveness
The aggregate attester effectiveness over the requested time period, that applies to said entity. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating/raver-v3.0-current#attester-effectiveness).
The average inclusion delay over the requested time period, that applies to said entity. Read more about the methodology [here](https://docs.rated.network/documentation/explorer/ethereum/network-views/pools-operators-and-validators/entity-metrics-drill-down#inclusion-delay).
Net consensus rewards for the day that apply to said entity (i.e. net of penalties). This is a validator balance difference between the last epoch in the day and the last epoch in the previous day.
Gross estimated protocol penalties accrued that apply to said entity.
Estimated gross validator consensus rewards that apply to said entity. Those are protocol rewards without protocol penalties accrued accounted for.
The number of empty blocks that said enitity has proposed.
The number of successful block proposals that said entity has been party to.
The number of block slots that said entity has been awarded. proposerDutiesCount minus proposedCount should give you the number of blocks missed by said entity.
The aggregate proposer effectiveness over the requested time period, that applies to said entity. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating).
The number of times said entity has been slashed.
All net consensus (i.e. rewards less penalties) and execution rewards, that apply to said entity. This should be the reflection of the net gain (or loss) a validator has recorded the period in question.
All aggregated attestation rewards, that apply to said entity. This includes rewards from sync committee duties/attestations
Our attempt to separate MEV from priority fees, for blocks procured from MEV Relays by said entity. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/baseline-mev-computation).
Consensus rewards earned by said index for successfully producing a block.
The number of correct head votes found in said index's attestations.
The number of correct target votes found in said index's attestations.
The sum of `sumPriorityFees` and `sumBaselineMev` from blocks proposed by said index that were sourced from mev-boost/MEV relays (i.e. blocks not built by the index itself).
The total inclusion delay for a period. Useful when computing the average inclusion delay of arbitrary periods.
The sum of all late source penalties for the period, that apply to said index.
Penalties for late target vote penalties, that apply to said index.
All penalties accrued for missed attestations, that apply to said index.
Estimated missed rewards in cases of missed attestations, that apply to said index. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation).
Estimated value of missed consensus block rewards in cases of missed block proposals, that apply to said index. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation).
Estimated execution rewards in case the validator missed a block proposal that apply to said index. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation).
Estimated missed rewards in cases of missed sync committee signatures, that apply to said index. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation).
Priority fees accrued from succesfully producing blocks that apply to said index.
Penalties for missed sync committee signatures, that apply to said index.
Rewards for fulfilled sync committee duties/signatures, that apply to said index.
Wrong head penalties, that apply to said index. Only applicable pre-Altair.
Penalties for wrong target vote penalties, that apply to said index.
The total number attestation slots the pubkeys that map back to said index have been awarded attestation duties.
The total number of attestations included in blocks. Note: an attestation can be included multiple times.
The total number of unique attestations.
The average uptime (or participation rate) over the requested time period, that applies to said index. Read more about the methodology [here](https://docs.rated.network/network-explorer/entity-views/entity-metrics-drill-down#participation-rate).
The aggregate validator effectiveness over the requested time period, that applies to said index. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating).
# Network
Source: https://docs.rated.network/rated-api/glossary/ethereum/network
Glossary of terms found under /network and /eth
The aggregate attestation correctness across all active validators in the network.
The aggregate inclusion delay across all active validators in the network.
The aggregate participation rate across all active validators in the network.
The aggregate validator effectiveness across all active validators in the network.
The amount of stake consolidated in a given time period.
The percentage (in decimal form) of the consolidation churn capacity that has been used up by consolidations during a given time period.
The consolidated stake amount over a given period divided by the total active stake.
The number of validators consolidated in a given time period.
The amount of stake that can be consolidated in a given time period.
The percentage (in decimal form) of the churn limit that is yet to be consumed.
# Operators
Source: https://docs.rated.network/rated-api/glossary/ethereum/operators
Glossary of terms found under /operators
The active stake of validators that map back to said entity. This is the denominator in APR%
The number of active validator pubkeys that map to said entity.
The APR% calculation type in question. At the moment Rated only supports backward looking APR%. Read more about the methodology that underlies it [here](https://docs.rated.network/documentation/methodologies/ethereum/backward-looking-apr).
The consensus client distribution of a given entity.
The sum of the validator balances being consolidated by an entity.
The count of validators being consolidated by an entity.
The percentage of overall network stake that said entity maps to.
The parent entity or entities that said index maps back to.
The actual APR% value.
The proportion of APR% attributed to consensus rewards.
The proportion of APR% attributed to execution rewards.
The distribution of post-merge block space of a given entity. This tracks which MEV Relays said entity is procuring blocks from, on part with how many blocks are locally built.
The entity related to the validator being consolidated.
The entity type of the entity related to the validator being consolidated.
The quality tag that maps back to said index. Read more about tags [here](https://mirror.xyz/ratedw3b.eth/f8TLAnN1e9kboHiPoctsNplGTD77EH6LXw9ymJV3Axc).
The number of validator keys that map to said index.
# Pool shares
Source: https://docs.rated.network/rated-api/glossary/ethereum/pool-shares
Glossary of terms found under /pool-shares
coming 🔜
```
██╗░░░██╗███╗░░██╗██████╗░███████╗██████╗░
██║░░░██║████╗░██║██╔══██╗██╔════╝██╔══██╗
██║░░░██║██╔██╗██║██║░░██║█████╗░░██████╔╝
██║░░░██║██║╚████║██║░░██║██╔══╝░░██╔══██╗
╚██████╔╝██║░╚███║██████╔╝███████╗██║░░██║
░╚═════╝░╚═╝░░╚══╝╚═════╝░╚══════╝╚═╝░░╚═╝
░█████╗░░█████╗░███╗░░██╗░██████╗████████╗██████╗░██╗░░░██╗░█████╗░████████╗██╗░█████╗░███╗░░██╗
██╔══██╗██╔══██╗████╗░██║██╔════╝╚══██╔══╝██╔══██╗██║░░░██║██╔══██╗╚══██╔══╝██║██╔══██╗
██║░░╚═╝██║░░██║██╔██╗██║╚█████╗░░░░██║░░░██████╔╝██║░░░██║██║░░╚═╝░░░██║░░░██║██║░░
██║░░██╗██║░░██║██║╚████║░╚═══██╗░░░██║░░░██╔══██╗██║░░░██║██║░░██╗░░░██
╚█████╔╝╚█████╔╝██║░╚███║██████╔╝░░░██║░░░██║░░██║╚██████╔╝╚█████╔╝░
░╚════╝░░╚════╝░╚═╝░░╚══╝╚═════╝░░░░╚═╝░░░╚═╝░░╚═╝░╚═════╝░░╚══
```
# Validators
Source: https://docs.rated.network/rated-api/glossary/ethereum/validators
Glossary of terms found under /validators
The balance being transferred from the source validator to the target validator during consolidation.
The epoch where the validator was consolidated (`source_validator_index` to `target_validator_index`).
The DVT network that said index maps to.
List of operators under a validator index. Note: only applicable in Obol or SSV DVT clusters.
The node operator that said index maps to.
The pool that said index maps to.
The entity related to the validator being consolidated.
The entity type of the entity related to the validator being consolidated.
The validator being consolidated.
The balance of the target validator before receiving the balance of the validator being consolidated.
The balance of the target validator after receiving the consolidated balance of the source validator. It is the balance of the target validator after the consolidation and the epoch itself have been processed.
The effective balance of the target validator after receiving the consolidated balance of the source validator. It is the effective balance of the target validator after the consolidation and the epoch itself have been processed.
The entity related to the target validator; validator receiving the balance of the validator being consolidated.
The entity type of the entity related to the target validator.
The validator receiving the balance of the validator being consolidated.
# Withdrawals
Source: https://docs.rated.network/rated-api/glossary/ethereum/withdrawals
Glossary of terms found under /withdrawals
The withdrawn amount in gwei units.
The index of the specific withdrawal across all withdrawals in a particular slot.
The address where withdrawn ETH is sent to.
The index of the specific withdrawal across all withdrawals.
# Network
Source: https://docs.rated.network/rated-api/glossary/polkadot/network
Glossary of terms found under /network
The total active validators on a given day.
The total rewards claimed/received by nominators (delegators/stakers).
The total nominators (delegators/stakers) on a given day.
The total rewards claimed/received by validators.
# Validators
Source: https://docs.rated.network/rated-api/glossary/polkadot/validators
Glossary of terms found under /validators
The total number of nominators (delegators) that are staked to a validator.
The amount staked by a validator to itself (self-stake).
The address attributable to a validator that controls the staking operations.
The total rewards claimed/received by nominators (delegators/stakers) attributed to a validator based on the former's stake weight.
The total stake attributable to a validator.
The total rewards claimed/received by a validator.
The name of a validator primarily based on the supplied metadata for a validator. If no name is available, this is generated based on the first six characters of a validator's stash account address.
# Delegators
Source: https://docs.rated.network/rated-api/glossary/polygon/delegators
Glossary of terms found under /delegators
The address of a delegator.
The amount of stake delegated by a delegator
The id of the validator that a delegator is delegated to.
The amount of rewards missed by a delegator due to their delegated validator's underperformance.
The amount of rewards received by a delegator.
# Network
Source: https://docs.rated.network/rated-api/glossary/polygon/network
Glossary of terms found under /network
The count of active delegators in the network.
The difference between the current number of active delegators and from the last time period based on the time window.
The count of active validators in the network.
The difference between the current number of active validators and from the last time period based on the time window.
The amount of stake delegated by an average delegator.
The average number of validators a delegator has delegated their stake to.
The network aggregate rate being paid by delegators on the rewards they earn to their delegate validators based on latter's stake weight.
The annual percentage rate (APR) apportioned to Bor proposal rewards.
The ratio of rewards attributable to Bor block proposals.
The aggregate annual percentage rate (APR) of delegators in the network. For more information, see here.
The annual percentage rate (APR) apportioned to Heimdall checkpoint rewards, both signing and proposals.
The ratio of rewards attributable to Heimdall checkpoint duties, both signing and proposals.
The aggregate annual percentage rate (APR) of all validators after distributing rewards to their delegators. For more information, see here.
The percentage of Bor proposal duties across all validators that were successful.
The percentage of checkpoint proposal duties across all validators that were successful.
The percentage of checkpoint signing duties across all validators that were successful.
The aggregate effectiveness over the requested time period. Read more about the methodology here.
The MEV (maximum extractable value) rewards from the Bor chain. This is from data mainly sourced from [Fastlane](https://www.fastlane.finance/) and [Marlin](https://explore.marlin.org/#/).
The transaction priority fees received by validators from proposing blocks on the Bor chain.
The rewards from checkpoint proposals.
The rewards from signing checkpoints
The total amount of delegated stake in the network.
The total amount of stake that is staked by validators themselves.
The total amount of stake in the network.
The aggregate annual percentage rate (APR) of all validators before distributing rewards to their delegators. For more information, see here.
# Validators
Source: https://docs.rated.network/rated-api/glossary/polygon/validators
Glossary of terms found under /validators
The number of block proposal duties a validator assigned in the Bor chain (i.e. chain where Polygon PoS end-user transactions are processed).
The percentage of Bor proposal duties across by a validator that were successful.
The number of Bor blocks successfully proposed by a validator.
The number of checkpoint proposal duties assigned to a validator.
The percentage of checkpoint proposal duties by a validator that were successful.
The rewards received by a validator from the protocol for their successful checkpoint proposals.
The number of checkpoints successfully proposed by a validator.
The number of checkpoint signing duties a validator has been assigned. Said differently, this the number of checkpoints a validator is tasked to attest to.
The rewards from successfully signing checkpoints.
The number of checkpoints successfully signed/attested to by a validator.
The percentage of [checkpointSignatureDuties](#checkpointSignatureDuties) wherein a validator was able to successfully attest to/sign a checkpoint.
The rate charged by validators to entities that have delegated their stake to them. This is applied to the delegators' share of the commissionSignatureRewards]\(#commissionSignatureRewards).
The amount of stake delegated to a validator.
The number of delegators that have delegated their stake to a validator.
The rewards received by the delegator/s who have delegated their stake to this validator from checkpoint signings. For more information, see here.
These are the rewards that a validator distributes to its delegators before taking commissions.
The aggregate validator effectiveness over the requested time period, that applies to said validator. Read more about the methodology here.
The rewards received by this validator due to MEV (maximum extractable value). This is from data mainly sourced from [Fastlane](https://www.fastlane.finance/) and Marlin.
These are the rewards a validator missed out on (i.e. opportunity cost) from missing their checkpoint proposal duties.
These are the checkpoint signing rewards missed (i.e. opportunity cost) from failing to sign checkpoints.
These are the commissions a validator missed out on from missing checkpoint signing duties.
These are the rewards a validator's delegators missed out on due to the validator's failure to sign checkpoints.
Similar to [missedDelegatorRewards](#missedDelegatorRewards) but also includes the commissions a validator missed out on.
The rewards a validator missed out on from failing to sign checkpoints. These are checkpoint signing rewards a validator was supposedly entitled to based on the stake they have staked themselves ([selfStake](#selfStake)).
The transaction priority fees received by validators from proposing blocks on the Bor chain.
These are rewards from checkpoint signing that a validator is entitled to based on their [selfStake](#selfStake).
The amount of POL that was staked by the validator itself.
This is the amount of POL staked with this validator. This is a combination of the amount a validator has staked themselves and the stake delegated to them.
# Delegators
Source: https://docs.rated.network/rated-api/glossary/solana/delegators
Glossary of terms found under /delegators
The stake-weighted effectiveness rating of the validators being delegated to. For more information on the effectiveness rating, see [here](https://docs.rated.network/methodologies/solana/solana-validator-effectiveness-rating).
The stake-weighted MEV commission rate being charged to a delegator based on its delegated validators.
The stake-weighted voting rewards (i.e. staking rewards) commission rate being charged to a delegator based on its delegated validators.
The amount of stake delegated.
The information related to the validators a delegator has delegated to including the percentage share of the delegator's stake.
The annual percentage yield earned by a delegator. For more information see [here](https://docs.rated.network/methodologies/solana/annual-percentage-yield-apy).
The commission paid by this delegator on the MEV rewards it receives.
The MEV commission rate being charged to a delegator based on its delegated validators.
The MEV rewards received by a delegator.
The annual percentage rate earned by a delegator on the MEV rewards it receives.
The estimated staking rewards (i.e. vote rewards) missed by a delegator based on validator underperformance. Feature to follow; defaults to 0 for now.
The percentage of overall network stake the particular delegator is associated with.
The name of the staking pool
The address of the stake account.
The stake authority address.
The commission paid by a delegator on the staking rewards (i.e. vote rewards) it receives.
The staking rewards a delegator receives. Specifically these are the rewards that delegators get from the successful voting duties that validators fulfill. These rewarded by the protocol through SOL inflation.
The annual percentage yield of a delegator on the staking rewards its receives.
The status of a stake account based on whether it is active (i.e. delegated), inactive (i.e. undelegated), activating (i.e. in the process of delegating), or deactivating (i.e. in the process of undelegating).
The total commission paid by a delegator to its validator delegate/s based on the rewards the former receives.
The total rewards (staking/voting and MEV) a delegator receives.
The number of validators a delegator is currently delegating to.
The validator effectiveness over the requested time period that applies to the validator being delegated to. For more information, see [here](https://docs.rated.network/methodologies/solana/solana-validator-effectiveness-rating).
The name of the validator being delegated to.
The vote account address (i.e. unique identifier/pubkey) of the validator being delegated to.
The voting rewards (i.e. staking rewards) commission rate being charged to a delegator based on its delegated validator.
The withdraw authority address.
# Network
Source: https://docs.rated.network/rated-api/glossary/solana/network
Glossary of terms found under /network
The count of active stake accounts in the network.
The difference between the current number of active stake accounts and from the last time period based on the time window.
The count of active stake authority addresses in the network.
The difference between the current number of active stake authority addresses and from the last time period based on the time window.
The count of active withdraw authority addresses in the network.
The difference between the current number of active withdraw authority addresses and from the last time period based on the time window.
The count of active validators in the network.
The difference between the current number of active validators and from the last time period based on the time window.
The geographical city where this validator's node is located.
The geographical country where this validator's node is located.
The number of deactivating stake accounts in the network.
The aggregate annual percentage yield (APY) of delegators in the network. For more information, see [here](https://docs.rated.network/methodologies/solana/annual-percentage-yield-apy).
The network's gini coefficient. For more information, see here (link to Gini coefficient methodology for Solana).
The hosting provider/data service provider used by this validator for its infrastructure.
The median [vote latency](/rated-api/glossary/solana/validators#votelatency) across validators.
The aggregate annual percentage yield (APR) of all validators after distributing rewards to their delegators. For more information, see [here](https://docs.rated.network/methodologies/solana/annual-percentage-yield-apy).
The aggregate effectiveness over the requested time period. Read more about the methodology here (link to Solana effectiveness methodology).
The difference between the current network effectiveness and the effectiveness from the last time period based on the time window.
The percentage of block production duties missed in the network.
The percentage of voting duties that were correctly done by validators across the network.
The average voting latency across the network.
Network-wide rewards that are from maximum extractable value (MEV).
Network-wide rewards that are from block production.
Network-wide rewards that are from slot voting duties.
The ratio of stake accounts versus the number of stake authority addresses.
The ratio of stake accounts versus the number of withdraw authority addresses.
See [totalStake](/rated-api/glossary/solana/network#totalstake).
The total amount of stake in the network.
The aggregate annual percentage yield (APY) of all validators before distributing rewards to their delegators.
# Validators
Source: https://docs.rated.network/rated-api/glossary/solana/validators
Glossary of terms found under /validators
The average compute units in a block. Compute units are the measure of computational resources used by transactions.
The average amount of MEV tips in blocks produced by a validator.
The average amount of rewards in blocks produced by a validator.
The average number of transactions in a block.
The rewards a validator got from producing blocks. Comprised of the base fees and priority fees.
The geographical city where this validator's node is located.
The Solana client that this validator is running.
The geographical country where this validator's node is located.
The annual percentage yield earned by delegators that have delegated to this validator. For more information see [here](https://docs.rated.network/methodologies/solana/annual-percentage-yield-apy).
The validator effectiveness over the requested time period that applies to said validator. For more information, see [here](https://docs.rated.network/methodologies/solana/solana-validator-effectiveness-rating).
The hosting provider/data service provider used by this validator for its infrastructure.
See [voteLatency](/rated-api/glossary/solana/validators#votelatency)
The MEV rewards claimed by a validator.
The commission rate being charged by this validator to its delegators for any MEV rewards it collects under the Jito ecosystem.
The tips/fees paid to a validator for including MEV-related transactions in the blocks they produced.
See [validatorName](/rated-api/glossary/solana/validators#validatorname)
The percentage of overall network stake the particular validator is associated with.
The percent of total transactions in a block that have failed or have an error.
The percent of total transactions in a block that is above 5000 lamports (0.000005 SOL) in fees.
The number of blocks produced/proposed by this validator.
The rent paid to the validator.
The number of slots that this validator did not produce a block for when they were the designated slot leader/block producer.
The sum of all the voting latency by this validator, measured in slots.
The total stake delegated to this validator.
The total number of votes made by this validator.
The number of votes made by this validator over the number of blocks produced by the network
The annual percentage yield that this validator gets based on the rewards it has received.
This is the account that is used to pay for all vote transaction fees by the validator. This is also the public key that is used to identify a validator node in Solana's gossip network.
The entity name of the validator.
The account required to operate a validator. This account is the best way to identify a validator as it cannot be changed.
The commission rate that this validator charges its delegators for voting rewards.
The voting latency (i.e. distance between the slot they are voting for and the slot where their vote was included) of this validator, measured in slots.
The number of blocks produced by this validator that contained only vote transactions.
The rewards a validator got from voting for valid blocks (i.e. correct fork) of the network.
# Developers FAQ
Source: https://docs.rated.network/rated-api/guides/developers-faq
Frequently asked questions in and around the Rated API.
## How do I access the Rated API?
To access the Rated API you will need to head to [console.rated.network](https://console.rated.network/) and create an account.
## How is the Rated API structured?
The RatedAPI is adopted for rewards tracking, performance monitoring and benchmarking. Full details can be found under [API reference](/rated-api/api-reference).
## How can I use the Rated API for monitoring validator performance on Grafana?
Check out our Rated CLI on [github](https://github.com/rated-network/rated-cli) to bring all the information that the Rated API supports, in your local monitoriong suite.
Please remember to contribute back to the main branch if you come up with extensions, bug fixes, new modules etc.
## What is the definition of "effectiveness" in the API?
The effectiveness rating (RAVER) is a methodology Rated has proposed for evaluating validator performance in a concise way. The methodology has been through a number of iterations with the community and is widespread by now. For more information on the specifics, please refer to our documentation.
## Can I query the API up to a specific granular time (i.e. epoch, slot)?
The API doesn't allow you to specify epoch. Data is pre-aggregated into 225 epoch intervals, so the minimum current granularity is 1 day. The API does offer `startEpoch` and `endEpoch` in the response, so that you have visibility of which epochs have been aggregated.
## Can I get the current balance of the validator node from the API?
This information is not currently available. We are working on withdrawals and as part of this we are planning a few features related to balances and partial/full withdrawals that will be updated in real-time!
## I am trying to use /v0/eth/validators/effectiveness endpoint with granularity set to month, but I get error: "Can't use granularity when grouping by validator." Any suggestions?
The API can aggregate in two ways. Depending on what you are trying to achieve the query params available are different.
1. `timeWindow` - Validator data is aggregated in time buckets
* Data for validator 1,2 and 3 get aggregated and one row is returned for every day/week/month. [Link to example](https://api.rated.network/v0/eth/validators/effectiveness?indices=10\&indices=11\&indices=13\&groupBy=timeWindow\&granularity=day)
2. `validator` - Daily validator data is aggregated by pubkey/index
* Data for validators 1,2,3 get aggregated in one row per validator. The time period to aggregate can be arbitrary. [Link to example](https://api.rated.network/v0/eth/validators/effectiveness?indices=10\&indices=11\&indices=13\&groupBy=validator\&from=2023-01-30\&to=2023-01-01\&filterType=datetime)
## My use case requires a higher bandwidth of use than the current rated limit allows. Wat do?
shoot us a note at [hello@rated.network](mailto:hello@rated.network).
# Performance Benchmarking
Source: https://docs.rated.network/rated-api/guides/use-cases/performance-benchmarking
Performance benchmarking is a critical practice that involves evaluating and comparing the efficiency of various validators, both internal and external, to find areas of efficiency. Rated APIs provide access to standardized performance metrics, which can be used by:
1. **Node Operators** to continuously monitor their own performance metrics in relation to their competitors. This not only helps in identifying areas of improvement but also facilitates the formulation of effective strategies to enhance their operational efficiency and service quality.
2. **Custodians** and **Centralised Exchanges** to conduct thorough evaluations of validator operators, comparing their performance against network standards and other validators. This comprehensive analysis assists in making strategic decisions regarding SLAs and pricing, ensuring optimal performance and cost-effectiveness.
## Integration Steps
### Step 1: Generate Authorization Token
[Sign into the Rated Console](https://rated.network/signIn) to generate your API Token.
### Step 2: Get Performance Data
The Rated API offers time window aggregation, allowing you to consolidate data over various time periods such as `day`, `week`, `month`, `quarter`, `year` or `all time`. You can retrieve performance data in two ways:
1. Pre-materialized views
2. Specific validator groups
#### Step 2.1: Getting Performance Data for Pre-materialized Views
Imagine you're Kiln (a Node Operator), Lido (a Pool), or Coinbase (an Exchange). You want all your performance details for August 2023, shown daily. Here's how you'd go about getting this data.
| Key | Required? | Value | Description |
| :------------ | :-------- | :------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `operator_id` | Yes | string | Name of the Entity. For this example, you should either put `Lido` ,`Kiln` or`Coinbase` **Note:** the operator\_id is case-sensitive and should follow the same typecase as they are on the [Rated Explorer](https://www.rated.network/?network=mainnet\&view=pool\&timeWindow=1d\&page=1\&poolType=all) |
| `idType` | Yes | string | The type of entity class you would like returned. You might ask for `pool`, `poolShare`, `nodeOperator`, `depositAddress`, or `withdrawalAddress`. **Note:** it is optional and can be inferred automatically for pools, pool shares and node operators. It defaults to `depositAddress` if it is missing and an address is provided. |
| `granularity` | Yes | string | The size of time increments you are looking to query. Can be `day` / `week` / `month` / `quarter` / `year`. For this example, you should set granularity to `day`. |
| `from` | Yes | string | Start day (integer) or date (e.g. from="2022-12-01") For this example, set from to `2023-08-31` |
| `size` | Yes | integer | The number of results included per page. For this example, you should set size as 31 as we want the monthly data for August 2023. |
| `filterType` | Yes | string | `hour`, `day` and `datetime` For this example, set to `datetime` |
| `include` | Yes | array | A list of field names. To get the performance data, you should include the following data: `day`, `validatorCount`, `avgInclusionDelay`, `avgUptime`, `avgCorrectness`, `avgProposerEffectiveness`, `avgValidatorEffectiveness`, `avgAttesterEffectiveness`,`sumCorrectHead`, `sumCorrectTarget`, `sumCorrectSource`,`sumInclusionDelay`, `sumProposedCount`, `sumProposerDutiesCount`, `slashesCollected`, `slashesReceived`, `sumMissedSyncSignatures`, `sumLateSourceVotes`, `sumWrongTargetVotes`, `sumLateTargetVotes`, `sumMissedAttestations`, `sumWrongHeadVotes`, `sumExecutionProposedEmptyCount` |
**Example:** Obtaining daily performance metrics for the month of August 2023 for Kiln
```sh curl theme={null}
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/operators/Kiln/effectiveness?from=2023-08-31&size=31&granularity=day&filterType=datetime&include=validatorCount&include=avgInclusionDelay&include=avgUptime&include=avgCorrectness&include=avgProposerEffectiveness&include=avgValidatorEffectiveness&include=avgAttesterEffectiveness&include=sumCorrectHead&include=sumCorrectTarget&include=sumCorrectSource&include=sumInclusionDelay&include=sumProposedCount&include=sumProposerDutiesCount&include=slashesCollected&include=slashesReceived&include=day&include=sumMissedSyncSignatures&include=sumLateSourceVotes&include=sumWrongTargetVotes&include=sumLateTargetVotes&include=sumMissedAttestations&include=sumWrongHeadVotes&include=sumExecutionProposedEmptyCount&idType=nodeOperator' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
```
```python python theme={null}
import requests
url = "https://api.rated.network/v0/eth/operators/Kiln/effectiveness"
params = {
"from": "2023-08-31",
"size": 31,
"granularity": "day",
"filterType": "datetime",
"include": [
"validatorCount", "avgInclusionDelay", "avgUptime",
"avgCorrectness", "avgProposerEffectiveness",
"avgValidatorEffectiveness", "avgAttesterEffectiveness",
"sumCorrectHead", "sumCorrectTarget", "sumCorrectSource",
"sumInclusionDelay", "sumProposedCount", "sumProposerDutiesCount",
"slashesCollected", "slashesReceived", "day",
"sumMissedSyncSignatures", "sumLateSourceVotes",
"sumWrongTargetVotes", "sumLateTargetVotes",
"sumMissedAttestations", "sumWrongHeadVotes",
"sumExecutionProposedEmptyCount"
],
"idType": "nodeOperator"
}
headers = {
"Content-Type": "application/json",
"X-Rated-Network": "mainnet",
"Authorization": "Bearer "
}
response = requests.get(url, params=params, headers=headers)
print(response.json())
```
#### Step 2.2: Getting Performance Data for Specific Validator Groups
For validator groupings, you will need to call the [Aggregating validator indices](/rated-api/api-reference/v0/ethereum/validators/get-effectiveness-aggregation) endpoint. We'll show this similarly as above for all performance details for the month of August 2023 for a set of validator indices, aggregated daily.
| Key | Required? | Value | Description |
| :----------------------- | :-------- | :------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `pubkeys` (OR) `indices` | Yes | array \[string] (OR) array \[integer] | Array of validator pubkeys or indicies you're performing the grouped analysis for. For this example, you should put indices as `675893` `675894` and `675895` |
| `filterType` | Yes | string | `hour`, `day` and `datetime`. For this example, set to `datetime` |
| `from` | Yes | string | The most recent date for your desired timeline. In this example, it is `2023-08-31` |
| `size` | Yes | integer | The number of results included per page. For this example, you should set size as 31 as we want the monthly data for August 2023. |
| `granularity` | Yes | string | The size of time increments you are looking to query. Can be `day` / `week` / `month` / `quarter` / `year`. For this example, set granularity to `day`. |
| `groupBy` | Yes | string | Aggregation groupings. Can be `timeWindow` if you'd like to aggregation for your desired time window or `validator` if you'd like it per validator. For this example, set it to `timeWindow`. |
| `include` | Yes | array \[string] | A list of field names. To get the performance data, you should include the following data: `day`, `validatorCount`, `avgInclusionDelay`, `avgUptime`, `avgCorrectness`, `avgProposerEffectiveness`, `avgValidatorEffectiveness`, `avgAttesterEffectiveness`,`sumCorrectHead`, `sumCorrectTarget`, `sumCorrectSource`,`sumInclusionDelay`, `sumProposedCount`, `sumProposerDutiesCount`, `slashesCollected`, `slashesReceived`, `sumMissedSyncSignatures`, `sumLateSourceVotes`, `sumWrongTargetVotes`, `sumLateTargetVotes`, `sumMissedAttestations`, `sumWrongHeadVotes`, `sumExecutionProposedEmptyCount` |
**Example:** Obtaining daily performance metrics for the month of August 2023 for Validator group `{675893,675894,675895}`
```sh curl theme={null}
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/validators/effectiveness?indices=675893&indices=675894&indices=675895&from=2023-08-31&size=31&granularity=day&filterType=datetime&include=validatorCount&include=avgInclusionDelay&include=avgUptime&include=avgCorrectness&include=avgProposerEffectiveness&include=avgValidatorEffectiveness&include=avgAttesterEffectiveness&include=sumCorrectHead&include=sumCorrectTarget&include=sumCorrectSource&include=sumInclusionDelay&include=sumProposedCount&include=sumProposerDutiesCount&include=slashesCollected&include=slashesReceived&include=day&include=sumMissedSyncSignatures&include=sumLateSourceVotes&include=sumWrongTargetVotes&include=sumLateTargetVotes&include=sumMissedAttestations&include=sumWrongHeadVotes&include=sumExecutionProposedEmptyCount&groupBy=timeWindow' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
```
```python python theme={null}
import requests
url = "https://api.rated.network/v0/eth/validators/effectiveness"
params = {
"indices": [675893, 675894, 675895],
"from": "2023-08-31",
"size": 31,
"granularity": "day",
"filterType": "datetime",
"groupBy": "timeWindow",
"include": [
"validatorCount", "avgInclusionDelay", "avgUptime",
"avgCorrectness", "avgProposerEffectiveness",
"avgValidatorEffectiveness", "avgAttesterEffectiveness",
"sumCorrectHead", "sumCorrectTarget", "sumCorrectSource",
"sumInclusionDelay", "sumProposedCount", "sumProposerDutiesCount",
"slashesCollected", "slashesReceived", "day",
"sumMissedSyncSignatures", "sumLateSourceVotes",
"sumWrongTargetVotes", "sumLateTargetVotes",
"sumMissedAttestations", "sumWrongHeadVotes",
"sumExecutionProposedEmptyCount"
]
}
headers = {
"Content-Type": "application/json",
"X-Rated-Network": "mainnet",
"Authorization": "Bearer "
}
response = requests.get(url, params=params, headers=headers)
print(response.json())
```
# Private Sets
Source: https://docs.rated.network/rated-api/guides/use-cases/private-sets
Private sets is a self-serve feature designed to enable organizations to curate a set of validators, each marked with a unique tag. This tag, carrying an identifier specific to your organization, ensures that only you can view the performance and rewards metrics for it. Displayed within your console, these tags streamline analysis processes and let you perform A/B testing on your node setup or group together validators for a specific customer confidentially.
### Getting Started
Build and Growth API users can create private sets. Build tier comes with max 4 sets while Growth comes with 20.
### Step 1: Creating a Tag and associating validators to it
To call a set's effectiveness, you must first create a tag which acts as a unique identifier for the set.
**Body parameters (Required)**
| Name | Type | Description |
| :----- | :----- | :--------------- |
| `name` | string | Name for the tag |
**Response**
```json 200 theme={null}
{
"id": "string",
"name": "string",
"network": "mainnet",
"organizationId": "string",
"createdBy": "string",
"createdAt": "2024-03-14T18:12:14.677Z",
"updatedAt": "2024-03-14T18:12:14.677Z"
}
```
Using the `id` that you get in the response above, call the following endpoint to associate validators with the tag
**Body parameters (Required)**
| Name | Type | Description |
| :-------- | :---- | :------------------------------------------ |
| `pubkeys` | array | list of keys you wish to associate to a tag |
**Response**
```json 200 theme={null}
{
"tag": "string",
"pubkeysAdded": integer
}
```
Once you have a tag with validator mappings, you can move to Step 2.
To add more validators to a tag, call `POST` `/v1/tags/{id}/validators` with the new keys you'd like to add. Similarly, to remove a pubkey from an existing tag, call`DELETE` `/v1/tags/{id}/validators/{pubkey}.`
Removing keys from a tag doesn't erase their impact on historical performance ie performance of a removed pubkey continues to impact the all-time performance of a set.
### Step 2: Calling the performance and rewards endpoints for your set
Using the tag's ID, call the sets endpoints to retrieve performance and rewards metrics. These endpoints operate similar to the /operators/ endpoints with similar granularities and refresh windows.
**Query parameters**
| Name | Type | Value |
| :------------ | :------ | :------------------------------------------------------------------------------------------ |
| `granularity` | enum | `hour`or `day` |
| `fromDate` | date | the date from which you wish to retrieve the data |
| `toDate` | date | the date upto which you wish to retrieve the data |
| `limit` | integer | the number of rows returned per page |
| `offset` | integer | offset allows you to omit a specified number of rows before the beginning of the result set |
**Response**
```json 200 (effectiveness) theme={null}
{
"pages": 3,
"results": [
{
"hour": null,
"day": 796,
"date": 2023-01-01,
"startEpoch": 179324,
"endEpoch": 179100,
"validatorCount": 16075,
"avgInclusionDelay": 1.0138705386457403,
"avgUptime": 0.9999466390184881,
"avgCorrectness": 0.9929917401071404,
"avgProposerEffectiveness": 99.53271028037379,
"avgValidatorEffectiveness": 97.96642775943795,
"avgAttesterEffectiveness": 97.9580945527236
}
],
"previous": "string",
"next": "string"
}
```
```json 200 (attestations) theme={null}
{
"pages": 3,
"results": [
{
"hour": null,
"day": 796,
"date": 2023-01-01,
"startEpoch": 179324,
"endEpoch": 179100,
"validatorCount": 16075,
"totalUniqueAttestations": 3616682,
"sumMissedAttestations": 193,
"sumMissedSyncSignatures": 2837,
"sumCorrectHead": 3547355,
"sumCorrectTarget": 3612248,
"sumCorrectSource": 3614403,
"sumWrongHeadVotes": 48767,
"sumWrongTargetVotes": 4434,
"sumWrongSourcetVotes": 4434,
"sumLateSourceVotes": 2279,
"sumLateTargetVotes": 0,
"sumLateHeadVotes": 0,
"avgAttesterEffectiveness": 97.9580945527236
}
],
"previous": "string",
"next": "string"
}
```
```json 200 (proposals) theme={null}
{
"pages": 3,
"results": [
{
"hour": null,
"day": 796,
"date": 2023-01-01,
"startEpoch": 179324,
"endEpoch": 179100,
"validatorCount": 16075,
"sumProposedCount": 213,
"sumProposerDutiesCount": 214,
"avgProposerEffectiveness": 99.53271028037379
}
],
"previous": "string",
"next": "string"
}
```
```json 200 (rewards) theme={null}
{
"pages": 3,
"results": [
{
"hour": null,
"day": 796,
"date": 2023-01-01,
"startEpoch": 179324,
"endEpoch": 179100,
"validatorCount": 16075,
"sumEarnings": 56766373292,
"sumEstimatedRewards": 56675239144,
"sumPriorityFees": 10662221791,
"sumBaselineMev": 5266131924,
"sumMissedExecutionRewards": 58181568,
"sumConsensusBlockRewards": 6554423259,
"sumMissedConsensusBlockRewards": 31228533,
"sumAllRewards": 72694727007,
"sumAttestationRewards": 50120815885,
"sumMissedAttestationRewards": 269961427,
"sumMissedSyncCommitteeRewards": 44317643,
"sumExternallySourcedExecutionRewards": 14862131536
}
],
"previous": "string",
"next": "string"
}
```
```json 200 (penalties) theme={null}
{
"pages": 3,
"results": [
{
"hour": null,
"day": 796,
"date": 2023-01-01,
"startEpoch": 179324,
"endEpoch": 179100,
"validatorCount": 16075,
"sumEstimatedPenalties": -82967688,
"sumSyncCommitteePenalties": -44317643,
"sumWrongTargetPenalties": -28763358,
"sumLateTargetPenalties": 0,
"sumMissedAttestationPenalties": -1926140,
"sumWrongHeadPenalties": 0,
"sumLateSourcePenalties": -7960547
}
],
"previous": "string",
"next": "string"
}
```
# Rewards Accounting
Source: https://docs.rated.network/rated-api/guides/use-cases/rewards-accounting
The Rated API facilitates efficient and detailed management of rewards distributed on Ethereum. By leveraging the API, users can achieve granular insight into their reward dynamics, aiding in precise accounting and better decision-making.
1. **Node Operators** can keep track of their rewards in granular detail, accounting for the attribution of rewards for specific validator duties.
2. **Pools**, **Custodians** and **Centralised Exchanges** can take stock of the rewards they receive from one or more staking providers in a consolidated view, including a breakdown of the different sources of rewards.
## Integration Steps
### Step 1: Generate Authorization Token
[Sign into the Rated Console](https://rated.network/signIn) to generate your API Token.
### Step 2: Get Rewards Data
The Rated API offers time window aggregation, allowing you to consolidate data over various time periods such as `day`, `week`, `month`, `quarter`, `year` or `all time`. You can retrieve reward info in two ways:
1. Pre-materialized views
2. Specific validator groups
#### Step 2.1: Getting Rewards for Pre-materialized Views
Imagine you're Kiln (a Node Operator), Lido (a Pool), or Coinbase (an Exchange). You want all your reward details (consensus layer and execution layer including penalties) for August 2023, shown daily. Here's how you'd go about getting this data.
Call the [Operator effectiveness](/rated-api/api-reference/v0/ethereum/operators/get-effectiveness)endpoint with the following parameters set:
| Key | Required? | Value | Description |
| :------------ | :-------- | :------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `operator_id` | Yes | string | Name of the Entity. For this example, you should either put `Lido` ,`Kiln` or`Coinbase` **Note:** the operator\_id is case-sensitive and should follow the same typecase as they are on the [Rated Explorer.](https://www.rated.network/?network=mainnet\&view=pool\&timeWindow=1d\&page=1\&poolType=all) |
| `idType` | Yes | string | The type of entity class you would like returned. You might ask for `pool`, `poolShare`, `nodeOperator`, `depositAddress`, or `withdrawalAddress`. **Note:** it is optional and can be inferred automatically for pools, pool shares and node operators. It defaults to `depositAddress` if it is missing and an address is provided. |
| `granularity` | Yes | string | The size of time increments you are looking to query. Can be `day` / `week` / `month` / `quarter` / `year`. For this example, you should set granularity to `day`. |
| `from` | Yes | string | Start day (integer) or date (e.g. from="2022-12-01") For this example, set from to `2023-08-31` |
| `size` | Yes | integer | The number of results included per page. For this example, you should set size as 31 as we want the monthly data for August 2023. |
| `filterType` | Yes | string | `hour`, `day` and `datetime` For this example, set to `datetime` |
| `include` | Yes | array | A list of field names. To get the rewards data, you should include the following data: `day`, `sumEarnings`, `sumEstimatedRewards`, `sumEstimatedPenalties`, `sumPriorityFees`, `sumBaselineMev`, `sumMissedExecutionRewards`, `sumConsensusBlockRewards`, `sumMissedConsensusBlockRewards`, `sumAllRewards`, `sumAttestationRewards`, `sumMissedAttestationRewards`, `sumMissedAttestationPenalties`, `sumWrongTargetPenalties`, `sumLateTargetPenalties`, `sumWrongHeadPenalties` and `sumLateSourcePenalties` |
| Key | Required? | Value | Description |
| :------------ | :-------- | :------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `idType` | Yes | string | The type of entity class you would like returned. You might ask for `pool`, `poolShare`, `nodeOperator`, `depositAddress`, or `withdrawalAddress`. **Note:** it is optional and can be inferred automatically for pools, pool shares and node operators. It defaults to `depositAddress` if it is missing and an address is provided. |
| `granularity` | Yes | string | The size of time increments you are looking to query. Can be `day` / `week` / `month` / `quarter` / `year`. For this example, you should set granularity to `day`. |
| `from` | Yes | string | Start day (integer) or date (e.g. from="2022-12-01") For this example, set from to `2023-08-31` |
| `size` | Yes | integer | The number of results included per page. For this example, you should set size as 31 as we want the monthly data for August 2023. |
| `filterType` | Yes | string | `hour`, `day` and `datetime` For this example, set to `datetime` |
| `include` | Yes | array | A list of field names. To get the rewards data, you should include the following data: `day`, `sumEarnings`, `sumEstimatedRewards`, `sumEstimatedPenalties`, `sumPriorityFees`, `sumBaselineMev`, `sumMissedExecutionRewards`, `sumConsensusBlockRewards`, `sumMissedConsensusBlockRewards`, `sumAllRewards`, `sumAttestationRewards`, `sumMissedAttestationRewards`, `sumMissedAttestationPenalties`, `sumWrongTargetPenalties`, `sumLateTargetPenalties`, `sumWrongHeadPenalties` and `sumLateSourcePenalties` |
#### Get Effectiveness
**Example:** Obtaining daily reward metrics for the month of August 2023 for Kiln
```sh curl theme={null}
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/operators/Kiln/effectiveness?idType=nodeOperator&granularity=day&from=2023-08-31&size=31&filterType=datetime&include=sumEarnings&include=day&include=sumEstimatedRewards&include=sumEstimatedPenalties&include=sumPriorityFees&include=sumBaselineMev&include=sumMissedExecutionRewards&include=sumConsensusBlockRewards&include=sumMissedConsensusBlockRewards&include=sumAttestationRewards&include=sumAllRewards&include=sumMissedAttestationRewards&include=sumMissedAttestationPenalties&include=sumWrongTargetPenalties&include=sumLateTargetPenalties&include=sumWrongHeadPenalties&include=sumLateSourcePenalties' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
```
```python python theme={null}
import requests
url = "https://api.rated.network/v0/eth/operators/Coinbase/effectiveness"
params = {
"idType": "nodeOperator",
"granularity": "day",
"from": "2023-08-31",
"size": 31,
"filterType": "datetime",
"include": [
"sumEarnings", "day", "sumEstimatedRewards", "sumEstimatedPenalties",
"sumPriorityFees", "sumBaselineMev", "sumMissedExecutionRewards",
"sumConsensusBlockRewards", "sumMissedConsensusBlockRewards",
"sumAttestationRewards", "sumAllRewards", "sumMissedAttestationRewards",
"sumMissedAttestationPenalties", "sumWrongTargetPenalties",
"sumLateTargetPenalties", "sumWrongHeadPenalties", "sumLateSourcePenalties"
]
}
headers = {
"Content-Type": "application/json",
"X-Rated-Network": "mainnet",
"Authorization": "Bearer "
}
response = requests.get(url, params=params, headers=headers)
data = response.json()
```
You will get the following response:
```json theme={null}
{
"page": {
"from": "2023-08-31",
"to": null,
"size": 31,
"granularity": "day",
"filterType": "datetime"
},
"total": 898,
"data": [
{
"day": 1003,
"sumEarnings": 77486856706,
"sumEstimatedRewards": 77373138429,
"sumEstimatedPenalties": -118318923,
"sumPriorityFees": 17774426424,
"sumBaselineMev": 3491590102,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9990007760,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 98752873232,
"sumWrongTargetPenalties": -49457460.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -13833800.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 67667148655.0,
"sumLateSourcePenalties": -11938591.0,
"sumMissedAttestationRewards": 284356667.0
},
{
"day": 1002,
"sumEarnings": 77143472373,
"sumEstimatedRewards": 77391611207,
"sumEstimatedPenalties": -120229039,
"sumPriorityFees": 18343668557,
"sumBaselineMev": 10356072440,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 10319158586,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 105843213370,
"sumWrongTargetPenalties": -26537147.0,
"sumLateTargetPenalties": -21268.0,
"sumMissedAttestationPenalties": -36654580.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 67263902633.0,
"sumLateSourcePenalties": -19645906.0,
"sumMissedAttestationRewards": 286496225.0
},
{
"day": 1001,
"sumEarnings": 76074505835,
"sumEstimatedRewards": 76247558832,
"sumEstimatedPenalties": -137348952,
"sumPriorityFees": 19972445511,
"sumBaselineMev": 6018452671,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9791416575,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 102065404017,
"sumWrongTargetPenalties": -44169801.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -36647400.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 66503540668.0,
"sumLateSourcePenalties": -15249640.0,
"sumMissedAttestationRewards": 329264913.0
},
{
"day": 1000,
"sumEarnings": 74927018847,
"sumEstimatedRewards": 74951967765,
"sumEstimatedPenalties": -87687005,
"sumPriorityFees": 19894046470,
"sumBaselineMev": 6328736364,
"sumMissedExecutionRewards": 64569010,
"sumConsensusBlockRewards": 9663448571,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 101149801681,
"sumWrongTargetPenalties": -22716304.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -13626780.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 65429057326.0,
"sumLateSourcePenalties": -25472167.0,
"sumMissedAttestationRewards": 299629203.0
},
{
"day": 999,
"sumEarnings": 74450326845,
"sumEstimatedRewards": 74442548500,
"sumEstimatedPenalties": -94866866,
"sumPriorityFees": 15629334347,
"sumBaselineMev": 3163139471,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9143393628,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 93242800663,
"sumWrongTargetPenalties": -16739619.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -27380820.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 65416918513.0,
"sumLateSourcePenalties": -16548504.0,
"sumMissedAttestationRewards": 322013802.0
},
{
"day": 998,
"sumEarnings": 74559187641,
"sumEstimatedRewards": 74955978079,
"sumEstimatedPenalties": -118172069,
"sumPriorityFees": 13262259657,
"sumBaselineMev": 13354512742,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9361867132,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 101175960040,
"sumWrongTargetPenalties": -33376759.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -19439660.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 65604374555.0,
"sumLateSourcePenalties": -11486685.0,
"sumMissedAttestationRewards": 408981581.0
},
{
"day": 997,
"sumEarnings": 75052710169,
"sumEstimatedRewards": 74978533403,
"sumEstimatedPenalties": -99768855,
"sumPriorityFees": 16001568993,
"sumBaselineMev": 5507554734,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8946159003,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 96561833896,
"sumWrongTargetPenalties": -17664088.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -7671440.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 66308894671.0,
"sumLateSourcePenalties": -19986120.0,
"sumMissedAttestationRewards": 285461898.0
},
{
"day": 996,
"sumEarnings": 74871703449,
"sumEstimatedRewards": 74708910502,
"sumEstimatedPenalties": -75255605,
"sumPriorityFees": 19605086555,
"sumBaselineMev": 22209861662,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9728316748,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 116686651666,
"sumWrongTargetPenalties": -13585351.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -10273620.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 65245633437.0,
"sumLateSourcePenalties": -16255204.0,
"sumMissedAttestationRewards": 221794127.0
},
{
"day": 995,
"sumEarnings": 74316890091,
"sumEstimatedRewards": 74039058325,
"sumEstimatedPenalties": -57112712,
"sumPriorityFees": 18504571594,
"sumBaselineMev": 11768658033,
"sumMissedExecutionRewards": 82083111,
"sumConsensusBlockRewards": 9456206280,
"sumMissedConsensusBlockRewards": 37448909,
"sumAllRewards": 104590119718,
"sumWrongTargetPenalties": -14968772.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -2750740.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 64940299581.0,
"sumLateSourcePenalties": -10766084.0,
"sumMissedAttestationRewards": 220500261.0
},
{
"day": 994,
"sumEarnings": 72508933169,
"sumEstimatedRewards": 72423066679,
"sumEstimatedPenalties": -95087909,
"sumPriorityFees": 16880244177,
"sumBaselineMev": 2760444076,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 7992521257,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 92149621422,
"sumWrongTargetPenalties": -26118846.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -16278480.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 64712341492.0,
"sumLateSourcePenalties": -23772294.0,
"sumMissedAttestationRewards": 267184308.0
},
{
"day": 993,
"sumEarnings": 72803366526,
"sumEstimatedRewards": 72606477307,
"sumEstimatedPenalties": -92099755,
"sumPriorityFees": 19482043694,
"sumBaselineMev": 8999804612,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8473582662,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 101285214832,
"sumWrongTargetPenalties": -36716394.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -9331120.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 64478387038.0,
"sumLateSourcePenalties": -18030117.0,
"sumMissedAttestationRewards": 272457748.0
},
{
"day": 992,
"sumEarnings": 71975424908,
"sumEstimatedRewards": 73002158724,
"sumEstimatedPenalties": -107227509,
"sumPriorityFees": 18884800795,
"sumBaselineMev": 6729257290,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8340423622,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 97589482993,
"sumWrongTargetPenalties": -5972265.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -25987300.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 64448595752.0,
"sumLateSourcePenalties": -26496505.0,
"sumMissedAttestationRewards": 326248992.0
},
{
"day": 991,
"sumEarnings": 71693037399,
"sumEstimatedRewards": 71534022217,
"sumEstimatedPenalties": -80770537,
"sumPriorityFees": 15475987697,
"sumBaselineMev": 2388037004,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8776044106,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 89557062100,
"sumWrongTargetPenalties": -13690729.0,
"sumLateTargetPenalties": -21632.0,
"sumMissedAttestationPenalties": -16372540.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 63028705091.0,
"sumLateSourcePenalties": -16504019.0,
"sumMissedAttestationRewards": 324803231.0
},
{
"day": 990,
"sumEarnings": 71201257831,
"sumEstimatedRewards": 71323917377,
"sumEstimatedPenalties": -61400543,
"sumPriorityFees": 19460495365,
"sumBaselineMev": 20033856389,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8934140687,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 110695609585,
"sumWrongTargetPenalties": -21345376.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -9318400.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62463557805.0,
"sumLateSourcePenalties": -9295104.0,
"sumMissedAttestationRewards": 264891633.0
},
{
"day": 989,
"sumEarnings": 72921120155,
"sumEstimatedRewards": 73099619635,
"sumEstimatedPenalties": -86178482,
"sumPriorityFees": 28427036992,
"sumBaselineMev": 39116573891,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9732141534,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 140464731038,
"sumWrongTargetPenalties": -27817062.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -9261540.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 63476439000.0,
"sumLateSourcePenalties": -13139483.0,
"sumMissedAttestationRewards": 259552569.0
},
{
"day": 988,
"sumEarnings": 70756984738,
"sumEstimatedRewards": 70860707768,
"sumEstimatedPenalties": -88235800,
"sumPriorityFees": 20710830304,
"sumBaselineMev": 15488157260,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8397890884,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 106955972302,
"sumWrongTargetPenalties": -51629604.0,
"sumLateTargetPenalties": -16263.0,
"sumMissedAttestationPenalties": -4412060.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62630617761.0,
"sumLateSourcePenalties": -4766734.0,
"sumMissedAttestationRewards": 257295869.0
},
{
"day": 987,
"sumEarnings": 70893103774,
"sumEstimatedRewards": 70741064230,
"sumEstimatedPenalties": -56303757,
"sumPriorityFees": 24327872488,
"sumBaselineMev": 3849211195,
"sumMissedExecutionRewards": 152541808,
"sumConsensusBlockRewards": 8517893562,
"sumMissedConsensusBlockRewards": 37158073,
"sumAllRewards": 99070187457,
"sumWrongTargetPenalties": -31729126.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -5024360.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62499986937.0,
"sumLateSourcePenalties": -1398628.0,
"sumMissedAttestationRewards": 199524315.0
},
{
"day": 986,
"sumEarnings": 71345527791,
"sumEstimatedRewards": 71509004942,
"sumEstimatedPenalties": -52422987,
"sumPriorityFees": 19311633455,
"sumBaselineMev": 4899880144,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9008353871,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 95557041390,
"sumWrongTargetPenalties": -19962423.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -2417040.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62584831923.0,
"sumLateSourcePenalties": -7754460.0,
"sumMissedAttestationRewards": 174063536.0
},
{
"day": 985,
"sumEarnings": 70353861382,
"sumEstimatedRewards": 70289485267,
"sumEstimatedPenalties": -109933471,
"sumPriorityFees": 13574679849,
"sumBaselineMev": 6958761601,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8293793082,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 90887302832,
"sumWrongTargetPenalties": -26003978.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -19357800.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62272629862.0,
"sumLateSourcePenalties": -15568364.0,
"sumMissedAttestationRewards": 352447031.0
},
{
"day": 984,
"sumEarnings": 69279029765,
"sumEstimatedRewards": 69239938549,
"sumEstimatedPenalties": -57023477,
"sumPriorityFees": 14460823853,
"sumBaselineMev": 970362493,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8035987437,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 84710216111,
"sumWrongTargetPenalties": -19388460.0,
"sumLateTargetPenalties": -5460.0,
"sumMissedAttestationPenalties": -4097860.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 61433252823.0,
"sumLateSourcePenalties": -11460106.0,
"sumMissedAttestationRewards": 263046293.0
},
{
"day": 983,
"sumEarnings": 70119743088,
"sumEstimatedRewards": 70171046005,
"sumEstimatedPenalties": -83004798,
"sumPriorityFees": 16327857620,
"sumBaselineMev": 6121330397,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9017477978,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 92568931105,
"sumWrongTargetPenalties": -28844478.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -13163200.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 61255338001.0,
"sumLateSourcePenalties": -18498830.0,
"sumMissedAttestationRewards": 255244092.0
},
{
"day": 982,
"sumEarnings": 71838320945,
"sumEstimatedRewards": 71735220828,
"sumEstimatedPenalties": -73764264,
"sumPriorityFees": 18399433628,
"sumBaselineMev": 8332378294,
"sumMissedExecutionRewards": 80856814,
"sumConsensusBlockRewards": 9044614368,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 98570132867,
"sumWrongTargetPenalties": -23823969.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -4908860.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62993853433.0,
"sumLateSourcePenalties": -4785928.0,
"sumMissedAttestationRewards": 214308844.0
},
{
"day": 981,
"sumEarnings": 69170743871,
"sumEstimatedRewards": 69718217491,
"sumEstimatedPenalties": -81037263,
"sumPriorityFees": 16751087201,
"sumBaselineMev": 8377124384,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8696340897,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 94298955456,
"sumWrongTargetPenalties": -38548822.0,
"sumLateTargetPenalties": -49374.0,
"sumMissedAttestationPenalties": -5117980.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 60936329191.0,
"sumLateSourcePenalties": -13469120.0,
"sumMissedAttestationRewards": 249990574.0
},
{
"day": 980,
"sumEarnings": 67774955877,
"sumEstimatedRewards": 67486593483,
"sumEstimatedPenalties": -86121052,
"sumPriorityFees": 17632932919,
"sumBaselineMev": 3623878190,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 7359748324,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 89031766986,
"sumWrongTargetPenalties": -34863530.0,
"sumLateTargetPenalties": -153608.0,
"sumMissedAttestationPenalties": -9748200.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 60501373581.0,
"sumLateSourcePenalties": -16288356.0,
"sumMissedAttestationRewards": 315871984.0
},
{
"day": 979,
"sumEarnings": 68969624532,
"sumEstimatedRewards": 69125694220,
"sumEstimatedPenalties": -92678427,
"sumPriorityFees": 25457935159,
"sumBaselineMev": 11969638268,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8779398321,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 106397197959,
"sumWrongTargetPenalties": -47274903.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -6799460.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 60501905157.0,
"sumLateSourcePenalties": -12820423.0,
"sumMissedAttestationRewards": 276544680.0
},
{
"day": 978,
"sumEarnings": 68715799142,
"sumEstimatedRewards": 68768785228,
"sumEstimatedPenalties": -103641259,
"sumPriorityFees": 17159615224,
"sumBaselineMev": 3747660259,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8369514059,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 89623074625,
"sumWrongTargetPenalties": -30373213.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -13387720.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 60568975623.0,
"sumLateSourcePenalties": -21386463.0,
"sumMissedAttestationRewards": 322394599.0
},
{
"day": 977,
"sumEarnings": 67647407987,
"sumEstimatedRewards": 67755256605,
"sumEstimatedPenalties": -79139325,
"sumPriorityFees": 17646547352,
"sumBaselineMev": 2810008816,
"sumMissedExecutionRewards": 93426969,
"sumConsensusBlockRewards": 7971601348,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 88103964155,
"sumWrongTargetPenalties": -23310248.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -6767040.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 59942856826.0,
"sumLateSourcePenalties": -10916304.0,
"sumMissedAttestationRewards": 272629654.0
},
{
"day": 976,
"sumEarnings": 67573615877,
"sumEstimatedRewards": 67524182514,
"sumEstimatedPenalties": -54578218,
"sumPriorityFees": 13540169774,
"sumBaselineMev": 2817235411,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8503008669,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 83931021062,
"sumWrongTargetPenalties": -22945481.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -4283860.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 59164461159.0,
"sumLateSourcePenalties": -6292083.0,
"sumMissedAttestationRewards": 209503573.0
},
{
"day": 975,
"sumEarnings": 66437488350,
"sumEstimatedRewards": 66373097798,
"sumEstimatedPenalties": -58055221,
"sumPriorityFees": 17052013003,
"sumBaselineMev": 3878743025,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8083532577,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 87368244378,
"sumWrongTargetPenalties": -32006325.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -5618500.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 58498556338.0,
"sumLateSourcePenalties": -5021800.0,
"sumMissedAttestationRewards": 233054225.0
},
{
"day": 974,
"sumEarnings": 66824414130,
"sumEstimatedRewards": 66851503332,
"sumEstimatedPenalties": -57752865,
"sumPriorityFees": 20969913781,
"sumBaselineMev": 6467713168,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8587530284,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 94262041079,
"sumWrongTargetPenalties": -31376397.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -5747420.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 58294636711.0,
"sumLateSourcePenalties": -5969586.0,
"sumMissedAttestationRewards": 188969938.0
},
{
"day": 973,
"sumEarnings": 67672180612,
"sumEstimatedRewards": 67602223782,
"sumEstimatedPenalties": -67143708,
"sumPriorityFees": 20409089574,
"sumBaselineMev": 6615645878,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 7848078023,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 94696916064,
"sumWrongTargetPenalties": -19176079.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8843900.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 59980970328.0,
"sumLateSourcePenalties": -6192389.0,
"sumMissedAttestationRewards": 158298360.0
}
],
"next": "/v0/eth/operators/Kiln/effectiveness?idType=nodeOperator&granularity=day&from=2023-07-31&size=31&filterType=datetime&include=sumEarnings&include=day&include=sumEstimatedRewards&include=sumEstimatedPenalties&include=sumPriorityFees&include=sumBaselineMev&include=sumMissedExecutionRewards&include=sumConsensusBlockRewards&include=sumMissedConsensusBlockRewards&include=sumAttestationRewards&include=sumAllRewards&include=sumMissedAttestationRewards&include=sumMissedAttestationPenalties&include=sumWrongTargetPenalties&include=sumLateTargetPenalties&include=sumWrongHeadPenalties&include=sumLateSourcePenalties"
}
```
Note that if you're looking to get the same data grouped by withdrawal/deposit address, you can simply input `operator_id` as the address (`0x..`) and `idType` as `withdrawalAddress` or `depositAddress`.
#### Step 2.2: Getting Rewards for specific validators groups
For validator groupings, you will need to call the [Aggregating validator indices](/rated-api/api-reference/v0/ethereum/validators/get-effectiveness-aggregation) endpoint. We'll show this similarly as above for all reward details for the month of August 2023 for a set of validator indices, aggregated daily.
| Key | Required? | Value | Description |
| :----------------------- | :-------- | :------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `pubkeys` (OR) `indices` | Yes | array \[string] (OR) array \[integer] | Array of validator pubkeys or indicies you're performing the grouped analysis for. For this example, you should put indices as `675893` `675894` and `675895` |
| `filterType` | Yes | string | `hour`, `day` and `datetime`. For this example, set to `datetime` |
| `from` | Yes | string | The most recent date for your desired timeline. In this example, it is `2023-08-31` |
| `size` | Yes | integer | The number of results included per page. For this example, you should set size as 31 as we want the monthly data for August 2023. |
| `granularity` | Yes | string | The size of time increments you are looking to query. Can be `day` / `week` / `month` / `quarter` / `year`. For this example, set granularity to `day`. |
| `groupBy` | Yes | string | Aggregation groupings. Can be `timeWindow` if you'd like to aggregation for your desired time window or `validator` if you'd like it per validator. For this example, set it to `timeWindow`. |
| `include` | Yes | array \[string] | A list of field names. To get the rewards data, you should include the following data: `day`, `sumEarnings`, `sumEstimatedRewards`, `sumEstimatedPenalties`, `sumPriorityFees`, `sumBaselineMev`, `sumMissedExecutionRewards`, `sumConsensusBlockRewards`, `sumMissedConsensusBlockRewards`, `sumAllRewards`, `sumAttestationRewards`, `sumMissedAttestationRewards`, `sumMissedAttestationPenalties`, `sumWrongTargetPenalties`, `sumLateTargetPenalties`, `sumWrongHeadPenalties` and `sumLateSourcePenalties` |
#### Get Effectiveness Aggregation
**Example**: Obtaining daily reward metrics for the month of August 2023 for Validator group `{675893, 675894, 675895}`
```sh curl theme={null}
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/validators/effectiveness?indices=675893&indices=675894&indices=675895&granularity=day&from=2023-08-31&size=31&filterType=datetime&groupBy=timeWindow&include=sumEarnings&include=day&include=sumEstimatedRewards&include=sumEstimatedPenalties&include=sumPriorityFees&include=sumBaselineMev&include=sumMissedExecutionRewards&include=sumConsensusBlockRewards&include=sumMissedConsensusBlockRewards&include=sumAttestationRewards&include=sumAllRewards&include=sumMissedAttestationRewards&include=sumMissedAttestationPenalties&include=sumWrongTargetPenalties&include=sumLateTargetPenalties&include=sumWrongHeadPenalties&include=sumLateSourcePenalties' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
```
```python python theme={null}
import requests
url = "https://api.rated.network/v0/eth/validators/effectiveness"
params = {
"indices": [675893, 675894, 675895],
"granularity": "day",
"from": "2023-08-31",
"size": 31,
"filterType": "datetime",
"groupBy": "timeWindow",
"include": [
"sumEarnings",
"day",
"sumEstimatedRewards",
"sumEstimatedPenalties",
"sumPriorityFees",
"sumBaselineMev",
"sumMissedExecutionRewards",
"sumConsensusBlockRewards",
"sumMissedConsensusBlockRewards",
"sumAttestationRewards",
"sumAllRewards",
"sumMissedAttestationRewards",
"sumMissedAttestationPenalties",
"sumWrongTargetPenalties",
"sumLateTargetPenalties",
"sumWrongHeadPenalties",
"sumLateSourcePenalties"
]
}
headers = {
"Content-Type": "application/json",
"X-Rated-Network": "mainnet",
"Authorization": "Bearer "
}
response = requests.get(url, params=params, headers=headers)
print(response.json())
```
You will get the following response:
```json theme={null}
{
"page": {
"from": "2023-08-31",
"to": null,
"size": 31,
"granularity": "day",
"filterType": "datetime"
},
"total": 405,
"data": [
{
"day": 1003,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7323094,
"sumWrongTargetPenalties": -10608.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7333702.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 42897.0
},
{
"day": 1002,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7352178,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8180.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7360358.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 27504.0
},
{
"day": 1001,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7308796,
"sumWrongTargetPenalties": -21320.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7330116.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 61341.0
},
{
"day": 1000,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7296080,
"sumWrongTargetPenalties": -10673.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7321103.0,
"sumLateSourcePenalties": -14350.0,
"sumMissedAttestationRewards": 64617.0
},
{
"day": 999,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7369542,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8220.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7377762.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 24528.0
},
{
"day": 998,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7373639,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7376516.0,
"sumLateSourcePenalties": -2877.0,
"sumMissedAttestationRewards": 24370.0
},
{
"day": 997,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7362400,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8240.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7373524.0,
"sumLateSourcePenalties": -2884.0,
"sumMissedAttestationRewards": 46694.0
},
{
"day": 996,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7416434,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7419325.0,
"sumLateSourcePenalties": -2891.0,
"sumMissedAttestationRewards": 19434.0
},
{
"day": 995,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7433960,
"sumWrongTargetPenalties": -5369.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7439329.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 16214.0
},
{
"day": 994,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7375968,
"sumWrongTargetPenalties": -10764.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8280.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7400808.0,
"sumLateSourcePenalties": -5796.0,
"sumMissedAttestationRewards": 71112.0
},
{
"day": 993,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7438829,
"sumWrongTargetPenalties": -5382.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7444211.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 24790.0
},
{
"day": 992,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7436435,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7439340.0,
"sumLateSourcePenalties": -2905.0,
"sumMissedAttestationRewards": 35287.0
},
{
"day": 991,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7436976,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7436976.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 36077.0
},
{
"day": 990,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7463503,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7463503.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 22090.0
},
{
"day": 989,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7433338,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -16680.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7452937.0,
"sumLateSourcePenalties": -2919.0,
"sumMissedAttestationRewards": 58700.0
},
{
"day": 988,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7487113,
"sumWrongTargetPenalties": -10842.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7497955.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 30200.0
},
{
"day": 987,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7505733,
"sumWrongTargetPenalties": -10868.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7516601.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 35666.0
},
{
"day": 986,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7391225,
"sumWrongTargetPenalties": -5434.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -58520.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7455179.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 106388.0
},
{
"day": 985,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7505601,
"sumWrongTargetPenalties": -10894.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7516495.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 39010.0
},
{
"day": 984,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7529373,
"sumWrongTargetPenalties": -10920.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7543233.0,
"sumLateSourcePenalties": -2940.0,
"sumMissedAttestationRewards": 43993.0
},
{
"day": 983,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7556157,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7556157.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 14160.0
},
{
"day": 982,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7580477,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7580477.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 19784.0
},
{
"day": 981,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7567289,
"sumWrongTargetPenalties": -5486.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7575729.0,
"sumLateSourcePenalties": -2954.0,
"sumMissedAttestationRewards": 25280.0
},
{
"day": 980,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7569934,
"sumWrongTargetPenalties": -10972.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7580906.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 30199.0
},
{
"day": 979,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7459291,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -59220.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7524433.0,
"sumLateSourcePenalties": -5922.0,
"sumMissedAttestationRewards": 101713.0
},
{
"day": 978,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7555320,
"sumWrongTargetPenalties": -11011.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7569292.0,
"sumLateSourcePenalties": -2961.0,
"sumMissedAttestationRewards": 58219.0
},
{
"day": 977,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7630867,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7630867.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 22499.0
},
{
"day": 976,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7648668,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7648668.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 14216.0
},
{
"day": 975,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7583032,
"sumWrongTargetPenalties": -16575.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8500.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7608107.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 61688.0
},
{
"day": 974,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7627491,
"sumWrongTargetPenalties": -11076.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7641549.0,
"sumLateSourcePenalties": -2982.0,
"sumMissedAttestationRewards": 47934.0
},
{
"day": 973,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7655815,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -17040.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7672855.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 31458.0
}
],
"next": "/v0/eth/validators/effectiveness?indices=675893&indices=675894&indices=675895&from=2023-07-31&size=31&granularity=day&groupBy=timeWindow&filterType=datetime&include=sumEarnings&include=sumEstimatedRewards&include=sumEstimatedPenalties&include=sumPriorityFees&include=sumBaselineMev&include=sumMissedExecutionRewards&include=sumConsensusBlockRewards&include=sumMissedConsensusBlockRewards&include=sumAllRewards&include=sumAttestationRewards&include=sumMissedAttestationRewards&include=sumMissedAttestationPenalties&include=sumWrongTargetPenalties&include=sumLateTargetPenalties&include=sumWrongHeadPenalties&include=sumLateSourcePenalties"
}
```
# Compute Units
Source: https://docs.rated.network/rated-api/pricing/compute-units
All you need to know about the fundamental unit of account Rated API v1.
Compute Units are a metric reflecting the computational resources utilized by each API request. Some queries, like `/apr`, are quick and lightweight, while others, such as `/operators/{operator_id}/effectiveness`, may be more resource-intensive.
Compute Units for each endpoint are determined using the following formula:
$$
\left(\frac{\text{Content Length Bytes}}{\text{Weight}}\right) + \left(\text{Item Count} \times \text{Business Value} \times \text{Parameter Multiplier}\right)
$$
## Why use Compute Units?
We wanted to find an approach that guarantees fairness and scalability, ensuring that the costs align with the real value our users get from the APIs. By basing costs on compute units, we ensure that you receive the most transparent and equitable pricing. As we continue to innovate and evolve, we remain focused on delivering both top-notch services and clear, fair pricing that benefits our users.
## How to Monitor Your Compute Unit (CU) Consumption
You can track your compute unit usage in two ways:
1. **API Response Headers**:
Every API request you make includes the `x-rated-compute-units` header in the response. This header displays the exact number of CUs consumed by that specific request.
2. **Rated Console Dashboard**:
* View your overall CU usage on the main [Dashboard](https://console.rated.network/)
* See detailed CU consumption per endpoint in the [Usage Limits](https://console.rated.network/settings/usageLimits) page (navigate via *Settings → Usage Limits*)
## Weights per Endpoint
This represents the weight component of compute unit calculation used per endpoint. Note that your specific averages compute units per endpoint will vary based on your usage patterns of the endpoints and the kinds of aggregations you perform.
| Endpoint | Weight | Business Value | Parameter Multiplier | Multiplier |
| :----------------------------------------------------------------- | :----- | :------------- | :------------------- | :--------- |
| `/v1/eth` | 8 | 5 | | null |
| `/v1/eth/effectiveness` | 8 | 5 | | null |
| `/v1/eth/rewards` | 8 | 5 | | null |
| `/v1/eth/geographicalDistributions` | 8 | 10 | | null |
| `/v1/eth/hostDistributions` | 8 | 10 | | null |
| `/v1/eth/entities` | 8 | 5 | | null |
| `/v1/eth/entities/summaries` | 8 | 2 | | null |
| `/v1/eth/entities/{entity_id}/summaries` | 8 | 2 | | null |
| `/v1/eth/entities/{entity_id}/effectiveness` | 8 | 10 | | null |
| `/v1/eth/entities/{entity_id}/attestations` | 8 | 10 | | null |
| `/v1/eth/entities/{entity_id}/proposals` | 8 | 10 | | null |
| `/v1/eth/entities/{entity_id}/rewards` | 8 | 10 | | null |
| `/v1/eth/entities/{entity_id}/penalties` | 8 | 10 | | null |
| `/v1/eth/entities/{entity_id}/mappings` | 2 | 10 | | null |
| `/v1/eth/entities/{entity_id}/aprs` | 2 | 10 | | null |
| `/v1/eth/entities/{entity_id}/slashings` | 2 | 10 | | null |
| `/v1/eth/validators` | 4 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/effectiveness` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/attestations` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/proposals` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/rewards` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/penalties` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/withdrawals` | 8 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/mappings` | 2 | 10 | | null |
| `/v1/eth/validators/{validator_index_or_pubkey}/aprs` | 8 | 10 | | null |
| `/v1/eth/validators/effectiveness` | 4 | 10 | | null |
| `/v1/eth/validators/attestations` | 4 | 10 | | null |
| `/v1/eth/validators/proposals` | 4 | 10 | | null |
| `/v1/eth/validators/mappings` | 2 | 10 | | null |
| `/v1/eth/validators/slashings` | 4 | 10 | | null |
| `/v1/sets/{id}/effectiveness` | 4 | 10 | | null |
| `/v1/sets/{id}/attestations` | 4 | 10 | | null |
| `/v1/sets/{id}/proposals` | 4 | 10 | | null |
| `/v1/sets/{id}/rewards` | 4 | 10 | | null |
| `/v1/sets/{id}/penalties` | 4 | 10 | | null |
| `/v1/solana/delegators/stakeAccounts/{stake_account}/rewards` | 8 | 5 | | null |
| `/v1/solana/delegators/stakeAuthorities/{stake_authority}/rewards` | 8 | 5 | | null |
| `/v1/solana/network/overview` | 8 | 5 | | null |
| `/v1/solana/network/validatorDistributions` | 8 | 5 | | null |
| `/v1/solana/network/effectiveness` | 8 | 5 | | null |
| `/v1/solana/validators/{validator_id}/rewards` | 1 | 5 | | null |
| `/v1/solana/validators/{validator_id}/performance` | 1 | 5 | | null |
| `/v1/solana/validators/{validator_id}/performance/latency` | 1 | 5 | | null |
| `/v1/solana/validators/leaderboard` | 8 | 5 | | null |
| `/v1/solana/validators/{validator_id}` | 8 | 2 | | null |
| `/v1/solana/validators/{validator_id}/delegators` | 25 | 2 | | null |
| `/v1/solana/validators` | 8 | 5 | | null |
| `/v1/solana/validators/{validator_id}/summary` | 8 | 2 | | null |
| `/v1/eigenlayer/delegators/{address}/delegations` | 1 | 500 | | null |
| `/v1/eigenlayer/entities/{entity_id}/delegations` | 1 | 500 | | null |
| `/v1/eigenlayer/eigenpods/{address}/rewards` | 1 | 500 | granularity=week | 5 |
| `/v1/eigenlayer/delegators/{address}/rewards` | 1 | 1200 | granularity=week | 5 |
| `/v1/eigenlayer/entities/{entity_id}/rewards` | 1 | 1200 | granularity=week | 5 |
| `/v1/eigenlayer/eigenpods/{address}/state` | 1 | 500 | | null |
| `/v1/eigenlayer/operators/{address}/state` | 1 | 1200 | | null |
| `/v1/cosmos/validators/{validator_address}/rewards` | 2 | 10 | | null |
| `/v1/cosmos/network/rewards` | 2 | 10 | | null |
| `/v1/avalanche/validators/{node_id}/rewards` | 2 | 10 | | null |
| `/v1/avalanche/network/rewards` | 2 | 10 | | null |
| `/v1/celestia/validators/{validator_address}/rewards` | 2 | 10 | | null |
| `/v1/celestia/network/rewards` | 2 | 10 | | null |
| `/v1/cardano/validators/{pool_id}/rewards` | 2 | 10 | | null |
| `/v1/cardano/network/rewards` | 2 | 10 | | null |
| `/v1/polkadot/validators/{validator_address}/rewards` | 2 | 10 | | null |
| `/v1/polkadot/network/rewards` | 2 | 10 | | null |
For the endpoint `/v1/tags/{id}/validators`, we will calculate compute units as 128 pubkeys reported
| Endpoint | Weight | Business Value |
| :----------------------------------------------------------------- | :----- | :------------- |
| `/v0/eth/network/overview` | 8 | 5 |
| `/v0/eth/network/stats` | 8 | 1 |
| `/v0/eth/network/capacity` | 8 | 5 |
| `/v0/eth/network/capacity/pool` | 8 | 5 |
| `/v0/eth/p2p/geographical` | 8 | 5 |
| `/v0/eth/p2p/hostingProvider` | 8 | 5 |
| `/v0/eth/operators` | 8 | 5 |
| `/v0/eth/operators/percentiles` | 8 | 1 |
| `/v0/eth/operators/{operator_id}` | 8 | 5 |
| `/v0/eth/operators/{operator_id}/effectiveness` | 8 | 10 |
| `/v0/eth/operators/{operator_id}/apr` | 8 | 5 |
| `/v0/eth/operators/{operator_id}/summary` | 8 | 2 |
| `/v0/eth/operators/{operator_id}/stakeMovement` | 8 | 1 |
| `/v0/eth/operators/{operator_id}/clients` | 8 | 1 |
| `/v0/eth/operators/{operator_id}/relayers` | 8 | 1 |
| `/v0/eth/validators/effectiveness` | 8 | 10 |
| `/v0/eth/validators/{validator_index_or_pubkey}` | 8 | 10 |
| `/v0/eth/validators/{validator_index_or_pubkey}/effectiveness` | 32 | 10 |
| `/v0/eth/validators/{validator_index_or_pubkey}/apr` | 32 | 1 |
| `/v0/eth/blocks` | 32 | 10 |
| `/v0/eth/blocks/{consensus_slot}` | 32 | 10 |
| `/v0/eth/relayers` | 32 | 1 |
| `/v0/eth/relayers/recent` | 32 | 1 |
| `/v0/eth/relayers/stats` | 32 | 1 |
| `/v0/eth/trending/effectiveness/operators` | 32 | 5 |
| `/v0/eth/trending/mev/operators` | 32 | 5 |
| `/v0/eth/trending/effectiveness/validators` | 32 | 5 |
| `/v0/eth/trending/slashings/operators` | 32 | 5 |
| `/v0/eth/slashings/overview` | 32 | 1 |
| `/v0/eth/slashings/leaderboard` | 32 | 1 |
| `/v0/eth/slashings/cohortAnalysis` | 32 | 5 |
| `/v0/eth/slashings/timeseries` | 32 | 5 |
| `/v0/eth/slashings` | 32 | 5 |
| `/v0/eth/slashings/{validator_index_or_pubkey}` | 32 | 1 |
| `/v0/polygon/network/overview` | 8 | 5 |
| `/v0/polygon/validators` | 8 | 5 |
| `/v0/polygon/validators/{validator_id}` | 8 | 5 |
| `/v0/polygon/validators/{validator_id}/effectiveness` | 8 | 10 |
| `/v0/polygon/validators/{validator_id}/summary` | 8 | 2 |
| `/v0/polygon/delegators` | 8 | 5 |
| `/v0/polygon/delegators/{delegator_address}/summary` | 8 | 10 |
| `/v0/polygon/delegators/{delegator_address}/rewards` | 8 | 10 |
| `/v0/solana/delegators/stakeAccounts/{stake_account}/rewards` | 8 | 5 |
| `/v0/solana/delegators/stakeAuthorities/{stake_authority}/rewards` | 8 | 5 |
| `/v0/solana/network/overview` | 8 | 5 |
| `/v0/solana/network/validatorDistributions` | 8 | 5 |
| `/v0/solana/network/effectiveness` | 8 | 5 |
| `/v0/solana/validators/{validator_id}/rewards` | 1 | 5 |
| `/v0/solana/validators/{validator_id}/performance` | 1 | 5 |
| `/v0/solana/validators/{validator_id}/performance/latency` | 1 | 5 |
| `/v0/solana/validators/leaderboard` | 8 | 5 |
| `/v0/solana/validators/{validator_id}` | 8 | 2 |
| `/v0/solana/validators` | 8 | 5 |
| `/v0/solana/validators/{validator_id}/summary` | 8 | 2 |
# Rate limits
Source: https://docs.rated.network/rated-api/rate-limits
Learn about API rate limits and how to work with them.
The Rated API employs a number of safeguards against bursts of incoming traffic to help maximise its stability. Users who send many requests in quick succession may see error responses that show up as status code `429 Too many requests.`
For Free tier users, Rated allows up to 2 requests per second with a 10,000 Lifetime request safeguard.
For paid tiers, rate limit details can be found at our [Plans](/rated-api/pricing/plans) page.
Once you get rate limited you can use `Retry-After` and `Age` headers to compute how long you need to wait before being able to continue using the API.
## Handling Rate Limits
When you receive a `429` status code, check the response headers:
* `Retry-After`: Number of seconds to wait before making another request
* `Age`: How long the current rate limit window has been active
### Examples
```python Python theme={null}
import time
import requests
response = requests.get('https://api.rated.network/v0/eth/network/overview')
if response.status_code == 429:
retry_after = int(response.headers.get('retry-after', 1))
print(f"Rate limited. Retry after {retry_after} seconds")
# Wait before retrying
time.sleep(retry_after)
# Make your request again
```
```javascript JavaScript theme={null}
if (response.status === 429) {
const retryAfter = response.headers['retry-after'];
console.log(`Rate limited. Retry after ${retryAfter} seconds`);
// Wait before retrying
setTimeout(() => {
// Make your request again
}, retryAfter * 1000);
}
```
```bash cURL theme={null}
# If you get a 429 response, check the headers
curl -i https://api.rated.network/v0/eth/network/overview
# Response headers will include:
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Age: 15
# Wait 30 seconds then retry
```
```go Go theme={null}
if resp.StatusCode == 429 {
retryAfter := resp.Header.Get("retry-after")
fmt.Printf("Rate limited. Retry after %s seconds\n", retryAfter)
// Convert to duration and wait
if seconds, err := strconv.Atoi(retryAfter); err == nil {
time.Sleep(time.Duration(seconds) * time.Second)
// Make your request again
}
}
```
We may reduce limits to prevent abuse, or increase limits to enable high-traffic applications. To request an increased rate limit, please [contact us](mailto:hello@rated.network).
# Request IDs
Source: https://docs.rated.network/rated-api/request-ids
How to find those, and code examples.
Each API request has an associated request identifier. You can find this value in the response headers, under `X-Request-Id`.
If you need to contact us about a specific request, providing the request identifier will ensure the fastest possible resolution.
```curl Curl theme={null}
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/validators/69/effectiveness' \
-H 'accept: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
...
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< access-control-expose-headers: X-Request-ID
< content-length: 45
< content-type: application/json
< date: Wed, 19 Apr 2023 19:32:56 GMT
< server: envoy
< www-authenticate: Bearer
< x-request-id: 4b07649d-a553-4f1a-8be9-9a7a514ffcf9
< x-envoy-upstream-service-time: 11
<
* Connection #0 to host api.rated.network left intact
```
```python Python theme={null}
# my_token contains a JWT you got previously from console.rated.network/apiKeys
import requests
response = requests.get(
"https://api.rated.network/v0/eth/validators/69/effectiveness",
headers={"Authorization": f"Bearer {my_token}"},
)
try:
response.raise_for_status()
except requests.exceptions.HTTPError:
print(response.headers["x-request-id"])
```
# Rated CLI
Source: https://docs.rated.network/rated-api/tools/rated-cli
A community built Prometheus exporter for the Rated API
The rated-cli is an OS community built tool that allows power users to port Rated API metrics over to their local monitoring environments. You can learn more about in on [this Github repo](https://github.com/rated-network/rated-cli).
![]()
Please remember to contribute back to the main branch with extensions you might build locally, that can be generalised and add value to others.
# Rated Console
Source: https://docs.rated.network/rated-api/tools/rated-console
A dashboard console for the Rated API
# Rated Network Explorer
Source: https://docs.rated.network/rated-api/tools/rated-explorer
A Network Explorer based of the Rated API
# Rated SDK
Source: https://docs.rated.network/rated-api/tools/rated-sdk
Libraries and tools for interacting with your Rated integration
The SDK is currently in beta phase. If you find bugs, please open an [issue](https://github.com/rated-network/rated-python/issues) on Github. If you have feature requests or feedback, head to [feedback.rated.network]().
Rated's [Python SDK](https://github.com/rated-network/rated-python) reduces the amount of work required to use Rated's REST APIs, starting with reducing the boilerplate code you have to write. Below is the installation instructions for this library in Python.
### Installation
Install using `pip`:
```bash theme={null}
pip install rated-python
```
### Usage
**Example:** how to get a validator effectiveness rating by pubkey
```python theme={null}
from rated import Rated
from rated.ethereum import MAINNET
RATED_KEY = "ey..."
r = Rated(RATED_KEY)
eth = r.ethereum(network=MAINNET)
for eff in eth.validator.effectiveness("0x123456789...", from_day=873, size=1):
print(f"Day: {eff.day}, Eff: {eff.validator_effectiveness}")
>>> Day: 873, Eff: 98.82005899705014
```
Try this beta SDK and share feedback with us before the features reach the stable phase. To learn more about how to use the beta SDK, head to the [readme file](https://github.com/rated-network/rated-python/blob/main/README.md) in the GitHub repository.
# Overview
Source: https://docs.rated.network/documentation/explorer/ethereum/ethereum
Definitions of the variables that live on the landing page of the Rated Network Explorer.
The default view of the Rated Explorer is the "Network Overview" view. This represents a bird's eye view of the network with a series of metrics that attempt to capture the current state of the network at the highest level. We'll dive into the different metrics seen on this page on [Network Overview](/documentation/explorer/ethereum/network-views/network-overview).
![]()
# Leaderboard
Source: https://docs.rated.network/documentation/explorer/ethereum/miscellaneous/leaderboard
Definitions relating to the Leaderboard section available on the Rate Explorer.
*The definitions in this page are separated by theme in the order that these appear on the explorer. All screens are modulated by the master "time window" toggle at the top right of the screen.*
It is normal to see differences between the effectiveness ratings on the [Pools, Operators and Validators](/documentation/explorer/ethereum/network-views/pools-operators-and-validators/pools-operators-and-validators) front pages and the Trending page. This is because the data in the former refreshes on an hourly basis while the latter refreshes on a daily basis.
## By Effectiveness
A collection of trending operators according to their respective effectiveness scores. Read more about the Effectiveness Rating in the [Rated Effectiveness Rating](/documentation/methodologies/ethereum/rated-effectiveness-rating/rated-effectiveness-rating) section of the docs.
![]()
For the `All-time` calculation in this section, we are only considering validators that have been active for more than 30 days so that we reduce noise. This is equally true for Trending validator indices, as well as for operator groupings (we exclude validators younger than the 30day window from the calculation).
# Overview
Source: https://docs.rated.network/documentation/explorer/ethereum/miscellaneous/miscellaneous
A series of pages that don't quite fit the other categories but present a view on a new slice of the network
Top and bottom performing Operators by Effectiveness
A comprehensive view of Slashing metrics on Ethereum
# Slashings
Source: https://docs.rated.network/documentation/explorer/ethereum/miscellaneous/slashings
This page provides a comprehensive view of the slashing metrics on the Ethereum network.
## Summary Statistics
In this section, we go over the definitions of the all time counters one might find sitting atop the Slashings page. Collectively, they provide a high level understanding of the state of slashings on Ethereum.
![]()
### Validator Keys Slashed
A cumulative count of validator keys that have been slashed on the network, indicating the total number of penalties for validator misbehaviour since the Beacon Chain's inception.
### Discrete Slashing Events
The total number of days in which slashing incidents have been recorded.
### Max Keys Slashed in Incident
The highest number of validator keys slashed in a single incident, showcasing the severity of a particular slashing event.
### Slashing Penalty
The sum of the current slashing penalty and estimated offline penalties until a slashed validator is exited, indicating the financial repercussions for a validator's misbehaviour.
## Slashing Metrics and Slashings Over Time
![]()
### Slashing Metrics
A summary of various metrics related to slashing events including:
* **Blocks with Slashings over All Blocks**: The ratio of blocks containing slashing events to the total number of blocks, showing the prevalence of slashing incidents.
* **ETH Slashed over Rewards Generated**: The ratio of total ETH slashed to rewards generated, indicating the financial impact of slashing relative to network incentives.
* **ETH Slashed over ETH Staked**: The ratio of total ETH slashed to total ETH staked, indicating the financial risk associated with staking.
* **Solos vs. Pros Slashings**: The ratio of slashing incidents between solo validators and validators ran by professional node operators, shedding light on the relative risk profiles of different types of validators.
### Slashings over time
The number of slashing events recorded per month, providing a time-based analysis of slashing incidents.
## Cohort Analysis
A cohort analysis showing the frequency of slashing incidents for validators, grouped by different operator sizes, from solo to professional operators with more than 5,000 keys. The cohorts are mapped against different time periods ranging from 6 months to all time.
![]()
The heat map represents the frequency of slashing events for solo stakers and professional operators. It varies in color from green to red; green indicates a lower number of times slashed, while darker colors like orange and red indicate a higher frequency of slashing events. The numbers within the heatmap cells represent the actual count of times the keys were slashed per cohort, providing a visual representation of slashing frequency across different operator cohorts.
## Leaderboard by Slashing history
A collection of trending operators in terms of how many times they have been slashed or how many times they produced a block with a slashing proof included. The frame of view is all-time slashings to make the analysis comprehensive as slashings are not a frequent phenomenon on the Beacon Chain.
![]()
### Median slash time
This is the subtitle to the slashing counter under "Top operators by times slashed" and represents the median time at which an entity was slashed. The purpose of this is to show how recently or not recently the majority of those incidents took place, which offers a proxy for how each operator has performed since.
### Slasher pedigree
This is the subtitle to the slashing counter under "Top operators slashes reported" and is a direct reference to how [@eth2REKT](https://twitter.com/eth2REKT) attributes titles to the top slashers by slashing proofs included.
Every time a validator slashes another, eth2REKT adds a `+1` on the lifetime count of slashes executed to the entity associated with said validator. For more information on how Rated approaches building entities out of validator keys, please refer to .
The following naming conventions apply to the different classes of lifetime slashes executed:
| Slashings | Tag |
| :-------- | :---------- |
| 1-5 | Noob Saibot |
| 6-10 | Reptile |
| 11-15 | Sub Zero |
| 16-20 | Scorpion |
| 21-30 | Prince Goro |
| 31-50 | Shang Tsung |
| 50+ | Shao Khan |
# Activation queue length
Source: https://docs.rated.network/documentation/explorer/ethereum/network-views/network-overview/activation-queue-length
A more in depth discussion of how Rated computes the overall activation queue length
The activation queue length aims to answer this question:
> "If I were to deposit ETH into the beacon chain contract right now, how long will I have to wait before my validator becomes active?"
To answer this question, first we need to consider how long it takes for the Beacon Chain to recognize a deposit to the beacon chain deposit contract on the execution layer. This used to take a minimum of \~14 hours ([Reference](https://github.com/ethereum/consensus-specs/blob/v1.2.0/specs/phase0/validator.md#process-deposit)) but with the Pectra upgrade, specifically [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110), deposits are now processed on the same block they appear. Now with the gas limit per block being the only limitation for deposit processing, compared to the hardcoded 16 deposit limit per block, deposits can now be recognized almost instantaneously.
To get the amount of time it will take to activate these validators who have made the deposits, we need to get the `churn limit per epoch` which is based on the stake of currently active validators. The churn limit caps the number of validators that can be activated per epoch based on stake. We take the total stake balance of recognized deposits and divide that by the churn limit to get the number of epochs it will take to activate the stake and the related validators (i.e. clear the queue).
We then take the minute equivalent of this number of epochs (6.4 minutes per epoch) and add it to amount of time it takes for the Beacon Chain to recognize deposits to get the full activation queue length in minutes.
# Exit queue length
Source: https://docs.rated.network/documentation/explorer/ethereum/network-views/network-overview/exit-queue-length
A more in depth discussion of how Rated computes the overall exit queue length
The exit queue length aims to answer this question:
> "If an entity or operator were to exit their validator right now, when will it actually exit the Beacon Chain?"
To answer this question, we need to first determine the validators that are currently in the exit queue (`exit_epoch` > `latest_epoch`) and add their exiting stake. We divide this by the current `churn limit per epoch` to get the number of epochs it will take to clear this queue. We then take the minute equivalent of this number of epochs (6.4 minutes per epoch). There is also a minimum 4 epoch wait to fully exit a validator (`MAX_SEED_LOOKAHEAD`) so this needs to be taken into account as well.
The `MAX_SEED_LOOKAHEAD` is the minimum delay on validator activations and exits; it basically means that validators strategically activating and exiting can only affect the seed 4 epochs into the future. See [here](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#aside-randao-seeds-and-committee-generation) for more information.
# Overview
Source: https://docs.rated.network/documentation/explorer/ethereum/network-views/network-overview/network-overview
A series of metrics that attempt to capture the current state of the network at the highest level.
## Global parameters
This part of the page is composed of a series of screens which help users navigate the present and historical states of the Ethereum infrastructure layer, in the highest level of aggregation.
![]()
### Network health metrics
A collection of high level metrics that point to the current state of the network’s consensus layer.
* **Global effectiveness:** An aggregation of the effectiveness ratings of all active network validators, on an average basis. Learn more about the methodology that powers the validator effectiveness metric via [Rated Effectiveness Rating](/documentation/methodologies/ethereum/rated-effectiveness-rating/rated-effectiveness-rating)
* **Inclusion delay & Participation rate:** Learn more about the definitions of those parameters via the [Ethereum](/documentation/explorer/ethereum/ethereum) section in the docs
* **Missed blocks:** The number of missed blocks observed in the network in absolute and percentage terms (over all the blocks produced)
All metrics in this view are sensitive to the time window toggles to the top right.
### Rewards reference rates
A collection of reference rates of return, aggregated across the whole validator active set.
* **Network APR%:** The rate of return that the average validator has earned in the time period toggled.
* **Consensus Layer APR%:** The APR% apportioned exclusively to Consensus Layer rewards.
* **Execution Layer APR%:** The APR% apportioned exclusively to Execution Layer rewards.
* **EL : CL global rewards:** The aggregate ratio of Execution Layer to Consensus Layer rewards earned from all the network's validators. Referencing the screenshot below, this implies that in the time frame toggled for every 2 ETH earned from the EL, network validators in the aggregate earned 8 ETH from the CL.
The parameters that govern the APR% calculations here are the same as in [APR%](/documentation/methodologies/ethereum/apr). All metrics in this view are sensitive to the time window toggles to the top right.
![]()
### Validator set overview
A collection of metrics regarding the current state of the network’s active set.
* **Active validators:** The sum of all validators in "active" state (post-activation queue and attesting) on the network, as captured at the last refresh of the RatedDB.
* **Activation queue length:** The time that it might take for a validator's stake to pass through the activation queue, as of the last discrete hour mark. Learn more via [Activation queue length](/documentation/explorer/ethereum/network-views/network-overview/activation-queue-length).
* **Exit queue length:** The time that it might take for a validator to pass through the exit queue, as of the last discrete hour mark. Learn more via [Exit queue length](/documentation/explorer/ethereum/network-views/network-overview/exit-queue-length).
* **Withdrawal queue length:** The maximum time that it might take for a validator to pass through the exit queue and withdrawal processing queue, as of the last discrete hour mark. Learn more via [Withdrawal queue length](/documentation/explorer/ethereum/network-views/network-overview/withdrawal-queue-length).
The metrics in this view are **NOT** sensitive to the time window toggles, and represent the current state of the network.
### State of network balances
A collection of metrics regarding the state of ETH balances and flows as they relate to the infrastructure layer of the network.
* **Active stake:** An expression of the "active set" in terms of "active balances."
* **Average validator balance:** The "active balance" and consensus layer rewards earned, averaged out across all validators currently active on the network.
* **Rewards distribution:** The distribution of rewards earned across the consensus and execution layers of the network. To learn more about how we separate MEV from priority fees, please refer to [Baseline MEV computation](/documentation/methodologies/ethereum/baseline-mev-computation).
* **Network Gini coefficient:** A measure of inequality across the highest level of entity aggregation on the Ethereum network. Learn more about the methodology that powers this metric via [Gini coefficient measurement](/documentation/methodologies/ethereum/gini-coefficient-measurement).
All metrics in this view are sensitive to the time window toggles, **EXCEPT** the Gini coefficient.
## Activations and Exits
This section of the page illustrates the state of the activation and exit capacity, as well as the distribution of entities taking up the two capacities' respective bandwidths in the time-frame toggled.
![]()
### Computing bandwidth
The churn capacity for a given period is calculated by first getting the per epoch average number of active validators and their total stake for that period. We then take this number and divide it by the `churn limit quotient` which is 2\*\*16 (65,536) to get the `churn limit per epoch`. We then add the churn limit per epoch for all epochs in a period to get the `churn limit for the whole period`.
The stake of activated and exited validators for the specific period is then divided by the period’s churn limit to get the `churn capacity filled`.
To get the total stake balance of validators exited or activated over a period, we use the `exit_epoch` or `activation_epoch` of each validator as determined by the Beacon Chain as reference. We then add up all the validators and their stake which have these reference epochs that have already passed for a given period.
### Breakdown of capacity utilization distribution
The methodology for this set of views is mostly the same as the general churn capacity calculation. The additional step is breaking down the activated and exited validators according to the pool they belong to. If they do not fall under any pool, they are labeled accordingly under `unidentified validators`. For a clearer visualisation, we removed the unfilled capacity to better see the breakdown of pools.
![]()
![]()
## Client distribution
![]()
### Consensus Client Distribution
This is the percentage distribution of consensus clients across the body of validators that make up the whole network.
In order to produce consensus client distribution statistics for validator keys and across entities we are using [blockprint](https://github.com/sigp/blockprint), an open source client classifier. Please note that the results that blockprint produces have a relatively wide statistical confidence interval.
### Execution Client Distribution
This is the percentage distribution of execution clients across the body of validators that make up the whole network.
This execution client distribution statistic is sourced from [Ethernodes](https://ethernodes.org).
## Geographic Distribution
This map shows the latest global geographic distribution of all validators in the Ethereum network. Toggling the "world" icon changes this to show the distribution of the validators run by professional entities which builds off our work in [classifying solo stakers in Ethereum](https://blog.rated.network/blog/solo-stakers).
![]()
In order to produce these mappings, we used our in-house peer-to-peer networking layer probe. This allows us to pinpoint IP addresses of nodes, and resolve those addresses to their geographical locations and other network metadata.
We are actively building features on top of this dataset. If you are interested in learning more and using these features for yourself, get in touch via [hello@rated.network](mailto:hello@rated.network).
## Hosting Provider Distribution
![]()
This graph shows the market share of hosting service providers across Ethereum validators.
In order to produce this distribution, we used our in-house peer-to-peer networking layer probe. This allows us to pinpoint IP addresses of nodes, and resolve those addresses to their hosting service providers and other network metadata.
We are actively building features on top of this dataset. If you are interested in learning more and using these features for yourself, get in touch via [hello@rated.network](mailto:hello@rated.network).
# Withdrawal queue length
Source: https://docs.rated.network/documentation/explorer/ethereum/network-views/network-overview/withdrawal-queue-length
A more in depth discussion of how Rated computes the overall withdrawal queue length
The withdrawal queue length aims to answer this question:
> "If an entity or operator were to exit their validator right now, when would their withdrawn ETH land on their withdrawal address?"
To answer this question, we need to first determine the length of the exit queue. We do this by adding the stake of the validators that are currently in the exit queue (`exit_epoch` > `latest_epoch`). We divide this by the current `churn limit per epoch` to get the number of epochs it will take to clear this queue. We then take the minute equivalent of this number of epochs (6.4 minutes per epoch). There is also a minimum 4 epoch wait to fully exit (`MAX_SEED_LOOKAHEAD`) so this needs to be taken into account as well. These combined then form the part of the queue involved in exiting.
The `MAX_SEED_LOOKAHEAD` is the minimum delay on validator activations and exits; it basically means that validators strategically activating and exiting can only affect the seed 4 epochs into the future. See [here](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#aside-randao-seeds-and-committee-generation) for more information.
Next we need to determine how long it would take to process the current withdrawal processing queue. This is length of time it will take to process all current partial and full withdrawals at a maximum rate of 16 per execution layer block.
For partial withdrawals, these are validators with valid withdrawal credentials (i.e. 0x01) which have balances of more than 32 ETH, and compounding validators (i.e 0x02) with balances of more than 2048 ETH. Their balances above their respective thresholds get withdrawn. This also includes compounding validators who have requested to partially withdraw some of their stake.
Full withdrawals involve validators who have fully exited and have waited 256 epochs afterwards, meaning their `exit_epoch` and `withdrawable_epoch` have passed. We also only consider those who have valid withdrawal credentials and compounding validators. Their full stakes and rewards (i.e. any ETH balance above 0) get withdrawn.
We then add the number of partial and full withdrawals waiting to be processed and divide it by 256 to get the withdrawals processed per epoch (16 per block, 32 blocks per epoch). This gives us the number of epochs it will take to clear the withdrawals waiting to be processed. Multiplying this by 6.4 minutes gives us the minute equivalent of the total epochs.
In actuality, there will be some block proposals missed which means no withdrawals will be processed. We are not taking this into account in this calculation as missed blocks have historically been only around 1% and this is only an estimate which is not aiming to be precise up to the second.
Lastly, to get the full withdrawal queue length from exit to actual withdrawal, we add the minutes calculated related to exiting, and the minutes calculated related to processing the partial and full withdrawals\_.\_
# Network Views
Source: https://docs.rated.network/documentation/explorer/ethereum/network-views/network-views
In this section of the documentation, we cover all you need to know about the various pages and views that make up the 'Network views' section of the Explorer for Ethereum and its testnets.
### Quick Start
Network level view of Ethereum
Deep dive into the various performance, rewards and metadata metrics of different entities that operate on Ethereum
# Classes of aggregation
Source: https://docs.rated.network/documentation/explorer/ethereum/network-views/pools-operators-and-validators/classes-of-aggregation
Definitions of the classes of aggregations Rated groups indices by, as seen under "Entity Views" in the Rated Network Explorer Sidebar.
Rated maintains the most complete library of tags of Ethereum validator indices out there! This is ongoing work we undertake, drawing from (i) on-chain registries, (ii) OS libraries, (iii) Node Operator disclosures, and (iv) clustering work that Rated Labs performs over the dataset. These different classes of entities are found under the "Entity views" section in the Explorer sidebar and represent different, but often overlapping, views of the network.
Node Operators and Pools can now get their validator sets onboarded on the Network Explorer in a self-serve fashion. See [here for Node Operators](/rated-api/api-reference/v0/ethereum/self-report/self-report) and [here ](https://bit.ly/RatedPoolsOnboarding)[for Pools](https://bit.ly/RatedPoolsOnboarding).
In this section, we outline the semantics across the four distinct views that one can find in the Rated Network Explorer.
![]()
### Pools
The highest order of commonality among validators. What we conceptualise as `pools` in the Ethereum staking value chain, is the capital aggregation layer––in the broadest sense possible. In that sense, a good definition is "custodial or non custodial applications or interfaces, that facilitate the allocation of capital to node operators." Among those we bundle:
* Liquid staking pools (e.g. Lido or Rocketpool) that operate exclusively on-chain.
* Custodial exchanges or custodians that offer staking as a product to their users (e.g. Coinbase or Bitcoin Suisse).
* Interfaces that intermediate and/or facilitate users allocating capital to node operators (e.g. Ledger Live).
### Node Operators
The operating layer of Ethereum validators. In this category we bundle professional entities that task themselves with running validator nodes in custodial or non-custodial fashion. These often are the recipients of "delegations" from pools.
### Addresses
The highest order of pure on-chain commonality between validators. While we recognize that various deposit and withdrawal patterns can link unrelated capital or operational layers, we believe there's significant value in such groupings. This is particularly true for smaller node operators and solo stakers. For convenience, we've enabled a toggle allowing you to view these groupings either by deposit or withdrawal addresses using the address filter. The Explorer enables users to search a deposit or withdrawal address by passing a specific address (e.g. `0x8cf07ac011d6c39fc28f6a946df192a85eb3a723`) to the search bar.
### Validator indices
Ungrouped validator index pages. The Explorer enables users to search a validator by passing a specific validator index (e.g. `88888`) or its associated pubkey to the search bar.
![]()
![]()
# Entity metrics drill-down
Source: https://docs.rated.network/documentation/explorer/ethereum/network-views/pools-operators-and-validators/entity-metrics-drill-down
Definitions of variables that appear in the Pool, Operator, Addresses and Validator drill-down pages of the Rated Explorer.
## At a glance
*Definitions of the variables that appear on the horizontal bar at the top of the entity level pages of the Rated Explorer.*
![]()
### Number of validators
The number of validators that map back to any given entity that is in focus at the time. To learn more about how we aggregate those, please visit [Classes of aggregation](/documentation/explorer/ethereum/network-views/pools-operators-and-validators/classes-of-aggregation).
### Network penetration
This is the percentage distribution of stake that maps under any given pool.
We calculate this as:
$$
\text{Network penetration} = \frac{\text{active stake in pool}}{\text{active stake on the Ethereum Beacon Chain}}
$$
Where "active stake" means the sum of at least 32 ETH increment balances that map to any given pool.
In order for a validator to become "active" on the network, it needs to (i) be funded with a balance of of at least 32 ETH, and to (ii) get past the activation queue stage.
### Backward looking APR%
Please refer to the [APR%](/documentation/methodologies/ethereum/apr) section of the documentation for a deep dive into how we compute this metric.
### Effectiveness Rating
The Rated model of validator performance. The colour coding in each of those values hints to the relative performance of the entity.
For more information on how this is computed and the methodology behind it, please refer to the [Rated Effectiveness Rating](/documentation/methodologies/ethereum/rated-effectiveness-rating/rated-effectiveness-rating) page. You can also learn more about how we rank for relative performance via [Rating percentiles](/documentation/methodologies/ethereum/rating-percentiles).
## Effectiveness breakdown
*Definitions of the variables that appear on the Effectiveness Breakdown section of the entity level pages of the Rated Network Explorer.*
![]()
### Participation Rate
The number of epochs a validator’s attestation was included on-chain divided by the number of epochs that validator is active, aggregated across all validator indices associated with a given operator address.
### Inclusion Delay
The average of the distance between the slot a validator’s attestation is expected by the network and the slot the attestation is actually included on-chain, across all validators associated with an operator address.
### Correctness
The combined average between correct target votes, head votes, and source votes. This is done by adding the votes together then dividing by triple the number of attestations. Learn more by diving deeper into the [Rated Effectiveness Rating](/documentation/methodologies/ethereum/rated-effectiveness-rating/rated-effectiveness-rating) section of the documentation.
### Effectiveness Rating
The Rated model of validator performance.
For more information on how this is computed and the methodology behind it, please refer to the [Rated Effectiveness Rating](/documentation/methodologies/ethereum/rated-effectiveness-rating/rated-effectiveness-rating) page.
![]()
## Performance metrics
*Definitions of variables that appear in "Performance metrics" section of the Entity views.*
### Source vote accuracy
The amount of epochs a valid vote for the source checkpoint was included in the attestation divided by the number of epochs a validator index has been active, averaged across the sum of validators associated with said operator address.
### Target vote accuracy
The amount of epochs a valid vote for the target checkpoint was included in the attestation divided by the number of epochs a validator index has been active, averaged across the sum of validators associated with said operator address.
### Head vote accuracy
The amount of epochs a valid vote for the head of the chain was included in the attestation divided by the number of epochs a validator index has been active, averaged across the sum of validators associated with said operator address.
### Proposal Miss Rate
The average of Failed Block Proposals divided by Proposal Slots Attributed across the sum of the validator indices associated with said operator address.
## Consensus layer metrics
*Definitions of variables that appear in "Consensus layer metrics" section of the Entity views.*
### Consensus rewards earned
The sum of the net rewards earned by said validator or group of validators by performing consensus layer duties.
### Total penalties accrued
The sum of offline penalties accrued on all the validator indices associated with said entity, adjusted for the Rating Time Window toggled. For more information on how we model penalties, see [Penalties computation](/documentation/methodologies/ethereum/penalties-and-missed-rewards/penalties-computation).
### Times slashed
The sum of slashed validator indices associated with said operator address.
### Consensus client distribution
This is the percentage distribution of consensus clients said operator or entity is running across the body of validator indices that it operates.
In order to produce client distribution statistics for validator keys and across entities we are using [blockprint](https://github.com/sigp/blockprint), an open source client classifier. Please note that the results that blockprint produces have a relatively wide statistical confidence interval.
## Execution layer metrics
*Definitions of variables that appear in "Execution layer metrics" section of the Entity views.*
### Priority fees earned
The sum of priority fees that said entity (i.e. grouping of validators) has earned through proposing blocks, over the time-frame in question. For a more in depth discussion of how priority fees (aka tips) are computed, please refer to [ethereum.org](https://ethereum.org/en/developers/docs/gas/).
### Baseline MEV collected
Rated's estimation of the lower bound MEV of said entity has collected through proposing blocks, over the time-frame in question. See [Baseline MEV computation](/documentation/methodologies/ethereum/baseline-mev-computation) for a detailed discussion of the methodology Rated is using to surface baseline MEV.
### Block rewards missed
The total value that said entity has forgone by failing to propose blocks in slots that its validators were awarded block proposal duties. Dive deeper into how we calculate the value of a missed block via [Execution missed rewards computation](/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation/execution-missed-rewards-computation).
### Relays Supported
Since The Merge, validators have the ability to outsource block production to specialized entities called "Builders", and effectively "shop" for pre-packaged blocks through an interface agent called the "Relay". The Block Space Distribution column on the Explorer displays the distribution of blocks as it relates to the origin of those blocks. The explorer currently segregates between the different Relays blocks were procured from, as well as blocks that were built locally (showing in the distribution bars as "vanilla blocks").
We source this data directly from the public Relay Data APIs. Dive deeper via [Relays](/documentation/explorer/ethereum/pbs-landscape/relays/relays).
## Aggregate rewards statistics
*Definitions of variables that appear in the "*Aggregate rewards statistics*" section of the Entity views.*
### Proposed blocks
The number of blocks the Entity in focus has proposed in the toggled time period.
To quickly compute how many blocks the entity missed, you can divide **Proposed blocks** by the entity's **Proposal miss rate**.
### Total rewards earned
The sum of Execution Layer and Consensus Layer rewards an entity has earned over the selected time-frame.
### Total rewards missed
The sum of Execution Layer and Consensus Layer rewards an entity has missed over the selected time-frame. This is a measure of opportunity cost that we go to great lengths to compute.
You can dive deeper into the methodologies that power **Total rewards missed** by visiting [Validator missed rewards computation](/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation).
### Backward looking APR%
Please refer to the [APR%](/documentation/methodologies/ethereum/apr) section of the documentation for a deep dive into how we compute this metric.
## Activations and Withdrawals status
This particular section of the page comes in two flavours. On all toggles except for the `1d` view, the page shows historical statistics relating to the validators said entity has activated or exited.
![]()
However, when toggling `1d`, the frame of reference changes to the "spot" view. This means that at any given point in time, this view will give you information on the current state of activations and withdrawals as of the last discrete hour mark.
![]()
# Overview
Source: https://docs.rated.network/documentation/explorer/ethereum/network-views/pools-operators-and-validators/pools-operators-and-validators
All the content in this page translates equally to the 'Pools' and 'Node Operators' list views. We will be drilling down on a the Pool page for ease of referencing.
### Counters
At the top of the Pools list page sit four counters that show the aggregate performance of the network on the previous completed day. These are normally helpful in quickly referencing how an entity is performing compared to the network average.
![]()
For a deeper dive into what each of these metrics represents, please visit the [Effectiveness breakdown](/documentation/explorer/ethereum/network-views/pools-operators-and-validators/entity-metrics-drill-down#effectiveness-breakdown) page in the documentation.
Each list contains the following metrics:
* Name
* Network penetration
* Consensus client distribution
* block space distribution
* APR%
* RAVER (Rated Effectiveness Rating)
**You can sort the table by Network Penetration, APR% and RAVER.** You need simply click on the metric you want to sort by!
![]()
### Network penetration
This is the percentage distribution of stake that maps under any given pool.
We calculate this as:
$$
\text{Network penetration} = \frac{\text{active stake in pool}}{\text{active stake on the Ethereum Beacon Chain}}
$$
Where "active stake" means, the sum of at least 32 ETH increment balances that map to any given pool.
In order for a validator to become "active" on the network, it needs to (i) be funded with a balance of at least 32 ETH, and to (ii) get past the activation queue stage.
### Client distribution
This is the percentage distribution of consensus clients an operator or entity is running across the body of validator indices that it operates.
In order to produce client distribution statistics for validator keys and across entities, we are using [blockprint](https://github.com/sigp/blockprint), an open source client classifier. Please note that the results that blockprint produces have a relatively wide statistical confidence interval.
### Block space distribution
Since The Merge, validators have the ability to outsource block production to specialized entities called "Builders", and effectively "shop" for pre-packaged blocks through an interface agent called the "Relay". The Block Space Distribution column on the Explorer displays the distribution of blocks as it relates to the origin of those blocks. The explorer currently segregates between the different Relays blocks were procured from, as well as blocks that were built locally (showing in the distribution bars as "vanilla blocks").
### APR%
Please refer to the [APR%](/documentation/methodologies/ethereum/apr) section of the documentation for a deep dive into how we compute this metric.
### Effectiveness Rating
The Rated model of validator performance. The colour coding in each of those values hints to the relative performance of the entity.
For more information on how this is computed and the methodology behind it, please refer to the [Rated Effectiveness Rating](/documentation/methodologies/ethereum/rated-effectiveness-rating/rated-effectiveness-rating) page. You can also learn more about how we rank for relative performance via [Rating percentiles](/documentation/methodologies/ethereum/rating-percentiles).
# "View by" toggle
Source: https://docs.rated.network/documentation/explorer/ethereum/network-views/pools-operators-and-validators/view-by-toggle
Making the most of the Main operator page by shifting between views.
There are normally two view options available to any drill-down window in an Entity view; view by "Operator" and by "Aggregate". We explain the outline of these views in the sections below.
In cases where no more "drill-downs" are available, which normally are either Entities that we have no more granular information on, or views of Entities that reach the maximum granularity level available, the view defaults to "View by Aggregate".
### View by "Operator"
In cases where a pool might have a public registry of its constituent members, we offer two views to it. The default view is the "Operator" view, where users can look through a breakdown of a pool by its constituent members. You can enable this by clicking on the "View by Operator toggle".
![]()
Equivalently when the same view is available on the Node Operator section of the explorer, users can look through the stake that a given operator runs, apportioned by "Pool" it maps to (hinted at by the relevant orange tag). The share that comes with no "Pool" tag relates to validators that are operated by said Node Operator which do not map back to any staking pool.
![]()
The variables exposed in the table are the equivalent to those explained in depth in the [Ethereum](/documentation/explorer/ethereum/ethereum) section of the documentation.
### View by "Aggregate"
The Aggregate Operator view exposes all kinds of statistics relating to the Pool, Operator, Deposit Address, or Validator Index in focus. You can enable it by toggling "Aggregate" on the *view by* toggle.
The top half view gives you a time series of the [Rated Effectiveness Rating](/documentation/methodologies/ethereum/rated-effectiveness-rating/rated-effectiveness-rating) over the toggled time period, complemented with a series of counters. We have covered the semantics of which in the [Effectiveness breakdown](/documentation/explorer/ethereum/network-views/pools-operators-and-validators/entity-metrics-drill-down#effectiveness-breakdown) section.
![]()
The bottom half of the page exposes statistics relating to performance, rewards, different configurations of the operation (in the aggregate), and the status of the operation relating to activations and withdrawals of validators they operate or are associated with.
![]()
You can learn more about what each of these metrics represent, and the methodologies that power them in the following sections.
# Builder pubkeys
Source: https://docs.rated.network/documentation/explorer/ethereum/pbs-landscape/builders/builder-pubkeys
A repo of all the known pubkeys that map to builder entities.
This list contains keys that we have mapped to builder entities by look at the extradata field on blocks we see via the Relay APIs. If you are a builder and find inaccuracies under your entity, please get in touch via [hello@rated.network](mailto:hello@rated.network).
*Last updated: Aug 10, 2023*
```
0xb066a09b52c583db4c8bb1eba3c629f20b96d6f9a355b0615da653c8dbc136b85f467e77a4225cde9eadcd45f8693900
```
```
0x96a59d355b1f65e270b29981dd113625732539e955a1beeecbc471dd0196c4804574ff871d47ed34ff6d921061e9fc27
```
```
0xb5d883565500910f3f10f0a2e3a031139d972117a3b67da191ff93ba00ba26502d9b65385b5bca5e7c587273e40f2319
```
```
0xa21a2f4807a2bcb6b07c10cea241322e0910c30869c1e4eda686b0d69bdcb74d2a140ef994afcf0bb38e0b960df4d2ee
```
```
0xacb407cfb554255db2fbbb320f79bb7f1cc1e8d2dc43324e8e31baafd0836340d49c43eebc51828f53bf6d364f9ac207
```
```
0xaec4ec48c2ec03c418c599622980184e926f0de3c9ceab15fc059d617fa0eafe7a0c62126a4657faf596a1b211eec347
```
```
0x8dde59a0d40b9a77b901fc40bee1116acf643b2b60656ace951a5073fe317f57a086acf1eac7502ea32edcca1a900521
```
```
0xafc9274fe595e8cff421ab9e73b031f0dff707ea1852e2233ff070ef18e3876e25c44a9831c4b5f802653d4678ccc31f
```
```
0x94aa4ee318f39b56547a253700917982f4b737a49fc3f99ce08fa715e488e673d88a60f7d2cf9145a05127f17dcb7c67
```
```
0x80c7311597316f871363f8395b6a8d056071d90d8eb27defd14759e8522786061b13728623452740ba05055f5ba9d3d5
```
```
0x976e63c505050e25b70b39238990c78ddf0948685eb8c5687d17ba5089541f37dd3c45999f2db449eac298b1d4856013
```
```
0xb086acdd8da6a11c973b4b26d8c955addbae4506c78defbeb5d4e00c1266b802ff86ec7457c4c3c7c573fa1e64f7e9e0
```
```
0x8b8edce58fafe098763e4fabdeb318d347f9238845f22c507e813186ea7d44adecd3028f9288048f9ad3bc7c7c735fba
```
```
0x82801ab0556f7df1fb9bb3a61ca84beea8285a8dc3c455a7ea16a8b2993fe06058e0e7d275b28ea5d9f2ae995aa72605
```
```
0x965a05a1ba338f4bbbb97407d70659f4cea2146d83ac5da6c2f3de824713c927dcba706f35322d65764912e7756103e2
```
```
0xb9b50821ec5f01bb19ec75e0f22264fa9369436544b65c7cf653109dd26ef1f65c4fcaf1b1bcd2a7278afc34455d3da6
```
```
0x95701d3f0c49d7501b7494a7a4a08ce66aa9cc1f139dbd3eec409b9893ea213e01681e6b76f031122c6663b7d72a331b
```
```
0xaa1488eae4b06a1fff840a2b6db167afc520758dc2c8af0dfb57037954df3431b747e2f900fe8805f05d635e9a29717b
```
```
0xa66f3abc04df65c16eb32151f2a92cb7921efdba4c25ab61b969a2af24b61508783ceb48175ef252ec9f82c6cdf8d8fd
```
```
0x8000008a03ebae7d8ab2f66659bd719a698b2e74097d1e423df85e0d58571140527c15052a36c19878018aaebe8a6fea
```
```
0xa00000a975dffbd1ef61953ac6c90b52b70eb0188eb9d030774346c9248f81e875f7e8bc56c4bbbda297a9543cfa051d
```
```
0xa88888a1fbd3d15da31c44544c4522b5ad85dd6128eaaa5036ed7a8937a946b2eb887ddbd892d981015038ebd14ea740
```
```
0x8638492723b6376bf83ec6eeff53b7b5d490219501e24a722f39af65a49672441d0320aea5659608bcab37e395cd4b73
```
```
0xab847befe59b5effffa12f47acf44cbf8ef875e7c891a4ee9e9c483254cf9a55f5ed688e43ff5bc6cd9276e99091921b
```
```
0xa31892c0466813868f0cd8d3255dab5f84ae1a6d4a28a85bd85a68c30de311b5ad9b535bc611daa6bcf2365677f7a3fd
```
```
0x91afe2631915f3fbd83f1d75e13ae8597b593441344bb55bf542b9bac31f662d1c820cafe4cde17291f115bb68a9945a
```
```
0x8d6e6c1b552fb5acba2a08eb882008f93f18f0e9c36ff96983778a3c167dd121ced4d214ae5380a9527a8f5ec64e3efd
```
```
0x8c344feeb5426018c1855bc33cf739c15ce43fe780fc13275163f3c33075318619e6b2151407f87a970be24443c9cea4
```
```
0x987ff80fcf6c5ee530f4a4352884cb89fc5f57ab287e58dd44d641f3bbe4cc40633d6ba0bbecc9c81b1d5be40a2abb99
```
```
0x82ba7cadcdfc1b156ba2c48c1c627428ba917858e62c3a97d8f919510da23d0f11cf5db53cb92a5faf5de7d31bf38632
```
```
0x8bc8d110f8b5207e7edc407e8fa033937ddfe8d2c6f18c12a6171400eb6e04d49238ba2b0a95e633d15558e6a706fbe4
```
```
0xb8fceec09779ff758918a849bfe8ab43cea79f6a98320af0af5b030f6a7850fcc5883cb965d02efb10eed1ffa987e899
```
```
0xb194b2b8ec91a71c18f8483825234679299d146495a08db3bf3fb955e1d85a5fca77e88de93a74f4e32320fc922d3027
```
```
0xa971c4ee4ac5d47e0fb9e16be05981bfe51458f14c06b7a020304099c23d2d9952d4254cc50f291c385d15e7cae0cf9d
```
```
0xa4fb63c2ceeee73d1f1711fadf1c5357ac98cecb999d053be613f469a48f7416999a4da35dd60a7824478661399e6772
```
```
0xa412007971217a42ca2ced9a90e7ca0ddfc922a1482ee6adf812c4a307e5fb7d6e668a7c86e53663ddd53c689aa3d350
```
```
0x8e39849ceabc8710de49b2ca7053813de18b1c12d9ee22149dac4b90b634dd7e6d1e7d3c2b4df806ce32c6228eb70a8b
```
```
0x91970c2db7c12510acb2e9c45844f7de602f83a7f31064f7ca04a807b607d7aebfc0abda73c036a92e5c3e56ebca04b7
```
```
0xa5eec32c40cc3737d643c24982c7f097354150aac1612d4089e2e8af44dbeefaec08a11c76bd57e7d58697ad8b2bbef5
```
```
0x8c0d45833884744d8cc4bb3438c3e93bcbc1436a25da5da44cc357e93bc0a7eea1d4664c287c4c63958eedada3846ae8
```
```
0xaa1488eae4b06a1fff840a2b6db167afc520758dc2c8af0dfb57037954df3431b747e2f900fe8805f05d635e9a29717b
```
```
0x8c0d45833884744d8cc4bb3438c3e93bcbc1436a25da5da44cc357e93bc0a7eea1d4664c287c4c63958eedada3846ae8
```
```
0x8ed74896fb129ac7f48d6a2908400044103b65d5c4e8f63feafd849f90fc174a4b71206a51b9453c12292bab3a92a4a2
```
```
0x8ea1393f49d894ae22ec86e38d9aeb64b8336dac947e69cb8468acf510d010ce0b51b21ac3e1244bdb91c52e020ea525
```
```
0x8e96593b5418b162e7f7d5c165fef2566a67d5e03357baa780a2956a6f2c0b6426c20d7f82f527bcaa1719ebbc8d6048
```
```
0x8ee8f19da59077f203110aa1c897eac75d93dfb0e3675fe1a64e4d3f2fbc0c652551297c8ff4210d790d2bf8d4fb7104
```
```
0x8ef6185b16ab8fe018ba98c9f514522a60e437be0e8d8b88ade174d3b859256ceb464f766c268458bfd33142b2913a0e
```
```
0x8eb772d96a747ba63af7acdf92dc775a859f76a77e4c6ed124dca6360e74e4e798a75a925eb8fd0dde866317fff18ad0
```
```
0x8ecd091acecda7907aefa2a86253de9e4b4ba3d1d69bf45be9289bb6876d9e611d5281865db2c792ae2dca3001b0a4a8a
```
```
0x81babeec8c9f2bb9c329fd8a3b176032fe0ab5f3b92a3f44d4575a231c7bd9c31d10b6328ef68ed1e8c02a3dbc8e80f9
```
```
0xa1dead01e65f0a0eee7b5170223f20c8f0cbf122eac3324d61afbdb33a8885ff8cab2ef514ac2c7698ae0d6289ef27fc
```
```
0x81beef03aafd3dd33ffd7deb337407142c80fea2690e5b3190cfc01bde5753f28982a7857c96172a75a234cb7bcb994f
```
```
0xb89b9308fbc6c2998c7e60e39424b858c74b02c234b3e0fa5ecf7c3971208dfa5f92e0bdbe16fc24abfd71c248acf0f9
```
```
0x81babad2d5fd9413c942f49bfd86bc1dca5b02ff4cd065a10c7ab05713e63883056e6a87777e236424574aa25bbe3e99
```
```
0xa35e2b13ef528efbed8d2f709c0eb9eceb1225ed0605a653ba923588b0150c94772a9ba1c809d048e321f6b73d905c60
```
```
0xa1defa73d675983a6972e8686360022c1ebc73395067dd1908f7ac76a526a19ac75e4f03ccab6788c54fdb81ff84fc1
```
```
0x81babeec8c9f2bb9c329fd8a3b176032fe0ab5f3b92a3f44d4575a231c7bd9c31d10b6328ef68ed1e8c02a3dbc8e80f9
```
```
0xa1dead01e65f0a0eee7b5170223f20c8f0cbf122eac3324d61afbdb33a8885ff8cab2ef514ac2c7698ae0d6289ef27fc
```
```
0x81beef03aafd3dd33ffd7deb337407142c80fea2690e5b3190cfc01bde5753f28982a7857c96172a75a234cb7bcb994f
```
```
0xb89b9308fbc6c2998c7e60e39424b858c74b02c234b3e0fa5ecf7c3971208dfa5f92e0bdbe16fc24abfd71c248acf0f9
```
```
0x81babad2d5fd9413c942f49bfd86bc1dca5b02ff4cd065a10c7ab05713e63883056e6a87777e236424574aa25bbe3e99
```
```
0xa35e2b13ef528efbed8d2f709c0eb9eceb1225ed0605a653ba923588b0150c94772a9ba1c809d048e321f6b73d905c60
```
```
0xa1defa73d675983a6972e8686360022c1ebc73395067dd1908f7ac76a526a19ac75e4f03ccab6788c54fdb81ff84fc1
```
```
0xabc387dff20ff4bda974b7f3041ea857d591681cc03271519196587a2d6b30c953ea4df11acf637db76f462834a8c80e
```
```
0xb3d48d36bb54c159417d3e87a890ff6bf513b14bdba5b823456813dde13afdf78d0f29e9dc2f798d734ee2abaad17182
```
```
0x984357f7e6489e5e04049920bf63087ee6904272e937371f27ae84c064c36ae28f0f7bbb9f127fcd736df63a34172c11
```
```
0x84b02bdb674a28dea0467d3dded2b4aad11c0c5dba79b3d11c38476e2f45eb937ac078492781cca8d2123c2c574a7eb8
```
```
0xb3a4b137b0224321813151568035e4c0dd7af8a2523a606a73b7d459a6202e7d6d58f2149a32bc2fe85980866fdc0c92
```
```
0xaa1488eae4b06a1fff840a2b6db167afc520758dc2c8af0dfb57037954df3431b747e2f900fe8805f05d635e9a29717b
```
```
0x8d0187110022b21a97a265d9b98aae51cdd563e53ceacb6ca9ebd0dcdac91866a52aff73836d95ef1e587591291abb02
```
```
0xb1b734b8dd42b4744dc98ea330c3d9da64b7afc050afed96875593c73937d530a773e35ddc4b480f9d2e1d5ba452a469
```
```
0xa0d0dbdf7b5eda08c921dee5da7c78c34c9685db3e39e81eb91da94af29eaa50f1468813c86503bf41b4b51bf772800e
```
```
0xb5a688d26d7858b38c44f44568d68fb94f112fc834cd225d32dc52f0277c2007babc861f6f157a6fc6c1dc25bf409046
```
```
0x906c185200638862772a530fbe2ef16c1f6539e0b68c278e1088f635d81bd08562be688ceea88028421016c7c5fc7101
```
```
0xa82f9afce834eeb0e6d9aa5bb99d2d87a2ba6d97f6f7db6b73646965f3dec263f8dc8e6e2a0d2d9acd6253c383f08c19
```
```
0x85beff526119fe3fbc718e207140cb7bb154c9dfc03b502bc569434a83c28758fa0d5116610dd9f71b9dba212d54f4bd
```
```
0xaa1488eae4b06a1fff840a2b6db167afc520758dc2c8af0dfb57037954df3431b747e2f900fe8805f05d635e9a29717b
```
```
0x85b603e6b0b27e117e80c67a615060b3d0441ae2aee163cc49f30c964155e46fbd324b25c0fbadf9f4995a4b8b245be3
```
```
0x8070d2fbed08a3f251189cf304b5aa4de1c6817189e6779fa91bfed92a54c14ad81a86e3860040a36cbe6225ad5961e2
```
```
0xac193b0f72fa96fab3695697f01a27441fdc70fe38bc6ad1eb4fd887f84025eb1708cd1678b6b4d7a63cc62039845251
```
```
0xac4aac0f9ce2bafd4bab348c6b4d8a31e583043baea9bf0a619ebcd8568694b64888f0c9ca40c1c1f93e9c34e1b39cb1
```
```
0xa65a9e75ae055aefbd850ff8e3baf8cb999814038f8e48dd34447ecf3e3c5c0a631fc0c1147b5b1c74aa389754612882
```
```
0x89551cb5def7a710d58c3f3c0b234266df9cab138d6bd79e58b03c3681030751f1aab2e2b08a706e2aba6db23ee1fb8b
```
```
0x86d59ae03894b181e2935ec684912571da5888a6b2bd7870d58411eace02416a8d04aa0ba33545fc87f833d06b64253f
```
```
0x8b32405861c6b674de8db46dfeb1f7c13ebc2f9e038994efa63b029cd39e36f7324a8401200889e2bbd5f07827b2c895
```
```
0x98e7e3f6e08470add6bc2d312ed33cd8d59775782c85d7e7f98a34e792f1c4326b1c89846723e7fbe826a0cd559bc574
```
```
0x958514edaa1889e029548916327f3090da2de32afa4d9e2aff8489070e3bf7639000735adf02d86aa6bc8ec287045570
```
```
0x92183c4b21b5264659a3af2fb631a7f291d3e8fcbfd895f1952145fd4c093cb3e0831d1732fa5c6cff85025a56fb07da
```
```
0x945fc51bf63613257792926c9155d7ae32db73155dc13bdfe61cd476f1fd2297b66601e8721b723cef11e4e6682e9d87
```
```
0x83d3495a2951065cf19c4d282afca0a635a39f6504bd76282ed0138fe28680ec60fa3fd149e6d27a94a7d90e7b1fb640
```
```
0x978a35c39c41aadbe35ea29712bccffb117cc6ebcad4d86ea463d712af1dc80131d0c650dc29ba29ef27c881f43bd587
```
```
0xacfdcf458829f4693168a57d0659253069d687682bc64ec130d935ecb6e05ccfb80c138bd3cf53546c86715696612ec8
```
```
0x8e6df6e0a9ca3fd89db2aa2f3daf77722dc4fbcd15e285ed7d9560fdf07b7d69ba504add4cc12ac999b8094ff30ed06c
```
```
0x8aab0ed724d2c7f94af139bd2249ab511f08474ac69e761e56918403c81c358f5f8a6d61c62a86dc4cd7bcad935f49d9
```
```
0x805492e33b23293a17d0defd5be6abe0449390e188fda1826a5417a99ae9ec04e7b334676d84428b505ce6386ed9992a
```
```
0xb67eaa5efcfa1d17319c344e1e5167811afbfe7922a2cf01c9a361f465597a5dc3a5472bd98843bac88d2541a78eab08
```
```
0x94a076b27f294dc44b9fd44d8e2b063fb129bc85ed047da1cefb82d16e1a13e6b50de31a86f5b233d1e6bbaca3c69173
```
```
0xb26f96664274e15fb6fcda862302e47de7e0e2a6687f8349327a9846043e42596ec44af676126e2cacbdd181f548e681
```
```
0x95c8cc31f8d4e54eddb0603b8f12d59d466f656f374bde2073e321bdd16082d420e3eef4d62467a7ea6b83818381f742
```
```
0xabf1ad5ec0512cb1adabe457882fa550b4935f1f7df9658e46af882049ec16da698c323af8c98c3f1f9570ebc4042a83
```
```
0xa630217edeeb6e4f85bce4e2766559aa58f94ee43c8a16900c1d95dae9801efc551c25d950f362ec8daeec0769b69bcb
```
```
0xb5290d65b0b3f145630cf89c132dd647ea046c1f7fbc79df727c7c372fa18b0c88b84dd48da2b4a8ef7602ba293469cd
```
```
0xb34a533cc69e98573ce6eef4c8364dc873ae677eaa644a51c8fe3367ee7ef1b1aa9d9458d59ec86ee8e25a7720dcc107
```
```
0xa4e5b8d42b092d9db7ad828c538dd47ee8f21af920b79b79d47559a7e3dbc026c7a348a5b0526efc5d66c64abce198fa
```
```
0x89c70d784ed1c7752a15be119dbbc7f077c98ad28ee44b2b280c27d2ad760fa2f31f1caac1b333689c981df9627fbac7
```
```
0x8c4c0e9af00edb8a25fa8684e07118c0cbd49459b87337953a4c3d6db57b896f6914070192fb404f22917fa44cf2aef4
```
```
0xa46444fdef3a72da9a069e95da0703fdb3ea5a5d0ee8633b55bc71d46ec79b888582749059c468be1cf62808a57bdaba
```
# Overview
Source: https://docs.rated.network/documentation/explorer/ethereum/pbs-landscape/builders/builders
A series of metrics that compose a high level view of the builder market in post-Merge Ethereum.
## At a glance
In this section, we go over the definitions of the counters one might find that sit atop the Builders page.
![]()
### Value of blocks built
The total ETH value of blocks created by builders in the time period toggled. This should be equal to the total value relayed field in the Relay Landscape page.
### Active builders
The number of active builder entities involved in crafting mainnet blocks over the time period toggled. Learn more about how we put those entity views together in [our docs](/documentation/explorer/ethereum/network-views/network-views).
### Top 3 builders share
The number of blocks built by the top 3 builder entities, divided by the total number of blocks built in the period toggled.
### Most valuable block
The most valuable block built in the time period toggled.
## Breakdown by Builder
We aggregate builder public keys according to commonalities observed in the `extra-data` field procured by MEV Relay Data APIs.
![]()
### Market share
The number of blocks built by a single (aggregated) entity, over the total number of blocks built. We compute market share based on block count, and not by the sum of value of those blocks.
### Relay distribution
The distribution of which relays have those builder entities been sending their payloads to.
### Avg transactions included
The distribution of which relays have those builder entities been sending their payloads to.
### Exclusive order flow
A measure of exclusivity in the transaction space that makes up each individual builder entity’s block mass.
The way we compute this is by first looking at the addresses in blocks involved in transactions that are only appearing in one builder's blocks (i.e. do not appear in any other builders’ blocks). We then map those to the number of transactions that they participated in, and produce a ratio such that:
$$
Exclusive\_order\_flow == \frac{exclusive\_txs}{total\_txs\_packed\_in\_blocks}
$$
**Please note:** this is a rough and speculative approach that we would love to evolve together with the community. To propose amends and improvements, please get in touch on [our Discord](https://bit.ly/ratediscord).
### Median block value
The median ETH value stemming from the population of blocks produced by said block builder entity.
# PBS Landscape
Source: https://docs.rated.network/documentation/explorer/ethereum/pbs-landscape/pbs-landscape
Here you can follow the development of the evolving landscape of Proposer-Builder Separation (PBS) in post-Merge Ethereum.
## Quick start
In this page we track the most important statistics relating to the operation of MEV Relays introduced with the advent of mev-boost in PoS Ethereum
A series of metrics that compose a high level view of the builder market in post-Merge Ethereum
# Relay addresses
Source: https://docs.rated.network/documentation/explorer/ethereum/pbs-landscape/relays/relay-addresses
A repo of all the known Relay addresses.
```
https://0xa15b52576bcbf1072f4a011c0f99f9fb6c66f3e1ff321f11f461d15e31b1cb359caa092c71bbded0bae5b5ea401aab7e@aestus.live
```
```
https://0xa7ab7a996c8584251c8f925da3170bdfd6ebc75d50f5ddc4050a6fdc77f2a3b5fce2cc750d0865e05d7228af97d69561@agnostic-relay.net
```
```
https://0x9000009807ed12c1f08bf4e81c6da3ba8e3fc3d953898ce0102433094e5f22f21102ec057841fcb81978ed1ea0fa8246@builder-relay-mainnet.blocknative.com
```
```
https://0x8b5d2e73e2a3a55c6c87b8b6eb92e0149a125c852751db1422fa951e42a09b82c142c3ea98d0d9930b056a3bc9896b8f@bloxroute.max-profit.blxrbdn.com
```
```
https://0xad0a8bb54565c2211cee576363f3a347089d2f07cf72679d16911d740262694cadb62d7fd7483f27afd714ca0f1b9118@bloxroute.ethical.blxrbdn.com
```
```
https://0xb0b07cd0abef743db4260b0ed50619cf6ad4d82064cb4fbec9d3ec530f7c5e6793d9f286c4e082c0244ffb9f2658fe88@bloxroute.regulated.blxrbdn.com
```
```
https://0xb3ee7afcf27f1f1259ac1787876318c6584ee353097a50ed84f51a1f21a323b3736f271a895c7ce918c038e4265918be@relay.edennetwork.io
```
```
https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net
```
```
https://0x95a0a6af2566fa7db732020bb2724be61963ac1eb760aa1046365eb443bd4e3cc0fba0265d40a2d81dd94366643e986a@blockspace.frontier.tech
```
```
https://0x98650451ba02064f7b000f5768cf0cf4d4e492317d82871bdc87ef841a0743f69f0f1eea11168503240ac35d101c9135@mainnet-relay.securerpc.com
```
```
https://0x84e78cb2ad883861c9eeeb7d1b22a8e02332637448f84144e245d20dff1eb97d7abdde96d4e7f80934e5554e11915c56@relayooor.wtf
```
```
https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf1a38af0a8fe88b9e4b1f61f236d2e64d95733327a62@relay.ultrasound.money
```
```
https://0x8c7d33605ecef85403f8b7289c8058f440cbb6bf72b055dfe2f3e2c6695b6a1ea5a9cd0eb3a7982927a463feb4c3dae2@relay.wenmerge.com
```
# Overview
Source: https://docs.rated.network/documentation/explorer/ethereum/pbs-landscape/relays/relays
In this page we track the most important statistics relating to the operation of MEV Relays introduced with the advent of mev-boost in PoS Ethereum.
## At a glance
In this section, we go over the definitions of the counters one might find that sit atop the Relays page.
![]()
### Total value relayed
The total value paid to validators in order to facilitate the production of blocks crafted by block builders. This is a combination of `priority_fees` and `baseline_mev`. This should be equal to the value of the sum of `winning_bid` observed across relays.
### Value over vanilla blocks
The value surplus that blocks that were procured from MEV Relays exhibit when compared to the locally built (vanilla) blocks. This is a comparison of aggregate average values over the time-span of the toggled time period, and is derived from the *execution layer rewards* that these blocks pack for validators.
### MEV facilitated
This is an estimation of the gross amount of MEV that the relays have facilitated over time. It is based on a `sum` of our [Baseline MEV computation](/documentation/methodologies/ethereum/baseline-mev-computation) across the period in question.
## Mainnet block distribution
In this section, we provide definitions for all the metrics that make up the "Mainnet block distribution" section of the Relayer Landscape page.
![]()
### mev-boost ✗ vs mev-boost ✔
An aggregate comparison between blocks that have been produced locally (`mev-boost ✗`) and blocks that have been procured from MEV relays (`mev-boost ✔`).
### Sample size
The size of the sample of blocks in the RatedDB which relate to the time period toggled.
### Average transactions included
The number of transactions that either category of blocks packed in the respective time-period, on average.
### Average execution rewards
The value of the execution layer rewards for validators that the average block in either category packed over the time period toggled. Learn more about how we compute those in [Baseline MEV computation](/documentation/methodologies/ethereum/baseline-mev-computation).
### Average consensus rewards
The value of the consensus layer rewards that the average block in either category packed over the time period toggled.
### Average total rewards
The sum of execution and consensus layer rewards for either category of blocks.
## Breakdown by MEV relay
### Relay market share
This view represents the share of blocks that active relays contributed to the total block mass of mev-boost blocks produced on Ethereum Mainnet.
![]()
Due to the lack of data from relays around the submission of validator signatures when proposers source MEV-boost blocks, there has been no clear way to attribute a MEV-boost block to a single relay when said block appears on more than one relay.
As a stop-gap measure, we are attributing a `+1` counter to every relay that revealed the winning bid to the block proposer. This obviously leads to poor accounting as the sum of bids revealed will be greater than the sum of blocks produced. To counter this, we are only adopting this approach on comparative screens and do not account for it in other sums.
# Introduction
Source: https://docs.rated.network/documentation/explorer/introduction
A short intro to the Rated Explorer and prompts relating to navigating this section of the documentation.
The Rated Explorer is a well-loved hub that acts as a point of reference for the community of PoS networks. Validator operators, Relay operators, Builders, Searchers, and Wallets use the Rated Explorer on a daily basis to inform their best responses to present challenges, as well as future opportunities.
![]()
The Explorer section of the documentation outlines the contextual backdrop of the different sections that make up the whole of the Explorer, as well as a series of definitions on the variables that it exposes and the methodologies that power those.
## How to use the Explorer
Within each network, there are 3 core levers that you need to be aware of in order to use the Rated Explorer effectively; (i) the [Network selection menu](#network-selection-menu), (ii) the [sidebar](#the-sidebar), and (iii) the [time window (or date) toggle](#the-time-window-toggle).
### Network selection menu
At the top left of the Explorer, you will find a dropdown menu through which you can switch between networks that Rated currently supports - Ethereum, Solana and Holesky.
![]()
Remember that you can always head to the landing page to navigate between all the networks we support with important documentation links.
### The sidebar
At the left hand side of your screen, you will find an index of all the different views that the explorer supports. These indexes are network specific but can generally be segregated between (i) Network views––where we display information for all kinds of aggregations of validators (from index to operator to network) level, (ii) Network Landscape––where we display information on different "key frames of reference" for network as a whole, and (iii) Misc––under which you will find anything that does not fit well under any of the above categories.
![]()
### The time window toggle
At the top right of most screens, you will find a toggle that modulates what you see in the rest of the screen that you are on. The Rated Explorer takes an opinionated view and displays information in four distinct frames of reference––in their majority look backs. These are:
* **1d:** The period elapsed between the last hourly snapshot and the 24 hours preceding that
* **7d:** The period spanning the week preceding the last completed day (inclusive)
* **30d:** The period spanning the month preceding the last completed day (inclusive)
* **All time:** The period spanning the useful life of the network (since genesis). The time window here might vary depending on the actual useful life of the subject matter in a network context (i.e. an operator's history will go only as far back as the first validator activated that is associated with it)
![]()
## Quick start
Definitions of all metrics that live on the Ethereum pages of the Explorer
Definitions of all metrics that live on the Solana pages of the Explorer
# Solana
Source: https://docs.rated.network/documentation/explorer/solana/solana
Definitions of the variables that live on the landing page of the Rated Network Explorer for Solana
The default view of Solana is the "Network Overview" view. This represents a bird's eye view of the network with a series of metrics that attempt to capture the current state of the network at the highest level. We'll dive into the different metrics seen on this page on [Network Overview](/documentation/explorer/solana/network-views/network-overview).
![]()
# Welcome
Source: https://docs.rated.network/documentation/welcome
Rated offers independent, third-party node and node operator ratings, robust data pipelines, and the most comprehensive infrastructure dataset for Ethereum.
Welcome to the **Rated Documentation**!
In this hub you will find information about (i) the definitions of variables on the Rated Network Explorer, (ii) a series of useful resources that some of our work is based off of, (iii) a deep dive into the various methodologies of the metrics that Rated produces and exposes, (iv) our API documentation, and (v) resources on where to find us and how to get involved.
Rated was originally created by [**@eliasimos**](https://www.twitter.com/eliasimos) and [**@ariskkol**](https://www.twitter.com/ariskkol).
## Quick start
Walkthrough and "how to's" on all things relating to the Rated Network Explorer.
Learn more about the methodologies that power the various metrics Rated publishes.
Dive deep in the API reference and code examples, and learn how to harness the power of the RatedAPI.
# Blocks
Source: https://docs.rated.network/rated-api/glossary/ethereum/blocks
Glossary of terms found under /blocks
The base fees paid to the network (i.e. burnt) per gas unit.
This metric is in wei.
The minimum MEV rewards calculated in the block, outside of any `priorityFees`. Read more about the calculation methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/baseline-mev-computation).
These are the public keys of the builder that built a particular block.
The timestamp of when the block was recorded on based on the genesis of the chain.
The hash indicating the specific consensus slot.
Indicates whether a proposer proposed a Consensus Layer slot (`proposed`) or missed a proposal (`missed`).
These are the proposal rewards from the Ethereum Consensus Layer (Beacon Chain).
The slot number in the Ethereum Consensus Layer (Beacon Chain).
The epoch number of a particular slot. Each epoch has 32 slots.
The hash indicating the specific execution block.
The block number in the Ethereum Execution Layer
Indicates whether a proposer proposed a block that contains transactions (proposed), a block with no transactions (empty), or completely missed a proposal (missed).
The rewards from the Ethereum Execution Layer.
This is the sum of `totalPriorityFeesValidator` and `baselineMev`.
The address that received the block rewards on the Ethereum Execution Layer.
The Consensus Layer rewards missed by a validator for not being able to propose a slot. Read more about how this is estimated [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation/consensus-missed-rewards-computation#consensus-missed-proposal-rewards).
The Execution Layer rewards missed by a validator for not being able to propose a block or by proposing an empty block. Read more about how this is estimated [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation/execution-missed-rewards-computation).
The mev-boost relays where a particular block was sourced from.
The gas fees burnt for the set of transactions in the particular block.
This metric is in wei.
The gas units used by the set of transactions in the particular block.
The transaction fees paid by the end-user to the block's `feeRecipient`.
The portion of the `totalPriorityFees` that were paid to the validator that proposed the block. Given that the `feeRecipient` of a block can be the builder (as opposed to the proposer itself), it is up to the builder how much they pay to the validator in terms of the priority fees the former captured from building the block.
The sum of `consensusRewards` and `executionRewards`.
The sum of `missedConsensusRewards` and `missedExecutionRewards`.
The count of transactions that involve one or more addresses (i.e. in `to` and `from` addresses) that are in any sanctions lists by government bodies.
The total count of transactions in the particular block.
The count of type0 transactions.
Type0 Ethereum transactions are legacy transactions; this was the main transaction type before the [EIP-1559 upgrade](https://eips.ethereum.org/EIPS/eip-1559). Despite being referred to as "legacy", these are still in use after the upgrade.
The transaction fees generated by `type0Transactions`.
This metric is in wei.
The count of type1 transactions.
Type1 transactions are transactions that contain an access list, which is a list of addresses and storage keys that the transactions plan to access.
The transaction fees generated by `type1Transactions`.
This metric is in wei.
The count of type2 transactions.
Type2 Ethereum transactions were introduced with the [EIP-1559 upgrade](https://eips.ethereum.org/EIPS/eip-1559).
The transaction fees generated by `type2Transactions` less any `burntFees`.
The index of the validator assigned to propose for that particular slot/block.
# Effectiveness
Source: https://docs.rated.network/rated-api/glossary/ethereum/effectiveness
Glossary of terms found under /effectiveness
The aggregate attester effectiveness over the requested time period, that applies to said entity. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating/raver-v3.0-current#attester-effectiveness).
The average inclusion delay over the requested time period, that applies to said entity. Read more about the methodology [here](https://docs.rated.network/documentation/explorer/ethereum/network-views/pools-operators-and-validators/entity-metrics-drill-down#inclusion-delay).
Net consensus rewards for the day that apply to said entity (i.e. net of penalties). This is a validator balance difference between the last epoch in the day and the last epoch in the previous day.
Gross estimated protocol penalties accrued that apply to said entity.
Estimated gross validator consensus rewards that apply to said entity. Those are protocol rewards without protocol penalties accrued accounted for.
The number of empty blocks that said enitity has proposed.
The number of successful block proposals that said entity has been party to.
The number of block slots that said entity has been awarded. proposerDutiesCount minus proposedCount should give you the number of blocks missed by said entity.
The aggregate proposer effectiveness over the requested time period, that applies to said entity. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating).
The number of times said entity has been slashed.
All net consensus (i.e. rewards less penalties) and execution rewards, that apply to said entity. This should be the reflection of the net gain (or loss) a validator has recorded the period in question.
All aggregated attestation rewards, that apply to said entity. This includes rewards from sync committee duties/attestations
Our attempt to separate MEV from priority fees, for blocks procured from MEV Relays by said entity. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/baseline-mev-computation).
Consensus rewards earned by said index for successfully producing a block.
The number of correct head votes found in said index's attestations.
The number of correct target votes found in said index's attestations.
The sum of `sumPriorityFees` and `sumBaselineMev` from blocks proposed by said index that were sourced from mev-boost/MEV relays (i.e. blocks not built by the index itself).
The total inclusion delay for a period. Useful when computing the average inclusion delay of arbitrary periods.
The sum of all late source penalties for the period, that apply to said index.
Penalties for late target vote penalties, that apply to said index.
All penalties accrued for missed attestations, that apply to said index.
Estimated missed rewards in cases of missed attestations, that apply to said index. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation).
Estimated value of missed consensus block rewards in cases of missed block proposals, that apply to said index. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation).
Estimated execution rewards in case the validator missed a block proposal that apply to said index. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation).
Estimated missed rewards in cases of missed sync committee signatures, that apply to said index. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation).
Priority fees accrued from succesfully producing blocks that apply to said index.
Penalties for missed sync committee signatures, that apply to said index.
Rewards for fulfilled sync committee duties/signatures, that apply to said index.
Wrong head penalties, that apply to said index. Only applicable pre-Altair.
Penalties for wrong target vote penalties, that apply to said index.
The total number attestation slots the pubkeys that map back to said index have been awarded attestation duties.
The total number of attestations included in blocks. Note: an attestation can be included multiple times.
The total number of unique attestations.
The average uptime (or participation rate) over the requested time period, that applies to said index. Read more about the methodology [here](https://docs.rated.network/network-explorer/entity-views/entity-metrics-drill-down#participation-rate).
The aggregate validator effectiveness over the requested time period, that applies to said index. Read more about the methodology [here](https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating).
# Network
Source: https://docs.rated.network/rated-api/glossary/ethereum/network
Glossary of terms found under /network and /eth
The aggregate attestation correctness across all active validators in the network.
The aggregate inclusion delay across all active validators in the network.
The aggregate participation rate across all active validators in the network.
The aggregate validator effectiveness across all active validators in the network.
The amount of stake consolidated in a given time period.
The percentage (in decimal form) of the consolidation churn capacity that has been used up by consolidations during a given time period.
The consolidated stake amount over a given period divided by the total active stake.
The number of validators consolidated in a given time period.
The amount of stake that can be consolidated in a given time period.
The percentage (in decimal form) of the churn limit that is yet to be consumed.
# Operators
Source: https://docs.rated.network/rated-api/glossary/ethereum/operators
Glossary of terms found under /operators
The active stake of validators that map back to said entity. This is the denominator in APR%
The number of active validator pubkeys that map to said entity.
The APR% calculation type in question. At the moment Rated only supports backward looking APR%. Read more about the methodology that underlies it [here](https://docs.rated.network/documentation/methodologies/ethereum/backward-looking-apr).
The consensus client distribution of a given entity.
The sum of the validator balances being consolidated by an entity.
The count of validators being consolidated by an entity.
The percentage of overall network stake that said entity maps to.
The parent entity or entities that said index maps back to.
The actual APR% value.
The proportion of APR% attributed to consensus rewards.
The proportion of APR% attributed to execution rewards.
The distribution of post-merge block space of a given entity. This tracks which MEV Relays said entity is procuring blocks from, on part with how many blocks are locally built.
The entity related to the validator being consolidated.
The entity type of the entity related to the validator being consolidated.
The quality tag that maps back to said index. Read more about tags [here](https://mirror.xyz/ratedw3b.eth/f8TLAnN1e9kboHiPoctsNplGTD77EH6LXw9ymJV3Axc).
The number of validator keys that map to said index.
# Pool shares
Source: https://docs.rated.network/rated-api/glossary/ethereum/pool-shares
Glossary of terms found under /pool-shares
coming 🔜
```
██╗░░░██╗███╗░░██╗██████╗░███████╗██████╗░
██║░░░██║████╗░██║██╔══██╗██╔════╝██╔══██╗
██║░░░██║██╔██╗██║██║░░██║█████╗░░██████╔╝
██║░░░██║██║╚████║██║░░██║██╔══╝░░██╔══██╗
╚██████╔╝██║░╚███║██████╔╝███████╗██║░░██║
░╚═════╝░╚═╝░░╚══╝╚═════╝░╚══════╝╚═╝░░╚═╝
░█████╗░░█████╗░███╗░░██╗░██████╗████████╗██████╗░██╗░░░██╗░█████╗░████████╗██╗░█████╗░███╗░░██╗
██╔══██╗██╔══██╗████╗░██║██╔════╝╚══██╔══╝██╔══██╗██║░░░██║██╔══██╗╚══██╔══╝██║██╔══██╗
██║░░╚═╝██║░░██║██╔██╗██║╚█████╗░░░░██║░░░██████╔╝██║░░░██║██║░░╚═╝░░░██║░░░██║██║░░
██║░░██╗██║░░██║██║╚████║░╚═══██╗░░░██║░░░██╔══██╗██║░░░██║██║░░██╗░░░██
╚█████╔╝╚█████╔╝██║░╚███║██████╔╝░░░██║░░░██║░░██║╚██████╔╝╚█████╔╝░
░╚════╝░░╚════╝░╚═╝░░╚══╝╚═════╝░░░░╚═╝░░░╚═╝░░╚═╝░╚═════╝░░╚══
```
# Validators
Source: https://docs.rated.network/rated-api/glossary/ethereum/validators
Glossary of terms found under /validators
The balance being transferred from the source validator to the target validator during consolidation.
The epoch where the validator was consolidated (`source_validator_index` to `target_validator_index`).
The DVT network that said index maps to.
List of operators under a validator index. Note: only applicable in Obol or SSV DVT clusters.
The node operator that said index maps to.
The pool that said index maps to.
The entity related to the validator being consolidated.
The entity type of the entity related to the validator being consolidated.
The validator being consolidated.
The balance of the target validator before receiving the balance of the validator being consolidated.
The balance of the target validator after receiving the consolidated balance of the source validator. It is the balance of the target validator after the consolidation and the epoch itself have been processed.
The effective balance of the target validator after receiving the consolidated balance of the source validator. It is the effective balance of the target validator after the consolidation and the epoch itself have been processed.
The entity related to the target validator; validator receiving the balance of the validator being consolidated.
The entity type of the entity related to the target validator.
The validator receiving the balance of the validator being consolidated.
# Withdrawals
Source: https://docs.rated.network/rated-api/glossary/ethereum/withdrawals
Glossary of terms found under /withdrawals
The withdrawn amount in gwei units.
The index of the specific withdrawal across all withdrawals in a particular slot.
The address where withdrawn ETH is sent to.
The index of the specific withdrawal across all withdrawals.
# Delegators
Source: https://docs.rated.network/rated-api/glossary/polygon/delegators
Glossary of terms found under /delegators
The address of a delegator.
The amount of stake delegated by a delegator
The id of the validator that a delegator is delegated to.
The amount of rewards missed by a delegator due to their delegated validator's underperformance.
The amount of rewards received by a delegator.
# Network
Source: https://docs.rated.network/rated-api/glossary/polygon/network
Glossary of terms found under /network
The count of active delegators in the network.
The difference between the current number of active delegators and from the last time period based on the time window.
The count of active validators in the network.
The difference between the current number of active validators and from the last time period based on the time window.
The amount of stake delegated by an average delegator.
The average number of validators a delegator has delegated their stake to.
The network aggregate rate being paid by delegators on the rewards they earn to their delegate validators based on latter's stake weight.
The annual percentage rate (APR) apportioned to Bor proposal rewards.
The ratio of rewards attributable to Bor block proposals.
The aggregate annual percentage rate (APR) of delegators in the network. For more information, see here.
The annual percentage rate (APR) apportioned to Heimdall checkpoint rewards, both signing and proposals.
The ratio of rewards attributable to Heimdall checkpoint duties, both signing and proposals.
The aggregate annual percentage rate (APR) of all validators after distributing rewards to their delegators. For more information, see here.
The percentage of Bor proposal duties across all validators that were successful.
The percentage of checkpoint proposal duties across all validators that were successful.
The percentage of checkpoint signing duties across all validators that were successful.
The aggregate effectiveness over the requested time period. Read more about the methodology here.
The MEV (maximum extractable value) rewards from the Bor chain. This is from data mainly sourced from [Fastlane](https://www.fastlane.finance/) and [Marlin](https://explore.marlin.org/#/).
The transaction priority fees received by validators from proposing blocks on the Bor chain.
The rewards from checkpoint proposals.
The rewards from signing checkpoints
The total amount of delegated stake in the network.
The total amount of stake that is staked by validators themselves.
The total amount of stake in the network.
The aggregate annual percentage rate (APR) of all validators before distributing rewards to their delegators. For more information, see here.
# Validators
Source: https://docs.rated.network/rated-api/glossary/polygon/validators
Glossary of terms found under /validators
The number of block proposal duties a validator assigned in the Bor chain (i.e. chain where Polygon PoS end-user transactions are processed).
The percentage of Bor proposal duties across by a validator that were successful.
The number of Bor blocks successfully proposed by a validator.
The number of checkpoint proposal duties assigned to a validator.
The percentage of checkpoint proposal duties by a validator that were successful.
The rewards received by a validator from the protocol for their successful checkpoint proposals.
The number of checkpoints successfully proposed by a validator.
The number of checkpoint signing duties a validator has been assigned. Said differently, this the number of checkpoints a validator is tasked to attest to.
The rewards from successfully signing checkpoints.
The number of checkpoints successfully signed/attested to by a validator.
The percentage of [checkpointSignatureDuties](#checkpointSignatureDuties) wherein a validator was able to successfully attest to/sign a checkpoint.
The rate charged by validators to entities that have delegated their stake to them. This is applied to the delegators' share of the commissionSignatureRewards]\(#commissionSignatureRewards).
The amount of stake delegated to a validator.
The number of delegators that have delegated their stake to a validator.
The rewards received by the delegator/s who have delegated their stake to this validator from checkpoint signings. For more information, see here.
These are the rewards that a validator distributes to its delegators before taking commissions.
The aggregate validator effectiveness over the requested time period, that applies to said validator. Read more about the methodology here.
The rewards received by this validator due to MEV (maximum extractable value). This is from data mainly sourced from [Fastlane](https://www.fastlane.finance/) and Marlin.
These are the rewards a validator missed out on (i.e. opportunity cost) from missing their checkpoint proposal duties.
These are the checkpoint signing rewards missed (i.e. opportunity cost) from failing to sign checkpoints.
These are the commissions a validator missed out on from missing checkpoint signing duties.
These are the rewards a validator's delegators missed out on due to the validator's failure to sign checkpoints.
Similar to [missedDelegatorRewards](#missedDelegatorRewards) but also includes the commissions a validator missed out on.
The rewards a validator missed out on from failing to sign checkpoints. These are checkpoint signing rewards a validator was supposedly entitled to based on the stake they have staked themselves ([selfStake](#selfStake)).
The transaction priority fees received by validators from proposing blocks on the Bor chain.
These are rewards from checkpoint signing that a validator is entitled to based on their [selfStake](#selfStake).
The amount of POL that was staked by the validator itself.
This is the amount of POL staked with this validator. This is a combination of the amount a validator has staked themselves and the stake delegated to them.
# Delegators
Source: https://docs.rated.network/rated-api/glossary/solana/delegators
Glossary of terms found under /delegators
The stake-weighted effectiveness rating of the validators being delegated to. For more information on the effectiveness rating, see [here](https://docs.rated.network/methodologies/solana/solana-validator-effectiveness-rating).
The stake-weighted MEV commission rate being charged to a delegator based on its delegated validators.
The stake-weighted voting rewards (i.e. staking rewards) commission rate being charged to a delegator based on its delegated validators.
The amount of stake delegated.
The information related to the validators a delegator has delegated to including the percentage share of the delegator's stake.
The annual percentage yield earned by a delegator. For more information see [here](https://docs.rated.network/methodologies/solana/annual-percentage-yield-apy).
The commission paid by this delegator on the MEV rewards it receives.
The MEV commission rate being charged to a delegator based on its delegated validators.
The MEV rewards received by a delegator.
The annual percentage rate earned by a delegator on the MEV rewards it receives.
The estimated staking rewards (i.e. vote rewards) missed by a delegator based on validator underperformance. Feature to follow; defaults to 0 for now.
The percentage of overall network stake the particular delegator is associated with.
The name of the staking pool
The address of the stake account.
The stake authority address.
The commission paid by a delegator on the staking rewards (i.e. vote rewards) it receives.
The staking rewards a delegator receives. Specifically these are the rewards that delegators get from the successful voting duties that validators fulfill. These rewarded by the protocol through SOL inflation.
The annual percentage yield of a delegator on the staking rewards its receives.
The status of a stake account based on whether it is active (i.e. delegated), inactive (i.e. undelegated), activating (i.e. in the process of delegating), or deactivating (i.e. in the process of undelegating).
The total commission paid by a delegator to its validator delegate/s based on the rewards the former receives.
The total rewards (staking/voting and MEV) a delegator receives.
The number of validators a delegator is currently delegating to.
The validator effectiveness over the requested time period that applies to the validator being delegated to. For more information, see [here](https://docs.rated.network/methodologies/solana/solana-validator-effectiveness-rating).
The name of the validator being delegated to.
The vote account address (i.e. unique identifier/pubkey) of the validator being delegated to.
The voting rewards (i.e. staking rewards) commission rate being charged to a delegator based on its delegated validator.
The withdraw authority address.
# Network
Source: https://docs.rated.network/rated-api/glossary/solana/network
Glossary of terms found under /network
The count of active stake accounts in the network.
The difference between the current number of active stake accounts and from the last time period based on the time window.
The count of active stake authority addresses in the network.
The difference between the current number of active stake authority addresses and from the last time period based on the time window.
The count of active withdraw authority addresses in the network.
The difference between the current number of active withdraw authority addresses and from the last time period based on the time window.
The count of active validators in the network.
The difference between the current number of active validators and from the last time period based on the time window.
The geographical city where this validator's node is located.
The geographical country where this validator's node is located.
The number of deactivating stake accounts in the network.
The aggregate annual percentage yield (APY) of delegators in the network. For more information, see [here](https://docs.rated.network/methodologies/solana/annual-percentage-yield-apy).
The network's gini coefficient. For more information, see here (link to Gini coefficient methodology for Solana).
The hosting provider/data service provider used by this validator for its infrastructure.
The median [vote latency](/rated-api/glossary/solana/validators#votelatency) across validators.
The aggregate annual percentage yield (APR) of all validators after distributing rewards to their delegators. For more information, see [here](https://docs.rated.network/methodologies/solana/annual-percentage-yield-apy).
The aggregate effectiveness over the requested time period. Read more about the methodology here (link to Solana effectiveness methodology).
The difference between the current network effectiveness and the effectiveness from the last time period based on the time window.
The percentage of block production duties missed in the network.
The percentage of voting duties that were correctly done by validators across the network.
The average voting latency across the network.
Network-wide rewards that are from maximum extractable value (MEV).
Network-wide rewards that are from block production.
Network-wide rewards that are from slot voting duties.
The ratio of stake accounts versus the number of stake authority addresses.
The ratio of stake accounts versus the number of withdraw authority addresses.
See [totalStake](/rated-api/glossary/solana/network#totalstake).
The total amount of stake in the network.
The aggregate annual percentage yield (APY) of all validators before distributing rewards to their delegators.
# Validators
Source: https://docs.rated.network/rated-api/glossary/solana/validators
Glossary of terms found under /validators
The average compute units in a block. Compute units are the measure of computational resources used by transactions.
The average amount of MEV tips in blocks produced by a validator.
The average amount of rewards in blocks produced by a validator.
The average number of transactions in a block.
The rewards a validator got from producing blocks. Comprised of the base fees and priority fees.
The geographical city where this validator's node is located.
The Solana client that this validator is running.
The geographical country where this validator's node is located.
The annual percentage yield earned by delegators that have delegated to this validator. For more information see [here](https://docs.rated.network/methodologies/solana/annual-percentage-yield-apy).
The validator effectiveness over the requested time period that applies to said validator. For more information, see [here](https://docs.rated.network/methodologies/solana/solana-validator-effectiveness-rating).
The hosting provider/data service provider used by this validator for its infrastructure.
See [voteLatency](/rated-api/glossary/solana/validators#votelatency)
The MEV rewards claimed by a validator.
The commission rate being charged by this validator to its delegators for any MEV rewards it collects under the Jito ecosystem.
The tips/fees paid to a validator for including MEV-related transactions in the blocks they produced.
See [validatorName](/rated-api/glossary/solana/validators#validatorname)
The percentage of overall network stake the particular validator is associated with.
The percent of total transactions in a block that have failed or have an error.
The percent of total transactions in a block that is above 5000 lamports (0.000005 SOL) in fees.
The number of blocks produced/proposed by this validator.
The rent paid to the validator.
The number of slots that this validator did not produce a block for when they were the designated slot leader/block producer.
The sum of all the voting latency by this validator, measured in slots.
The total stake delegated to this validator.
The total number of votes made by this validator.
The number of votes made by this validator over the number of blocks produced by the network
The annual percentage yield that this validator gets based on the rewards it has received.
This is the account that is used to pay for all vote transaction fees by the validator. This is also the public key that is used to identify a validator node in Solana's gossip network.
The entity name of the validator.
The account required to operate a validator. This account is the best way to identify a validator as it cannot be changed.
The commission rate that this validator charges its delegators for voting rewards.
The voting latency (i.e. distance between the slot they are voting for and the slot where their vote was included) of this validator, measured in slots.
The number of blocks produced by this validator that contained only vote transactions.
The rewards a validator got from voting for valid blocks (i.e. correct fork) of the network.
# Developers FAQ
Source: https://docs.rated.network/rated-api/guides/developers-faq
Frequently asked questions in and around the Rated API.
## How do I access the Rated API?
To access the Rated API you will need to head to [console.rated.network](https://console.rated.network/) and create an account.
## How is the Rated API structured?
The RatedAPI is adopted for rewards tracking, performance monitoring and benchmarking. Full details can be found under [API reference](/rated-api/api-reference).
## How can I use the Rated API for monitoring validator performance on Grafana?
Check out our Rated CLI on [github](https://github.com/rated-network/rated-cli) to bring all the information that the Rated API supports, in your local monitoriong suite.
Please remember to contribute back to the main branch if you come up with extensions, bug fixes, new modules etc.
## What is the definition of "effectiveness" in the API?
The effectiveness rating (RAVER) is a methodology Rated has proposed for evaluating validator performance in a concise way. The methodology has been through a number of iterations with the community and is widespread by now. For more information on the specifics, please refer to our documentation.
## Can I query the API up to a specific granular time (i.e. epoch, slot)?
The API doesn't allow you to specify epoch. Data is pre-aggregated into 225 epoch intervals, so the minimum current granularity is 1 day. The API does offer `startEpoch` and `endEpoch` in the response, so that you have visibility of which epochs have been aggregated.
## Can I get the current balance of the validator node from the API?
This information is not currently available. We are working on withdrawals and as part of this we are planning a few features related to balances and partial/full withdrawals that will be updated in real-time!
## I am trying to use /v0/eth/validators/effectiveness endpoint with granularity set to month, but I get error: "Can't use granularity when grouping by validator." Any suggestions?
The API can aggregate in two ways. Depending on what you are trying to achieve the query params available are different.
1. `timeWindow` - Validator data is aggregated in time buckets
* Data for validator 1,2 and 3 get aggregated and one row is returned for every day/week/month. [Link to example](https://api.rated.network/v0/eth/validators/effectiveness?indices=10\&indices=11\&indices=13\&groupBy=timeWindow\&granularity=day)
2. `validator` - Daily validator data is aggregated by pubkey/index
* Data for validators 1,2,3 get aggregated in one row per validator. The time period to aggregate can be arbitrary. [Link to example](https://api.rated.network/v0/eth/validators/effectiveness?indices=10\&indices=11\&indices=13\&groupBy=validator\&from=2023-01-30\&to=2023-01-01\&filterType=datetime)
## My use case requires a higher bandwidth of use than the current rated limit allows. Wat do?
shoot us a note at [hello@rated.network](mailto:hello@rated.network).
# Performance Benchmarking
Source: https://docs.rated.network/rated-api/guides/use-cases/performance-benchmarking
Performance benchmarking is a critical practice that involves evaluating and comparing the efficiency of various validators, both internal and external, to find areas of efficiency. Rated APIs provide access to standardized performance metrics, which can be used by:
1. **Node Operators** to continuously monitor their own performance metrics in relation to their competitors. This not only helps in identifying areas of improvement but also facilitates the formulation of effective strategies to enhance their operational efficiency and service quality.
2. **Custodians** and **Centralised Exchanges** to conduct thorough evaluations of validator operators, comparing their performance against network standards and other validators. This comprehensive analysis assists in making strategic decisions regarding SLAs and pricing, ensuring optimal performance and cost-effectiveness.
## Integration Steps
### Step 1: Generate Authorization Token
[Sign into the Rated Console](https://rated.network/signIn) to generate your API Token.
### Step 2: Get Performance Data
The Rated API offers time window aggregation, allowing you to consolidate data over various time periods such as `day`, `week`, `month`, `quarter`, `year` or `all time`. You can retrieve performance data in two ways:
1. Pre-materialized views
2. Specific validator groups
#### Step 2.1: Getting Performance Data for Pre-materialized Views
Imagine you're Kiln (a Node Operator), Lido (a Pool), or Coinbase (an Exchange). You want all your performance details for August 2023, shown daily. Here's how you'd go about getting this data.
| Key | Required? | Value | Description |
| :------------ | :-------- | :------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `operator_id` | Yes | string | Name of the Entity. For this example, you should either put `Lido` ,`Kiln` or`Coinbase` **Note:** the operator\_id is case-sensitive and should follow the same typecase as they are on the [Rated Explorer](https://www.rated.network/?network=mainnet\&view=pool\&timeWindow=1d\&page=1\&poolType=all) |
| `idType` | Yes | string | The type of entity class you would like returned. You might ask for `pool`, `poolShare`, `nodeOperator`, `depositAddress`, or `withdrawalAddress`. **Note:** it is optional and can be inferred automatically for pools, pool shares and node operators. It defaults to `depositAddress` if it is missing and an address is provided. |
| `granularity` | Yes | string | The size of time increments you are looking to query. Can be `day` / `week` / `month` / `quarter` / `year`. For this example, you should set granularity to `day`. |
| `from` | Yes | string | Start day (integer) or date (e.g. from="2022-12-01") For this example, set from to `2023-08-31` |
| `size` | Yes | integer | The number of results included per page. For this example, you should set size as 31 as we want the monthly data for August 2023. |
| `filterType` | Yes | string | `hour`, `day` and `datetime` For this example, set to `datetime` |
| `include` | Yes | array | A list of field names. To get the performance data, you should include the following data: `day`, `validatorCount`, `avgInclusionDelay`, `avgUptime`, `avgCorrectness`, `avgProposerEffectiveness`, `avgValidatorEffectiveness`, `avgAttesterEffectiveness`,`sumCorrectHead`, `sumCorrectTarget`, `sumCorrectSource`,`sumInclusionDelay`, `sumProposedCount`, `sumProposerDutiesCount`, `slashesCollected`, `slashesReceived`, `sumMissedSyncSignatures`, `sumLateSourceVotes`, `sumWrongTargetVotes`, `sumLateTargetVotes`, `sumMissedAttestations`, `sumWrongHeadVotes`, `sumExecutionProposedEmptyCount` |
**Example:** Obtaining daily performance metrics for the month of August 2023 for Kiln
```sh curl theme={null}
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/operators/Kiln/effectiveness?from=2023-08-31&size=31&granularity=day&filterType=datetime&include=validatorCount&include=avgInclusionDelay&include=avgUptime&include=avgCorrectness&include=avgProposerEffectiveness&include=avgValidatorEffectiveness&include=avgAttesterEffectiveness&include=sumCorrectHead&include=sumCorrectTarget&include=sumCorrectSource&include=sumInclusionDelay&include=sumProposedCount&include=sumProposerDutiesCount&include=slashesCollected&include=slashesReceived&include=day&include=sumMissedSyncSignatures&include=sumLateSourceVotes&include=sumWrongTargetVotes&include=sumLateTargetVotes&include=sumMissedAttestations&include=sumWrongHeadVotes&include=sumExecutionProposedEmptyCount&idType=nodeOperator' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
```
```python python theme={null}
import requests
url = "https://api.rated.network/v0/eth/operators/Kiln/effectiveness"
params = {
"from": "2023-08-31",
"size": 31,
"granularity": "day",
"filterType": "datetime",
"include": [
"validatorCount", "avgInclusionDelay", "avgUptime",
"avgCorrectness", "avgProposerEffectiveness",
"avgValidatorEffectiveness", "avgAttesterEffectiveness",
"sumCorrectHead", "sumCorrectTarget", "sumCorrectSource",
"sumInclusionDelay", "sumProposedCount", "sumProposerDutiesCount",
"slashesCollected", "slashesReceived", "day",
"sumMissedSyncSignatures", "sumLateSourceVotes",
"sumWrongTargetVotes", "sumLateTargetVotes",
"sumMissedAttestations", "sumWrongHeadVotes",
"sumExecutionProposedEmptyCount"
],
"idType": "nodeOperator"
}
headers = {
"Content-Type": "application/json",
"X-Rated-Network": "mainnet",
"Authorization": "Bearer "
}
response = requests.get(url, params=params, headers=headers)
print(response.json())
```
#### Step 2.2: Getting Performance Data for Specific Validator Groups
For validator groupings, you will need to call the [Aggregating validator indices](/rated-api/api-reference/v0/ethereum/validators/get-effectiveness-aggregation) endpoint. We'll show this similarly as above for all performance details for the month of August 2023 for a set of validator indices, aggregated daily.
| Key | Required? | Value | Description |
| :----------------------- | :-------- | :------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `pubkeys` (OR) `indices` | Yes | array \[string] (OR) array \[integer] | Array of validator pubkeys or indicies you're performing the grouped analysis for. For this example, you should put indices as `675893` `675894` and `675895` |
| `filterType` | Yes | string | `hour`, `day` and `datetime`. For this example, set to `datetime` |
| `from` | Yes | string | The most recent date for your desired timeline. In this example, it is `2023-08-31` |
| `size` | Yes | integer | The number of results included per page. For this example, you should set size as 31 as we want the monthly data for August 2023. |
| `granularity` | Yes | string | The size of time increments you are looking to query. Can be `day` / `week` / `month` / `quarter` / `year`. For this example, set granularity to `day`. |
| `groupBy` | Yes | string | Aggregation groupings. Can be `timeWindow` if you'd like to aggregation for your desired time window or `validator` if you'd like it per validator. For this example, set it to `timeWindow`. |
| `include` | Yes | array \[string] | A list of field names. To get the performance data, you should include the following data: `day`, `validatorCount`, `avgInclusionDelay`, `avgUptime`, `avgCorrectness`, `avgProposerEffectiveness`, `avgValidatorEffectiveness`, `avgAttesterEffectiveness`,`sumCorrectHead`, `sumCorrectTarget`, `sumCorrectSource`,`sumInclusionDelay`, `sumProposedCount`, `sumProposerDutiesCount`, `slashesCollected`, `slashesReceived`, `sumMissedSyncSignatures`, `sumLateSourceVotes`, `sumWrongTargetVotes`, `sumLateTargetVotes`, `sumMissedAttestations`, `sumWrongHeadVotes`, `sumExecutionProposedEmptyCount` |
**Example:** Obtaining daily performance metrics for the month of August 2023 for Validator group `{675893,675894,675895}`
```sh curl theme={null}
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/validators/effectiveness?indices=675893&indices=675894&indices=675895&from=2023-08-31&size=31&granularity=day&filterType=datetime&include=validatorCount&include=avgInclusionDelay&include=avgUptime&include=avgCorrectness&include=avgProposerEffectiveness&include=avgValidatorEffectiveness&include=avgAttesterEffectiveness&include=sumCorrectHead&include=sumCorrectTarget&include=sumCorrectSource&include=sumInclusionDelay&include=sumProposedCount&include=sumProposerDutiesCount&include=slashesCollected&include=slashesReceived&include=day&include=sumMissedSyncSignatures&include=sumLateSourceVotes&include=sumWrongTargetVotes&include=sumLateTargetVotes&include=sumMissedAttestations&include=sumWrongHeadVotes&include=sumExecutionProposedEmptyCount&groupBy=timeWindow' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
```
```python python theme={null}
import requests
url = "https://api.rated.network/v0/eth/validators/effectiveness"
params = {
"indices": [675893, 675894, 675895],
"from": "2023-08-31",
"size": 31,
"granularity": "day",
"filterType": "datetime",
"groupBy": "timeWindow",
"include": [
"validatorCount", "avgInclusionDelay", "avgUptime",
"avgCorrectness", "avgProposerEffectiveness",
"avgValidatorEffectiveness", "avgAttesterEffectiveness",
"sumCorrectHead", "sumCorrectTarget", "sumCorrectSource",
"sumInclusionDelay", "sumProposedCount", "sumProposerDutiesCount",
"slashesCollected", "slashesReceived", "day",
"sumMissedSyncSignatures", "sumLateSourceVotes",
"sumWrongTargetVotes", "sumLateTargetVotes",
"sumMissedAttestations", "sumWrongHeadVotes",
"sumExecutionProposedEmptyCount"
]
}
headers = {
"Content-Type": "application/json",
"X-Rated-Network": "mainnet",
"Authorization": "Bearer "
}
response = requests.get(url, params=params, headers=headers)
print(response.json())
```
# Private Sets
Source: https://docs.rated.network/rated-api/guides/use-cases/private-sets
Private sets is a self-serve feature designed to enable organizations to curate a set of validators, each marked with a unique tag. This tag, carrying an identifier specific to your organization, ensures that only you can view the performance and rewards metrics for it. Displayed within your console, these tags streamline analysis processes and let you perform A/B testing on your node setup or group together validators for a specific customer confidentially.
### Getting Started
Build and Growth API users can create private sets. Build tier comes with max 4 sets while Growth comes with 20.
### Step 1: Creating a Tag and associating validators to it
To call a set's effectiveness, you must first create a tag which acts as a unique identifier for the set.
**Body parameters (Required)**
| Name | Type | Description |
| :----- | :----- | :--------------- |
| `name` | string | Name for the tag |
**Response**
```json 200 theme={null}
{
"id": "string",
"name": "string",
"network": "mainnet",
"organizationId": "string",
"createdBy": "string",
"createdAt": "2024-03-14T18:12:14.677Z",
"updatedAt": "2024-03-14T18:12:14.677Z"
}
```
Using the `id` that you get in the response above, call the following endpoint to associate validators with the tag
**Body parameters (Required)**
| Name | Type | Description |
| :-------- | :---- | :------------------------------------------ |
| `pubkeys` | array | list of keys you wish to associate to a tag |
**Response**
```json 200 theme={null}
{
"tag": "string",
"pubkeysAdded": integer
}
```
Once you have a tag with validator mappings, you can move to Step 2.
To add more validators to a tag, call `POST` `/v1/tags/{id}/validators` with the new keys you'd like to add. Similarly, to remove a pubkey from an existing tag, call`DELETE` `/v1/tags/{id}/validators/{pubkey}.`
Removing keys from a tag doesn't erase their impact on historical performance ie performance of a removed pubkey continues to impact the all-time performance of a set.
### Step 2: Calling the performance and rewards endpoints for your set
Using the tag's ID, call the sets endpoints to retrieve performance and rewards metrics. These endpoints operate similar to the /operators/ endpoints with similar granularities and refresh windows.
**Query parameters**
| Name | Type | Value |
| :------------ | :------ | :------------------------------------------------------------------------------------------ |
| `granularity` | enum | `hour`or `day` |
| `fromDate` | date | the date from which you wish to retrieve the data |
| `toDate` | date | the date upto which you wish to retrieve the data |
| `limit` | integer | the number of rows returned per page |
| `offset` | integer | offset allows you to omit a specified number of rows before the beginning of the result set |
**Response**
```json 200 (effectiveness) theme={null}
{
"pages": 3,
"results": [
{
"hour": null,
"day": 796,
"date": 2023-01-01,
"startEpoch": 179324,
"endEpoch": 179100,
"validatorCount": 16075,
"avgInclusionDelay": 1.0138705386457403,
"avgUptime": 0.9999466390184881,
"avgCorrectness": 0.9929917401071404,
"avgProposerEffectiveness": 99.53271028037379,
"avgValidatorEffectiveness": 97.96642775943795,
"avgAttesterEffectiveness": 97.9580945527236
}
],
"previous": "string",
"next": "string"
}
```
```json 200 (attestations) theme={null}
{
"pages": 3,
"results": [
{
"hour": null,
"day": 796,
"date": 2023-01-01,
"startEpoch": 179324,
"endEpoch": 179100,
"validatorCount": 16075,
"totalUniqueAttestations": 3616682,
"sumMissedAttestations": 193,
"sumMissedSyncSignatures": 2837,
"sumCorrectHead": 3547355,
"sumCorrectTarget": 3612248,
"sumCorrectSource": 3614403,
"sumWrongHeadVotes": 48767,
"sumWrongTargetVotes": 4434,
"sumWrongSourcetVotes": 4434,
"sumLateSourceVotes": 2279,
"sumLateTargetVotes": 0,
"sumLateHeadVotes": 0,
"avgAttesterEffectiveness": 97.9580945527236
}
],
"previous": "string",
"next": "string"
}
```
```json 200 (proposals) theme={null}
{
"pages": 3,
"results": [
{
"hour": null,
"day": 796,
"date": 2023-01-01,
"startEpoch": 179324,
"endEpoch": 179100,
"validatorCount": 16075,
"sumProposedCount": 213,
"sumProposerDutiesCount": 214,
"avgProposerEffectiveness": 99.53271028037379
}
],
"previous": "string",
"next": "string"
}
```
```json 200 (rewards) theme={null}
{
"pages": 3,
"results": [
{
"hour": null,
"day": 796,
"date": 2023-01-01,
"startEpoch": 179324,
"endEpoch": 179100,
"validatorCount": 16075,
"sumEarnings": 56766373292,
"sumEstimatedRewards": 56675239144,
"sumPriorityFees": 10662221791,
"sumBaselineMev": 5266131924,
"sumMissedExecutionRewards": 58181568,
"sumConsensusBlockRewards": 6554423259,
"sumMissedConsensusBlockRewards": 31228533,
"sumAllRewards": 72694727007,
"sumAttestationRewards": 50120815885,
"sumMissedAttestationRewards": 269961427,
"sumMissedSyncCommitteeRewards": 44317643,
"sumExternallySourcedExecutionRewards": 14862131536
}
],
"previous": "string",
"next": "string"
}
```
```json 200 (penalties) theme={null}
{
"pages": 3,
"results": [
{
"hour": null,
"day": 796,
"date": 2023-01-01,
"startEpoch": 179324,
"endEpoch": 179100,
"validatorCount": 16075,
"sumEstimatedPenalties": -82967688,
"sumSyncCommitteePenalties": -44317643,
"sumWrongTargetPenalties": -28763358,
"sumLateTargetPenalties": 0,
"sumMissedAttestationPenalties": -1926140,
"sumWrongHeadPenalties": 0,
"sumLateSourcePenalties": -7960547
}
],
"previous": "string",
"next": "string"
}
```
# Rewards Accounting
Source: https://docs.rated.network/rated-api/guides/use-cases/rewards-accounting
The Rated API facilitates efficient and detailed management of rewards distributed on Ethereum. By leveraging the API, users can achieve granular insight into their reward dynamics, aiding in precise accounting and better decision-making.
1. **Node Operators** can keep track of their rewards in granular detail, accounting for the attribution of rewards for specific validator duties.
2. **Pools**, **Custodians** and **Centralised Exchanges** can take stock of the rewards they receive from one or more staking providers in a consolidated view, including a breakdown of the different sources of rewards.
## Integration Steps
### Step 1: Generate Authorization Token
[Sign into the Rated Console](https://rated.network/signIn) to generate your API Token.
### Step 2: Get Rewards Data
The Rated API offers time window aggregation, allowing you to consolidate data over various time periods such as `day`, `week`, `month`, `quarter`, `year` or `all time`. You can retrieve reward info in two ways:
1. Pre-materialized views
2. Specific validator groups
#### Step 2.1: Getting Rewards for Pre-materialized Views
Imagine you're Kiln (a Node Operator), Lido (a Pool), or Coinbase (an Exchange). You want all your reward details (consensus layer and execution layer including penalties) for August 2023, shown daily. Here's how you'd go about getting this data.
Call the [Operator effectiveness](/rated-api/api-reference/v0/ethereum/operators/get-effectiveness)endpoint with the following parameters set:
| Key | Required? | Value | Description |
| :------------ | :-------- | :------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `operator_id` | Yes | string | Name of the Entity. For this example, you should either put `Lido` ,`Kiln` or`Coinbase` **Note:** the operator\_id is case-sensitive and should follow the same typecase as they are on the [Rated Explorer.](https://www.rated.network/?network=mainnet\&view=pool\&timeWindow=1d\&page=1\&poolType=all) |
| `idType` | Yes | string | The type of entity class you would like returned. You might ask for `pool`, `poolShare`, `nodeOperator`, `depositAddress`, or `withdrawalAddress`. **Note:** it is optional and can be inferred automatically for pools, pool shares and node operators. It defaults to `depositAddress` if it is missing and an address is provided. |
| `granularity` | Yes | string | The size of time increments you are looking to query. Can be `day` / `week` / `month` / `quarter` / `year`. For this example, you should set granularity to `day`. |
| `from` | Yes | string | Start day (integer) or date (e.g. from="2022-12-01") For this example, set from to `2023-08-31` |
| `size` | Yes | integer | The number of results included per page. For this example, you should set size as 31 as we want the monthly data for August 2023. |
| `filterType` | Yes | string | `hour`, `day` and `datetime` For this example, set to `datetime` |
| `include` | Yes | array | A list of field names. To get the rewards data, you should include the following data: `day`, `sumEarnings`, `sumEstimatedRewards`, `sumEstimatedPenalties`, `sumPriorityFees`, `sumBaselineMev`, `sumMissedExecutionRewards`, `sumConsensusBlockRewards`, `sumMissedConsensusBlockRewards`, `sumAllRewards`, `sumAttestationRewards`, `sumMissedAttestationRewards`, `sumMissedAttestationPenalties`, `sumWrongTargetPenalties`, `sumLateTargetPenalties`, `sumWrongHeadPenalties` and `sumLateSourcePenalties` |
| Key | Required? | Value | Description |
| :------------ | :-------- | :------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `idType` | Yes | string | The type of entity class you would like returned. You might ask for `pool`, `poolShare`, `nodeOperator`, `depositAddress`, or `withdrawalAddress`. **Note:** it is optional and can be inferred automatically for pools, pool shares and node operators. It defaults to `depositAddress` if it is missing and an address is provided. |
| `granularity` | Yes | string | The size of time increments you are looking to query. Can be `day` / `week` / `month` / `quarter` / `year`. For this example, you should set granularity to `day`. |
| `from` | Yes | string | Start day (integer) or date (e.g. from="2022-12-01") For this example, set from to `2023-08-31` |
| `size` | Yes | integer | The number of results included per page. For this example, you should set size as 31 as we want the monthly data for August 2023. |
| `filterType` | Yes | string | `hour`, `day` and `datetime` For this example, set to `datetime` |
| `include` | Yes | array | A list of field names. To get the rewards data, you should include the following data: `day`, `sumEarnings`, `sumEstimatedRewards`, `sumEstimatedPenalties`, `sumPriorityFees`, `sumBaselineMev`, `sumMissedExecutionRewards`, `sumConsensusBlockRewards`, `sumMissedConsensusBlockRewards`, `sumAllRewards`, `sumAttestationRewards`, `sumMissedAttestationRewards`, `sumMissedAttestationPenalties`, `sumWrongTargetPenalties`, `sumLateTargetPenalties`, `sumWrongHeadPenalties` and `sumLateSourcePenalties` |
#### Get Effectiveness
**Example:** Obtaining daily reward metrics for the month of August 2023 for Kiln
```sh curl theme={null}
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/operators/Kiln/effectiveness?idType=nodeOperator&granularity=day&from=2023-08-31&size=31&filterType=datetime&include=sumEarnings&include=day&include=sumEstimatedRewards&include=sumEstimatedPenalties&include=sumPriorityFees&include=sumBaselineMev&include=sumMissedExecutionRewards&include=sumConsensusBlockRewards&include=sumMissedConsensusBlockRewards&include=sumAttestationRewards&include=sumAllRewards&include=sumMissedAttestationRewards&include=sumMissedAttestationPenalties&include=sumWrongTargetPenalties&include=sumLateTargetPenalties&include=sumWrongHeadPenalties&include=sumLateSourcePenalties' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
```
```python python theme={null}
import requests
url = "https://api.rated.network/v0/eth/operators/Coinbase/effectiveness"
params = {
"idType": "nodeOperator",
"granularity": "day",
"from": "2023-08-31",
"size": 31,
"filterType": "datetime",
"include": [
"sumEarnings", "day", "sumEstimatedRewards", "sumEstimatedPenalties",
"sumPriorityFees", "sumBaselineMev", "sumMissedExecutionRewards",
"sumConsensusBlockRewards", "sumMissedConsensusBlockRewards",
"sumAttestationRewards", "sumAllRewards", "sumMissedAttestationRewards",
"sumMissedAttestationPenalties", "sumWrongTargetPenalties",
"sumLateTargetPenalties", "sumWrongHeadPenalties", "sumLateSourcePenalties"
]
}
headers = {
"Content-Type": "application/json",
"X-Rated-Network": "mainnet",
"Authorization": "Bearer "
}
response = requests.get(url, params=params, headers=headers)
data = response.json()
```
You will get the following response:
```json theme={null}
{
"page": {
"from": "2023-08-31",
"to": null,
"size": 31,
"granularity": "day",
"filterType": "datetime"
},
"total": 898,
"data": [
{
"day": 1003,
"sumEarnings": 77486856706,
"sumEstimatedRewards": 77373138429,
"sumEstimatedPenalties": -118318923,
"sumPriorityFees": 17774426424,
"sumBaselineMev": 3491590102,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9990007760,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 98752873232,
"sumWrongTargetPenalties": -49457460.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -13833800.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 67667148655.0,
"sumLateSourcePenalties": -11938591.0,
"sumMissedAttestationRewards": 284356667.0
},
{
"day": 1002,
"sumEarnings": 77143472373,
"sumEstimatedRewards": 77391611207,
"sumEstimatedPenalties": -120229039,
"sumPriorityFees": 18343668557,
"sumBaselineMev": 10356072440,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 10319158586,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 105843213370,
"sumWrongTargetPenalties": -26537147.0,
"sumLateTargetPenalties": -21268.0,
"sumMissedAttestationPenalties": -36654580.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 67263902633.0,
"sumLateSourcePenalties": -19645906.0,
"sumMissedAttestationRewards": 286496225.0
},
{
"day": 1001,
"sumEarnings": 76074505835,
"sumEstimatedRewards": 76247558832,
"sumEstimatedPenalties": -137348952,
"sumPriorityFees": 19972445511,
"sumBaselineMev": 6018452671,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9791416575,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 102065404017,
"sumWrongTargetPenalties": -44169801.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -36647400.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 66503540668.0,
"sumLateSourcePenalties": -15249640.0,
"sumMissedAttestationRewards": 329264913.0
},
{
"day": 1000,
"sumEarnings": 74927018847,
"sumEstimatedRewards": 74951967765,
"sumEstimatedPenalties": -87687005,
"sumPriorityFees": 19894046470,
"sumBaselineMev": 6328736364,
"sumMissedExecutionRewards": 64569010,
"sumConsensusBlockRewards": 9663448571,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 101149801681,
"sumWrongTargetPenalties": -22716304.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -13626780.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 65429057326.0,
"sumLateSourcePenalties": -25472167.0,
"sumMissedAttestationRewards": 299629203.0
},
{
"day": 999,
"sumEarnings": 74450326845,
"sumEstimatedRewards": 74442548500,
"sumEstimatedPenalties": -94866866,
"sumPriorityFees": 15629334347,
"sumBaselineMev": 3163139471,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9143393628,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 93242800663,
"sumWrongTargetPenalties": -16739619.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -27380820.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 65416918513.0,
"sumLateSourcePenalties": -16548504.0,
"sumMissedAttestationRewards": 322013802.0
},
{
"day": 998,
"sumEarnings": 74559187641,
"sumEstimatedRewards": 74955978079,
"sumEstimatedPenalties": -118172069,
"sumPriorityFees": 13262259657,
"sumBaselineMev": 13354512742,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9361867132,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 101175960040,
"sumWrongTargetPenalties": -33376759.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -19439660.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 65604374555.0,
"sumLateSourcePenalties": -11486685.0,
"sumMissedAttestationRewards": 408981581.0
},
{
"day": 997,
"sumEarnings": 75052710169,
"sumEstimatedRewards": 74978533403,
"sumEstimatedPenalties": -99768855,
"sumPriorityFees": 16001568993,
"sumBaselineMev": 5507554734,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8946159003,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 96561833896,
"sumWrongTargetPenalties": -17664088.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -7671440.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 66308894671.0,
"sumLateSourcePenalties": -19986120.0,
"sumMissedAttestationRewards": 285461898.0
},
{
"day": 996,
"sumEarnings": 74871703449,
"sumEstimatedRewards": 74708910502,
"sumEstimatedPenalties": -75255605,
"sumPriorityFees": 19605086555,
"sumBaselineMev": 22209861662,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9728316748,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 116686651666,
"sumWrongTargetPenalties": -13585351.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -10273620.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 65245633437.0,
"sumLateSourcePenalties": -16255204.0,
"sumMissedAttestationRewards": 221794127.0
},
{
"day": 995,
"sumEarnings": 74316890091,
"sumEstimatedRewards": 74039058325,
"sumEstimatedPenalties": -57112712,
"sumPriorityFees": 18504571594,
"sumBaselineMev": 11768658033,
"sumMissedExecutionRewards": 82083111,
"sumConsensusBlockRewards": 9456206280,
"sumMissedConsensusBlockRewards": 37448909,
"sumAllRewards": 104590119718,
"sumWrongTargetPenalties": -14968772.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -2750740.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 64940299581.0,
"sumLateSourcePenalties": -10766084.0,
"sumMissedAttestationRewards": 220500261.0
},
{
"day": 994,
"sumEarnings": 72508933169,
"sumEstimatedRewards": 72423066679,
"sumEstimatedPenalties": -95087909,
"sumPriorityFees": 16880244177,
"sumBaselineMev": 2760444076,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 7992521257,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 92149621422,
"sumWrongTargetPenalties": -26118846.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -16278480.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 64712341492.0,
"sumLateSourcePenalties": -23772294.0,
"sumMissedAttestationRewards": 267184308.0
},
{
"day": 993,
"sumEarnings": 72803366526,
"sumEstimatedRewards": 72606477307,
"sumEstimatedPenalties": -92099755,
"sumPriorityFees": 19482043694,
"sumBaselineMev": 8999804612,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8473582662,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 101285214832,
"sumWrongTargetPenalties": -36716394.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -9331120.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 64478387038.0,
"sumLateSourcePenalties": -18030117.0,
"sumMissedAttestationRewards": 272457748.0
},
{
"day": 992,
"sumEarnings": 71975424908,
"sumEstimatedRewards": 73002158724,
"sumEstimatedPenalties": -107227509,
"sumPriorityFees": 18884800795,
"sumBaselineMev": 6729257290,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8340423622,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 97589482993,
"sumWrongTargetPenalties": -5972265.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -25987300.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 64448595752.0,
"sumLateSourcePenalties": -26496505.0,
"sumMissedAttestationRewards": 326248992.0
},
{
"day": 991,
"sumEarnings": 71693037399,
"sumEstimatedRewards": 71534022217,
"sumEstimatedPenalties": -80770537,
"sumPriorityFees": 15475987697,
"sumBaselineMev": 2388037004,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8776044106,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 89557062100,
"sumWrongTargetPenalties": -13690729.0,
"sumLateTargetPenalties": -21632.0,
"sumMissedAttestationPenalties": -16372540.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 63028705091.0,
"sumLateSourcePenalties": -16504019.0,
"sumMissedAttestationRewards": 324803231.0
},
{
"day": 990,
"sumEarnings": 71201257831,
"sumEstimatedRewards": 71323917377,
"sumEstimatedPenalties": -61400543,
"sumPriorityFees": 19460495365,
"sumBaselineMev": 20033856389,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8934140687,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 110695609585,
"sumWrongTargetPenalties": -21345376.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -9318400.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62463557805.0,
"sumLateSourcePenalties": -9295104.0,
"sumMissedAttestationRewards": 264891633.0
},
{
"day": 989,
"sumEarnings": 72921120155,
"sumEstimatedRewards": 73099619635,
"sumEstimatedPenalties": -86178482,
"sumPriorityFees": 28427036992,
"sumBaselineMev": 39116573891,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9732141534,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 140464731038,
"sumWrongTargetPenalties": -27817062.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -9261540.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 63476439000.0,
"sumLateSourcePenalties": -13139483.0,
"sumMissedAttestationRewards": 259552569.0
},
{
"day": 988,
"sumEarnings": 70756984738,
"sumEstimatedRewards": 70860707768,
"sumEstimatedPenalties": -88235800,
"sumPriorityFees": 20710830304,
"sumBaselineMev": 15488157260,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8397890884,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 106955972302,
"sumWrongTargetPenalties": -51629604.0,
"sumLateTargetPenalties": -16263.0,
"sumMissedAttestationPenalties": -4412060.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62630617761.0,
"sumLateSourcePenalties": -4766734.0,
"sumMissedAttestationRewards": 257295869.0
},
{
"day": 987,
"sumEarnings": 70893103774,
"sumEstimatedRewards": 70741064230,
"sumEstimatedPenalties": -56303757,
"sumPriorityFees": 24327872488,
"sumBaselineMev": 3849211195,
"sumMissedExecutionRewards": 152541808,
"sumConsensusBlockRewards": 8517893562,
"sumMissedConsensusBlockRewards": 37158073,
"sumAllRewards": 99070187457,
"sumWrongTargetPenalties": -31729126.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -5024360.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62499986937.0,
"sumLateSourcePenalties": -1398628.0,
"sumMissedAttestationRewards": 199524315.0
},
{
"day": 986,
"sumEarnings": 71345527791,
"sumEstimatedRewards": 71509004942,
"sumEstimatedPenalties": -52422987,
"sumPriorityFees": 19311633455,
"sumBaselineMev": 4899880144,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9008353871,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 95557041390,
"sumWrongTargetPenalties": -19962423.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -2417040.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62584831923.0,
"sumLateSourcePenalties": -7754460.0,
"sumMissedAttestationRewards": 174063536.0
},
{
"day": 985,
"sumEarnings": 70353861382,
"sumEstimatedRewards": 70289485267,
"sumEstimatedPenalties": -109933471,
"sumPriorityFees": 13574679849,
"sumBaselineMev": 6958761601,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8293793082,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 90887302832,
"sumWrongTargetPenalties": -26003978.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -19357800.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62272629862.0,
"sumLateSourcePenalties": -15568364.0,
"sumMissedAttestationRewards": 352447031.0
},
{
"day": 984,
"sumEarnings": 69279029765,
"sumEstimatedRewards": 69239938549,
"sumEstimatedPenalties": -57023477,
"sumPriorityFees": 14460823853,
"sumBaselineMev": 970362493,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8035987437,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 84710216111,
"sumWrongTargetPenalties": -19388460.0,
"sumLateTargetPenalties": -5460.0,
"sumMissedAttestationPenalties": -4097860.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 61433252823.0,
"sumLateSourcePenalties": -11460106.0,
"sumMissedAttestationRewards": 263046293.0
},
{
"day": 983,
"sumEarnings": 70119743088,
"sumEstimatedRewards": 70171046005,
"sumEstimatedPenalties": -83004798,
"sumPriorityFees": 16327857620,
"sumBaselineMev": 6121330397,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 9017477978,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 92568931105,
"sumWrongTargetPenalties": -28844478.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -13163200.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 61255338001.0,
"sumLateSourcePenalties": -18498830.0,
"sumMissedAttestationRewards": 255244092.0
},
{
"day": 982,
"sumEarnings": 71838320945,
"sumEstimatedRewards": 71735220828,
"sumEstimatedPenalties": -73764264,
"sumPriorityFees": 18399433628,
"sumBaselineMev": 8332378294,
"sumMissedExecutionRewards": 80856814,
"sumConsensusBlockRewards": 9044614368,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 98570132867,
"sumWrongTargetPenalties": -23823969.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -4908860.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 62993853433.0,
"sumLateSourcePenalties": -4785928.0,
"sumMissedAttestationRewards": 214308844.0
},
{
"day": 981,
"sumEarnings": 69170743871,
"sumEstimatedRewards": 69718217491,
"sumEstimatedPenalties": -81037263,
"sumPriorityFees": 16751087201,
"sumBaselineMev": 8377124384,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8696340897,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 94298955456,
"sumWrongTargetPenalties": -38548822.0,
"sumLateTargetPenalties": -49374.0,
"sumMissedAttestationPenalties": -5117980.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 60936329191.0,
"sumLateSourcePenalties": -13469120.0,
"sumMissedAttestationRewards": 249990574.0
},
{
"day": 980,
"sumEarnings": 67774955877,
"sumEstimatedRewards": 67486593483,
"sumEstimatedPenalties": -86121052,
"sumPriorityFees": 17632932919,
"sumBaselineMev": 3623878190,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 7359748324,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 89031766986,
"sumWrongTargetPenalties": -34863530.0,
"sumLateTargetPenalties": -153608.0,
"sumMissedAttestationPenalties": -9748200.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 60501373581.0,
"sumLateSourcePenalties": -16288356.0,
"sumMissedAttestationRewards": 315871984.0
},
{
"day": 979,
"sumEarnings": 68969624532,
"sumEstimatedRewards": 69125694220,
"sumEstimatedPenalties": -92678427,
"sumPriorityFees": 25457935159,
"sumBaselineMev": 11969638268,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8779398321,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 106397197959,
"sumWrongTargetPenalties": -47274903.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -6799460.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 60501905157.0,
"sumLateSourcePenalties": -12820423.0,
"sumMissedAttestationRewards": 276544680.0
},
{
"day": 978,
"sumEarnings": 68715799142,
"sumEstimatedRewards": 68768785228,
"sumEstimatedPenalties": -103641259,
"sumPriorityFees": 17159615224,
"sumBaselineMev": 3747660259,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8369514059,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 89623074625,
"sumWrongTargetPenalties": -30373213.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -13387720.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 60568975623.0,
"sumLateSourcePenalties": -21386463.0,
"sumMissedAttestationRewards": 322394599.0
},
{
"day": 977,
"sumEarnings": 67647407987,
"sumEstimatedRewards": 67755256605,
"sumEstimatedPenalties": -79139325,
"sumPriorityFees": 17646547352,
"sumBaselineMev": 2810008816,
"sumMissedExecutionRewards": 93426969,
"sumConsensusBlockRewards": 7971601348,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 88103964155,
"sumWrongTargetPenalties": -23310248.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -6767040.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 59942856826.0,
"sumLateSourcePenalties": -10916304.0,
"sumMissedAttestationRewards": 272629654.0
},
{
"day": 976,
"sumEarnings": 67573615877,
"sumEstimatedRewards": 67524182514,
"sumEstimatedPenalties": -54578218,
"sumPriorityFees": 13540169774,
"sumBaselineMev": 2817235411,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8503008669,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 83931021062,
"sumWrongTargetPenalties": -22945481.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -4283860.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 59164461159.0,
"sumLateSourcePenalties": -6292083.0,
"sumMissedAttestationRewards": 209503573.0
},
{
"day": 975,
"sumEarnings": 66437488350,
"sumEstimatedRewards": 66373097798,
"sumEstimatedPenalties": -58055221,
"sumPriorityFees": 17052013003,
"sumBaselineMev": 3878743025,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8083532577,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 87368244378,
"sumWrongTargetPenalties": -32006325.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -5618500.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 58498556338.0,
"sumLateSourcePenalties": -5021800.0,
"sumMissedAttestationRewards": 233054225.0
},
{
"day": 974,
"sumEarnings": 66824414130,
"sumEstimatedRewards": 66851503332,
"sumEstimatedPenalties": -57752865,
"sumPriorityFees": 20969913781,
"sumBaselineMev": 6467713168,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 8587530284,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 94262041079,
"sumWrongTargetPenalties": -31376397.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -5747420.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 58294636711.0,
"sumLateSourcePenalties": -5969586.0,
"sumMissedAttestationRewards": 188969938.0
},
{
"day": 973,
"sumEarnings": 67672180612,
"sumEstimatedRewards": 67602223782,
"sumEstimatedPenalties": -67143708,
"sumPriorityFees": 20409089574,
"sumBaselineMev": 6615645878,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 7848078023,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 94696916064,
"sumWrongTargetPenalties": -19176079.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8843900.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 59980970328.0,
"sumLateSourcePenalties": -6192389.0,
"sumMissedAttestationRewards": 158298360.0
}
],
"next": "/v0/eth/operators/Kiln/effectiveness?idType=nodeOperator&granularity=day&from=2023-07-31&size=31&filterType=datetime&include=sumEarnings&include=day&include=sumEstimatedRewards&include=sumEstimatedPenalties&include=sumPriorityFees&include=sumBaselineMev&include=sumMissedExecutionRewards&include=sumConsensusBlockRewards&include=sumMissedConsensusBlockRewards&include=sumAttestationRewards&include=sumAllRewards&include=sumMissedAttestationRewards&include=sumMissedAttestationPenalties&include=sumWrongTargetPenalties&include=sumLateTargetPenalties&include=sumWrongHeadPenalties&include=sumLateSourcePenalties"
}
```
Note that if you're looking to get the same data grouped by withdrawal/deposit address, you can simply input `operator_id` as the address (`0x..`) and `idType` as `withdrawalAddress` or `depositAddress`.
#### Step 2.2: Getting Rewards for specific validators groups
For validator groupings, you will need to call the [Aggregating validator indices](/rated-api/api-reference/v0/ethereum/validators/get-effectiveness-aggregation) endpoint. We'll show this similarly as above for all reward details for the month of August 2023 for a set of validator indices, aggregated daily.
| Key | Required? | Value | Description |
| :----------------------- | :-------- | :------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `pubkeys` (OR) `indices` | Yes | array \[string] (OR) array \[integer] | Array of validator pubkeys or indicies you're performing the grouped analysis for. For this example, you should put indices as `675893` `675894` and `675895` |
| `filterType` | Yes | string | `hour`, `day` and `datetime`. For this example, set to `datetime` |
| `from` | Yes | string | The most recent date for your desired timeline. In this example, it is `2023-08-31` |
| `size` | Yes | integer | The number of results included per page. For this example, you should set size as 31 as we want the monthly data for August 2023. |
| `granularity` | Yes | string | The size of time increments you are looking to query. Can be `day` / `week` / `month` / `quarter` / `year`. For this example, set granularity to `day`. |
| `groupBy` | Yes | string | Aggregation groupings. Can be `timeWindow` if you'd like to aggregation for your desired time window or `validator` if you'd like it per validator. For this example, set it to `timeWindow`. |
| `include` | Yes | array \[string] | A list of field names. To get the rewards data, you should include the following data: `day`, `sumEarnings`, `sumEstimatedRewards`, `sumEstimatedPenalties`, `sumPriorityFees`, `sumBaselineMev`, `sumMissedExecutionRewards`, `sumConsensusBlockRewards`, `sumMissedConsensusBlockRewards`, `sumAllRewards`, `sumAttestationRewards`, `sumMissedAttestationRewards`, `sumMissedAttestationPenalties`, `sumWrongTargetPenalties`, `sumLateTargetPenalties`, `sumWrongHeadPenalties` and `sumLateSourcePenalties` |
#### Get Effectiveness Aggregation
**Example**: Obtaining daily reward metrics for the month of August 2023 for Validator group `{675893, 675894, 675895}`
```sh curl theme={null}
curl -v -X 'GET' \
'https://api.rated.network/v0/eth/validators/effectiveness?indices=675893&indices=675894&indices=675895&granularity=day&from=2023-08-31&size=31&filterType=datetime&groupBy=timeWindow&include=sumEarnings&include=day&include=sumEstimatedRewards&include=sumEstimatedPenalties&include=sumPriorityFees&include=sumBaselineMev&include=sumMissedExecutionRewards&include=sumConsensusBlockRewards&include=sumMissedConsensusBlockRewards&include=sumAttestationRewards&include=sumAllRewards&include=sumMissedAttestationRewards&include=sumMissedAttestationPenalties&include=sumWrongTargetPenalties&include=sumLateTargetPenalties&include=sumWrongHeadPenalties&include=sumLateSourcePenalties' \
-H 'Content-Type: application/json' \
-H 'X-Rated-Network: mainnet' \
-H 'Authorization: Bearer '
```
```python python theme={null}
import requests
url = "https://api.rated.network/v0/eth/validators/effectiveness"
params = {
"indices": [675893, 675894, 675895],
"granularity": "day",
"from": "2023-08-31",
"size": 31,
"filterType": "datetime",
"groupBy": "timeWindow",
"include": [
"sumEarnings",
"day",
"sumEstimatedRewards",
"sumEstimatedPenalties",
"sumPriorityFees",
"sumBaselineMev",
"sumMissedExecutionRewards",
"sumConsensusBlockRewards",
"sumMissedConsensusBlockRewards",
"sumAttestationRewards",
"sumAllRewards",
"sumMissedAttestationRewards",
"sumMissedAttestationPenalties",
"sumWrongTargetPenalties",
"sumLateTargetPenalties",
"sumWrongHeadPenalties",
"sumLateSourcePenalties"
]
}
headers = {
"Content-Type": "application/json",
"X-Rated-Network": "mainnet",
"Authorization": "Bearer "
}
response = requests.get(url, params=params, headers=headers)
print(response.json())
```
You will get the following response:
```json theme={null}
{
"page": {
"from": "2023-08-31",
"to": null,
"size": 31,
"granularity": "day",
"filterType": "datetime"
},
"total": 405,
"data": [
{
"day": 1003,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7323094,
"sumWrongTargetPenalties": -10608.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7333702.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 42897.0
},
{
"day": 1002,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7352178,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8180.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7360358.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 27504.0
},
{
"day": 1001,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7308796,
"sumWrongTargetPenalties": -21320.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7330116.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 61341.0
},
{
"day": 1000,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7296080,
"sumWrongTargetPenalties": -10673.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7321103.0,
"sumLateSourcePenalties": -14350.0,
"sumMissedAttestationRewards": 64617.0
},
{
"day": 999,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7369542,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8220.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7377762.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 24528.0
},
{
"day": 998,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7373639,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7376516.0,
"sumLateSourcePenalties": -2877.0,
"sumMissedAttestationRewards": 24370.0
},
{
"day": 997,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7362400,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8240.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7373524.0,
"sumLateSourcePenalties": -2884.0,
"sumMissedAttestationRewards": 46694.0
},
{
"day": 996,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7416434,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7419325.0,
"sumLateSourcePenalties": -2891.0,
"sumMissedAttestationRewards": 19434.0
},
{
"day": 995,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7433960,
"sumWrongTargetPenalties": -5369.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7439329.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 16214.0
},
{
"day": 994,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7375968,
"sumWrongTargetPenalties": -10764.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8280.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7400808.0,
"sumLateSourcePenalties": -5796.0,
"sumMissedAttestationRewards": 71112.0
},
{
"day": 993,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7438829,
"sumWrongTargetPenalties": -5382.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7444211.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 24790.0
},
{
"day": 992,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7436435,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7439340.0,
"sumLateSourcePenalties": -2905.0,
"sumMissedAttestationRewards": 35287.0
},
{
"day": 991,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7436976,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7436976.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 36077.0
},
{
"day": 990,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7463503,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7463503.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 22090.0
},
{
"day": 989,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7433338,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -16680.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7452937.0,
"sumLateSourcePenalties": -2919.0,
"sumMissedAttestationRewards": 58700.0
},
{
"day": 988,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7487113,
"sumWrongTargetPenalties": -10842.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7497955.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 30200.0
},
{
"day": 987,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7505733,
"sumWrongTargetPenalties": -10868.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7516601.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 35666.0
},
{
"day": 986,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7391225,
"sumWrongTargetPenalties": -5434.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -58520.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7455179.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 106388.0
},
{
"day": 985,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7505601,
"sumWrongTargetPenalties": -10894.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7516495.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 39010.0
},
{
"day": 984,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7529373,
"sumWrongTargetPenalties": -10920.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7543233.0,
"sumLateSourcePenalties": -2940.0,
"sumMissedAttestationRewards": 43993.0
},
{
"day": 983,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7556157,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7556157.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 14160.0
},
{
"day": 982,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7580477,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7580477.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 19784.0
},
{
"day": 981,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7567289,
"sumWrongTargetPenalties": -5486.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7575729.0,
"sumLateSourcePenalties": -2954.0,
"sumMissedAttestationRewards": 25280.0
},
{
"day": 980,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7569934,
"sumWrongTargetPenalties": -10972.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7580906.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 30199.0
},
{
"day": 979,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7459291,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -59220.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7524433.0,
"sumLateSourcePenalties": -5922.0,
"sumMissedAttestationRewards": 101713.0
},
{
"day": 978,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7555320,
"sumWrongTargetPenalties": -11011.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7569292.0,
"sumLateSourcePenalties": -2961.0,
"sumMissedAttestationRewards": 58219.0
},
{
"day": 977,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7630867,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7630867.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 22499.0
},
{
"day": 976,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7648668,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7648668.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 14216.0
},
{
"day": 975,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7583032,
"sumWrongTargetPenalties": -16575.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -8500.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7608107.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 61688.0
},
{
"day": 974,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7627491,
"sumWrongTargetPenalties": -11076.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": 0.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7641549.0,
"sumLateSourcePenalties": -2982.0,
"sumMissedAttestationRewards": 47934.0
},
{
"day": 973,
"sumPriorityFees": 0,
"sumBaselineMev": 0,
"sumMissedExecutionRewards": 0,
"sumConsensusBlockRewards": 0,
"sumMissedConsensusBlockRewards": 0,
"sumAllRewards": 7655815,
"sumWrongTargetPenalties": 0.0,
"sumLateTargetPenalties": 0.0,
"sumMissedAttestationPenalties": -17040.0,
"sumWrongHeadPenalties": 0.0,
"sumAttestationRewards": 7672855.0,
"sumLateSourcePenalties": 0.0,
"sumMissedAttestationRewards": 31458.0
}
],
"next": "/v0/eth/validators/effectiveness?indices=675893&indices=675894&indices=675895&from=2023-07-31&size=31&granularity=day&groupBy=timeWindow&filterType=datetime&include=sumEarnings&include=sumEstimatedRewards&include=sumEstimatedPenalties&include=sumPriorityFees&include=sumBaselineMev&include=sumMissedExecutionRewards&include=sumConsensusBlockRewards&include=sumMissedConsensusBlockRewards&include=sumAllRewards&include=sumAttestationRewards&include=sumMissedAttestationRewards&include=sumMissedAttestationPenalties&include=sumWrongTargetPenalties&include=sumLateTargetPenalties&include=sumWrongHeadPenalties&include=sumLateSourcePenalties"
}
```
# Rated CLI
Source: https://docs.rated.network/rated-api/tools/rated-cli
A community built Prometheus exporter for the Rated API
The rated-cli is an OS community built tool that allows power users to port Rated API metrics over to their local monitoring environments. You can learn more about in on [this Github repo](https://github.com/rated-network/rated-cli).
![]()
Please remember to contribute back to the main branch with extensions you might build locally, that can be generalised and add value to others.
# Rated Console
Source: https://docs.rated.network/rated-api/tools/rated-console
A dashboard console for the Rated API
# Rated Network Explorer
Source: https://docs.rated.network/rated-api/tools/rated-explorer
A Network Explorer based of the Rated API
# Rated SDK
Source: https://docs.rated.network/rated-api/tools/rated-sdk
Libraries and tools for interacting with your Rated integration
The SDK is currently in beta phase. If you find bugs, please open an [issue](https://github.com/rated-network/rated-python/issues) on Github. If you have feature requests or feedback, head to [feedback.rated.network]().
Rated's [Python SDK](https://github.com/rated-network/rated-python) reduces the amount of work required to use Rated's REST APIs, starting with reducing the boilerplate code you have to write. Below is the installation instructions for this library in Python.
### Installation
Install using `pip`:
```bash theme={null}
pip install rated-python
```
### Usage
**Example:** how to get a validator effectiveness rating by pubkey
```python theme={null}
from rated import Rated
from rated.ethereum import MAINNET
RATED_KEY = "ey..."
r = Rated(RATED_KEY)
eth = r.ethereum(network=MAINNET)
for eff in eth.validator.effectiveness("0x123456789...", from_day=873, size=1):
print(f"Day: {eff.day}, Eff: {eff.validator_effectiveness}")
>>> Day: 873, Eff: 98.82005899705014
```
Try this beta SDK and share feedback with us before the features reach the stable phase. To learn more about how to use the beta SDK, head to the [readme file](https://github.com/rated-network/rated-python/blob/main/README.md) in the GitHub repository.
# Product Updates
Source: https://docs.rated.network/changelog
Starting July 9, 2025, support for the [Polygon](https://docs.rated.network/rated-api/api-reference/v1/polygon/overview/overview) network on the Rated API will be put under maintenance. This is due to the significant revamp of the Polygon Proof-of-Stake network's consensus component, Heimdall. We will be upgrading our data infrastructure to support [Heimdall v2](https://forum.polygon.technology/t/heimdall-v2-migration/21017). We apologize for any inconvenience this may cause.
Stay tuned here, in our [Discord](https://discord.com/invite/qnK8pYkQvy), and in our [forum](https://feedback.rated.network) for the latest updates. Feel free to reach out and tell us how we can best support you through the upgrade.
With the [Ethereum Pectra upgrade](https://eips.ethereum.org/EIPS/eip-7600), we are releasing new endpoints where you can access data on validator consolidations.
**GET** `/v1/eth/validators/consolidations`
* This endpoint returns a daily list of processed validator consolidations on Ethereum, along with metadata such as the entities involved in the consolidations ([docs](/rated-api/api-reference/v1/ethereum/metadata/get-consolidations-for-validators)).
***Sample Request***
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/eth/validators/consolidations'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
***Sample Response***
```json theme={null}
{
"previous": null,
"next": null,
"pages": 1,
"results": [
{
"date": "2025-05-07",
"consolidationEpoch": 364266,
"sourceValidatorIndex": 500000,
"sourceEntity": "Node Operator 1",
"sourceEntityType": "nodeOperator",
"targetValidatorIndex": 500002,
"targetEntity": "StakePool",
"targetEntityType": "pool",
"consolidatedAmount": 32000000000,
"targetBalanceBeforeConsolidationEpoch": 32000000000,
"targetBalanceAtConsolidationEpoch": 64000000000,
"targetEffectiveBalanceAtConsolidationEpoch": 64000000000,
},
{
"date": "2025-05-07",
"consolidationEpoch": 364266,
"sourceValidatorIndex": 766532,
"sourceEntity": "Node Operator 2",
"sourceEntityType": "nodeOperator",
"targetValidatorIndex": 766531,
"targetEntity": "Node Operator 2",
"targetEntityType": "nodeOperator",
"consolidatedAmount": 32000000000,
"targetBalanceBeforeConsolidationEpoch": 32000000000,
"targetBalanceAtConsolidationEpoch": 64000000000,
"targetEffectiveBalanceAtConsolidationEpoch": 64000000000,
}
]
}
```
**GET** `/v1/eth/entityConsolidations`
* Returns validator consolidations data aggregated by entity. This is based on the entity that triggers the consolidation (ie. the source validator) ([docs](/rated-api/api-reference/v1/ethereum/metadata/get-validator-consolidations-information-for-pools-and-operators)).
***Sample Request***
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/eth/entityConsolidations?entity=Pooler'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
***Sample Response***
```json theme={null}
{
"previous": null,
"next": null,
"pages": 1,
"results": [
{
"date": "2025-05-10",
"sourceEntity": "Pooler",
"sourceEntityType": "nodeOperator",
"consolidatedValidators": 20,
"consolidatedBalance": 640000000000,
},
{
"date": "2025-05-12",
"sourceEntity": "Pooler",
"sourceEntityType": "nodeOperator",
"consolidatedValidators": 10,
"consolidatedBalance": 320000000000,
}
]
}
```
**GET** `/v1/eth/consolidationCapacity`
* This endpoint gives summarized information on the validator consolidation churn limit of the Ethereum network across defined time windows ([docs](/rated-api/api-reference/v1/ethereum/network/get-information-on-the-validator-consolidation-churn-capacity-of-ethereum)).
***Sample Request***
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/eth/consolidationCapacity'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
***Sample Response***
```json theme={null}
{
"previous": null,
"next": null,
"pages": 1,
"results": [
{
"timeWindow": "all",
"latestEpoch": 364032,
"consolidationChurnLimit": 49693200000000000,
"consolidatedValidators": 220000,
"consolidatedBalance": 7040000000000000,
"consolidationCapacityFilled": 0.14,
"consolidatedPercentage": 0.10,
},
....
{
"timeWindow": "1d",
"latestEpoch": 364032,
"consolidationChurnLimit": 28800000000000,
"consolidatedValidators": 120,
"consolidatedBalance": 3840000000000,
"consolidationCapacityFilled": 0.13,
"consolidatedPercentage": 0.00012,
}
]
}
```
**GET** `/v1/eth/consolidationCapacity/entity`
* This endpoint gives summarized information on the validator consolidation churn limit of the Ethereum network on a per entity level across defined time windows ([docs](/rated-api/api-reference/v1/ethereum/network/get-information-on-the-per-entity-validator-consolidation-churn-capacity-of-ethereum)).
***Sample Request***
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/eth/consolidationCapacity/entity'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
***Sample Response***
```json theme={null}
{
"previous": null,
"next": null,
"pages": 1,
"results": [
{
"timeWindow": "all",
"latestEpoch": 364032,
"consolidationChurnLimit": 49693200000000000,
"entity": "PoolTwo",
"consolidatedValidators": 10000,
"consolidatedBalance": 320000000000000,
"consolidationCapacityFilled": 0.006,
"networkCapacityRemaining": 0.994,
},
....
{
"timeWindow": "all",
"latestEpoch": 364032,
"consolidationChurnLimit": 49693200000000000,
"entity": "EightPool",
"consolidatedValidators": 5000,
"consolidatedBalance": 160000000000000,
"consolidationCapacityFilled": 0.003,
"networkCapacityRemaining": 0.991,
}
]
}
```
**Learn more**
We encourage you to check out our [API documentation](/rated-api/api-reference/v1/ethereum/metadata/get-consolidations-for-validators) to learn more about validator consolidations on Ethereum and the Pectra upgrade in general. You can also find a [glossary for the different fields](/rated-api/glossary/ethereum/validators) in the responses returned by these endpoints.
**Reach out**
How can we better support you? Let us know at [feedback.rated.network](https://feedback.rated.network) or at [hello@rated.network](mailto:hello@rated.network)
After being stable for the past few weeks and passing data quality checks, we will be taking the [Babylon Genesis rewards endpoints](/rated-api/api-reference/v1/babylon/rewards/rewards) out of the beta period on May 2, 2025.
This means that these endpoints will start to consume compute units (CUs) and will be billed accordingly. For more information on compute unit consumption and our pricing plans, please see our [documentation](/rated-api/pricing/compute-units).
If you have any questions or feedback, feel free to reach out to us at [feedback.rated.network](https://feedback.rated.network) or at [hello@rated.network](mailto:hello@rated.network).
Starting today, you can access and query rewards data for validators on Babylon Genesis, both at an individual level and network level over a specified time period. In addition to this, you can also access stake balance data for validators and delegators. These rewards and stake balances are denominated in the network's native token, `BABY`.
**GET** `/v1/babylon/validators/{validator_address}/rewards`
* Provides a detailed summary of all rewards earned by a specific validator, identified by their `validator_address`
***Sample Request***
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/babylon/validators/bbnvaloper109x4ruspxarwt62puwcenhclw36l9v7j92f0ex/rewards?fromDate=2025-02-01&toDate=2025-02-03'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
***Sample Response***
```json theme={null}
{
"previous": null,
"next": null,
"pages": 1,
"results": [
{
"day": "2025-02-01",
"validator": "bbnvaloper109x4ruspxarwt62puwcenhclw36l9v7j92f0ex",
"validatorMoniker": "Babylon Labs 1",
"consensusAddress": "bbnvalcons1s7r9pmnkqkw4vy83rp8f4dxtfclayurjxpx9sn",
"consensusPubkey": "6dNq2wZBtn8kOc1O+n6cKTQMVM5HPCeYGFufeaarQDI=",
"accountAddress": "bbn109x4ruspxarwt62puwcenhclw36l9v7jcgrj48",
"fromBlockNumber": 186727,
"toBlockNumber": 194673,
"totalDelegationRewards": 42724.99651515086,
"totalCommissionRewards": 1281.7498954545258,
"commissionRate": 0.03
},
{
"day": "2025-02-03",
"validator": "bbnvaloper109x4ruspxarwt62puwcenhclw36l9v7j92f0ex",
"validatorMoniker": "Babylon Labs 1",
"consensusAddress": "bbnvalcons1s7r9pmnkqkw4vy83rp8f4dxtfclayurjxpx9sn",
"consensusPubkey": "6dNq2wZBtn8kOc1O+n6cKTQMVM5HPCeYGFufeaarQDI=",
"accountAddress": "bbn109x4ruspxarwt62puwcenhclw36l9v7jcgrj48",
"fromBlockNumber": 202598,
"toBlockNumber": 210519,
"totalDelegationRewards": 41566.81039846076,
"totalCommissionRewards": 1247.0043119538227,
"commissionRate": 0.03
}
]
}
```
**GET** `/v1/babylon/network/rewards`
* Provides historical network level rewards for Babylon Genesis
***Sample Request***
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/babylon/network/rewards?fromDate=2025-02-01&toDate=2025-02-02'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
**Sample Response**
```json theme={null}
{
"previous":null,
"next":null,
"pages":1,
"results":[
{
"day":"2025-02-01",
"fromBlockNumber":186727,
"toBlockNumber":194673,
"totalBondedValidators":100,
"totalDelegationRewards":208637.819,
"totalCommissionRewards":26793.123,
"avgCommissionRate":0.0932
},
{
"day":"2025-02-02",
"fromBlockNumber":194674,
"toBlockNumber":202597,
"totalBondedValidators":100,
"totalDelegationRewards":208605.944,
"totalCommissionRewards":26792.561,
"avgCommissionRate":0.0932
}
]
}
```
**GET** `/v1/babylon/validators/{validator_address}/state`
* Provides historical stake balances for a validator based on their `validator_address`
**Sample Request**
```curl theme={null}
curl -X 'GET' https://api.rated.network/v1/babylon/validators/bbnvaloper109x4ruspxarwt62puwcenhclw36l9v7j92f0ex/state?fromDate=2025-03-13&toDate=2025-03-14'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
**Sample Response**
```json theme={null}
{
"previous": null,
"next": null,
"pages": 1,
"results": [
{
"day": "2025-03-14",
"fromBlockNumber": 499203,
"toBlockNumber": 506515,
"validator": "bbnvaloper109x4ruspxarwt62puwcenhclw36l9v7j92f0ex",
"activeStake": 201.331,
"totalDelegators": 7
},
{
"day": "2025-03-13",
"fromBlockNumber": 491577,
"toBlockNumber": 499202,
"validator": "bbnvaloper109x4ruspxarwt62puwcenhclw36l9v7j92f0ex",
"activeStake": 0.002,
"totalDelegators": 1
}
]
}
```
**GET** `/v1/babylon/delegators/{delegator_address}/state`
* Provides historical stake balances for a delegator based on their `delegator_address` per validator they are delegated to
**Sample Request**
```curl theme={null}
curl -X 'GET' https://api.rated.network/v1/babylon/delegators/bbn12jm9z6hwm4ex7c0z8htey3yhyfhx44znrdhfnm/state?fromDate=2025-03-13&toDate=2025-03-14'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
**Sample Response**
```json theme={null}
{
"previous": null,
"next": null,
"pages": 1,
"results": [
{
"day": "2025-03-14",
"fromBlockNumber": 499203,
"toBlockNumber": 506515,
"validator": "bbnvaloper12jm9z6hwm4ex7c0z8htey3yhyfhx44zn70a5l6",
"delegator": "bbn12jm9z6hwm4ex7c0z8htey3yhyfhx44znrdhfnm",
"activeStake": 3015.67206
},
{
"day": "2025-03-14",
"fromBlockNumber": 499203,
"toBlockNumber": 506515,
"validator": "bbnvaloper1zsk3edk6ekplakmnvuv326kc7t45gfrzv2rrl7",
"delegator": "bbn12jm9z6hwm4ex7c0z8htey3yhyfhx44znrdhfnm",
"activeStake": 12400
},
{
"day": "2025-03-13",
"fromBlockNumber": 491577,
"toBlockNumber": 499202,
"validator": "bbnvaloper12jm9z6hwm4ex7c0z8htey3yhyfhx44zn70a5l6",
"delegator": "bbn12jm9z6hwm4ex7c0z8htey3yhyfhx44znrdhfnm",
"activeStake": 333.014659
}
]
}
```
**Learn more**
We encourage you to check out our [API documentation](/rated-api/api-reference/v1/babylon/rewards/rewards) to learn more about rewards behavior on Babylon. You can also find a [glossary for the different fields](/rated-api/glossary/babylon) in the responses returned by these endpoints.
**Beta Release and Pricing**
During the beta period, access to these new endpoints will be free. Compute unit based pricing will be introduced post-beta.
Given the plan of the Ethereum Core Devs to [stop supporting the Holesky testnet by September 2025](https://x.com/nixorokish/status/1902067313513525575), we are deprecating our support for Holesky.
We advice clients and partners to stop using our Ethereum endpoints for the Holesky network given degrading data quality due to issues with the testnet itself.
On a related note, let us know if you would like us to offer validator performance data support for the recently launched Hoodi testnet at [feedback.rated.network](https://feedback.rated.network).
After being stable for the past few weeks and passing data quality checks, we will be taking the [Cardano rewards endpoints](/rated-api/api-reference/v1/cardano/rewards/rewards) out of the beta period on March 7, 2025.
This means that these endpoints will start to consume compute units (CUs) and will be billed accordingly. For more information on compute unit consumption and our pricing plans, please see our [documentation](/rated-api/pricing/compute-units).
If you have any questions or feedback, feel free to reach out to us at [feedback.rated.network](https://feedback.rated.network) or at [hello@rated.network](mailto:hello@rated.network).
Starting today, you can access and query rewards data for validators on Polkadot, both at an individual level and network level over a specified time period. These rewards are denominated in the network's native token, `DOT`.
**GET** `/v1/polkadot/validators/{validator_address}/rewards`
* Provides a detailed summary of all rewards earned by a specific validator, identified by their `stashAccountAddress` which is what we are considering as the `validator_address`.
***Sample Request***
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/polkadot/49qZqcHHbsmHfo1NebF2xZHb4TJJpiqZZ3reeTo8dZov6LZ/rewards?fromDate=2025-02-01&toDate=2025-02-03'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
***Sample Response***
```json theme={null}
{
"previous":null,
"next":null,
"pages":1,
"results":[
{
"day":"2025-02-03",
"stashAccountAddress":"49qZqcHHbsmHfo1NebF2xZHb4TJJpiqZZ3reeTo8dZov6LZ",
"validatorName":"Validator 49qZqc",
"totalValidatorRewards":31.1734487904,
"totalDelegatorRewards":509.5058978832,
"totalStake":1677788.1924884196,
"ownStake":13634.8169149428,
"nominatorCount":30
},
{
"day":"2025-02-02",
"stashAccountAddress":"49qZqcHHbsmHfo1NebF2xZHb4TJJpiqZZ3reeTo8dZov6LZ",
"validatorName":"Validator 49qZqc",
"totalValidatorRewards":31.9884351335,
"totalDelegatorRewards":523.3591219791,
"totalStake":1687899.947075712,
"ownStake":13602.8284798092,
"nominatorCount":36
},
{
"day":"2025-02-01",
"stashAccountAddress":"49qZqcHHbsmHfo1NebF2xZHb4TJJpiqZZ3reeTo8dZov6LZ",
"validatorName":"Validator 49qZqc",
"totalValidatorRewards":32.4620415819,
"totalDelegatorRewards":530.5921283948,
"totalStake":1696128.927065384,
"ownStake":13570.3664382274,
"nominatorCount":40
}
]
}
```
**GET** `/v1/polkadot/network/rewards`
* Provides historical network level rewards for the Polkadot relay chain
***Sample Request***
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/polkadot/network/rewards?fromDate=2025-02-14&toDate=2025-02-14'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
**Sample Response**
```json theme={null}
{
"previous":null,
"next":null,
"pages":1,
"results":[
{
"day":"2025-02-14",
"totalValidatorRewards":47879.4255002901,
"totalDelegatorRewards":145043.2524373676,
"totalActiveValidators":500,
"totalNominators":21869
}
]
}
```
**Learn more**
We encourage you to check out our [API documentation](/rated-api/api-reference/v1/polkadot/rewards/rewards) to learn more about rewards behavior on Polkadot. You can also find a [glossary for the different fields](/rated-api/glossary/polkadot) in the responses returned by these endpoints. Lastly, we have historical rewards data going back to November 1, 2024.
**Beta Release and Pricing**
During the beta period, access to these new endpoints will be free. Compute unit based pricing will be introduced post-beta.
**More to come**
This is part of Rated's ongoing effort to expand its coverage to more chains and networks. In case you missed it, we recently released support for [Celestia](#february-04-2025) and [Cardano](#february-19-2025) as well.
Stay tuned for more!
*If you have any questions or feedback, especially on which networks we should cover, feel free to reach out to us at* [*feedback.rated.network*](http://feedback.rated.network/) *or at* [*hello@rated.network*](mailto:hello@rated.network)*.*
After being stable for the past few weeks and passing data quality checks, we will be taking the [Avalanche rewards endpoints](/rated-api/api-reference/v1/avalanche/rewards/rewards) out of the beta period on March 3, 2025.
This means that these endpoints will start to consume compute units (CUs) and will be billed accordingly. For more information on compute unit consumption and our pricing plans, please see our [documentation](/rated-api/pricing/compute-units).
If you have any questions or feedback, feel free to reach out to us at [feedback.rated.network](https://feedback.rated.network) or at [hello@rated.network](mailto:hello@rated.network).
We have introduced an update to the Rated Console that streamlines how you monitor, analyze, and manage your private set of validators. These changes enable you to better understand validator performance and rewards, while also providing powerful navigation and filtering tools to help you quickly access the data that matters most.
**New Features and Improvements**
1. Validator Effectiveness Column
* Displays the effectiveness score for each set of validators in your dashboard.
2. Sorting and Filtering
* Allows sorting by any column and narrowing down your view by specific time windows.
3. Enhanced UI and Navigation
* Provides a more intuitive interface for viewing, comparing, and analyzing individual validators within your private sets.
**Expanded Set View Metrics**
1. Network Penetration
2. Annual Percentage Rate (APR%)
3. Effectiveness Breakdown
4. Performance Metrics
5. Rewards Metrics
6. Execution Layer Metrics
7. Consensus Layer Metrics
**Compute Unit Consumption**
Viewing these pages will consume compute units. An indicator of Compute Units consumed will be displayed on the page.
We hope you find these enhancements valuable and that they offer deeper insights into your validator sets' performance.
*If you have any questions or feedback, head to* [*feedback.rated.network*](http://feedback.rated.network/)*. We're here to help.*
After being stable for the past few weeks and passing data quality checks, we will be taking the [Celestia rewards endpoints](/rated-api/api-reference/v1/celestia/rewards/rewards) out of the beta period on February 25, 2025.
This means that these endpoints will start to consume compute units (CUs) and will be billed accordingly. For more information on compute unit consumption and our pricing plans, please see our [documentation](/rated-api/pricing/compute-units).
If you have any questions or feedback, feel free to reach out to us at [feedback.rated.network](https://feedback.rated.network) or at [hello@rated.network](mailto:hello@rated.network).
Starting today, you can access and query rewards data for stake pools (validators) on Cardano, both at an individual level and network level over a specified time period. These rewards are denominated in the network's native token, `ADA`.
**GET** `/v1/cardano/validators/{pool_id}/rewards`
* Provides a detailed summary of all rewards earned by a specific stake pool/validator, identified by their `pool_id`
* The `pool_id` can either be the human-readable version in the form of 'pool' + 52 characters (e.g. `pool1z5uqdk7dzdxaae5633fqfcu2eqzy3a3rgtuvy087fdld7yws0xt`) or the hashed version of this `pool_id` (e.g`153806dbcd134ddee69a8c5204e38ac80448f62342f8c23cfe4b7edf`). This is called `poolHashId` in the response.
***Sample Request***
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/cardano/pool1z5uqdk7dzdxaae56fdld7yws0xt33fqfcu2eqzy3a3rgtuvy087/rewards?fromDate=2025-02-03&toDate=2025-02-05'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
***Sample Response***
```json theme={null}
{
"previous":null,
"next":null,
"pages":1,
"results":[
{
"day":"2025-02-05",
"epoch":538,
"fromBlockNumber":11442645,
"toBlockNumber":11446899,
"fromSlotNumber":147147330,
"toSlotNumber":147233694,
"poolId":"pool1z5uqdk7dzdxaae56fdld7yws0xt33fqfcu2eqzy3a3rgtuvy087",
"poolName":"OPool",
"poolTicker":"OPO",
"poolOwnerStakeAddresses":[
"stake1uy89kzrdlpadjp73vcs3qhktrtmz5rzu8x95r4qnlpqhd3f8mf09e"
],
"poolHashId":"15380ac80448f62342f8c23cfe4b7ed6dbcd134ddee6",
"totalRealizedDelegatorRewards":0,
"totalRealizedValidatorRewards":0,
"totalEarnedDelegatorRewards":0,
"totalEarnedValidatorRewards":0,
"poolFee":0.009,
"poolFlatFee":340.0
},
<...>
{
"day":"2025-02-03",
"epoch":537,
"fromBlockNumber":11434179,
"toBlockNumber":11438051,
"fromSlotNumber":146974549,
"toSlotNumber":147052765,
"poolId":"pool1z5uqdk7dzdxaae56fdld7yws0xt33fqfcu2eqzy3a3rgtuvy087",
"poolName":"OPool",
"poolTicker":"OPO",
"poolOwnerStakeAddresses":[
"stake1uy89kzrdlpadjp73vcs3qhktrtmz5rzu8x95r4qnlpqhd3f8mf09e"
],
"poolHashId":"15380ac80448f62342f8c23cfe4b7ed6dbcd134ddee6",
"totalRealizedDelegatorRewards":25933.92021,
"totalRealizedValidatorRewards":758.90481,
"totalEarnedDelegatorRewards":22519.27481,
"totalEarnedValidatorRewards":707.24599,
"poolFee":0.009,
"poolFlatFee":340.0
},
]
}
```
**GET** `/v1/cardano/network/rewards`
* Provides historical network level stake pool rewards for Cardano
***Sample Request***
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/cardano/network/rewards?fromDate=2025-02-03&toDate=2025-02-03'
-H 'accept: application/json'
-H 'Authorization: Bearer '
```
**Sample Response**
```json theme={null}
{
"previous":null,
"next":null,
"pages":1,
"results":[
{
"day":"2025-02-03",
"epoch":537,
"fromBlockNumber":11434179,
"toBlockNumber":11438051,
"fromSlotNumber":146974549,
"toSlotNumber":147052765,
"totalActivePools":2974,
"totalRealizedDelegatorRewards":6301696.1356,
"totalRealizedValidatorRewards":1657505.78516,
"totalEarnedDelegatorRewards":6305413.42208,
"totalEarnedValidatorRewards":1674076.96465,
"avgPoolFee":0.05058,
"avgPoolFlatFee":550.00433
}
]
}
```
**Learn more**
We encourage you to check out our [API documentation](/rated-api/api-reference/v1/cardano/rewards/rewards) to learn more about rewards behavior on Celestia. You can also find a [glossary for the different fields](/rated-api/glossary/cardano) in the responses returned by these endpoints. Lastly, we have historical rewards data going back to November 1, 2024.
**Beta Release and Pricing**
During the beta period, access to these new endpoints will be free. Compute unit based pricing will be introduced post-beta.
**More to come**
This is part of Rated's ongoing effort to expand its coverage to more chains and networks. In case you missed it, we recently released support for [Avalanche](#january-30-2025) and [Celestia](#february-04-2025) as well.
Stay tuned for more!
*If you have any questions or feedback, especially on which networks we should cover, feel free to reach out to us at* [*feedback.rated.network*](http://feedback.rated.network/) *or at* [*hello@rated.network*](mailto:hello@rated.network)*.*
We're placing the solo staker list where it belongs: in the hands of the community.
The solo-staker filter and repository, originally curated by **Rated Labs**, is being handed over to [**EthStaker**](https://ethstaker.org) for ongoing stewardship.
## **What's Changing**
1. **Management & Oversight**
* **Before**: Rated managed and updated the “solo-stakers” repository, which contains heuristics and lists mapping addresses to potential solo validators on Ethereum.
* **Now**: EthStaker will assume primary responsibility for maintenance, updates, and community support. This includes curating new releases, reviewing community feedback, and stewarding the underlying dataset.
2. **Methodology & Data**
* The [existing methodology documentation](https://github.com/eth-educators/solo-stakers?tab=readme-ov-file#solo-stakers) (including the September 2024 update and prior versions) remains publicly accessible.
* EthStaker now manages all relevant data and methodologies, including deposit address mappings, withdrawal address associations, and the supporting heuristics.
3. **Community Involvement**
* Feedback, issues, and pull requests will now be directed to EthStaker, fostering a broader decentralized ethos for the project.
* For the transition period in the near term, Rated will stay involved as an advisor, helping address any questions on methodology while EthStaker manages the dataset.
## **Why EthStaker?**
EthStaker is a community dedicated to fostering a healthy and decentralized Ethereum staking ecosystem. With their active presence in the Ethereum solo staker community, they are well-positioned to guide the repository's future growth and ensure it remains a trusted resource for identifying self-sovereign stakers.
## **Looking Ahead**
* **Community Feedback**: We encourage validators, researchers, and the broader Ethereum community to provide feedback on the solo staker filter and make suggestions for improvements.
* **Periodic Updates**: EthStaker will continue publishing refreshed lists based on new data, feedback, and evolving best practices, ensuring the dataset remains accurate and relevant.
* **Opportunities for Innovation**: This handover paves the way for deeper integration with new staking tools, potential airdrops targeting solo stakers, and other community-led initiatives that benefit from identifying solo validators.
## **How to Get Involved**
* **Star & Fork** the [repository](https://github.com/eth-educators/solo-stakers) to show your support and keep track of updates.
* **Open Issues or Pull Requests** with questions or improvements.
* **Join EthStaker's Channels** (e.g., [Reddit](https://www.reddit.com/r/ethstaker), [Discord](https://dsc.gg/ethstaker)) to participate in discussions, share feedback, and stay informed about the latest development.
By entrusting management to EthStaker, we hope to further democratize access, stewardship, and innovation in Ethereum staking. We appreciate the continued support from the entire staking community and look forward to seeing how EthStaker evolves this initiative.
We're excited to announce the launch of Celestia on the Rated API!
Starting today, you can access and query rewards data for validators on the Celestia, both at an individual level and network level over a specified time period:
`GET /v1/celestia/validators/{node_id}/rewards`
* Provides a detailed summary of all rewards earned by a specific validator, identified by their validator\_address
**Sample Request**
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/celestia/{validator_address}/rewards?fromDate=2025-01-01&toDate=2025-01-05'
-H 'accept: application/json'
-H 'Authorization: Bearer <api_token>'
```
**Sample Response** (trimmed for brevity)
```json theme={null}
{
"previous":null,
"next":null,
"pages":1,
"results":[
{
"day":"2025-01-05",
"validator":"{validator_address}",
"validatorMoniker":"{validator_name}",
"consensusAddress":"celestiavalcons1uh9wyuh",
"consensusPubkey":"vrSsYrWno/rLAE0aGsqO/XkrE=",
"accountAddress":"celestia1xqc7wkg4tswjt7mn4p38v",
"fromBlockNumber":3330254,
"toBlockNumber":3346421,
"totalDelegationRewards":3458.99139127356,
"totalCommissionRewards":345.899139127356,
"commissionRate":0.1
},
...
{
"day":"2025-01-01",
"validator":"{validator_address}",
"validatorMoniker":"{validator_name}",
"consensusAddress":"celestiavalcons1uh9wyuh",
"consensusPubkey":"vrSsYrWno/rLAE0aGsqO/XkrE=",
"accountAddress":"celestia1xqc7wkg4tswjt7mn4p38v",
"fromBlockNumber":3314016,
"toBlockNumber":3330253,
"totalDelegationRewards":3731.780361524,
"totalCommissionRewards":373.17802385361523,
"commissionRate":0.1
}
]
}
```
`GET /v1/celestia/network/rewards`
* Provides historical network level validator rewards for Celestia
**Sample Request**
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/celestia/network/rewards?fromDate=2025-01-01&toDate=2025-01-02'
-H 'accept: application/json'
-H 'Authorization: Bearer <api_token>'
```
**Sample Response**
```json theme={null}
{
"previous":null,
"next":null,
"pages":1,
"results":[
{
"day":"2025-01-02",
"fromBlockNumber":3330254,
"toBlockNumber":3346421,
"totalBondedValidators":100,
"totalDelegationRewards":208637.819,
"totalCommissionRewards":26793.123,
"avgCommissionRate":0.0932
},
{
"day":"2025-01-01",
"fromBlockNumber":3314016,
"toBlockNumber":3330253,
"totalBondedValidators":100,
"totalDelegationRewards":208605.944,
"totalCommissionRewards":26792.561,
"avgCommissionRate":0.0932
}
]
}
```
**Learn more**
We encourage you to check out our [API documentation](/rated-api/api-reference/v1/celestia/rewards) to learn more about rewards behavior on Celestia. You can also find a [glossary for the different fields](/rated-api/glossary/celestia) in the responses returned by these endpoints. Lastly, we have historical rewards data going back to December 1, 2024, and are currently working to extend this further back into October 1, 2024.
**Beta Release and Pricing**
During the beta period, access to these new endpoints will be free. Compute unit based pricing will be introduced post-beta.
**More to come**
This is part of Rated's ongoing effort to expand its coverage to more chains and networks. Stay tuned for more!
If you have any questions or feedback, especially on which networks we should cover, feel free to reach out to us at [feedback.rated.network](https://feedback.rated.network) or at [hello@rated.network](mailto:hello@rated.network).
We're excited to announce the launch of Avalanche on the Rated API!
Starting today, you can access and query rewards data for validators on the Avalanche [Primary Network](https://build.avax.network/docs/quick-start/primary-network), both at an individual level and network level over a specified time period:
`GET /v1/avalanche/validators/{node_id}/rewards`
* Provides a detailed summary of all rewards earned by a specific validator, identified by their node\_id
**Sample Request**
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/avalanche/validators/{node_id}/rewards?fromDate=2024-12-01&toDate=2024-12-05'
-H 'accept: application/json'
-H 'Authorization: Bearer <api_token>'
```
**Sample Response** (trimmed for brevity)
```json theme={null}
{
"previous":null,
"next":null,
"pages":1,
"results":[
{
"day":"2024-12-05",
"nodeId":"{node_id}",
"validationStatus":"inactive",
"validatorPubkey": "0x8f8df4745a1329a6318634e60332df71ecc4a9430d",
"totalDelegatorRewards":1.55,
"totalValidatorRewards":290.90,
"totalValidatorFeeRewards":0.08,
"totalPotentialDelegatorRewards":0,
"totalPotentialValidatorRewards":0,
"totalPotentialValidatorFeeRewards":0
},
<...>
{
"day":"2024-12-01",
"nodeId":"{node_id}",
"validationStatus":"active",
"validatorPubkey": "0x8f8df4745a1329a6318634e60332df71ecc4a9430d",
"totalDelegatorRewards":0,
"totalValidatorRewards":0,
"totalValidatorFeeRewards":0,
"totalPotentialDelegatorRewards":2516.64,
"totalPotentialValidatorRewards":7904.87,
"totalPotentialValidatorFeeRewards":51.50
}
]
}
```
`GET /v1/avalanche/network/rewards`
* Provides historical network level validator rewards for the Primary Network
**Sample Request**
```curl theme={null}
curl -X 'GET' 'https://api.rated.network/v1/avalanche/network/rewards?fromDate=2025-01-26&toDate=2025-01-27'
-H 'accept: application/json'
-H 'Authorization: Bearer <api_token>'
```
**Sample Response**
```json theme={null}
{
"previous":null,
"next":null,
"pages":1,
"results":[
{
"day":"2025-01-27",
"totalActiveValidators":1518,
"totalValidatorRewards":6920.434755523,
"totalValidatorFeeRewards":2.489666824,
"totalDelegatorRewards":1717.71544618,
"totalPotentialValidatorRewards":7156084.009812852,
"totalPotentialValidatorFeeRewards":37273.058757847,
"totalPotentialDelegatorRewards":494018.077133481
},
{
"day":"2025-01-26",
"totalActiveValidators":1505,
"totalValidatorRewards":1488.872838484,
"totalValidatorFeeRewards":3.09354756,
"totalDelegatorRewards":2440.470582821,
"totalPotentialValidatorRewards":7152926.77444416,
"totalPotentialValidatorFeeRewards":37281.047946395,
"totalPotentialDelegatorRewards":494245.251667358
}
]
}
```
**Learn more**
As with all networks, there are nuances to how rewards behave on Avalanche. We encourage you to check out our [API documentation](/rated-api/api-reference/v1/avalanche/rewards) to learn more, which also contains a [glossary for the different fields](/rated-api/glossary/avalanche) in the responses returned by these endpoints. Lastly, we have historical rewards data going back to October 1, 2024.
**Beta Release and Pricing**
During the beta period, access to these new endpoints will be free (no compute unit consumption). Compute Unit (CU)-based pricing will be introduced post-beta.
**More to come**
This is part of Rated's ongoing effort to expand its coverage to more chains and networks. Stay tuned!
If you have any questions or feedback, feel free to reach out to us at [feedback.rated.network](http://feedback.rated.network) or at [hello@rated.network](mailto:hello@rated.network).
The [issue](#january-17-2025) we mentioned last week with the `ethPrice` and `usdPrice` being returned by our [Eigenlayer rewards](/rated-api/api-reference/v1/eigenlayer/rewards) endpoints has been fixed. Specifically these endpoints are:
* `/v1/eigenlayer/entities/{operator_address}/rewards/`
* `/v1/eigenlayer/delegators/{delegator_address}/rewards/`
* `/v1/eigenlayer/eigenpods/{eigenpod_address}/rewards`
We have also applied the correct historical conversion rates to past rewards. This means that both historical rewards and rewards moving forward will have the correct ETH and USD pricing as long as the particular set of rewards are claimable (`activatedAt`) and the related token has the appropriate liquidity.
Rest assured that we have taken steps to ensure that instances like this are minimized moving forward.
If you have any questions or feedback, feel free to go to [feedback.rated.network](http://feedback.rated.network).
For more information on our API endpoints, please see our [documentation](/rated-api/api-reference/).
Compute units (CUs) consumed for API calls are now available in the response header. This has been requested by our customers in order to have more visibility on consumption, and we are glad to have finally enabled this feature.
Below is an example using one of our rewards endpoints.
**Request**
```curl theme={null}
curl -v -X 'GET' 'https://api.rated.network/v1/eigenlayer/delegators/{delegator_address}/rewards?fromDate=2025-01-15&toDate=2025-01-16'
-H 'accept: application/json'
-H 'X-Rated-Network: mainnet'
-H 'Authorization: Bearer <api_key>
```
**Response header**
```sh theme={null}
using HTTP/1.x
GET (…)
Request completely sent off
< HTTP/1.1 200 OK
(...)
< x-rated-bytes-consumed: 2069
< x-rated-compute-units: 6869
(...)
Connection #0 to host api.rated.network left intact
```
is the field the that gives the total compute units consumed by the request and the successful response. In this case, the CUs consumed is `6869`.
Stay tuned for more releases regarding billing and usage transparency.
For more information on our pricing and the computation of compute units, please [see here](/pricing/compute-units).
We are aware of an issue with the `ethPrice` and `usdPrice` being returned by our [Eigenlayer rewards](/rated-api/api-reference/v1/eigenlayer/rewards) endpoints below:
* `/v1/eigenlayer/entities/operator_address/rewards/`
* `/v1/eigenlayer/delegators/delegator_address/rewards/`
* `/v1/eigenlayer/eigenpods/eigenpod_address/rewards/`
The prices being returned are wrong and we are working on a fix to address this. For now, please only use the `amount` field to measure the rewards for the corresponding token information being given in the response.
We apologize for any inconvenience this may have caused and will immediately keep you all updated as we address this issue in the coming week (week of January 20, 2025).
We have made changes to what was then the `v1/eigenlayer/rewardsApiMetadata` endpoint. Previously, this returned metadata specific to the latest complete rewards data available from our Eigenlayer rewards APIs. With the release of our [new daily stake state endpoints](https://feedback.rated.network/changelog/eigenlayer-daily-stake-state-endpoints-and-expanded-rewards-aggregation), we have now turned this endpoint into a more generalized one. Two main changes below.
***New name:*** `v1/eigenlayer/apiMetadata`
***Old name:*** `v1/eigenlayer/rewardsApiMetadata`
## New response schema:
```json theme={null}
{
"rewardsLastFullDay": "2024-12-16",
"rewardsLastSnapshotTimestamp": 1734393600000,
"rewardsDistributionRootIndex": 21,
"stateLastFullDay": "2024-12-30"
}
```
There are now fields specific to the latest data freshness of the [rewards](/rated-api/api-reference/v1/eigenlayer/rewards) API endpoints and the [state](/rated-api/api-reference/v1/eigenlayer/rewards) endpoints.
For more information, see our docs here: [Eigenlayer API Metadata](/rated-api/api-reference/v1/eigenlayer/metadata#api-metadata)
We've released three new endpoints regarding daily restaked balances in Eigenlayer. These are:
* `v1/eigenlayer/eigenpods/eigenpod_address/state`
* `v1/eigenlayer/entities/operator_address/state`
* `v1/eigenlayer/delegators/delegator_address/state`
These endpoints allow you to track restaked balances across operators, delegators, and eigenpods on a daily level.
Sample response:
```json theme={null}
{
"date": "2024-10-01",
"earner": "0xB0bd0c91798d720a5585364bb4be7396c5b9731",
"strategy": "0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc",
"tokenAddress": "0xBe9895146f7AF43049ca1c1AE358B0541Ea49704",
"totalShares": 12000000000000000000,
"totalBalance": 12000000000000000000
}
```
Coupled with our Eigenlayer rewards endpoints, you'll be able to track rates of return per operator and asset, and manage strategies accordingly.
Speaking of our rewards endpoints, the functionality of these existing endpoints have been extended to enable time-based aggregations using the granularity parameter, specifically weekly aggregations. As such we're also changing the compute unit consumption of this endpoint to reflect this change; 7x increase to account for the capability to aggregate weekly (from daily).
For more information on these endpoints, please see here:
* Stake state endpoints: [Eigenlayer API Metadata](/rated-api/api-reference/v1/eigenlayer/metadata#stake-state)
* Expanded rewards endpoints: [Eigenlayer Rewards](/rated-api/api-reference/v1/eigenlayer/rewards)
We've completed the migration of all Solana API endpoints to the v1 standard, introducing improvements and consistency across our infrastructure:
## Key Updates
* Standardized endpoint naming aligned with v1 schema
* Enhanced performance via optimized v1 routing
## API Reference 👉
[Solana API Reference](/rated-api/api-reference/v1/solana)
Legacy endpoints will remain operational until we deprecate the v0 endpoints in Q1 2025.
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network). If you have feedback, please let us know via [feedback.rated.network](https://feedback.rated.network)!
With the implementation of Timely Vote Credits (TVC) on Solana mainnet-beta starting from Epoch 703 (November 26, 2024 07:57:15 UTC), vote latency is now integrated into how we measure how effective a validator is on Solana.
Vote latency is the slot distance between the slot being voted for and the slot where the vote transaction lands. With the implementation of TVC, the protocol now rewards validators based on latency accordingly.
A validator that correctly votes within two (2) slots for the slot it is voting for will get the maximum 16 vote credits. For every slot that a validator delays its vote, it gets one (1) less vote credit, until such that it can only get the minimum of one (1). This means that at 18 slots of worth of latency or more, as long as a validator's vote is correct and is no later than 512 slots, it gets the minimum vote credit.
As such we assign a vote\_score for every correct vote based on the vote credits it receives. We then multiply the total number of confirmed blocks by 16 to get the maximum possible vote credits such that the voting effectiveness rating is:
```
voting effectiveness = vote_score / (total number of confirmed blocks * 16)
```
We have reflected this change in our methodology docs, [under Version 2.0 of the Solana Validator Effectiveness Rating](/documentation/methodologies/solana/solana-validator-effectiveness-rating/version-2.0-current).
You can now retrieve performance and rewards data for Ethereum based on UTC time intervals through our v1 endpoints!
### How to Use It
Simply add `utc=true` to your existing API queries. That's it!
**Note:** UTC data is available for dates from October 1, 2024 onwards
Here's an example of how this would work 👇 When querying Coinbase's effectiveness from Nov 1-7 2024, you'll receive data in daily UTC intervals.
![]()
## Day alignment
Since Ethereum epochs don't align perfectly with UTC midnight (they start at \~23:57 and end at \~00:03), we group epochs that start within a UTC day together. You can learn more about this [here](/rated-api/api-reference/v1/).
Ready to try it out? Check out the API docs here 👉 [API Reference](/rated-api/api-reference/v1/ethereum/performance)
If you have any questions or need support, don't hesitate to reach out to our team at [hello@rated.network](mailto:hello@rated.network). If you have feedback, please let us know via [feedback.rated.network](https://feedback.rated.network)!
We're excited to announce the Beta launch of EigenLayer on the Rated API! Starting today, you can access and query:
* [Rewards](/rated-api/api-reference/v1/eigenlayer/rewards) data for EigenLayer operators and eigenpods, giving you a breakdown of all rewards earned by an operator and eigenpods over a specified time period across all networks that they are involved in.
> `GET /v1/eigenlayer/eigenpods/address/rewards`
* Provides a detailed summary of all rewards earned by a specific Eigenpod across all networks over a specified time period
* `GET /v1/eigenlayer/entities/entity_id/rewards`
> Provides the rewards earned by an entity (operator) across all networks over a specified time period
* [Metadata](/rated-api/api-reference/v1/eigenlayer/metadata) related to EigenLayer operators and delegators, such as the delegation history by delegator or operator address.
> `GET /v1/eigenlayer/delegators/address/delegations`
* Data includes delegation details like the delegator's address, Eigenpod address, operator, and time range for the delegation
* `GET /v1/eigenlayer/operators/operator_id/delegations`
> Returns operator delegation data, detailing delegator addresses, Eigenpod addresses, and the time periods for which the operator had delegated stake
* Data is stored in daily snapshots
API reference for these endpoints can be found 👉 [here](/rated-api/api-reference/v1/eigenlayer)
**Beta Release and Pricing**
During the beta period, access to these new endpoints will be free (no CU consumption). CU-based pricing will be introduced post-beta.
If you have any questions or feedback, feel free to reach out to us at [hello@rated.network](mailto:hello@rated.network).
* SyncSignatureCount added to entities endpoint
> The `syncSignatureCount` field has been added to the `/v1/eth/entities/\{entity_id\}/attestations` endpoint, providing a more complete view of validator performance in the sync committee. This field was previously only available in the `/v1/eth/validators/\{validator_index_or_pubkey\}/attestations` endpoint
* Impacted endpoints: v1 entities endpoints
* Fix for from parameter in ChainDailyRewards endpoint
> Resolved a 500 error occurring when using the `from` parameter in the `chainDailyRewards` endpoint, caused by a datatype mismatch (int vs. string)
* Additionally, functionality has been added to support using UTC days in the from parameter for greater flexibility
* Impacted endpoints: v0/eth/network/chainDailyRewards
* New Ethereum chain days endpoint
> Added a new `chainDailyRewards` endpoint based on Ethereum chain days, in addition to the existing `dailyRewards` endpoint which is based on UTC days
* Impacted endpoints: `v0/eth/network/chainDailyRewards` and `v0/eth/network/chainDailyRewards/{day}`
* Additional validator balance field in Rewards endpoint
> The `v0/eth/network/chainDailyRewards` endpoint now includes the latest total effective balance of validators, providing more insight into validator performance
* Slot and timestamp fields added to Rewards endpoints
> Introduced `startSlot`, `endSlot`, `startTimestamp`, and `endTimestamp` fields to rewards endpoint
* The changes impact validator, entities, and network endpoints for enhanced data consistency across different API responses
* Data type update for execution rewards on Rewards endpoints
> Modified the data type for execution reward columns (e.g., `sum_priority_fees_wei` and `sum_baseline_mev_wei`) from `StrictInt` to `Decimal` to improve accuracy.
* Impacted endpoints: v1 rewards endpoints for validators
**Effective Date:** September 06, 2024
We are officially deprecating support for the Polygon network on both the Rated Explorer and the Rated API. Due to a lack of widespread adoption and the high cost of maintenance, we've made the decision to discontinue support.
* Impact: Users will no longer be able to access Polygon-related data or functionality in the Rated Explorer and Rated API after the deprecation date.
If you're impacted and need assistance, please reach out to us at [hello@rated.network](mailto:hello@rated.network) !
We are discontinuing support for hourly updates on the validator endpoints and the predicted withdrawals feature due to low adoption rate and increased maintenance costs.
This change is effective as of July 24,2024.
**Impacted Endpoints** Validator Endpoints
`/v1/eth/validators/{validator_index_or_pubkey}/effectiveness`
`/v1/eth/validators/{validator_index_or_pubkey}/attestations`
`/v1/eth/validators/{validator_index_or_pubkey}/proposals`
`/v0/eth/validators/{validator_index_or_pubkey}/effectiveness`
Predicted Withdrawal Endpoints
`/v0/eth/withdrawals/predicted/operators/{operator_id}`
`/v0/eth/withdrawals/predicted/operators/{operator_id}`
**Key Resources** - [API Reference](/rated-api/api-reference/v0/ethereum/blocks)
For support inquiries, please contact us at [hello@rated.network](mailto:hello@rated.network). If you have feedback, we would love to hear from you at [feedback.rated.network](https://feedback.rated.network)!
We have enhanced our Ethereum blocks endpoints to support real-time data retrieval. Users can now access data that is up to 2 epochs behind the current head of the chain at any time.
**Impacted Endpoints**
> `/v0/eth/blocks`
`/v0/eth/blocks/{consensus_slot}`
**Key Resources** - [API Reference](/rated-api/api-reference/v0/ethereum/blocks-)
* [Glossary](/rated-api/glossary/ethereum/blocks)
For support inquiries, please contact us at [hello@rated.network](mailto:hello@rated.network). If you have feedback, we would love to hear from you at [feedback.rated.network](https://feedback.rated.network)!
We are excited to announce the support of Solana on the Rated API, Explorer, and documentation hub. This update allows developers to access curated Solana data, develop reporting applications, create custom dashboards, and integrate a real-time, outside-in view into their monitoring stack.
* Validators: Monitor performance, benchmark against peers, and gain an external view on their infrastructure. View all [validator endpoints](/rated-api/api-reference/v0/solana/validators) and [validator views](https://explorer.rated.network/?network=solana\&view=validator\&timeWindow=1d\&page=1\&pageSize=15) on Explorer.
* Delegators: Make informed delegation decisions, review performance, manage rewards, and view commission rates. View all [delegator endpoints](/rated-api/api-reference/v0/solana/delegators) and [delegator views](https://explorer.rated.network/stake-accounts?network=solana\&timeWindow=1d\&page=1\&pageSize=15) on Explorer.
* Pools & Active Set Managers: Evaluate validator performance for onboarding, SLAs, and off-boarding. View [pool view](https://explorer.rated.network/pools?network=solana\&timeWindow=1d\&page=1\&pageSize=15) on Explorer.
* Network Researchers: Monitor network health and gain insights for research and development. View all [network endpoints](/rated-api/api-reference/v0/solana/network) and [network views](https://explorer.rated.network/network?network=solana\&timeWindow=1d) on Explorer.
Check out [Solana on the Explorer](https://explorer.rated.network/network?network=solana\&timeWindow=1d) and [view our docs](/documentation/explorer/solana) to help navigate through the different views.
Get started with the Rated API for Solana at [rated.network/apis](https://rated.network) and explore our comprehensive [API documentation hub](/rated-api/api-reference/v0/solana) for detailed guidance.
If you have any questions or need support, don't hesitate to reach out to our team at [hello@rated.network](mailto:hello@rated.network). If you have feedback, please let us know via [feedback.rated.network](https://feedback.rated.network)!
[Rated API v1](/rated-api/api-reference/v1-beta) is now available in public beta! After iterating on months of valuable feedback from our users, we have upgraded from v0 to bring you a more intuitive API design.
API v1 comes on Ethereum first. In the coming weeks, we'll enhance the Ethereum suite to match the full capabilities of v0 on v1. We'll also be working on bringing Polygon & upcoming network APIs to v1.
## Enhanced User Experience
We've redesigned our API from the ground up, focusing on simplicity and usability. No more heavy endpoints that are difficult to parse. The new endpoints are categorized as:
* [Performance APIs](/rated-api/api-reference/v1/ethereum/performance): Accurately track, improve and benchmark your current and historical validator fleet performance.
* [Rewards APIs](/rated-api/api-reference/v1/ethereum/rewards): Deploy precise accounting in a few simple calls, with granular tracking of validator rewards earned.
* [Metadata APIs](/rated-api/api-reference/v1/ethereum/metadata): Help users make informed decisions around staking with access to rich metadata about an entity's useful life.
## Improved Pagination
Navigating through data is now more efficient. We've upgraded to a limit-based pagination and introduced sorting to ensure that you can access large datasets quicker and with less hassle.
## Performance Enhancements
Smaller payloads means faster response times and reduced latency so that your applications can operate more efficiently and reliably.
## Important Links
* [API Reference](/rated-api/api-reference/v1)
* [Swagger docs](https://api.rated.network/docs#/)
* [How pagination works](/rated-api/pagination/v1)
**Disclaimer**
As we step into the public beta phase, anticipate encountering bugs and areas in need of UX refinement. This period is crucial for us to enhance feature stability, integrate user feedback, and ensure a seamless experience moving forward. Your understanding and contributions are invaluable!
We will also be gradually releasing guides and documentation on v1 as we complete the full rollout in Q2 2024. Rest assured that we will be maintaining both v0 and v1, until we sunset v0 in early Q3 2024.
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network). If you have feedback, please let us know via [feedback.rated.network](https://feedback.rated.network)!
Organizations within the Build and Growth tiers can now create and utilize private pre-materialized sets. This feature enables the creation of custom sets of validators, each marked with a unique tag for private use. It is aimed at enhancing capabilities in performance benchmarking, rewards accounting, and validator set management.
### Quickstart
* Tags: Validators within a set are tagged with identifiers unique to your organization, allowing for private viewing of performance and rewards metrics. This facilitates efficient analysis, A/B testing of node setups, and confidential grouping of validators for specific customers.
* Easy API Integration:
> To create a tag, initiate a POST request to [/v1/eth/tags](/rated-api/api-reference/v1/ethereum/private-sets#tags-1) with your desired validators
* Retrieve performance and reward metrics via GET requests to [/v1/eth/sets/:id/effectiveness](/rated-api/api-reference/v1/ethereum/performance#eth-sets-set_id-effectiveness) or [/v1/eth/sets/:id/rewards](/rated-api/api-reference/v1/ethereum/rewards#eth-sets-set_id-rewards)
### Limits
* Build tier users can create up to 4 tags
* Growth tier users can create up to 20 tags
### Important links 👇
* [API Reference](/rated-api/api-reference/v1/ethereum/private-sets)
* [How-To Guide](/rated-api/guides/use-cases/private-sets)
* [Compute Units](/pricing/compute-units)
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network). As we have launched this in beta, your feedback is crucial. Let us know at [feedback.rated.network](https://feedback.rated.network)!
A new page, [**Native Restaking**](https://explorer.rated.network/restaking?network=mainnet\&timeWindow=7d), on the Rated Explorer is now available, dedicated to detailed restaking stats. This enhancement provides users with access to comprehensive metrics surrounding the Ethereum native restaking ecosystem. Key metrics featured include:
* Total amount of ETH natively restaked
* Percentage of the validator fleet natively restaked at the operator level and their market share
* RAVER of validators at an operator level engaged in native restaking
To further aid in the visibility and understanding of native restaking participation, a restaking icon has been introduced in the operators list view. This icon serves as a quick visual indicator of which operators are actively participating in native restaking.
As the restaking ecosystem continues to evolve and mature, we are committed to regularly updating and enriching this data.
Restaking dashboard 👉 [explorer.rated.network/restaking](https://explorer.rated.network/restaking)
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network). If you have feedback, please let us know via [feedback.rated.network](https://feedback.rated.network)!
We've addressed an issue affecting the blocks endpoint, which resulted in the overstated reporting of execution layer rewards for a subset of blocks proposed via mev-boost.
This discrepancy was identified in cases where proposers were partially compensated by builders through internal transactions, with failed payments not being excluded from the calculations.
To rectify this, we've implemented a filter to exclude these failed transaction traces, and performed a comprehensive refresh of the blocks endpoint data. The columns updated include **baseline\_mev**, **execution\_rewards**, **missed\_execution\_rewards**, **total\_rewards**, and **total\_rewards\_missed**.
Impacted endpoints 👇
* `/v0/eth/blocks`
* `/v0/eth/blocks/{consensus_slot}`
This fix was applied retroactively (on 13th March 2024 at 8:43PM UTC) and impacts less than 0.5% of all blocks since the merge.
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network). If you have feedback, please let us know via [feedback.rated.network](https://feedback.rated.network)!
In preparation for the Dencun Upgrade on Ethereum slated for 13th March, we are introducing the following changes to the API:
* We're tracking the count of type 3 transactions (0x03; blob transactions) and the corresponding fees related to these transactions in the blocks endpoint. Impacted endpoints:
> `/v0/eth/blocks`
> `/v0/eth/blocks/{consensus_slot}`
* Accordingly, the validator rewards from these transactions are tracked in all our rewards endpoints which ensures we are accounting for all rewards that validators receive. Impacted endpoints:
> `/v0/eth/validators/{validator_index_or_pubkey}/effectiveness`
> `/v0/eth/validators/effectiveness`
> `/v0/eth/validators/{validator_index_or_pubkey}/apr`
> `/v0/eth/operators/{operator_id}/effectiveness`
> `/v0/eth/operators/{operator_id}/apr`
> `/v0/eth/network/overview`
Important links 👇
* API Reference: [/rated-api/api-reference](/rated-api/api-reference)
* Glossary: [/rated-api/glossary/ethereum/blocks](/rated-api/glossary/ethereum/blocks)
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network). If you have feedback, please let us know via [feedback.rated.network](https://feedback.rated.network)!
We've revamped the Rated Explorer, enhancing design and functionality for a better user experience. Key updates include a cleaner interface for efficient data access, intuitive navigation across networks, and improved sorting. The search feature is also upgraded for easier discovery of pool operators, addresses, or indices.
The explorer also got its own dedicated namespace in👉 [explorer.rated.network](http://explorer.rated.network)
Following the launch, navigating to [rated.network](http://rated.network) will direct users to Rated's homepage. Access to all explorer pages will require visiting [explorer.rated.network](http://explorer.rated.network) (bookmark for ease of access!).
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network). If you have feedback, please let us know via [feedback.rated.network](https://feedback.rated.network)!
We've launched a Python SDK for the Rated APIs to make integrating with our data easier and faster. The SDK support comes on Ethereum first with plans to add other networks in the coming weeks.
Important links 👇
* Rated API Python SDK documentation: [https://github.com/rated-network/rated-python](https://github.com/rated-network/rated-python)
* PyPI library: [https://pypi.org/project/rated-python/](https://pypi.org/project/rated-python/)
The Rated API Python SDK comes with examples for straightforward tasks, including retrieving operator summaries, APR, effectiveness, and network statistics.
We will be adding more complex scenarios such as performance benchmarking, rewards accounting, incident troubleshooting amongst others soon™.
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network). If you have feedback, please let us know via [feedback.rated.network](https://feedback.rated.network)!
We've adjusted the Compute Unit (CU) formula to better reflect the processing demands on Rated for generating the data.
### What's changed?
Initially, a constant weight of 32 was applied as a denominator to the content length, resulting in the formula:
```
Compute Units = (Content Length Bytes/32) + (Item Count x Business Value)
```
We've modified this approach to incorporate variable weights, which better account for the processing costs associated with producing this data. The new formula is:
```
Compute Units = (Content Length Bytes/Weight) + (Item Count x Business Value)
```
### Downstream impact on a per endpoint basis
This update changes the overall CU requirement to query certain endpoints that the Rated API supports, and are effective as of today. The updated weights, on a per endpoint basis, are available [here](/pricing/compute-units).
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network).
We have updated our list of solo-staker associated addresses to include another \~1.1k deposit addresses we identified, after collating all the feedback we received following the STRK airdrop announcement.
You can find the updated list in this repo: [https://github.com/rated-network/solo-stakers](https://github.com/rated-network/solo-stakers)
We have updated the heuristics that underlie the model, and done a lot of manual validation work drawing from various datasets available to us (e.g. EL activity patterns, gossip messages). The additional \~1.1k addresses represent an additional 15% to all the addresses that we had previously tagged as "high confidence solo-stakers".
The updated list still respects the original definition of a solo-staker as outlined in [this blog post](https://blog.rated.network/blog/solo-stakers).
This implies that addresses associated with validators that run on whitelabel providers are still not included. The same stands for validators that have been reported to us by Node Operator entities via the [Self Report API](/rated-api/api-reference/ethereum/self-report). Finally, the list **does not** include "whales" that appear to run a very large number of validators in professional-looking setups, but with no clear association to any of the known to us operators, whether that be implicit or explicit.
Finally the list still considers validators up to index 500,000 and no further.
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network).
We are excited to announce updates to the Rated API pricing and the introduction of a new tier to better serve our diverse user base. These changes are designed to provide more flexibility to different users' needs and usage patterns.
* Free Tier Update:
> Previous Allowance: 100,000 compute units per month.
* New Policy: 100,000 compute units lifetime allowance.
* Introduction of Starter Tier:
> Allowance: 100,000 base compute units per month.
* Rate Limit: 2 requests per second, with no limit on the number of requests.
* Sunsetting of Pro Tier:
> In response to user feedback, the Pro Tier will be discontinued. Users have expressed a preference for the Enterprise Tier, which offers greater flexibility and is better suited to their needs.
The [Terms of Service](https://legal.rated.network/terms/api-terms-of-service) have been updated to reflect these changes. These updates took effect on February 13, 2024. Users are encouraged to review the new terms.
You can view the plans in detail by visiting the [console](https://console.rated.network/settings/plans) or [docs](/pricing/plans).
If you'd like support or have questions, please reach out via [hello@rated.network](mailto:hello@rated.network).
We are updating how we compute and display "performance metrics" on the Rated Explorer, namely (i) Source Vote Accuracy, (ii) Target Vote Accuracy and (iii) Head Vote Accuracy on Ethereum, to more closely reflect user interpretations of these terms.
**Please note:** the change is purely illustrative and does not affect the RAVER calculation and methodology.
Specifically, we are shifting the basis of each metric from the number of submitted attestations to the total number of attestation duties.
**Previously:**
```
- Source Vote Accuracy = sum of correct source votes/total attestations submitted
- Target Vote Accuracy = sum of correct target votes/total attestations submitted
- Head Vote Accuracy = sum of correct head votes/total attestations submitted
```
**Moving forward:**
```
- Source Vote Accuracy = sum of correct source votes/total attestations duties
- Target Vote Accuracy = sum of correct target votes/total attestations duties
- Head Vote Accuracy = sum of correct head votes/total attestations duties
```
These updates were applied retroactively (on 6th Feb 2024 at 1200 UTC) to all time window (1d, 7d, 30d and All time) views across validators, operators and pools pages for Ethereum mainnet and holesky.
If you'd like to reach out to us for support, please reach out via [hello@rated.network](mailto:hello@rated.network).
In line with the ongoing phase-out of the Goerli network on Ethereum, we're updating our services at Rated.
Starting today, our products (API, Explorer, and Oracle) have ceased support for Goerli. Certain API customers will be able to access Goerli this week but we highly recommend switching to Holesky for your testing needs.
To learn more about how to use the APIs, please visit our [docs](/rated-api/getting-started/welcome).
If you'd like to reach out to us for support, please reach out via [hello@rated.network](mailto:hello@rated.network).
We've updated our methodology for tracking mev-boost rewards between builders and proposers on Ethereum to include additional payment patterns. Previously, we only recognized payments made directly from the builder's address that received transaction fees. Now, we track two new cases:
* Payments from Different Addresses: Builders using different addresses for paying proposers at the end of the block, separate from the address receiving transaction fees.
* Payments via Internal Transactions: Builders paying proposers through an end-of-block transaction to an alternate address, which then sends funds to the proposer via an internal transaction.
These updates were applied retroactively (on 22nd Jan 2024 at 2300 UTC) to our validator rewards database from September 2022, affecting approximately 23,000 blocks, or roughly 0.6% of all blocks since the Ethereum Merge. This change will impact all API endpoints and fields related to Ethereum execution layer rewards, including aggregations and APR values.
You can find details about these changes on our forum [here](https://feedback.rated.network/p/updating-ethereum-el-mev-boost-rewards-attribution-methodology-to-capture).
If you'd like to reach out to us for support, please contact us via [hello@rated.network](mailto:hello@rated.network).
# Frequently asked questions
Source: https://docs.rated.network/documentation/explorer/frequently-asked-questions
It's FAQs all the way down.
## What is the definition of "effectiveness"?
The effectiveness rating (RAVER) is a methodology Rated has proposed for evaluating validator performance in a concise way. The methodology has been through a number of iterations with the community and is widespread by now. For more information on the specifics, please refer to our documentation.
## Why is there a difference between the effectiveness ratings on the Leaderboard page and the Pools, Operators, and Validators pages?
This is because of a difference in data refresh frequency. The effectiveness ratings on the [Leaderboard](/documentation/explorer/ethereum/miscellaneous/leaderboard) page get refreshed on a daily basis while the data on the [Pools, Operators and Validators](/documentation/explorer/ethereum/network-views/pools-operators-and-validators/pools-operators-and-validators) pages get refreshed on an hourly basis.
## I'd like to list an entity to the Rated Network Explorer to track our performance. How does the onboarding process work?
As of Q2 2023, we have a streamlined way for Node Operators and Pools to onboard their sets to the Rated Network Explorer. See [here for Node Operators](/rated-api/api-reference/v0/ethereum/self-report/self-report) and [here for Pools](https://bit.ly/RatedPoolsOnboarding).
## Ethereum
### Is there a minimum number of validators an entity must have in order to build good ratings?
No, we do not require a minimum. The way we track overall effectiveness has more weight on [attestation ](/documentation/methodologies/ethereum/rated-effectiveness-rating/raver-v3.0-current#attester-effectiveness)duties—which validators are called to carry through every single epoch. Therefore, the fact that proposals do not happen all that frequently for a pubkey does not have a pronounced effect on the rating. Read about the effectiveness rating [here](/documentation/methodologies/ethereum/rated-effectiveness-rating/raver-v3.0-current)
### Does the missed rewards calculation compare different MEV relayers?
No, not by default. You can read about the four approaches we take to calculate missed rewards[ here.](/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation/consensus-missed-rewards-computation)
### When Rated shows a metric (e.g. inclusionDelay) for a specific date, what is the exact time frame?
We index 24 hour increments from genesis. So for example if the date is 28/01, the metric will include all epochs from \~12:00 on 27/01 to \~12:00 on the 28/1. The startEpoch and endEpoch can be seen in the API.
## Solana
### How does Rated calculate delegator and validator APYs?
The annual percentage yield (APY) for the returns of delegators and validators on their stake is calculated using a rolling time window calculation of total stake-weighted rewards. For a more detailed look, check out our documentation [Annual Percentage Yield (APY)](/documentation/methodologies/solana/annual-percentage-yield-apy/annual-percentage-yield-apy).
### Why does Rated use annual percentage yield (APY) on Solana but annual percentage rate (APR) for other networks?
The reason is that rewards in Solana are auto-compounded, meaning rewards from staking are added to the delegated stake immediately after they are distributed. The exception to this is the rewards received from MEV extraction through [Jito](https://jito-foundation.gitbook.io/mev/). Nonetheless, a significant majority is compounded hence the use of APY.
### How are slots and blocks counted on Solana?
In a given epoch in Solana, there will always be 432,000 slots and they are numbered accordingly since genesis. However, not all slots will contain blocks as validators chosen to produce blocks (i.e. leaders) can fail to do so at their turn. Despite this, blocks are not counted based on blocks that have been produced. Instead, they always refer to the slot where that block was produced.
**Example:**
> Block 200001 will refer to the block produced at Slot 200001. If there is no block produced on the next Slot (200002) and there is a block produced on the slot after (200003), this next produced block is referred to as Block 200003 as opposed to 200002. This is one of the reasons why it is acceptable to refer to slots and blocks interchangeably.
# Overview
Source: https://docs.rated.network/documentation/explorer/solana/network-views/delegators/delegators
Definitions of variables that appear in the delegator pages on the Rated Explorer for Solana.
A delegator is an entity that participates in securing a proof-of-stake network by staking their cryptocurrency holdings. Instead of actively participating in consensus and the block creation process themselves, delegators choose a validator to delegate their stake to. In exchange, they get a share of the rewards given to validators by the protocol.
### Quick Start
All metrics specific to stake accounts
All aggregated metrics specific to stake authorities
# Stake Account metrics drill-down
Source: https://docs.rated.network/documentation/explorer/solana/network-views/delegators/stake-accounts/stake-account-metrics-drill-down
Definitions of variables that appear in the Stake Account drill-down pages of the Rated Explorer.
**Data freshness**: The views on this page refresh on a daily basis except for metrics related to the amount staked, the status of a stake account, and their validator delegate. These other metrics refresh every epoch which is around 2 days.
## At a glance
*Definitions of the variables that appear on the horizontal bar at the top of the stake account level pages of the Rated Explorer.*
![]()
### Total amount delegated
The total amount of stake delegated by this delegator.
### Network penetration
This is the percentage distribution of stake that maps under a given delegator based on their delegated stake to validators. We calculate this as:
$$
Network\ penetration = \frac{delegated\ stake}{total\ network\ stake}
$$
### Validator
The validator this stake account has delegated to.
### Net Delegator APY%
The return earned by this delegator on their stake after commissions are taken by their delegate validators. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days). For more information, please refer to our documentation [Annual Percentage Yield (APY)](/documentation/methodologies/solana/annual-percentage-yield-apy/annual-percentage-yield-apy).
## Delegation State
*Definitions of the variables that appear in the "Delegation State" section of the stake account view.*
![]()
### Total staking rewards
The total staking rewards (i.e. validator voting rewards) this stake account earned.
### Staking commission paid
The total commission paid by this stake account to its validator delegate
### Validator effectiveness
The effectiveness of the validator to whom this stake account delegated its stake to.
### Commission Rate
These are the commission rates being charged to this stake account based on the validator they have delegated to. On the left is the commission rate for voting/staking rewards and on the right is the commission rate for MEV rewards.
### MEV rewards
The MEV rewards received by this stake account.
## Daily Rewards View
![]()
This is a bar chart showing the rewards received by a stake account over the last few days, depending on the time period selected.
## Stake Account Info
![]()
This contains the following addresses related to the stake account:
**Address:** The address of the stake account itself.
**Stake Authority:** The address that controls the staking actions of a stake account.
**Withdraw Authority:** The address that is authorized to withdraw the funds from the stake account. This address can also change the stake authority address.
# Stake Accounts
Source: https://docs.rated.network/documentation/explorer/solana/network-views/delegators/stake-accounts/stake-accounts
Definitions of variables that appear in the Stake Accounts page on the Rated Explorer for Solana.
**Data freshness**: The views on this page refresh on a daily basis except for metrics related to the amount staked, the status of a stake account, and their validator delegate. These other metrics refresh every epoch which is around 2 days.
In Solana, a stake account is the account that holds the staked tokens when they are delegated to a validator. Each stake account can only delegate to a single validator at any given time.
![]()
## Counters
There are four counters at the top of the view that show a general view of the delegated stake in the network at the moment.
**Total Stake**: Total amount staked in the network
**Stake Accounts**: The number of active (i.e. delegated) stake accounts
**Stake Accounts Deactivating**: The number of deactivating (i.e. undelegating) stake accounts
**Average Delegator APY**: the aggregate annual percentage yield (APY) for delegators in the network
![]()
## Network Penetration
This is the percentage distribution of stake that maps under any given delegator based on their delegated stake to validators. We calculate this as:
$$
Network\ penetration = \frac{delegated\ stake}{total\ network\ stake}
$$
## Status
The current status of the stake account based on whether they are active (delegated), activating (in the process of delegating), deactivating (in the process of undelegating), inactive (undelegated).
## Validator Delegate
The name of the validator to which this stake account is delegating to.
## Delegator APY
The annual percentage yield earned by this delegator. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days). For more information, please refer to our documentation [Annual Percentage Yield (APY)](/documentation/methodologies/solana/annual-percentage-yield-apy/annual-percentage-yield-apy).
## Validator Effectiveness
This is the effectiveness rating of the validator to whom this stake account has delegated their stake to.
# Overview
Source: https://docs.rated.network/documentation/explorer/solana/network-views/delegators/stake-authorities/stake-authorities
Definitions of variables that appear in the Stake Authorities page on the Rated Explorer for Solana.
**Data freshness**: The views on this page refresh on a daily basis except for metrics related to the amount staked, the status of the stake accounts under a stake authority, and their validator delegates. These other metrics refresh every epoch which is around 2 days.
A stake authority is the address that controls the actions of a stake account related to staking. These are delegating, undelegating, splitting, and merging. Stake accounts can have the same stake authority address which is why we provide an aggregate view of stake accounts through their stake authorities.
![]()
## Counters
There are four counters at the top of the view that show a general view of the delegated stake in the network at the moment.
**Total Stake**: Total amount staked in the network
**Stake Authority Addresses**: The number of stake authorities that have active stake accounts
**Stake Accounts to Stake Authority Ratio**: The number of stake accounts for every 1 stake authority address
**Average Delegator APY**: the aggregate annual percentage yield (APY) for delegators in the network
![]()
## Network Penetration
This is the percentage distribution of stake that maps under any given delegator based on their delegated stake to validators. We calculate this as:
$$
Network\ penetration = \frac{delegated\ stake}{total\ network\ stake}
$$
## Delegation distribution
This is the percentage distribution of validators to whom a particular stake authority has delegated their stake to through the stake accounts it controls.
## Commission Rate
This is the stake-weighted commission rate being charged to this stake authority based on the validators this stake authority has delegated its stake to. On the left is the commission rate for voting/staking rewards and on the right is the commission rate for MEV rewards.
## Delegator APY
The annual percentage yield earned by this delegator. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days). For more information, please refer to our documentation [Annual Percentage Yield (APY)](/documentation/methodologies/solana/annual-percentage-yield-apy/annual-percentage-yield-apy).
## Blended Effectiveness
This is the effectiveness rating of a stake authority based on the stake-weighted effectiveness of the validators they have delegated to.
# Stake Authority metrics drill-down
Source: https://docs.rated.network/documentation/explorer/solana/network-views/delegators/stake-authorities/stake-authority-metrics-drill-down
Definitions of variables that appear in the Stake Authority drill-down pages of the Rated Explorer.
**Data freshness**: The views on this page refresh on a daily basis except for metrics related to the amount staked, the status of the stake accounts under a stake authority, and their validator delegates. These other metrics refresh every epoch which is around 2 days.
## At a glance
*Definitions of the variables that appear on the horizontal bar at the top of the stake authority level pages of the Rated Explorer.*
![]()
### Total amount delegated
The total amount of stake delegated by this delegator.
### Network penetration
This is the percentage distribution of stake that maps under a given delegator based on their delegated stake to validators. We calculate this as:
$$
Network\ penetration = \frac{delegated\ stake}{total\ network\ stake}
$$
### Validators delegated to
The number of validators this stake authority has delegated to through the stake accounts it controls.
### Net Delegator APY%
The return earned by this delegator on their stake after commissions are taken by their delegate validators. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days). For more information, please refer to our documentation [Annual Percentage Yield (APY)](/documentation/methodologies/solana/annual-percentage-yield-apy/annual-percentage-yield-apy).
## Delegation State
*Definitions of the variables that appear in the "Delegation State" section of the stake authority view.*
![]()
### Total rewards
The total rewards (i.e. validator voting rewards and MEV rewards) this stake authority earned.
### Total commission paid
The total commission paid by this stake authority to its validator delegates. This includes both staking rewards and MEV rewards.
### Aggregate effectiveness
The stake-weighted effectiveness of the validators to whom this stake authority delegated its stake to through the stake accounts it controls.
### Blended commission rate
These are the stake-weighted commission rates being charged to this stake authority based on the validators this stake authority has delegated its stake to. On the left is the commission rate for voting/staking rewards and on the right is the commission rate for MEV rewards.
### Distribution of delegation
This is a bar chart showing the percentage distribution of validators to whom a particular stake authority has delegated their stake to.
## Daily Rewards View
![]()
This is a bar chart showing the rewards received by a stake authority's stake accounts over the last few days, broken down across the type of rewards it has received.
## Delegation Breakdown
![]()
This table gives a view on the performance of the validators a stake authority has delegated their stake to. It is similar to the [Validators View](/documentation/explorer/solana/network-views/validators/validators#validators-view) but specific to the stake authority.
# Network Overview
Source: https://docs.rated.network/documentation/explorer/solana/network-views/network-overview
A series of metrics that attempt to capture the current state of the network at the highest level.
**Data freshness**: The `1d` view refreshes every 3,000 slots (\~25 minutes). The rest of the views refresh on a daily basis.
## Network Health Metrics
### Network Effectiveness
An aggregation of effectiveness ratings of all validators across the network.
### Vote Success Rate
The number of correctly blocks voted on by a validator out of the total canonical blocks in the network.
### Voting Latency
The network’s average slot distance between where vote transactions were included and the slots they were actually voting for.
### Missed Blocks
The number of block production opportunities missed by the network. This is also commonly referred to as “skip rate.”
## Reward Reference Rates
### Network APY
The rate of return that the average validator has earned in the time period toggled before rewards are distributed to delegators. In other words, this considers all the rewards that validators and delegators receive. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
### Delegator APY
This is the annual percentage yield earned by an average delegator, net of commissions. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days). For more information, please refer to our documentation [Annual Percentage Yield (APY)](/documentation/methodologies/solana/annual-percentage-yield-apy/annual-percentage-yield-apy).
### Net Validator APY
The rate of return that the average validator has earned in the time period toggled after rewards are distributed to delegators. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
### Rewards Distribution
This shows the distribution between voting rewards, block production fees (base fees and priority fees), and MEV rewards.
![]()
## State of Network State
### Total Amount Staked
Total amount of SOL staked in the network.
### Active Validators
The number of active validators in the network.
### Active Stake Accounts
The number of stake accounts in the network.
### Gini Coefficient
A measure of inequality across the validators in the network based on stake allocation. Learn more about the methodology that powers this metric via the [Gini coefficient measurement](/documentation/methodologies/solana/gini-coefficient-measurement) page
![]()
## Infrastructure Overview
### Geo Distribution
The global map shows the geographical distribution of stake across the network.
### Host Distribution
This chart shows the distribution of stake across the network based on the validator infrastructure hosting providers.
![]()
### Client Distribution
The distribution of Solana client software implementations being run by validators in the network.
### Client Version
This chart shows the distribution of stake across the network based on the version of the clients being run by validators.
![]()
# Pool metrics drill-down
Source: https://docs.rated.network/documentation/explorer/solana/network-views/pools/pool-metrics-drill-down
Definitions of variables that appear in the Pool drill-down pages of the Rated Explorer.
**Data freshness**: The views on this page refresh on a daily basis.
## At a glance
*Definitions of the variables that appear on the horizontal bar at the top of the pool level pages of the Rated Explorer.*
![]()
### Total amount delegated
The total amount of stake delegated by this stake pool.
### Network penetration
This is the percentage distribution of stake that maps under a given pool based on their delegated stake to validators. We calculate this as:
$$
Network\ penetration = \frac{delegated\ stake}{total\ network\ stake}
$$
### Validators delegated to
The number of validators this pool has delegated to through the stake accounts it controls.
### Net Delegator APY
The return earned by this pool on their stake after commissions are taken by their delegate validators. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days). For more information, please refer to our documentation [Annual Percentage Yield (APY)](/documentation/methodologies/solana/annual-percentage-yield-apy/annual-percentage-yield-apy)
## Delegation State
*Definitions of the variables that appear in the "Delegation State" section of the pool view.*
![]()
### Total rewards
The total rewards (i.e. validator voting rewards and MEV rewards) this pool has earned.
### Total commission paid
The total commission paid by this pool to its validator delegates. This includes both staking rewards and MEV rewards.
### Aggregate effectiveness
The stake-weighted effectiveness of the validators to whom this pool delegated its stake to through the stake accounts it controls.
### Blended commission rate
These are the stake-weighted commission rates being charged to this pool based on the validators this pool has delegated its stake to. On the left is the commission rate for voting/staking rewards and on the right is the commission rate for MEV rewards.
### Distribution of delegation
This is a bar chart showing the percentage distribution of validators to whom a particular pool has delegated their stake to.
## Daily Rewards View
![]()
This is a bar chart showing the rewards received by a pool's stake accounts over the last few days, broken down across the type of rewards it has received.
## Delegation Breakdown
![]()
This table gives a view on the performance of the validators a pool has delegated their stake to. It is similar to the [Validators View](/documentation/explorer/solana/network-views/validators/validators) but specific to the pool.
# Overview
Source: https://docs.rated.network/documentation/explorer/solana/network-views/pools/pools
Definitions of variables that appear in the Pools page on the Rated Explorer for Solana.
**Data freshness**: The views on this page refresh on a daily basis.
On Solana, we have identified staking pools by aggregating [Stake Accounts](/documentation/explorer/solana/network-views/delegators/stake-accounts/stake-accounts) by their [Stake Authorities](/documentation/explorer/solana/network-views/delegators/stake-authorities/stake-authorities) and matching these addresses to pools through different public resources.
![]()
If you are part of an entity that manages a staking pool and would like to self-identify to be part of the pool set on the explorer, head on over to [our forum](https://feedback.rated.network/?b=65a68ac5cbfec0a42d492d9a) or reach out through our [discord](https://bit.ly/ratediscord).
## Counters
There are four counters at the top of the view that show the aggregate performance of the network in the time period selected.
![]()
## Network Penetration
This is the percentage distribution of stake that maps under any given pool based on their delegated stake to validators. We calculate this as:
$$
Network\ penetration = \frac{delegated\ stake}{total\ network\ stake}
$$
## Validators delegated to
The number of validators this pool has delegated to through the stake accounts it controls.
## Commission Rate
This is the stake-weighted commission rate being charged to this pool based on the validators this pool has delegated its stake to. On the left is the commission rate for voting/staking rewards and on the right is the commission rate for MEV rewards.
## Delegator APY
The annual percentage yield earned by this pool. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days). For more information, please refer to our documentation [Annual Percentage Yield (APY)](/documentation/methodologies/solana/annual-percentage-yield-apy)
## Blended Effectiveness
This is the effectiveness rating of a pool based on the stake-weighted effectiveness of the validators they have delegated to.
# Validator metrics drill-down
Source: https://docs.rated.network/documentation/explorer/solana/network-views/validators/validator-metrics-drill-down
Definitions of variables that appear in the Validator drill-down pages of the Rated Explorer.
**Data freshness**: The `1d` view refreshes every 3,000 slots (\~25 minutes). The rest of the views refresh on a daily basis.
Validators are entities responsible for creating new blocks and validating transactions on the blockchain. In Solana, validators can be mapped to various entities such as staking services, infrastructure providers, cryptocurrency exchanges, etc. In fact, given its permissionless nature, anyone can be a validator on Solana, ranging from knowledgeable hobbyists to enterprise teams.
## At a glance
*Definitions of the variables that appear on the horizontal bar at the top of the validator level pages of the Rated Network Explorer.*
![]()
### Total amount staked
The total amount of staked SOL that maps to this validator.
### Network Penetration
This is the percentage distribution of stake that maps under any given validator. We calculate this as:
$$
Network\ penetration = \frac{delegated\ stake}{total\ network\ stake}
$$
### Delegator APY
This is the annual percentage yield earned by delegators staking with this validator, net of commissions. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days). For more information, please refer to our documentation [Annual Percentage Yield (APY)](/documentation/methodologies/solana/annual-percentage-yield-apy/annual-percentage-yield-apy).
### Effectiveness Rating
The Rated model of validator performance for the Solana network. The colour coding in each of these values hints to the relative performance of the entity.
For more information on how this is computed and the methodology behind it, please refer to the [Solana Validator Effectiveness Rating](/documentation/methodologies/solana/solana-validator-effectiveness-rating/solana-validator-effectiveness-rating) page. You can also learn more about how we rank for relative performance via [Rating percentiles](/documentation/methodologies/ethereum/rating-percentiles).
## Effectiveness Breakdown
*Definitions of the variables that appear on the "Effectiveness Breakdown" section of the validator level pages.*
![]()
### Voting Effectiveness
The number of correctly blocks voted on by a validator out of the total canonical blocks in the network, modulated (i.e. divided) by their voting latency.
### Proposer Effectiveness
The number of blocks produced by this validator over the number of times they were selected as a leader (i.e. block proposer) in the network’s block production process.
### Voting Latency
The average slot distance between where a validator’s vote transaction was included and the slot they were actually voting for.
### Effectiveness Rating
The Rated model of validator performance for the Solana network.
For more information on how this is computed and the methodology behind it, please refer to the [Solana Validator Effectiveness Rating](/documentation/methodologies/solana/solana-validator-effectiveness-rating/solana-validator-effectiveness-rating) page.
![]()
## Stake Overview
*Definitions of variables that appear in the "Stake Overview" section of the validator level pages. This does not change with the time window toggles.*
### Total number of delegators
The total number of delegators (stake accounts) that have staked with this particular validator.
### Total amount delegated
The total amount of stake delegated to this validator.
### Average delegated stake
The average delegated stake to this validator based on the number of stake accounts.
### Commission Rate
The commission rate being charged by this validator to delegators. This is further separated into two: the commission rate specific to voting rewards and the one specific to MEV rewards through [Jito](https://jito-foundation.gitbook.io/mev/).
## Aggregate Rewards Statistics
*Definitions of variables that appear in the "Aggregate rewards statistics" section of the validator level pages.*
### Voting Commissions
These are the rewards received by this validator through the commission it charges for voting rewards.
### Block Production Fees
These are the fees received by this validator for producing blocks. This includes both base fees and priority fees by users.
### Total Rewards
The sum of all rewards earned by this validator which consists of voting commissions, block production fees, and if applicable, MEV rewards through [Jito](https://jito-foundation.gitbook.io/mev/).
### Net Validator APY%
This is the annual percentage yield earned by the validator for the rewards that they get. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
## Block Production
*Definitions of variables that appear in the "Block Production" section of the validator level pages.*
### Blocks Produced
The number of blocks produced by this validator.
### Vote Only Blocks
The number of blocks produced by this validator that only contains vote transactions.
### Block Proposal Miss Rate
The number of block production opportunities missed by this validator out of their total block production opportunities. This is also referred to as *skip rate*, meaning the rate at which this validator skipped (did not produce a block) out of the times it was assigned to be the block production leader.
## Infrastructure Information
### Hosting Provider
The service provider used by this validator to run its validator infrastructure.
### City and Country
The geolocation of this validator’s node infrastructure.
### Client
The validator client used by this validator.
## Validator Info
![]()
### Validator Identity
* Also called the identity account
* This is the account that is used to pay for all vote transaction fees by the validator
* This is also the public key that is used to identify a validator node in the gossip network
### Vote Account
* The account required to operate a validator and is a special account owned by the native VoteProgram
* This account is the best way to identify a validator as it cannot be changed
* Delegated stake is also directed to a validator’s vote account
# Overview
Source: https://docs.rated.network/documentation/explorer/solana/network-views/validators/validators
Definitions of variables that appear in the Validators page on the Rated Explorer for Solana.
**Data freshness**: The `1d` view refreshes every 3,000 slots (\~25 minutes). The rest of the views refresh on a daily basis.
## Validators View
This page shows pertinent metrics across the network's validator set. By default, it lists validators based on their allocation of stake (i.e. network penetration).
![]()
## Counters
There are four counters at the top of the view that show the aggregate performance of the network in the time period selected. These are helpful in quickly referencing how a validator is performing compared to the network average. The colored numbers represent the difference of the measure from the last period based on the time window toggle.
For a deeper dive into what each of these metrics mean, please visit the [Solana Validator Effectiveness Rating](/documentation/methodologies/solana/solana-validator-effectiveness-rating/solana-validator-effectiveness-rating) page.
## Network Penetration
This is the percentage distribution of stake that maps under any given validator. We calculate this as:
$$
Network\ penetration = \frac{delegated\ stake}{total\ network\ stake}
$$
## Commission Rate
This is the percentage commission taken by this validator from the staking rewards (i.e. voting) earned by the stake delegated to them, and also the commission they take on MEV rewards they get.
## Delegator APY
This is the annual percentage yield earned by delegators staking with this validator, net of commissions. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days). For more information, please refer to our documentation [Annual Percentage Yield (APY)](/documentation/methodologies/solana/annual-percentage-yield-apy/annual-percentage-yield-apy).
## Vote Latency
The average slot distance between where a validator’s vote transaction was included and the slot they were actually voting for.
## Effectiveness Rating
The Rated model of validator performance for the Solana network. The colour coding in each of these values hints to the relative performance of the entity.
For more information on how this is computed and the methodology behind it, please refer to the [Solana Validator Effectiveness Rating](/documentation/methodologies/solana/solana-validator-effectiveness-rating/solana-validator-effectiveness-rating) page. You can also learn more about how we rank for relative performance via [Rating percentiles](/documentation/methodologies/ethereum/rating-percentiles).
# Aggregating validator indices
Source: https://docs.rated.network/documentation/methodologies/ethereum/aggregating-validator-indices
## Aggregating by deposit address
Up to this point we have described how rated’s validator effectiveness model works, on the basis of indexing for individual validator ids, distinguished by a unique index number and public key address pair.
These unique validator ids are often operated by a single entity. In order to get to a grouping that more closely resembles that of a whole operator entity, we work based on the assumption that an eth1 deposit address is controlled by a single entity.
Deposit addresses are available on-chain, paired to public key data, such that one deposit address could be common to thousands of unique validator public keys.
We therefore proceed to compute the validator effectiveness per unique deposit address as a simple average between all keys that map to that same deposit address.
## Higher order aggregations
Both on the front-end and the API layer of Rated, we are further grouping deposit addresses up to the entities that they are associated with. At the moment, there is no standard way via which we collate this information; it is a combination of Etherscan research, Ethereum transaction log queries, block graffiti and in some cases operators coming straight to us willing to self-disclose.
# APR%
Source: https://docs.rated.network/documentation/methodologies/ethereum/apr
The methodology uses a rolling window calculation of total rewards based on the time periods (1 day, 7 days, 30 days, all-time) and the latest available day where validator rewards are calculated.
The calculation of total rewards accounts for CL+EL rewards divided by active stake and NOT counting rewards earned.
The total rewards are then divided by the total `active_stake` per identified entity in the given time period.
$$
APR \% = \frac{\text{total rewards in ETH}}{\text{active\_stake}} \times \frac{365}{\text{time\_period}} \times 100
$$
In order to control for noise introduced by differing activation times of validators in a group and the rewards they contribute to the aggregate group (e.g. an operator), the APR% calculation ONLY takes into consideration validators that have been active for the whole of the query window.
The maximum time-frame we are enabling at the moment (under ALL) is capped to 90 days in order to allow for better comparisons by not introducing disruptions such as the Genesis validators enjoying double digit APR% by merit of being early to the set.
If you would like to discuss the methodology implemented here, and propose suggestions and/or improvements, please [head to our discord](https://bit.ly/ratediscord).
Currently, the calculation makes no distinction whether the validators of an entity/operator were activated via re-staked ETH rewards (i.e. execution layer rewards) or by external stakers. We will soon be updating our methodology to reflect compounding in pools that explicitly seek to do so.
# Baseline MEV computation
Source: https://docs.rated.network/documentation/methodologies/ethereum/baseline-mev-computation
Post-Merge, validators earn rewards from maximal extractable value (MEV) as well as from transaction fees on Ethereum’s execution layer when they are elected to propose blocks.
MEV extracted from the perspective of the validator is difficult to accurately estimate. Some of it is embedded in priority fees, some is disbursed in direct payments to the validator fee recipient, some of it might be disbursed in a different payment pattern between a relayer, a builder and a proposer, and some might not ever print on-chain.
The emergence of out-of-protocol proposer-builder separation (PBS) with mev-boost has introduced a menu of different patterns that make it a non-trivial task to estimate how much MEV was extracted by a validator in a given block.
In this page, we are proposing a case based approach in separating MEV from priority fees on a block by block basis (and then on aggregate) based on information aggregated on-chain and from the various MEV relay APIs.
We are approaching crafting this methodology with an iterative mindset, and have yet to enshrine this to the front-end and API. We want to hear from the community on which approach is the most realistic, representative and fair.
## Useful definitions
| Term | Definition |
| :-------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `builder` | An agent that constructs a block, drawing from transactions or bundles of transactions sourced from public and/or private mempools. |
| `relay` | An entity that gathers blocks and bids from builders. The source of the block that is proposed by a validator who wants to get MEV rewards. |
| `vanilla_block` | A block that has not been procured from a MEV relay, and is most likely a build by default spec block. |
| `mev_boost_block` | A block that has been procured from a MEV relay. |
| `avg_bid` | The average value of bids logged on all relays, in any given block height. |
| `max_bid` | The maximum bid observed, from the population of bids received by relays, in any given block height. |
| `winning_bid` | The bid that represents the block that made it to the canonical chain as procured from an MEV relay. |
| `fee_recipient` | The specified address that receives the `priority_fees` in the block constructed by the builder. Depending on the case, the fee recipient could be the address of the builder or the proposer. |
| `priority_fees` | Also called block rewards; transaction fees paid to the `fee_recipient` by end-users for their transactions to be included in the block. |
| `end_tx` | A transaction that takes place at the end of the block and involves the builder that crafted the block and the block proposer. |
| `proposer_account` | Address specified by the validator/proposer where they want to be paid the rewards from the block by the `builder` |
| `baseline_mev` | The minimum MEV rewards calculated in the block, outside of any `priority_fees` |
| `secondary_builder_address` | A second address associated with the `builder` that is used to pay the `proposer_account`. |
| `internal_tx` | An internal transaction that takes place within the the end of the block that involves the value transfer from any of the builder's addresses to the block proposer. |
## MEV value transfer patterns in the wild
There are three main on-chain patterns in which we have observed value transfers between a block builder and a validator; (a) one that involves the `end_tx` as parametrized in the table above, (b) one in which the value transfer happens exclusively via the `fee_recipient,` and (c) one that involves an an `end_tx` and an `internal_tx`.
The following case based approach is based on modulating these three parameters, as well as whether the relay where the block was procured from is known or not.
### **Case A: Known MEV Relay blocks**
#### **Case A.1**
This class of cases describe patterns where the builder has set their own address as the `fee_recipient` and pays the proposer via an `end_tx` (e.g. Flashbots relay). A builder may choose to use the same address they set as the `fee_recipient` to pay the proposer or a different one (`secondary_builder_address`). What is consistent here is that regardless of the address used by the builder, the proposer is paid through an `end_tx`.
| Variable | Value |
| :-------------- | :------ |
| `relay` | KNOWN |
| `winning_bid` | KNOWN |
| `end_tx` | KNOWN |
| `fee_recipient` | Builder |
| `internal_tx` | n/a |
If the `winning_bid` is **greater than or equal to** the sum of `priority_fees` for the transactions in the block, and , we calculate baseline MEV as:
$$
\text{baseline\_mev} = \text{winning\_bid} - \text{priority\_fees}
$$
This is the most straightforward case as the components for computing the `baseline_mev` are known. The `winning_bid` is captured from the relay and the `priority_fees` are computed from the transaction fees in the block.
If the `winning_bid` is **less than** the sum of `priority_fees`, for the transactions in the block, we calculate:
```js theme={null}
baseline_mev cannot be determined
```
In the absence of tools to recreate what the block value would have looked like if the proposer made a block by spec, we classify the `winning_bid` they received as the `priority_fees` that went to said validator.
#### **Case A.2**
This class of cases describe patterns where the builder has set the \*\*\*\*proposer account as the `fee_recipient` (e.g. Manifold relay).
| Variable | Value |
| :-------------- | :------- |
| `relay` | KNOWN |
| `winning_bid` | KNOWN |
| `end_tx` | n/a |
| `fee_recipient` | Proposer |
| `internal_tx` | n/a |
In this case we revert to:
```js theme={null}
baseline_mev cannot be determined
```
Which implies we book everything that went to validator via priority fees.
While initially looking at this from the `winning_bid - priority_fees` lens appears rational, cases like the [Manifold bug](https://twitter.com/jon_charb/status/1581396552815632384?s=20\&t=zb6HlKh1pIsaXQMle7ka0A) have shown that bids can be misconfigured to not show exactly how much a validator receives in the end.
#### **Case A.3**
This class of cases describe patterns where the builder has set an alternate receiver address (say a smart contract) in the `end_tx` which then initiates an `internal_tx` to send the funds to the validator.
| Variable | Value |
| :-------------- | :------ |
| `relay` | KNOWN |
| `winning_bid` | KNOWN |
| `end_tx` | KNOWN |
| `fee_recipient` | Builder |
| `internal_tx` | KNOWN |
If the `winning_bid` is **greater than or equal to** the sum of `priority_fees` for the transactions in the block, and , we calculate baseline MEV as:
$$
\text{baseline\_mev} = \text{winning\_bid} - \text{priority\_fees}
$$
If the `winning_bid` is **less than** the sum of `priority_fees`, for the transactions in the block, we calculate:
```js theme={null}
baseline_mev cannot be determined
```
In the absence of tools to recreate what the block value would have looked like if the proposer made a block by spec, we classify the `winning_bid` they received as the `priority_fees` that went to said validator.
The calculation is identical to [Case A.1](#case-a-1), it is just that here, the winning bid would equate to the value of the `internal_tx` instead of the `end_tx`.
### **Case B: Unknown but likely MEV Relay**
This class of cases describe patterns where we do not know the relay the block came from, but given the presence of an `end_tx` this is most likely a relay block.
| Variable | Value |
| :------------ | :------ |
| `relay` | UNKNOWN |
| `winning_bid` | UNKNOWN |
| `end_tx` | KNOWN |
In the absence of data from relays, but with an `end_tx` still observed, if the `end_tx` is **greater than or equal to** the sum of `priority_fees` for transactions in the block, we calculate baseline MEV as:
$$
\text{baseline\_mev} = \text{end\_tx} - \text{priority\_fees}
$$
Conversely, if the `end_tx` is **less than** the sum of `priority_fees` for transactions in the block, we calculate baseline MEV as:
```js theme={null}
baseline_mev cannot be determined
```
We then consider `baseline_mev` undetermined and book all the value that went to the proposer as `priority_fees`.
### **Case** C: Vanilla block
| Variable | Value |
| :------------ | :------ |
| `relay` | UNKNOWN |
| `winning_bid` | UNKNOWN |
| `end_tx` | UNKNOWN |
If all of the parameters we are segregating for are UNKNOWN then we revert to :
```js theme={null}
baseline_mev cannot be determined
```
Qualitatively, if this type of state is observed, it could mean a few things: (1) this is a vanilla block, (2) the bid payment was made out of band (e.g. mev-hiding), or (3) the validator is doing their own block building and MEV extraction.
We believe that these cases in their majority are vanilla blocks, but hold out for emerging patterns as the landscape evolves towards maturity.
# Overview
Source: https://docs.rated.network/documentation/methodologies/ethereum/ethereum
A series of resources regarding our work on rationalizing how we collectively measure the most important metrics relating to the Ethereum Beacon Chain.
## Quick start
In this section, we dive deeper into the methodology that underlies the Rated validator Effectiveness Rating.
The methodology behind our calculation of percentile ranks in terms of Effectiveness.
This section discusses Rated's methodology in calculating accrued penalties on validators that failed to perform their duties, as well as missed rewards.
The methodology behind reference rates available via the Rated Explorer.
How we go about separating MEV from priority fees.
An overview of how Rated creates validator profiles.
# Gini coefficient measurement
Source: https://docs.rated.network/documentation/methodologies/ethereum/gini-coefficient-measurement
This page illustrates the approach Rated takes in computing this metric for the Ethereum network.
The Gini coefficient (Gini) is a measure of inequality across a certain set of values. In this case, we're measuring the Gini of the validator market share of entities we have identified.
## Entity groupings
We have taken the commonality by highest order such that grouping by pools takes precedence over node operators, which take precedence over deposit addresses.
## Interpreting the Gini
A Gini coefficient of 0 reflects perfect equality, where all income or wealth values are the same, while a Gini coefficient of 1 (or 100%) reflects maximal inequality among values.
## Gini calculation
Basing our calculation of the work by Evgeny Medvedev [here](https://medium.com/google-cloud/calculating-gini-coefficient-in-bigquery-3bc162c82168), we first take the `validator_count` of each of the entities on the latest day and `rank` them in descending order accordingly. We then use the `1-2B` formula for measuring the Gini, where B is the area under the Lorenz curve such that:
$$
1 - 2 \times \frac{\text{SUM}(\text{validator\_count} \times (\text{rank} - 1) + \frac{\text{validator\_count}}{2})}{\text{COUNT}(\text{entities}) \times \text{SUM}(\text{validator\_count})}
$$
###
![]()
### Function components
$$
\text{validator\_count} \times (\text{rank} - 1)
$$
is the area of the rectangular horizontal slice under the Lorenz curve.
$$
\text{validator\_count} / 2
$$
is the area of the triangle on the left of the rectangular slice.
$$
\text{SUM}(\text{validator\_count} \times (\text{rank} - 1) + \frac{\text{validator\_count}}{2})
$$
is the sum of all the slices
$$
\text{COUNT}(\text{entities})
$$
normalizes the x axis to the range 0 to 1
$$
\text{SUM}(\text{validator\_count})
$$
normalizes the y axis to the range 0 to 1
# Overview
Source: https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/penalties-computation/penalties-computation
This page discusses Rated's methodology in calculating accrued penalties on validators that failed to perform their duties.
The approach we are taking in calculating penalties at the per index level and then at the aggregate level thereafter, is a bottom-up, spec-based approach. This means breaking down the penalties into their individual components, based on the attestation duty that a validator fails to fulfil.
According to the **pre-Altair spec**, these are the following:
| Penalty | Description | Value |
| :-------------------- | :-------------------------------------------------- | :------------ |
| Incorrect source vote | A source vote that attests to the wrong source slot | `base_reward` |
| Incorrect target vote | A target vote that attests to the wrong target slot | `base_reward` |
| Incorrect head vote | Attesting to the wrong head of the chain | `base_reward` |
According to the **Altair spec**, the penalties are:
| Penalty | Description | Value |
| :------------------------------ | :---------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------- |
| Late source vote | A source vote being included in 6+ slots later than the slot being attested to; `f_inclusion_slot - f_slot ≥ 6` | 14/64 \* `base_reward` |
| Late target vote | A target vote being included in 32+ slots later than the slot being attested to; `f_inclusion_slot - f_slot ≥ 32` | 26/64 \* `base_reward` |
| Wrong target vote | A target vote that attests to the wrong target slot | 26/64 \* `base_reward` |
| Missed sync committee signature | A validator missing a sync committee attestation duty | 2/64 \* `active_validators` \* `base_reward` / (32\*512) |
| Missed attestation | Completely missing an attestation. This means getting a source vote penalty and a target vote penalty | (14/64 + 26/64) \* `base_reward` |
According to the current spec, which is the **Dencun spec**, the penalties are:
| Penalty | Description | Value |
| :------------------------------ | :-------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------- |
| Late source vote | A source vote being included in 6+ slots later than the slot being attested to; `f_inclusion_slot - f_slot ≥ 6` | 14/64 \* `base_reward` |
| Wrong target vote | A target vote that attests to the wrong target slot | 26/64 \* `base_reward` |
| Missed sync committee signature | A validator missing a sync committee attestation duty | 2/64 \* `active_validators` \* `base_reward` / (32\*512) |
| Missed attestation | Completely missing an attestation. This means getting a source vote penalty and a target vote penalty | (14/64 + 26/64) \* `base_reward` |
These penalties are them summed together to get the full penalties received by the validator index.
The main advantages of this approach are two-fold. First is that it removes the variability of uptime since the penalties calculation do not rely on the participation rate of the network. Second is that one can attribute the exact source of the penalties.
Please note that in the RatedDB, we have applied the above methodology only for the post-Altair part of the sample (Day 330; Oct 27, 2021 and onwards). Thus when using the RatedAPI and looking for penalties in the "All-time" frame, you will get a discrepancy in reconciling rewards with the sum of their parts as the methodology described on this page gets mixed with the [Pre-Altair penalties computation](/documentation/methodologies/ethereum/penalties-and-missed-rewards/penalties-computation/pre-altair-penalties-computation).
The RatedAPI reflects this methodology from Day 653 onwards. We are planning a DB migration as part of the API `v1` release, as we want to ensure that there is no interruption of service for API `beta` integrators.
# Pre-Altair penalties computation
Source: https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/penalties-computation/pre-altair-penalties-computation
### Estimating rewards
Validator rewards pre- and post-Altair are some function of `base_reward`. Our calculation follows the spec along each of the two periods. To estimate the actual reward amounts in Gwei, we sum the number of `units` validators should receive per activity, and then we multiply them by the estimated `base_reward` for that day. `Base_reward` is a function of active validators and uptime, and is computed per epoch, but the variability between a day is small enough to approximate it with daily averages; which is the approach we are taking.
```sql theme={null}
CASE WHEN vd.day > 329
THEN (
rewards*u.uptime*br.base_reward +
proposed_count*br.base_reward*br.active_validators*8.0/(32.0*64.0) +
sync_signature_count*(((br.total_active_balance64)/FLOOR(SQRT(br.total_active_balance))) / (32*512*32))
)
ELSE (
rewards*u.uptime*br.pre_alt_base_reward +
proposed_count*(br.pre_alt_base_reward/8.0)*(br.active_validators/32.0)
)
END as estimated_rewards
```
### Deriving penalties
Now from Lighthouse, we fetch a `validator_index`'s daily earnings and we can compare the theoretical maximum rewards for the given activities they performed with the actual outcome. We compute estimated penalties as:
$$
estimated\_penalties = estimated\_rewards - realized\_rewards
$$
**Example under Altair:** A validator attested perfectly 90 times but missed 10 attestations. Say the `base_reward` is 20K GWei For the 90 perfect attestations, the validator should get:
```js theme={null}
90 * (0.218752 + 0.40625) = 75.9375 * base_reward =
75.9375 * 20K = 1,518.75K = 1.5M GWei
```
If a validator received 1.2M Gwei, we have a difference of 300K Gwei that we need to attribute somewhere. It is not opportunity cost, as the theoretical maximum is not factored in at all in the model.
Thus it has to be the penalties.
# Slashing penalties
Source: https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/slashing-penalties
## Slashing on Ethereum
Slashing is the irreversible punishment that decreases a percentage of a validator’s current stake over time and forcibly ejects them from the network. It is the punishment given to validators who violate any of these three offences:
1. **Double Proposal** - proposing validator signs two different blocks for the same slot
2. **Surround Vote** - attesting validator signs a Casper FFG attestation (source `s` and target `t`) that “surrounds” another one, which contradicts what a validator said was finalized in a previous attestation
$$
s1 > s2 > t2 > t1
$$
3. **Double Vote** - attesting validator signs two different attestations with the Casper FFG target
## Mechanics of Slashing
Slashing requires a whistle-blowing validator that monitors and reports on any of the three offenses listed. This whistleblower sends a message to the network outlining the offense. After which, the proposing validator includes this message in their slot. They then get awarded the offending validator’s balance divided by 65,536 (\~0.00048 ETH if the balance is 32 ETH). The reward is small since this is not meant to be a for-profit activity; rewarding reports as such would encourage false positive reports/spam. As for the whistleblower, they get the offending validator's balance divided by 4096 (\~0.00781 ETH if the balance is 32 ETH).
## Slashing Penalties
At a high enough level, so far we have observed slashed validators be subject to the following levels of principal loss across Beacon Chain eras:
| Upgrade era | Principal loss on slashing (approx.) |
| :---------- | :----------------------------------- |
| Phase 0 | 0.25 ETH |
| Altair | 0.5 ETH |
| Bellatrix | 1 ETH |
| Electra | \~0.00781 ETH (32 ETH validator) |
In the section below, we dive a little deeper in the formulas that modulate the level of principal loss for a slashed validator.
Slashed validator irreversibly exits the network during an epoch 36 days in the future. The slashed validator receives a minimal penalty at the point of whistle-blowing report.
* Pre-Altair: Slashed Validator’s Effective Balance \* 1/32
* Post-Altair: Slashed Validator’s Effective Balance \* 1/64
* Post-Merge: Slashed Validator’s Effective Balance \* 1/32
* Post-Electra: Slashed Validator's Effective Balance \* 1/4096
Following that, the slashed validator receives a penalty at the start of each epoch from the time of the report until the scheduled network withdrawal/exit.
* Pre-Altair: 3 \* Base Reward \* 32 (per epoch)
* Post-Altair: 40/64 \* Base Reward \* 32 (per epoch)
* Post-Merge: 40/64 \* Base Reward \* 32 (per epoch)
* Post-Electra: 40/64 \* Base Reward \* Effective Balance (per epoch)
* This penalty is higher if an inactivity leak is activated in the network.
Finally, the slashed validator receives a special penalty halfway between the point of the whistle-blowing report and at the point which the validator is forced to exit/withdraw (18 days).
* Takes into consideration the number of validators slashed during the period 18 days before the offending validator was slashed and 18 days after (aka 36 days before this halfway point)
* Maximum amount can be as high as the slashed validator’s total effective balance
**Pre-Altair:**
$$
\left[\frac{\min(3 \times \text{Total Balance}_{\text{Slashed Validators}}, \text{Total Effective Balance}_{\text{of the Network}})}{\text{Total Effective Balance}_{\text{of the Network}}}\right] \times \text{Effective Balance}_{\text{Validator}}
$$
**Post-Altair:**
$$
\left[\frac{\min(2 \times \text{Total Balance}_{\text{Slashed Validators}}, \text{Total Effective Balance}_{\text{of the Network}})}{\text{Total Effective Balance}_{\text{of the Network}}}\right] \times \text{Effective Balance}_{\text{Validator}}
$$
**Post-Merge:**
$$
\left[\frac{\min(3 \times \text{Total Balance}_{\text{Slashed Validators}}, \text{Total Effective Balance}_{\text{of the Network}})}{\text{Total Effective Balance}_{\text{of the Network}}}\right] \times \text{Effective Balance}_{\text{Validator}}
$$
# Consensus missed rewards computation
Source: https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation/consensus-missed-rewards-computation
This page discusses Rated's methodology on calculating missed consensus layer rewards from missed block proposals and failed attestation duties.
There are two distinct parts in computing missed consensus rewards for validators, and these are missed rewards that happen owing to (i) missed proposals and (ii) missed attestations, such that:
$$
\text{consensus\_missed\_rewards} = \text{consensus\_missed\_proposal\_rewards} + \text{consensus\_missed\_attestation\_rewards}
$$
In the following sections, we examine the methodology in calculating each of the two components.
## Consensus missed proposal rewards
There will be times wherein validators miss proposing on slots they are assigned to. Aside from penalties, this will correspond to missed `CL` rewards that they would have gotten if these validators were able to fulfil their duty.
Rated estimates this opportunity cost by taking the average of the consensus layer proposer duty rewards for the epoch where the slot proposal was missed. As such the calculation is as follows:
$$
\text{consensus\_missed\_proposal\_rewards} = \frac{sum(\text{consensus\_rewards\_per\_epoch\_block})}{\text{proposed\_blocks\_in\_epoch}}
$$
An epoch-level average is taken because conditions and parameters are set on a per-epoch basis by the network (e.g. proposer assignments, number of active and participating validators). Therefore the missed slot is under the same conditions as the rest in the epoch and we can take a credible comparison.
In the extreme scenario where there is a serious inactivity incident and there are several epochs without blocks, we fall back to the global average (i.e. since the start of the beacon chain).
## Consensus missed attestation rewards
*This approach defines the Rated methodology insofar as the post-Altair era is concerned.*
Our approach to calculating missed attestation rewards is to first count how many attestation duties were wrongly fulfilled and then apply the spec based methodology on what these would have translated to in terms of rewards were they performed appropriately.
$$
consensus\_missed\_attestation\_rewards = head\_vote\_missed\_rewards \\
+ \ source\_vote\_missed\_rewards \\
+ \ target\_vote\_missed\_rewards \\
+ \ sync\_committee\_missed\_rewards
$$
Diving a little deeper into the methodology, recall that the attestation duties wherein a missed reward event can happen are the following:
1. source vote: the validator has made a timely vote for the correct source checkpoint
2. target vote: the validator has made a timely vote for the correct target checkpoint
3. head vote: the validator has made a timely vote for the correct head block
4. sync committee reward: the validator has participated in a sync committee
Our calculation starts by aggregating the count of these misses over a given epoch-based time-period.
```js theme={null}
count(missed_source_votes)
count(missed_target_votes)
count(missed_head_votes)
count(missed_sync_committee_signatures)
```
We then take these counts and multiply them by their respective base reward weights according to the Altair spec.
```js theme={null}
count(missed_source_votes) * 14/64 base_reward
count(missed_target_votes) * 26/64 base_reward
count(missed_head_votes) * 14/64 base_reward
count(missed_sync_committee_signatures) * 2/64 * active_validators * base_reward / (32*512)
```
The products of these operations are then multiplied by the respective network-wide fulfilment rates of each duty (i.e. the proportion of validators correctly fulfilling that duty) for the period, except for the missed sync committee signatures wherein the uptime does not factor in the calculation.
It goes without saying that completely missing an attestation counts towards a missed head vote, target vote, and source vote altogether.
### Consensus missed rewards pre-Altair
According to the Phase 0 Beacon Chain spec, missed rewards were more tightly coupled with penalties. It's worth revisiting how the [EF's documentation](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/#penalties) formalizes rewards and penalties.
> The penalties for missing the head, target, and source votes are equal to the rewards the attester would have received had they submitted them. **This means that instead of having the rewards added to their balance, they have an equal value removed from their balance**.
Given all of the above, there is a simple and elegant way in which we can capture missed attestation rewards on the Beacon Chain for any given validator index in any given epoch:
$$
consensus\_missed\_attestation\_rewards = |penalties|
$$
While the calculation is relatively straightforward, there is an important distinction to make here. The above stated approach is strictly encompassing of `missed_rewards`, when missed rewards are understood as a wholly different set from`penalties`, in a way that:
$$
opportunity\_cost = |penalties| + consensus\_missed\_attestation\_rewards
$$
# Execution missed rewards computation
Source: https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation/execution-missed-rewards-computation
This page discusses Rated's methodology on calculating missed execution layer rewards emanating from missed block proposals.
At a high enough level, all missed rewards at the `EL` stem from missing block proposals. This is clear enough to conceptualize.
Where things start getting complicated is when trying to ascertain the value of the block that would be. Unlike `CL` rewards, `EL` rewards for validators vary a lot more, based on the following two factors:
1. Demand for blockspace (i.e. transaction volume) on the chain
2. Procuring blocks from block builders vs crafting your own blocks (as a validator)
Complexity increases further once you consider groups of validators with similar configurations under a given operator; does one look at “what could have been” from the validator index perspective, or does it pay to aggregate upwards to the operator level and project back down to the index level from there?
In the following sections we discuss the merits and drawbacks of different approaches before arriving to the “current best” approach.
We are offering **Approach 1** via our [API](/rated-api/introduction). If you are interested in integrating any of the other approaches outlined in this page, [**get in touch**](mailto:hello@rated.network) with us!
## Approach 1: Simple average of block value in an epoch
In the simplest form, missed `EL` rewards would be calculated similarly to `CL` missed rewards:
$$
execution\_missed\_rewards = \frac{sum(execution\_rewards\_per\_block)}{proposed\_blocks\_in\_epoch}
$$
There are some clear **advantages** with this approach, namely that:
1. It is easy to understand.
2. It is easy enough to replicate.
3. It does not really require information that does not live on-chain (so long as the calculation of validator rewards is performed correctly).
4. It works well at the atomic level (a `pubkey`).
At the same time there are **disadvantages** to consider:
1. It flattens validators and operators insofar as their adoption of mev-boost goes, with the potential to unfairly penalize (for example) a validator that does not run mev-boost, but missed a block in an epoch that all produced blocks were mev-boost blocks.
2. It does not more accurately capture the specifics of the circumstance as well as a “next block” or “average relay bid” does.
## Approach 2: Referencing relay bids for opportunity cost
Another approach is to reference the global average of bids from the relay APIs for that particular block slot (addendum: bids that match the `parent_hash` with the previous block).
$$
execution\_missed\_rewards = avg(relay\_bids)
$$
While we initially considered taking the `max_bid` from relays to measure up against, we quickly have found that in the majority of cases `winning_bid` ≠ `max_bid`. This is most likely due to the fact that bids keep arriving after the `winning_bid` gets picked; naturally these bids pack more transactions, and with more transactions, the configurations for MEV multiply. The proposer could keep waiting for a later bid, but also that would increase the probability of missing that block. Overall, while this would be the purest form of opportunity cost, it is also highly unrealistic given our observations and penalizes missed proposals unfairly.
There are some clear **advantages** with this approach, namely that:
1. It captures a pure version of opportunity cost that references the state of the world at t=n when said block would have been produced.
2. It offers realistic hard data about the state of the world at t=n.
But at the same time there are some pretty serious **disadvantages**:
1. It assumes that every validator is running mev-boost, unfairly penalizing those that do not.
2. At any scale of downstream adoption, it creates incentives for running mev-boost, and is therefore more opinionated.
3. It is harder to replicate as it assumes widespread access to the archive of relay bids; this archive is not on-chain, data is in parts ephemeral, and while Rated does have all this data, it also becomes a choke point.
## Approach 3: Referencing the next block produced
The third approach available is to reference the value of the next block produced, such that:
$$
execution\_missed\_rewards(n) = prio\_fees(n+1) + baseline\_MEV(n+1) \\
= winning\_bid(n+1)
$$
The rationale behind this is that the validator who missed the proposal would have had access to the same transactions as the next proposer and could then have at least built the same block with the same transactions and corresponding fees.
There are some **advantages** with this approach, namely that:
1. It is more specific to the condition of said validator that missed the block.
2. The data is on-chain an therefore easy to replicate.
3. It is simple enough to calculate.
But at the same time there are some pretty serious **disadvantages**:
1. It is more stochastic than either Approach 1 or 2 as there is no smoothing, and is sensitive to spikes in demand for blockspace.
2. It does not distinguish between whether the validator is running mev-boost or not, and is therefore subject to the same class of disadvantages as Approach 2 is.
## Approach 4: Abstracting to the operator level
The final possible approach is to combine elements of Approach 1 and 2 with some probabilistic weighing of where the next block might come from, guided from an operator level distribution.
Say validator A belongs to a set of keys under operator B. Operator B has produced x% mev-boost blocks and y% vanilla blocks. We could therefore calculate the value of a missed block as:
$$
execution\_missed\_rewards = y\% \times \left[\frac{sum(execution\_rewards\_per\_block)}{proposed\_blocks\_in\_epoch}\right] + x\% \times \left[avg(relay\_bids)\right]
$$
There are some strong **advantages** with this approach, namely that:
1. It captures the probability space well and produces an expected value of opportunity cost.
2. It is specific to the context of each of the validators.
3. In a world of perfect information, it is probably the most accurate representation of missed value.
But at the same time there are some pretty serious **disadvantages**:
1. It assumes perfect knowledge of pubkey to operator mappings. In reality, this is very fickle and only translates well to operations that have on-chain registries that they correspond to (e.g. the Lido set). Hence this methodology does not scale well horizontally.
2. It comes with the same challenges as Approach 2 with respect to access to MEV relay data.
# Overview
Source: https://docs.rated.network/documentation/methodologies/ethereum/penalties-and-missed-rewards/validator-missed-rewards-computation/validator-missed-rewards-computation
This section discusses the methodologies that underlie Rated's calculation of missed rewards on the Beacon Chain.
When validators fail to perform their ascribed duties (e.g. due to downtime–being offline), besides in many cases accruing penalties, they are also subject to opportunity cost–i.e. what they could have earned had they performed their duties appropriately.
While the idea of missed rewards was fairly straightforward pre-Merge, with the introduction of the Execution Layer rewards and out-of-protocol PBS in the mix, not only has the opportunity cost of missed proposals become orders of magnitude higher, but also the semantics of what constitutes a missed reward have become equally more complex.
Producing a transparent, fair, and generally accepted methodology for missed rewards is a crucial step in unlocking new products for Node Operators (e.g. Nexus Mutual's slashing and downtime cover). In addition, for these products to proliferate in a way that treats those that benefit from them the most fairly, it is important to gather input and harden the methodologies early on.
We are approaching crafting this methodology with an iterative mindset and have yet to enshrine this to the front-end and API. We want to hear from the community on which approach is the most realistic, representative, and fair.
Join the conversation [**on Discord**](https://bit.ly/ratediscord).
## Context
As hinted in the introduction, we look at missed rewards in two tracks: Consensus and Execution layer missed proposer rewards. The two tracks are really the heart of the methodology/calculation. To calculate total missed rewards, we simply proceed as follows:
$$
total\_missed\_rewards = consensus\_missed\_rewards + execution\_missed\_rewards
$$
This is computed at the validator index level, and then aggregated upwards to different groupings as with many other metrics that Rated hosts. In the following section, we dive deeper into these components.
We are referring to Consensus and Execution Layer as CL and EL respectively hereon. Also every mention to missed rewards in this section specifically refers to missed **proposal** rewards.
# Overview
Source: https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating/rated-effectiveness-rating
Methodology that underlies the Rated Validator Effectiveness Rating of validator and operator performance on Ethereum.
This Content is available under the [*CC BY-NC-SA 4.0 International License*](https://creativecommons.org/licenses/by-nc-sa/4.0/?ref=chooser-v1) .
For more information on the license and the definitions of commercial vs non-commercial use, please see [here](https://legal.rated.network/licenses/raver-content-license).
The Rated Validator Effectiveness Rating (aka `RAVER`) is a measure of how well a validator has been performing its deterministic duties over time.
It seeks to be a true measure of performance, attributing points to the validator and operator for attributes of their onchain footprint that they have influence over (e.g. whether they are getting their attestations included, which implies that they are default online), while dampening the effect of metrics that allow randomness to creep into the measurement (e.g. execution layer rewards that the validator has accrued).
The RAVER is designed to work with the validator index (or pubkey) as the base unit of account. What the metric effectively does is to tally up the duties that a validator index is called to perform over a given time period (e.g. 10 epochs, a day, a year), and assign points to those instances when duties were completed successfully. The result is a percentage score that illustrates the job completion rate of a given validator index. Over time we have found that this correlates highly with how good an operator is in running performant infrastructure.
Where the RAVER really shines, however, is in the aggregations of validator keys into clusters, and “operators” thereafter.
The RAVER is designed in a way that allows the graceful aggregation of indices into larger groupings, while maintaining the same interface and potency in terms of signal.
# RAVER v1.0
Source: https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating/raver-v1.0
Applicable to Phase 0 of the Ethereum Beacon Chain spanning from epoch `1` to epoch `74239`.
## Components of RAVER
Validator performance in Ethereum PoS is largely described by 2 core activity centers.
These are:
In the following sections, we examine those one-by-one and then synthesise them together in what constitutes the RAVER.
## Proposer effectiveness
A block proposer is a validator that is chosen to pack the attestation information together and commit the block to the chain. There is one proposer per slot and 32 per epoch. Given their work is critical, the reward that they earn for successfully proposing a block is disproportionate to any given attester’s reward in an epoch.
Being elected as a proposer has a much lower probability attached to it (32/active\_validators), compared to a validator’s attestation duties (which is 100%).
The RAVER does not penalize effectiveness for orphaned blocks. This type of outcome is not controlled by the validator operator.
### Proposer effectiveness formula
We calculate proposer effectiveness simply as the ratio that expresses how many times a validator has successfully proposed a block out of the times that they were awarded proposer duties:
$$
\text{proposer\_effectiveness} = \frac{\text{slots\_proposed}}{\text{total\_proposer\_slots\_attributed}}
$$
## Attester effectiveness
Validators are called to attest once in every epoch. These attestations are important consensus material. When attesting, validators vote on their version of the perceived state of the chain, which is described by a handful of distinct variables. These variables are also known as a validator's duties.
When validators perform their duties appropriately, they earn rewards; if they do not, they are penalized. The core duties that validators are called to perform are:
* Getting a vote (1) included; this is equivalent to submitting a[ Casper FFG](https://blog.ethereum.org/2020/02/12/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat), which makes the final decision on which blocks are and are not a part of the chain.
* Getting a (2) correct vote included. Correctness is described by:
* **Head vote:** submitting an attestation that correctly identifies the head of the chain, by[ GHOST](https://blog.ethereum.org/2020/02/12/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat) rules
* **Target vote:** submitting an attestation that correctly identifies the Casper FFG target checkpoint of the chain
You can refer to[ Rewards and Penalties on Ethereum 2.0 \[Phase 0\]](https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/) for more context on how rewards are distributed in eth2 pre-Altair.
### Attester effectiveness formula
We measure (1) as participation rate, (2) correctness, and (3) as inclusion delay. These are calculated as:
1. **Participation rate:** total amount of attestations included over the number of epochs active.
2. **Correctness:** amount of correct head and target votes over the sum of votes included.
3. **Inclusion delay:** aggregate slot distance between the attestation slots attributed and the actual slots the votes were included in.
Given the above, we compute attester effectiveness as follows:
$$
\text{attester\_effectiveness} = \frac{\text{participation\_rate} \cdot \text{correctness\_score}}{\text{aggregate\_inclusion\_delay}}
$$
The premise in the above calculation is that it equally and accurately captures all the important elements in evaluating how well a validator's consensus duties are being performed while at the same time shielding the methodology from unnecessary complexity.
## Effectiveness rating
In order to come up with a unified validator effectiveness score, we combine proposer and attester effectiveness in a weighted average. We attribute the following weights to each, guided by the longer term expectation of rewards distribution between the two duties:
* Proposer effectiveness: 1/8
* Attester effectiveness: 7/8
Attributions of proposer slots are much rarer than attestation duties but bear a significantly higher reward if performed correctly. On average and over a long time period, a validator’s consensus layer rewards will be split between proposer and attester rewards at a ratio of 1:7. We have selected the respective probability weights to reflect that distribution.
Given the above, we calculate validator effectiveness as:
$$
\text{validator\_effectiveness} = \left[\frac{1}{8} \times \text{proposer\_effectiveness}\right] + \left[\frac{7}{8} \times \text{attester\_effectiveness}\right]
$$
## RAVER across time
The base unit of account in terms of time in the Rated DB is the “day”. What we have defined as “day” is the 24 hour increment post Beacon Chain genesis, which is further defined as X MANY epochs.
While Rated also produces an “hourly” effectiveness calculation (definition of the “hour” follows similar form to that of “day”) to power different features, the “day” is the main unit of account.
In order for the hourly and daily effectiveness of a given validator index to be computed, we aggregate the sum of duties a validator index has been allocated and apply the RAVER methodology, as outlined in the sections above.
Thereafter, in order to calculate validator effectiveness over periods that span multiple days (e.g. a month), we average across the “daily” effectiveness scores produced. This implies that for any given 30 day period, we would compute the RAVER off the sum of duties for the 30 discrete daily increments in that window, and then average across those.
$$
\text{multiday\_effectiveness} = \frac{\text{sum(daily\_effectiveness)}}{\text{number\_of\_days}}
$$
## RAVER at the operator level
As mentioned earlier in the documentation, the RAVER for Ethereum PoS is computed at the validator index level. In aggregating upwards to the operator level (defined as a group of validator indices), we simply compute the average RAVER of those keys, such that:
$$
\text{operator\_effectiveness} = \frac{\text{sum(validator\_effectiveness)}}{\text{number\_of\_indices}}
$$
While this produces a robust enough outcome and has clear benefits in the simplicity that it comes with, the approach was chosen for practical purposes and has been bound to some path dependency.
***
*Content on this page is subject to License described in the* [*Content License*](https://legal.rated.network/licenses/raver-content-license)*.*
# RAVER v2.0
Source: https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating/raver-v2.0
Applicable to the Altair upgrade of the Ethereum Beacon Chain spanning from epoch `74240` to epoch `96749`.
## Components of RAVER
Validator performance in Ethereum PoS is largely described by 2 core activity centers.
These are:
In the following sections, we examine those one-by-one and then synthesise them together in what constitutes the RAVER.
## Proposer effectiveness
A block proposer is a validator that is chosen to pack the attestation information together and commit the block to the chain. There is one proposer per slot and 32 per epoch. Given their work is critical, the reward that they earn for successfully proposing a block is disproportionate to any given attester’s reward in an epoch.
Being elected as a proposer has a much lower probability attached to it (32/active\_validators), compared to a validator’s attestation duties (which is 100%).
The RAVER does not penalize effectiveness for orphaned blocks. This type of outcome is not controlled by the validator operator.
### Proposer effectiveness formula
We calculate proposer effectiveness simply as the ratio that expresses how many times a validator has successfully proposed a block out of the times that they were awarded proposer duties:
$$
\text{proposer\_effectiveness} = \frac{\text{slots\_proposed}}{\text{total\_proposer\_slots\_attributed}}
$$
## Attester effectiveness
Validators are called to attest once in every epoch. These attestations are important consensus material. When attesting, validators vote on their version of the perceived state of the chain, which is described by a handful of distinct variables. These variables are also known as a validator's duties.
When validators perform their duties appropriately, they earn rewards; if they do not, they are penalized. The core duties that validators are called to perform are:
* Getting a vote (1) included; this is equivalent to submitting a[ Casper FFG](https://blog.ethereum.org/2020/02/12/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat), which makes the final decision on which blocks are and are not a part of the chain.
* Getting a (2) correct vote included. Correctness is described by:
* Head vote: submitting an attestation that correctly identifies the head of the chain, by[ GHOST](https://blog.ethereum.org/2020/02/12/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat) rules
* Target vote: submitting an attestation that correctly identifies the Casper FFG target checkpoint of the chain
* Getting a correct vote included (3) with minimal delay.
* Every validator is assigned a slot “n” to attest to in every epoch, and the earliest their vote could be included is on slot n+1. For every slot greater than n+1 that the vote gets included, the validator earns[ increasingly less rewards](https://www.attestant.io/posts/defining-attestation-effectiveness/).
You can refer to[ Rewards and Penalties on Ethereum 2.0 \[Phase 0\]](https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/) for more context on how rewards are distributed in eth2 pre-Altair.
### Attester effectiveness formula
The Altair upgrade brought on a few significant changes in how rewards and penalties tied to attestation duties are distributed in the consensus layer. More specifically, the rules governing the timing of when the vote material gets included on-chain and rewards/penalties relationship have become stricter. In RAVER terms:
1. **Participation rate:** in order for an attestation to be included, the source vote must still be correct. There are now additional penalties for cases when the attestation does not get included in a timely manner; namely within sqrt(EPOCH\_LENGTH) or 5 slots. This however does not affect how we calculate participation.
2. **Correctness:** the target and head votes must not only be correct, but also need to be included in a timely manner; namely within EPOCH\_LENGTH or 32 slots and 1 slot respectively. We also bundle source vote lateness (by the above criteria) in the correctness calculation. In this case we look at events in a binary way (prompt, late) and do not modulate for "how late" in the calculation.
3. **Inclusion delay:** The concept of moderating rewards downwards the more delayed the attestations are is not valid any longer on its own accord, and is rather feeding directly into participation and correctness
We have updated the RAVER to reflect the new rules that underlie participation and correctness. However, we have not changed the way the overall attester effectiveness calculation is computed in the spirit of maintaining the design goals initially set.
$$
\text{attester\_effectiveness} = \frac{\text{participation\_rate} \cdot \text{correctness\_score}}{\text{aggregate\_inclusion\_delay}}
$$
The premise in the above calculation is that it equally and accurately captures all the important elements in evaluating how well a validator's consensus duties are being performed while at the same time shielding the methodology from unnecessary complexity.
### Sync committees
With the Altair Beacon Chain upgrade, a new role for validator nodes was introduced: attesting to sync committees. These are duties related to enabling light clients to validate the Beacon Chain’s state. A light client only needs to know a previously validated block header and members of the previous, current and next committee to verify the beacon state.
A sync committee is a group of 512 randomly selected validators, chosen anew every 256 epochs. This committee signs block headers for each new slot in the beacon chain so that a light client can trust these headers to represent accurate and validated blocks.
Granted the stochastic nature of sync committee selection and the low probability of a single validator to be selected in a sync committee set, we are not including sync committee performance in the[ ](https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating)RAVER.
## Effectiveness rating
In order to come up with a unified validator effectiveness score, we combine proposer and attester effectiveness in a weighted average. We attribute the following weights to each, guided by the longer term expectation of rewards distribution between the two duties:
* Proposer effectiveness: 1/8
* Attester effectiveness: 7/8
Attributions of proposer slots are much rarer than attestation duties but bear a significantly higher reward if performed correctly. On average and over a long time period, a validator’s consensus layer rewards will be split between proposer and attester rewards at a ratio of 1:7. We have selected the respective probability weights to reflect that distribution.
Given the above, we calculate validator effectiveness as:
$$
\text{validator\_effectiveness} = \left[\frac{1}{8} \times \text{proposer\_effectiveness}\right] + \left[\frac{7}{8} \times \text{attester\_effectiveness}\right]
$$
The premise in the above calculation is that it equally and accurately captures all the important elements in evaluating how well a validator's consensus duties are being performed while at the same time shielding the methodology from unnecessary complexity.
## RAVER across time
The base unit of account in terms of time in the Rated DB is the “day”. What we have defined as “day” is the 24 hour increment post Beacon Chain genesis, which is further defined as X MANY epochs.
While Rated also produces an “hourly” effectiveness calculation (definition of the “hour” follows similar form to that of “day”) to power different features, the “day” is the main unit of account.
In order for the hourly and daily effectiveness of a given validator index to be computed, we aggregate the sum of duties a validator index has been allocated and apply the RAVER methodology, as outlined in the sections above.
Thereafter, in order to calculate validator effectiveness over periods that span multiple days (e.g. a month), we average across the “daily” effectiveness scores produced. This implies that for any given 30 day period, we would compute the RAVER off the sum of duties for the 30 discrete daily increments in that window, and then average across those.
$$
\text{multiday\_effectiveness} = \frac{\text{sum(daily\_effectiveness)}}{\text{number\_of\_days}}
$$
## RAVER at the operator level
As mentioned earlier in the documentation, the RAVER for Ethereum PoS is computed at the validator index level. In aggregating upwards to the operator level (defined as a group of validator indices), we simply compute the average RAVER of those keys, such that:
$$
\text{operator\_effectiveness} = \frac{\text{sum(validator\_effectiveness)}}{\text{number\_of\_indices}}
$$
While this produces a robust enough outcome and has clear benefits in the simplicity that it comes with, the approach was chosen for practical purposes and has been bound to some path dependency.
***
*Content on this page is subject to License described in the* [*Content License*](https://legal.rated.network/licenses/raver-content-license)*.*
# RAVER v2.1
Source: https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating/raver-v2.1
Applicable to the Altair upgrade of the Ethereum Beacon Chain spanning from epoch `96750` to epoch `146874`.
## Components of RAVER
Validator performance in Ethereum PoS is largely described by 2 core activity centers.
These are:
In the following sections, we examine those one-by-one and then synthesise them together in what constitutes the RAVER.
## Proposer effectiveness
A block proposer is a validator that is chosen to pack the attestation information together and commit the block to the chain. There is one proposer per slot and 32 per epoch. Given their work is critical, the reward that they earn for successfully proposing a block is disproportionate to any given attester’s reward in an epoch.
Being elected as a proposer has a much lower probability attached to it (32/active\_validators), compared to a validator’s attestation duties (which is 100%).
Orphaned blocks are now treated as missed proposals. It is quite often the proposer's fault that a block has been orphaned (either the proposer node is out of sync and builds a block on top of an older block, or it produces the new block too late and the next proposer uses an earlier parent).
### Proposer effectiveness formula
We calculate proposer effectiveness simply as the ratio that expresses how many times a validator has successfully proposed a block out of the times that they were awarded proposer duties:
$$
\text{proposer\_effectiveness} = \frac{\text{slots\_proposed}}{\text{total\_proposer\_slots\_attributed}}
$$
## Attester effectiveness
Validators are called to attest once in every epoch. These attestations are important consensus material. When attesting, validators vote on their version of the perceived state of the chain, which is described by a handful of distinct variables. These variables are also known as a validator's duties.
When validators perform their duties appropriately, they earn rewards; if they do not, they are penalized. The core duties that validators are called to perform are:
* Getting a vote (1) included; this is equivalent to submitting a[ Casper FFG](https://blog.ethereum.org/2020/02/12/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat), which makes the final decision on which blocks are and are not a part of the chain.
* Getting a (2) correct vote included. Correctness is described by:
* Head vote: submitting an attestation that correctly identifies the head of the chain, by[ GHOST](https://blog.ethereum.org/2020/02/12/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat) rules
* Target vote: submitting an attestation that correctly identifies the Casper FFG target checkpoint of the chain
* Getting a correct vote included (3) with minimal delay.
* Every validator is assigned a slot “n” to attest to in every epoch, and the earliest their vote could be included is on slot n+1. For every slot greater than n+1 that the vote gets included, the validator earns[ increasingly less rewards](https://www.attestant.io/posts/defining-attestation-effectiveness/).
You can refer to[ Rewards and Penalties on Ethereum 2.0 \[Phase 0\]](https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/) for more context on how rewards are distributed in eth2 pre-Altair.
### Attester effectiveness formula
The Altair upgrade brought on a few significant changes in how rewards and penalties tied to attestation duties are distributed in the consensus layer. More specifically, the rules governing the timing of when the vote material gets included on-chain and rewards/penalties relationship have become stricter. In RAVER terms:
1. **Participation rate:** in order for an attestation to be included, the source vote must still be correct. There are now additional penalties for cases when the attestation does not get included in a timely manner; namely within sqrt(EPOCH\_LENGTH) or 5 slots. This however does not affect how we calculate participation.
2. **Correctness:** the target and head votes must not only be correct, but also need to be included in a timely manner; namely within EPOCH\_LENGTH or 32 slots and 1 slot respectively. We also bundle source vote lateness (by the above criteria) in the correctness calculation. In this case we look at events in a binary way (prompt, late) and do not modulate for "how late" in the calculation.
3. **Inclusion delay:** The concept of moderating rewards downwards the more delayed the attestations are is not valid any longer on its own accord, and is rather feeding directly into participation and correctness
We have updated the RAVER to reflect the new rules that underlie participation and correctness. However, we have not changed the way the overall attester effectiveness calculation is computed in the spirit of maintaining the design goals initially set.
$$
\text{attester\_effectiveness} = \frac{\text{participation\_rate} \cdot \text{correctness\_score}}{\text{aggregate\_inclusion\_delay}}
$$
The premise in the above calculation is that it equally and accurately captures all the important elements in evaluating how well a validator's consensus duties are being performed while at the same time shielding the methodology from unnecessary complexity.
### Sync committees
With the Altair Beacon Chain upgrade, a new role for validator nodes was introduced: attesting to sync committees. These are duties related to enabling light clients to validate the Beacon Chain’s state. A light client only needs to know a previously validated block header and members of the previous, current and next committee to verify the beacon state.
A sync committee is a group of 512 randomly selected validators, chosen anew every 256 epochs. This committee signs block headers for each new slot in the beacon chain so that a light client can trust these headers to represent accurate and validated blocks.
Granted the stochastic nature of sync committee selection and the low probability of a single validator to be selected in a sync committee set, we are not including sync committee performance in the[ ](https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating)RAVER.
## Effectiveness rating
In order to come up with a unified validator effectiveness score, we combine proposer and attester effectiveness in a weighted average. We attribute the following weights to each, guided by the longer term expectation of rewards distribution between the two duties:
* Proposer effectiveness: 1/8
* Attester effectiveness: 7/8
Attributions of proposer slots are much rarer than attestation duties but bear a significantly higher reward if performed correctly. On average and over a long time period, a validator’s consensus layer rewards will be split between proposer and attester rewards at a ratio of 1:7. We have selected the respective probability weights to reflect that distribution.
Given the above, we calculate validator effectiveness as:
$$
\text{validator\_effectiveness} = \left[\frac{1}{8} \times \text{proposer\_effectiveness}\right] + \left[\frac{7}{8} \times \text{attester\_effectiveness}\right]
$$
The premise in the above calculation is that it equally and accurately captures all the important elements in evaluating how well a validator's consensus duties are being performed while at the same time shielding the methodology from unnecessary complexity.
## RAVER across time
The base unit of account in terms of time in the Rated DB is the “day”. What we have defined as “day” is the 24 hour increment post Beacon Chain genesis, which is further defined as X MANY epochs.
While Rated also produces an “hourly” effectiveness calculation (definition of the “hour” follows similar form to that of “day”) to power different features, the “day” is the main unit of account.
In order for the hourly and daily effectiveness of a given validator index to be computed, we aggregate the sum of duties a validator index has been allocated and apply the RAVER methodology, as outlined in the sections above.
Thereafter, in order to calculate validator effectiveness over periods that span multiple days (e.g. a month), we average across the “daily” effectiveness scores produced. This implies that for any given 30 day period, we would compute the RAVER off the sum of duties for the 30 discrete daily increments in that window, and then average across those.
$$
\text{multiday\_effectiveness} = \frac{\text{sum(daily\_effectiveness)}}{\text{number\_of\_days}}
$$
## RAVER at the operator level
As mentioned earlier in the documentation, the RAVER for Ethereum PoS is computed at the validator index level. In aggregating upwards to the operator level (defined as a group of validator indices), we simply compute the average RAVER of those keys, such that:
$$
\text{operator\_effectiveness} = \frac{\text{sum(validator\_effectiveness)}}{\text{number\_of\_indices}}
$$
While this produces a robust enough outcome and has clear benefits in the simplicity that it comes with, the approach was chosen for practical purposes and has been bound to some path dependency.
***
*Content on this page is subject to License described in the* [*Content License*](https://legal.rated.network/licenses/raver-content-license)*.*
# RAVER v3.0 [current]
Source: https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating/raver-v3.0-current
Applicable to the Altair upgrade of the Ethereum Beacon Chain spanning from epoch `146875` to present.
## Components of RAVER
Validator performance in Ethereum PoS is largely described by 2 core activity centers.
These are:
In the following sections, we examine those one-by-one and then synthesise them together in what constitutes the RAVER.
## Proposer effectiveness
In post-Merge Ethereum, validators have the responsibility of not only proposing valid blocks that contain all the consensus messages that help advance and finalize the chain, but they also have to facilitate the production of execution layer (EL) blocks that contain user transactions. Validators earn from these proposed blocks through priority fees and MEV.
This transition means that not only has the balance of rewards between proposal duties and attestation duties changed, but also signals a transition to validator “prime-time”, which is really them fulfilling the duty of helping secure value being transacted on the EL.
Given the above, we have introduced a series of changes in the way Proposer Effectiveness is measured at Rated.
For the purpose of the exercise, we look at the world of proposer effectiveness in two parallel tracks (CL and EL), and attribute different scores to different cases. We first provide the summary table that outlines the different cases, with a brief discussion to follow.
| Case | CL | EL | Score |
| :--- | :------- | :------- | :---- |
| A.1 | proposed | proposed | 1 |
| A.2 | proposed | empty | 0.25 |
| B | missed | missed | 0 |
### Case A.1
In this case the block is proposed as per usual, containing both transactions and attestations, in which case there is a full marginal contribution to the proposer effectiveness ratio.
### Case A.2
In this case the block is proposed “normally” from a consensus layer standpoint, but there are no transactions packed inside it. We have observed about 0.1% of the post-Merge blocks to exhibit this behavior. We have decided to penalize the EL failure disproportionately, as we view this as the reason why validators exist, and have opted for 0.25 points (instead of 0.5).
### Case B
In this case the block is wholly missed, yielding 0 points to the validator.
Orphaned blocks are treated as missed proposals. It is quite often the proposer's fault that a block has been orphaned (either the proposer node is out of sync and builds a block on top of an older block, or it produces the new block too late and the next proposer uses an earlier parent).
### Proposer effectiveness formula
We calculate proposer effectiveness simply as the ratio that expresses how many times a validator has successfully proposed a block out of the times that they were awarded proposer duties:
$$
\text{proposer\_effectiveness} = \frac{\text{non\_empty\_blocks} + \text{empty\_blocks} \times 0.25}{\text{total\_proposer\_slots\_attributed}}
$$
## Attester effectiveness
Validators are called to attest once in every epoch. These attestations are important consensus material. When attesting, validators vote on their version of the perceived state of the chain, which is described by a handful of distinct variables. These variables are also known as a validator's duties.
When validators perform their duties appropriately, they earn rewards; if they do not, they are penalized. The core duties that validators are called to perform are:
* Getting a vote (1) included; this is equivalent to submitting a[ Casper FFG](https://blog.ethereum.org/2020/02/12/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat), which makes the final decision on which blocks are and are not a part of the chain.
* Getting a (2) correct vote included. Correctness is described by:
* Head vote: submitting an attestation that correctly identifies the head of the chain, by[ GHOST](https://blog.ethereum.org/2020/02/12/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat) rules
* Target vote: submitting an attestation that correctly identifies the Casper FFG target checkpoint of the chain
* Getting a correct vote included (3) with minimal delay.
* Every validator is assigned a slot “n” to attest to in every epoch, and the earliest their vote could be included is on slot n+1. For every slot greater than n+1 that the vote gets included, the validator earns[ increasingly less rewards](https://www.attestant.io/posts/defining-attestation-effectiveness/).
### Attester effectiveness formula
There are two protocol upgrades that have affected the way attestation duties are evaluated on the consensus layer.
First is the Altair upgrade *(Slot 2375680)* which brought on a few significant changes in how rewards and penalties tied to attestation duties are distributed in the consensus layer. More specifically, the rules governing the timing of when the vote material gets included on-chain and rewards/penalties relationship have become stricter.
The second is the Dencun upgrade *(Slot 8626176)* which relaxed the rule on the timing of target votes.
In RAVER terms:
1. **Participation rate:** in order for an attestation to be included, the source vote must still be correct. There are now additional penalties for cases when the attestation does not get included in a timely manner; namely within sqrt(EPOCH\_LENGTH) or 5 slots. This however does not affect how we calculate participation.
2. **Correctness:** the target and head votes must not only be correct, but also need to be included in a timely manner; namely within EPOCH\_LENGTH or 32 slots and 1 slot respectively. After the Dencun upgrade, the timeliness criterion for target votes was removed. Regarding source vote lateness (by the above criteria), we also bundle this in the correctness calculation. In this case we look at events in a binary way (prompt, late) and do not modulate for "how late" in the calculation.
3. **Inclusion delay:** The concept of moderating rewards downwards the more delayed the attestations are is not valid any longer on its own accord, and is rather feeding directly into participation and correctness
We have updated the RAVER to reflect the new rules that underlie participation and correctness based on the slots on when they were applicable based on the timing of the protocol upgrades. However, we have not changed the way the overall attester effectiveness calculation is computed in the spirit of maintaining the design goals initially set.
$$
\text{attester\_effectiveness} = \frac{\text{participation\_rate} \cdot \text{correctness\_score}}{\text{aggregate\_inclusion\_delay}}
$$
The premise in the above calculation is that it equally and accurately captures all the important elements in evaluating how well a validator's consensus duties are being performed while at the same time shielding the methodology from unnecessary complexity.
### Sync committees
With the Altair Beacon Chain upgrade, a new role for validator nodes was introduced: attesting to sync committees. These are duties related to enabling light clients to validate the Beacon Chain’s state. A light client only needs to know a previously validated block header and members of the previous, current and next committee to verify the beacon state.
A sync committee is a group of 512 randomly selected validators, chosen anew every 256 epochs. This committee signs block headers for each new slot in the beacon chain so that a light client can trust these headers to represent accurate and validated blocks.
Granted the stochastic nature of sync committee selection and the low probability of a single validator to be selected in a sync committee set, we are not including sync committee performance in the[ ](https://docs.rated.network/documentation/methodologies/ethereum/rated-effectiveness-rating)RAVER.
## Effectiveness rating
In order to come up with a unified validator effectiveness score, we combine proposer and attester effectiveness in a weighted average. We attribute the following weights to each, guided by the longer term expectation of rewards distribution between the two duties:
* **Proposer effectiveness:** 3/8
* **Attester effectiveness:** 5/8
Post-Merge, proposal duties carry a lot more weight overall. This is not only because there is now a significant proportion of the overall yield that comes from successful proposals, but because missed proposals also mean delaying transaction processing for real users and billions of USD in value (EL), apart from not helping the chain progress (CL).
What we have observed thus far is that on-balance, execution to consensus layer rewards come at a 1:4 ratio. We expect that ratio to become even more balanced over time for the following reasons:
1. More active validators on the Beacon Chain crowd out CL APR%
2. More adoption of MEV Relays and out-of-protocol PBS boost overall EL APR%
Given the above, we introduce the following amendments to the weights of the effectiveness rating components, post-Merge:
* **Proposer effectiveness:** 1/8 → 3/8
* **Attester effectiveness:** 7/8 → 5/8
Such that the formula becomes:
$$
\text{validator\_effectiveness} = \left(\frac{3}{8} \times \text{proposer\_effectiveness}\right) + \left(\frac{5}{8} \times \text{attester\_effectiveness}\right)
$$
If a validator has not been assigned any proposer duties, we only take their attester effectiveness into consideration in calculating their effectiveness rating, such that `validator_effectiveness == attester_effectiveness`. We do this so that we do not artificially inflate the overall score.
## RAVER across time
The base unit of account in terms of time in the Rated DB is the “day”. What we have defined as “day” is the 24 hour increment post Beacon Chain genesis, which is further defined as X MANY epochs.
While Rated also produces an “hourly” effectiveness calculation (definition of the “hour” follows similar form to that of “day”) to power different features, the “day” is the main unit of account.
In order for the hourly and daily effectiveness of a given validator index to be computed, we aggregate the sum of duties a validator index has been allocated and apply the RAVER methodology, as outlined in the sections above.
Thereafter, in order to calculate validator effectiveness over periods that span multiple days (e.g. a month), we average across the “daily” effectiveness scores produced. This implies that for any given 30 day period, we would compute the RAVER off the sum of duties for the 30 discrete daily increments in that window, and then average across those.
$$
\text{multiday\_effectiveness} = \frac{\text{sum(daily\_effectiveness)}}{\text{number\_of\_days}}
$$
In version 3.1 of the RAVER, we are exploring transitioning to “per duty” fidelity. This implies that while the calculation would be the same, at the multi-day period level, the duties that make up attester and proposer effectiveness would be aggregated, and the completion rate of those duties would be computed in the aggregate, between two arbitrary epoch boundaries. This helps inject more robustness in accounting for varying times of validator index activation, and an easier to replicate methodology.
## RAVER at the operator level
As mentioned earlier in the documentation, the RAVER for Ethereum PoS is computed at the validator index level. In aggregating upwards to the operator level (defined as a group of validator indices), we simply compute the average RAVER of those keys, such that:
$$
\text{operator\_effectiveness} = \frac{\text{sum(validator\_effectiveness)}}{\text{number\_of\_indices}}
$$
While this produces a robust enough outcome and has clear benefits in the simplicity that it comes with, the approach was chosen for practical purposes and has been bound to some path dependency.
In version 3.1 of the RAVER, we are exploring transitioning to “per duty” fidelity, at the operator level. This implies that while the calculation would be the same, at the operator level, the duties that make up attester and proposer effectiveness would be aggregated, and the completion rate of those duties would be computed in the aggregate. This helps inject more robustness in accounting for varying times of validator index activation in a larger set.
***
*Content on this page is subject to License described in the* [*Content License*](https://legal.rated.network/licenses/raver-content-license)*.*
# Rating percentiles
Source: https://docs.rated.network/documentation/methodologies/ethereum/rating-percentiles
The methodology behind our calculation of percentile ranks in terms of Effectiveness.
The comparative placement of the entity’s [Rated Effectiveness Rating](/documentation/methodologies/ethereum/rated-effectiveness-rating/rated-effectiveness-rating.mdx) among their peers, going by different categories of aggregations. We are expressing the percentile score both in the tabular view (per pool, node operator, deposit address, or withdrawal address), as well as the main navigation with color coded dots (from deep red for lowest percentile rank to deep green for highest percentile rank).
Given we are ranking multiple entities on the front-end, we have separate tracks along which these percentiles are computed where relevant:
We are attributing percentile scores out of the available sample of validators, aggregated based on the pool that allocated the stake to these validators
We are attributing percentile scores out of the available sample of validators, aggregated based on the node operator running these validators
We are attributing percentile scores out of the available sample of validators, taking into account groups that appear to be operating more than 5 validators, and aggregated based on deposit addresses (to remove the noise from relatively small operations)
We are attributing percentile scores out of the available sample of validators, taking into account groups that appear to be operating more than 5 validators, and aggregated based on withdrawal addresses (to remove the noise from relatively small operations)
# Introduction to Methodologies
Source: https://docs.rated.network/documentation/methodologies/introduction-to-methodologies
Dive deeper into the methodologies that power some of the most important metrics exposed in the Rated Network Explorer and API.
Methodologies sit at the core of what we are working on at Rated.
Our mission is to promote transparency and good standards as they relate to improving the foundation of blockchains, so that they might eventually become the backbone of a new financial system, natively built on the Internet. But as we outlined in more depth in [Framing the problem](/documentation/getting-started/framing-the-problem), subjectivity is an insidious little demon that rears its ugly head more frequently than one might expect it to.
With our work on open and transparent methodologies, we set the foundation to collapse subjectivity and ultimately advance progress.
To discuss the various methodologies that Rated supports or propose changes to existing ones, head on over to the [**Rated Discord**](https://bit.ly/ratediscord).
## Design goals
We believe that a rating methodology for validator and operator performance, as well as all the adjacent methodologies that describe the various agents that make up Ethereum's consensus layer, should be described by the following principles:
To be as generalizable as possible
To be as easily understood as possible
To require as little adjustments after every upgrade as possible
To be as independent of the requirement for human action as possible
# Overview
Source: https://docs.rated.network/documentation/methodologies/solana/annual-percentage-yield-apy/annual-percentage-yield-apy
This section goes into our methodology in calculating the returns of validators and delegators on their stake.
## Sources of Rewards
There are two main sources of rewards in Solana: producing transaction blocks and voting for blocks (i.e. consensus participation)
### Proposing end-user transaction blocks
Validators are assigned to propose blocks (i.e. slot leaders). If they successfully produce blocks, they receive the base fees and priority fees from end-users and any MEV (maximum extractable value) they might extract. In terms of delegator rewards, validators do not share fees from block production to delegators. Meanwhile, MEV extracted through running the [Jito Labs client](https://www.jito.wtf/validators/) is shared with delegators based on the commission rate set by validators.
### Voting for blocks
As mentioned in [#voting-effectiveness](/documentation/methodologies/solana/solana-validator-effectiveness-rating/version-2.0-current#voting-effectiveness), validators are called to vote for every observed block that is on the correct fork. For every successful vote a validator casts, they receive one vote credit. These credits are multiplied by stake-weight to obtain points. After which, these points form the main basis for distributing the per-epoch inflation rate of the supply of the Solana token (SOL) that is given to validators.
Here is an example to illustrate:
* Total SOL supply: 560,382,222
* Annual inflation rate: 5.76%
* Epochs per year: 182.5 epochs
* Based on an ideal slot duration of 400 milliseconds or 48 hours per epoch and 365 days in a year
1. For a given epoch the total supply of SOL tokens is multiplied by the epoch inflation rate (we can call this absolute inflation):
$$
\text{absolute inflation} = \text{epoch inflation rate} \times \text{total supply} \\
= 0.000316 \times 560,382,222 \approx 177,080
$$
2. For each validator account epoch credits are multiplied by stake delegated to them to obtain each validator’s points
3. Each validator is awarded a share of absolute inflation based on their points
4. The share of inflation is paid to the stake accounts delegated to the validator pro-rata
5. The validator receives their commission into the vote account
Example for absolute inflation of 177,080 with three validators:
**TOTAL REWARDS**
| Delegator Stake | Validator | Credits | Points | Points % | Total Rewards |
| :-------------- | :--------------------------- | :------ | :-------------- | :------- | :------------ |
| 150 SOL | **A** - 350 SOL | 413,000 | 144,550,000 | 31.6% | **55,943** |
| 200 SOL | | | | | |
| 150 SOL | **B** - 350 SOL | 420,000 | 147,000,000 | 32.1% | **56,891** |
| 200 SOL | | | | | |
| 400 SOL | **C** - 400 SOL | 415,000 | 166,000,000 | 36.3% | **64,244** |
| **TOTAL** | | | **457,550,000** | **100%** | **177,080** |
**VALIDATOR AND DELEGATOR REWARDS**
| Delegator Stake | Validator | Total Rewards | Commission Rate | Commission Rewards | Delegator Rewards |
| :-------------- | :--------------------------- | :------------ | :-------------- | :----------------- | :---------------- |
| 150 SOL | **A** - 350 SOL | 55,943 | 10% | **5,594** | **21,578** |
| 200 SOL | | | | | **28,770** |
| 150 SOL | **B** - 350 SOL | 56,891 | 5% | **2,845** | **23,162** |
| 200 SOL | | | | | **30,884** |
| 400 SOL | **C** - 400 SOL | 64,244 | 5% | **3,212** | **61,032** |
| **TOTAL** | | **177,080** | | | |
From the above, we can see that validators **A** and **B** have the same stake-weight, however they have a different number of credits. As a result the delegators to validator **B** have earned higher pre-commission rewards.
In the next sections, we will go through the methodologies for computing the delegator APR and validator APR.
## Get going
The annual percentage yield (APY) for delegators in the network.
The annual percentage yield (APY) for validators in the network.
# Delegator APY%
Source: https://docs.rated.network/documentation/methodologies/solana/annual-percentage-yield-apy/delegator-apy
The methodology uses a rolling window calculation of total stake-weighted rewards based on the time periods (e.g. 3 days, 7 days, 30 days) calculated. Stake-weighted here means the daily rewards of delegators are divided by their delegated stake for the day. These stake-weighted rewards are then annualized over the given period. Delegator rewards are auto-compounded (except for MEV rewards through [Jito](https://explorer.jito.wtf/)).
$$
\text{APY}\% = \frac{\text{delegators rewards per stake in SOL} \times 365_{\text{d}} \times 24_{\text{h}} \times 60_{\text{m}} \times 60_{\text{s}}}{\text{time period in seconds}}
$$
In order to control for noise due to differing active delegation times, the APY% calculation ONLY takes into consideration delegators that have active delegations for the whole time window. On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
# Validator APY%
Source: https://docs.rated.network/documentation/methodologies/solana/annual-percentage-yield-apy/validator-apy
The validator APY calculation is conceptually the same as the Delegator APY% in terms of calculating and using stake-weighted rewards. Noise is also filtered out by only taking into account validators who have been active for the whole time window.
A validator’s total rewards take into account their commissions from voting rewards, block production fees (base fees and priority fees), and commissions from MEV extracted through [Jito](https://explorer.jito.wtf/) if applicable.
$$
\text{APY}\% = \frac{\text{validator's rewards per stake in SOL} \times 365_{\text{d}} \times 24_{\text{h}} \times 60_{\text{m}} \times 60_{\text{s}}}{\text{time period in seconds}}
$$
On the `1d` time period, the APY takes into account the rewards received for the last 3 days to smooth out the noise given Solana's staking rewards schedule, which is every epoch (\~2 days).
# Gini coefficient measurement
Source: https://docs.rated.network/documentation/methodologies/solana/gini-coefficient-measurement
This page details the approach Rated uses in computing this metric for the Solana network.
## Interpreting the Gini
A Gini coefficient of 0 reflects perfect equality, where all income or wealth values are the same, while a Gini coefficient of 1 (or 100%) reflects maximal inequality among values.
## Gini calculation
We first take the stake weight of each of the validators on the latest day and rank in descending order accordingly. We then use the 1-2B formula for measuring Gini, where B is the area under the Lorenz curve such that:
$$
1 - 2 \times \frac{\text{SUM}(\text{staked SOL} \times (\text{rank} - 1) + \text{staked SOL} / 2)}{\text{COUNT(validators)} \times \text{SUM}(\text{staked SOL})}
$$
![]()
### Function Components
$$
\text{staked SOL} \times (\text{rank} - 1)
$$
is the area of the rectangular horizontal slice under the Lorenz curve
$$
\frac{\text{staked SOL}}{2}
$$
is the area of the triangle on the left of the rectangular slice
$$
\text{SUM}(\text{staked SOL} \times (\text{rank} - 1) + \frac{\text{staked SOL}}{2})
$$
is the sum of all the slices
$$
\text{COUNT(validators)}
$$
normalizes the x axis to the range 0 to 1
$$
\text{SUM}(\text{staked SOL})
$$
normalizes the y axis to the range 0 to 1
$$
\text{SUM}(\text{staked SOL})
$$
# Overview
Source: https://docs.rated.network/documentation/methodologies/solana/solana
A series of resources regarding our work on rationalizing how we collectively measure the most important metrics relating to Solana.
## Quick start
In this section, we dive into the methodology that underlies the effectiveness rating of validator and operator performance on Solana.
This section discusses our approach in calculating the returns of validators and delegators on their stake.
This section details the approach Rated uses in computing this metric for the Solana network.
# Overview
Source: https://docs.rated.network/documentation/methodologies/solana/solana-validator-effectiveness-rating/solana-validator-effectiveness-rating
Methodology that underlies the effectiveness rating of validator and operator performance on Solana.
This effectiveness rating is a measure of how well a validator has been performing its rewarded duties over time.
It seeks to be a true measure of performance, attributing points to the validator for attributes of their onchain footprint that they have influence over (e.g. whether they are successfully voting for slots, which means they are actively participating in consensus), while dampening the effect of metrics that allow randomness to creep into the measurement (e.g. voting performance of other validators).
The Solana Effectiveness Rating is designed to work with the validator’s vote account as the base unit of account. What the metric effectively does is to tally up the duties that a validator is called to perform over a given time period (e.g. 2 epochs, a day, a year), and assign points to those instances when duties were completed successfully. The result is a percentage score that illustrates the job completion rate of a given validator vote account.
# Version 1.0
Source: https://docs.rated.network/documentation/methodologies/solana/solana-validator-effectiveness-rating/version-1.0
Applicable from `Epoch 0` to `Epoch 702`
## Components of Effectiveness
In the following sections, we examine those one-by-one and then synthesize them together in what constitutes the effectiveness rating.
### Proposer Effectiveness
Validators are expected to produce blocks of transactions. On Solana, the primary unit of time is an epoch which consists of 432,000 slots. Each slot has a target duration of around 400 milliseconds, which puts one epoch at 48 to 52 hours currently.
It is important to understand that in Solana, a slot presents an opportunity for a block to be produced by the selected leader (i.e. proposer) for that slot. A block is a batch of transactions produced by said leader. When blocks are not produced in slots, these slots are considered missed as the validator has failed to fulfill its duty to produce a block and advance the chain.
Another thing to note is that consensus messages by validators on Solana (i.e. votes) are propagated through transactions as well. These vote transactions are important when it comes to confirming the latest state of the chain, which we go deeper into in [Voting Effectiveness](#voting-effectiveness). Given these are transactions as well, it is entirely possible for proposers to build blocks only containing vote transactions. These are perfectly valid blocks however this means that no user transactions were confirmed/executed for the time being which degrades the experience of end-users, and arguably goes against the main purpose of the chain.
Given this, we attribute scores to a validator’s proposer effectiveness based on the following:
| Case | Block Produced | Score |
| :--- | :------------------------ | :---- |
| A.1 | Has end-user transactions | 1 |
| A.2 | Only vote transactions | 0.25 |
| B | Missed | 0 |
### Case A.1
In this case, a block was produced, containing both end-user and vote transactions, in which case a full point is given for the proposer effectiveness ratio.
### Case A.2
In this case, a block was produced but it only contains vote transactions (i.e. Vote Only Blocks). End-user transactions are not proposed which degrades the experience of the user.
### Case B
Lastly, in this case no block is produced and the proposer has completely missed their block production duty. This gets no point.
Thus we compute the proposer effectiveness for a validator as:
$$
\text{proposer effectiveness} = \\
\frac{\text{blocks with end-user and vote transactions} + (0.25 \times \text{blocks only with vote transactions})}{\text{total block production duties}}
$$
### Voting Effectiveness
Validators are called to vote for every observed block that is on the correct fork or what they perceive to be the correct state of the chain.
Forking occurs frequently on Solana due to the fast-paced nature of the network. When a validator is slow to produce a block X, the next validator may begin their allocated slot X+1 before it has received the previous block, therefore assuming it does not exist and building its block on top of the prior block X-1. This causes two competing forks both building on the ancestor X-1. The validator at X+2 will then determine which to continue building upon based on when it receives them. Most likely it will receive X first and continue on that and X+1 will end up being a dead fork and those slots will appear as skipped (i.e. missed).
A validator can only correctly vote for a slot with a block, and a confirmed fork means a slot that has more than ⅔ of stake voting on it. For every successful vote on a valid fork, the validator receives one credit which is used to compute the voting rewards at every epoch.
Using this information, we can then compute for the first component of voting effectiveness which is the voting success rate:
$$
\text{voting success rate} = \frac{\text{correct votes}}{\text{total number of confirmed blocks}}
$$
The second aspect of voting effectiveness is vote latency. As mentioned earlier, voting on Solana occurs through onchain transactions. The earliest a validator can vote for a slot is immediately the slot after and the latest they can do so is 512 slots after.
Vote latency is the slot distance between the slot being voted for and the slot where the vote transaction lands. While this does not directly impact the number of credits a validator receives (i.e. a correct vote will always get one credit), this impacts the speed of achieving consensus as it affects the time it takes to reach the ⅔ stake threshold needed to confirm a block.
There is also a system design proposal in Solana called [Timely Vote Credits](https://forum.solana.com/t/proposal-for-enabling-the-timely-vote-credits-mechanism-on-solana-mainnet/1179) which will modulate voting rewards based on latency. The proposal has passed an onchain governance vote, and is undergoing testing on Solana's testnet. Implementation to come soon on Solana mainnet-beta.
Given that the protocol has yet to fully penalize validators for vote latency, we have decided to not include this in the vote effectiveness calculation for now. Once the Timely Vote Credits feature has been enabled on mainnet-beta, we will modulate voting success rate accordingly using latency, as aligned with the protocol.
### Effectiveness Rating
In order to come up with a unified validator effectiveness score, we combine proposer effectiveness and voting effectiveness in a weighted average. We attribute the following weights to each component based on the distribution of rewards using the most recent data from Solana:
* Proposer Effectiveness: 30%
* Voting Effectiveness: 70%
Such that the formula becomes:
$$
\text{effectiveness} = (0.30 \times \text{proposer effectiveness}) + (0.70 \times \text{voting effectiveness})
$$
If a particular validator has not been assigned a particular duty for a given time period, we only take the effectiveness of whatever duty they were assigned with and had a chance to fulfil. Example is when a validator has not been assigned a block production duty for a given period. In this case, `effectiveness == voting effectiveness`.
We remain open to inputs from the community on how to best capture the effectiveness of a validator on Solana. Head on over to [our discord](https://bit.ly/ratediscord) to share your thoughts.
# Version 2.0 [current]
Source: https://docs.rated.network/documentation/methodologies/solana/solana-validator-effectiveness-rating/version-2.0-current
Applicable from after the implementation of Timely Vote Credits from `Epoch 703` (November 26, 2024) to present.
## Components of Effectiveness
In the following sections, we examine those one-by-one and then synthesize them together in what constitutes the effectiveness rating.
### Proposer Effectiveness
Validators are expected to produce blocks of transactions. On Solana, the primary unit of time is an epoch which consists of 432,000 slots. Each slot has a target duration of around 400 milliseconds, which puts one epoch at 48 to 52 hours currently.
It is important to understand that in Solana, a slot presents an opportunity for a block to be produced by the selected leader (i.e. proposer) for that slot. A block is a batch of transactions produced by said leader. When blocks are not produced in slots, these slots are considered missed as the validator has failed to fulfill its duty to produce a block and advance the chain.
Another thing to note is that consensus messages by validators on Solana (i.e. votes) are propagated through transactions as well. These vote transactions are important when it comes to confirming the latest state of the chain, which we go deeper into in [Voting Effectiveness](/documentation/methodologies/solana/solana-validator-effectiveness-rating/version-2.0-current#voting-effectiveness). Given these are transactions as well, it is entirely possible for proposers to build blocks only containing vote transactions. These are perfectly valid blocks however this means that no user transactions were confirmed/executed for the time being which degrades the experience of end-users, and arguably goes against the main purpose of the chain.
Given this, we attribute scores to a validator’s proposer effectiveness based on the following:
| Case | Block Produced | Score |
| :--- | :------------------------ | :---- |
| A.1 | Has end-user transactions | 1 |
| A.2 | Only vote transactions | 0.25 |
| B | Missed | 0 |
### Case A.1
In this case, a block was produced, containing both end-user and vote transactions, in which case a full point is given for the proposer effectiveness ratio.
### Case A.2
In this case, a block was produced but it only contains vote transactions (i.e. Vote Only Blocks). End-user transactions are not proposed which degrades the experience of the user.
### Case B
Lastly, in this case no block is produced and the proposer has completely missed their block production duty. This gets no point.
Thus we compute the proposer effectiveness for a validator as:
$$
\text{proposer effectiveness} = \\
\frac{\text{blocks with end-user and vote transactions} + (0.25 \times \text{blocks only with vote transactions})}{\text{total block production duties}}
$$
### Voting Effectiveness
Validators are called to vote for every observed block that is on the correct fork or what they perceive to be the correct state of the chain.
Forking occurs frequently on Solana due to the fast-paced nature of the network. When a validator is slow to produce a block X, the next validator may begin their allocated slot X+1 before it has received the previous block, therefore assuming it does not exist and building its block on top of the prior block X-1. This causes two competing forks both building on the ancestor X-1. The validator at X+2 will then determine which to continue building upon based on when it receives them. Most likely it will receive X first and continue on that and X+1 will end up being a dead fork and those slots will appear as skipped (i.e. missed).
A validator can only correctly vote for a slot with a block, and a confirmed fork means a slot that has more than ⅔ of stake voting on it. For every successful vote on a valid fork, the validator receives one credit which is used to compute the voting rewards at every epoch.
The second aspect of voting effectiveness is vote latency. As mentioned earlier, voting on Solana occurs through onchain transactions. The earliest a validator can vote for a slot is immediately the slot after and the latest they can do so is 512 slots after.
Vote latency is the slot distance between the slot being voted for and the slot where the vote transaction lands. This impacts the speed of achieving consensus as it affects the time it takes to reach the ⅔ stake threshold needed to confirm a block. To incentivize timeliness, the protocol rewards validators based on latency accordingly.
A validator that correctly votes within two (2) slots for the slot it is voting for will get the maximum 16 vote credits. For every slot that a validator delays its vote, it gets one (1) less vote credit, until such that it can only the minimum of one (1). This means that at 18 slots of worth of latency or more, as long as a validator's vote is correct and is no later than 512 slots, it gets the minimum vote credit.
As such we assign a `vote_score` for every correct vote based on the vote credits it receives. We then multiply the total number of confirmed blocks by `16` to get the maximum possible vote credits such that the voting effectiveness rating is:
$$
\text{voting effectiveness} = \frac{\text{vote\_score}}{\text{total number of confirmed blocks} \times 16}
$$
### Effectiveness Rating
In order to come up with a unified validator effectiveness score, we combine proposer effectiveness and voting effectiveness in a weighted average. We attribute the following weights to each component based on the distribution of rewards using the most recent data from Solana:
* Proposer Effectiveness: 30%
* Voting Effectiveness: 70%
Such that the formula becomes:
$$
\text{effectiveness} = (0.30 \times \text{proposer effectiveness}) + (0.70 \times \text{voting effectiveness})
$$
If a particular validator has not been assigned a particular duty for a given time period, we only take the effectiveness of whatever duty they were assigned with and had a chance to fulfil. Example is when a validator has not been assigned a block production duty for a given period. In this case, `effectiveness == voting effectiveness`.
We remain open to inputs from the community on how to best capture the effectiveness of a validator on Solana. Head on over to [our forum](https://feedback.rated.network/?b=65a68ac5cbfec0a42d492d9a) to share your thoughts.
# RAVER Content License
Source: https://docs.rated.network/legal/licenses/raver-content-license
Details around the CC license that governs the Rated Validators Effectiveness Rating.
The CC BY-NC-SA 4.0 International license is a Creative Commons license designed to promote the free sharing and adaptation of the RAVER. This license operates globally and grants users the freedom to copy, redistribute, remix, transform, and build upon the material in any medium or format.
You may use the content of the RAVER in any way that is consistent with the specific license that applies to the content, as described above, but we ask that you give proper attribution and use it for non commercial purposes only.
If you’d like to use the RAVER in a commercial setting, please contact us via [hello@rated.network](http://hello@rated.network).
Additionally, if you modify, transform, or build upon the RAVER, you must distribute your contributions under the same license as the original, ensuring that all derivative works share the same freedoms.
## Terms of Use
The RAVER is offered under a license that supports and encourages you to take, modify, reuse, repurpose, and remix the content according to your needs. For example, you could quote the text in a whitepaper, cut-and-paste sections to your blog, use it to advertise your operational excellence or even translate it.
We recommend that you follow the [Commercial vs Non Commercial Guidelines](#commercial-vs-noncommercial-guidelines) stated below to make a judgment on whether or not your use case is complying with the terms of the license.
### Commercial vs Noncommercial Guidelines
Please use these guidelines to help define the boundaries of commercial and non-commercial use of the RAVER, ensuring compliance with the intended use and licensing of the RAVER. Please note that the provided examples serve as guidelines and do not constitute an exhaustive list.
#### Examples of what might qualify as Non-Commercial use
* Leveraging the RAVER as a benchmark for service level agreements
* Using the RAVER to internally assess both your own and your network peers validator fleet performance
* Utilizing the RAVER for marketing purposes, as long as it's not the primary service offering
* Leveraging the RAVER for internal research and monitoring activities
* Quoting the RAVER in a whitepaper, advertisement or blog
#### Examples of what might qualify as Commercial use
* Employing the RAVER as the main service in a business
* Generating and selling data on effectiveness using RAVER
* Selling services or products based on effectiveness calculations derived from RAVER
As noted above, modifications or derivatives of RAVER content must be shared under the same CC BY-NC-SA 4.0 license, upholding the same usage freedoms.
### Attribution
Proper attribution is required when you reuse or create modified versions of content that appears on a page made available under the terms of the Creative Commons Attribution license. The complete requirements for attribution can be found in section 3a of the [Creative Commons legal code](https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.en).
### Exact Reproduction
If your work exactly reproduces text from the RAVER, in whole or in part, please include a paragraph at the bottom of your page that reads:
Portions of this page are reproduced from work created and [shared by the Rated Effectiveness Rating (RAVER)](/documentation/methodologies/ethereum/rated-effectiveness-rating) and used according to terms described in the [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License ](https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.en)\[CC BY-NC-SA 4.0].
Also, please link back to the original source page so that readers can refer there for more information.
### Modified versions
If your work shows modified content from the RAVER, please include a paragraph at the bottom of your page that reads:
Portions of this page are modifications based on work created and [shared by the Rated Effectiveness Rating (RAVER)](/documentation/methodologies/ethereum/rated-effectiveness-rating) and used according to terms described in the [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.en) \[CC BY-NC-SA 4.0].
Again, please link back to the original source page so that readers can refer there for more information. This is even more important when the content has been modified.
# Privacy Notice
Source: https://docs.rated.network/legal/privacy/privacy-notice
*Rated Labs is committed to protecting your privacy. This Privacy Notice ("Notice"), together with our website terms of use and any other documents referred to in it, sets out the types of personal information we collect, how we collect and process that information, who we share it with in relation to the services we provide and certain rights and options that you have in this respect.*
Rated Labs owns and operates this website rated.network (“site”).
### **Who is responsible for your personal data?**
Rated Labs is responsible for your personal data. Rated Labs comprises Rated Labs Limited (a limited company incorporated in England & Wales, registered number 14036060) (referred to as "Rated Labs" or "we" or "our"). For the purposes of applicable data protection law (in particular, the General Data Protection Regulation (EU) 2016/679 (the "GDPR") as applicable as part of UK domestic law by virtue of section 3 of the European Union (Withdrawal) Act 2018 and as amended by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (as amended) (“UK GDPR”)), your data will be controlled by the Rated Labs as the independent data controller of your personal data. This Notice applies to all sites that operate under Rated Labs sites.
### **Personal data we collect**
We (might) collect and process the following personal data from you, where these apply:
* **Identity and Contact Data**, including your name, email address, and other personal data concerning your preferences relevant to our services.
* **Profile and Usage Data**, including user credentials, passwords to Rated Labs websites or password protected platforms or services, your preferences in receiving marketing information from us, your communication preferences and information about how you use our websites(s), including the services you viewed or searched for, page response times, download errors, length of visits and page interaction information (such as scrolling, clicks, and mouse-overs). To learn more about our use of cookies or similar technology please see the “What cookies do we use and what information do they collect?” section below.
* **Technical Data**, including information collected during your visits to our website(s), the Internet Protocol (IP) address, login data, browser type and version, device type, time zone setting, browser plug-in types and versions, operating system and platform. To learn more about our use of cookies or similar technology please see the “What cookies do we use and what information do they collect?” section below.
### **Information about other people**
If you provide information to us about any person other than yourself, your employees, counterparties, your advisers or your suppliers, you must ensure that they understand how their information will be used, and that they have given their permission for you to disclose it to us and for you to allow us, and our outsourced service providers, to use it.
### **How do we collect your personal data?**
The circumstances in which we can collect personal data about you include:
* when you or your organisation use our services or use any of our online services;
* when you or your organisation offer to provide, or provides, services to us;
* when you correspond with us by email or other electronic means, or in writing, or when you provide other information directly to us, including in conversation with our staff;
* when you or your organisation browse, complete a form or make an enquiry or otherwise interact on our website or other online platforms;
* when you attend our events or sign up to receive information from us;
* We may use cookies on our website and to provide the services. Cookies are tiny data files placed on your device that contain a unique identifier that identify your browser. Cookies allow us to collect information about you as a user, to improve our platform, store preferences and settings, and help with sign-in. While you can manage cookies in your Account’s preferences setting, if you disable cookies, you may not be able to use or access some or all of the Services.
* Our web pages may contain electronic images known as web beacons (also called single- pixel gifs) that we use to help deliver cookies on our websites and to count users who have visited those websites. We may also include web beacons in our promotional email messages or newsletters to determine whether and when you open and act on them. When we talk about cookies in this Notice, this term includes these similar technologies.
### **What cookies do we use and what information do they collect?**
* **Necessary cookies:** these cookies are required to enable core functionality. Without these cookies, services you have asked for cannot be provided. If you disable these cookies certain parts of the Services will not function for you.
* **Analytics cookies:** these cookies help us improve or optimise the experience we provide. They allow us to measure how visitors interact with the Services and we use this information to improve the user experience and performance of our website and the Services. These cookies are used to collect technical information such as the number of pages visited, which parts of our website are clicked on and the length of time between clicks.
* **Functional cookies:** We may use cookies that are not essential but enable various helpful features on the Site. For example, these cookies collect information about your interaction with services provided on the Site.
We keep information collected from cookies for a maximum of 6 months.
### **If you fail to provide personal data**
Where we need to collect personal data by law or in order to process your instructions or perform a contract we have with you and you fail to provide that data when requested, we may not be able to carry out your instructions or perform the contract we have or are trying to enter into with you. In this case, we may have to cancel our engagement or contract you have with us, but we will notify you if this is the case at the time.
### How will we use your personal data?
We use your personal data only for the following purposes:
* To fulfil a contract, or take steps linked to a contract, with you or your organisation. This includes:
* to register you as a user of Rated Labs and grant you access to the Rated APIs via the site; and
* to provide and administer services as instructed by you or your organisation.
* As required by Rated Labs to conduct our business and pursue our legitimate interests, in particular:
* to administer and manage our relationship with you, including accounting, auditing, and taking other steps linked to the performance of our business relationship including identifying persons authorised to represent our customers, suppliers or service providers;
* to analyse and improve our services and communications, monitor user numbers and to monitor compliance with our policies and standards;
* to protect the security of our communications and other systems and to prevent and detect security threats, frauds or other criminal or malicious activities;
* to exercise or defend our legal rights or to comply with court orders;
* to communicate with you to keep you up-to-date on the latest developments, announcements, and other information about our services and solutions (including briefings, newsletters and other information), events and initiatives;
* to send you details of client surveys, marketing campaigns, market analysis, or other promotional activities; and
* to collect information about your preferences to personalise and improve the quality of our communications with you.
* For purposes required by law, including maintaining records, compliance checks or screening and recording (e.g. fraud and crime prevention and detection, trade sanctions and embargo laws). This can include making records of our communications with you for compliance purposes.
* With your consent, we may use your data to manage your email subscriptions, improve the relevance of our website, send you periodic marketing communications about the services we provide, invite you to participate in contests, promotions, surveys or other features of the services and to improve the relevance of our advertising.
We will not use your personal data for taking any automated decisions affecting or creating profiles other than as described above.
### Disclosure of your personal data
We may share your personal data, in the following circumstances:
* with our affiliates for the purposes of providing you with our services as described in this Notice;
* with third parties including certain service providers we have retained in connection with the services we provide;
* on a confidential basis with third parties for the purposes of collecting your feedback on the company’s service provision, to help us measure our performance and to improve and promote our services;
* with courts, law enforcement authorities, regulators, government officials or attorneys or other parties where it is reasonably necessary for the establishment, exercise or defence of a legal or equitable claim, or for the purposes of a confidential alternative dispute resolution process;
* with service providers who we engage within or outside of Rated Labs, domestically or abroad, e.g. shared service centres, to process personal data for any of the purposes listed above on our behalf and in accordance with our instructions only; and
* if we sell or buy any business or assets, in which case we may disclose your personal data to the prospective seller or buyer of such business or assets to whom we assign or novate any of our rights and obligations.
### Information we transfer
When we transfer your information to other countries, we will use, share and safeguard that information as described in this Notice. To provide our services, we may transfer the personal information we collect to countries outside of the EEA and UK which do not provide the same level of data protection as the country in which you reside and are not recognised by the European Commission or UK Information Commissioner as providing an adequate level of data protection. We only transfer personal information to these countries when it is necessary for the services we provide you, or it is necessary for the establishment, exercise or defence of legal claims or subject to safeguards that assure the protection of your personal information, such as European Commission approved standard contractual clauses or the Information Commissioner approved International Data Transfer Agreement or Addendum.
Rated Labs ensures a level of data protection at least as protective as that required in the European Economic Area and United Kingdom.
For further information, including obtaining a copy of the documents used to protect your information, please contact us on [hello@rated.network](mailto:hello@rated.network).
### Security of your personal data
We have put in place appropriate security measures to prevent your personal data from being accidentally lost, used or accessed in an unauthorised way, altered or disclosed. We have also put in place procedures to deal with any suspected personal data breach and will notify you and any applicable regulator of a breach where we are legally required to do so.
### Updating personal data about you
If any of the personal data that you have provided to us changes, for example if you change your email address or if you wish to cancel any request you have made of us, or if you become aware we have any inaccurate personal data about you, please let us know by sending an email to [hello@rated.network](mailto:hello@rated.network). We will not be responsible for any losses arising from any inaccurate, inauthentic, deficient or incomplete personal data that you provide to us.
### Your Rights
You have various rights with respect to our use of your personal data:
* Access: You have the right to request a copy of the personal data that we hold about you. There are exceptions to this right, so that access may be denied if, for example, making the information available to you would reveal personal data about another person, or if we are legally prevented from disclosing such information. You are entitled to see the personal data held about you. If you wish to do this, please contact us using the contact details provided below.
* Accuracy: We aim to keep your personal data accurate, current, and complete. We encourage you to contact us to let us know if any of your personal data is not accurate or changes, so that we can keep your personal data up-to-date.
* Objecting: In certain circumstances, you also have the right to object to processing of your personal data and to ask us to block, erase and restrict your personal data. If you would like us to stop using your personal data, please contact us.
* Porting: You have the right to request that some of your personal data is provided to you, or to another data controller, in a commonly used, machine-readable format.
* Erasure: You have the right to ask us to erase your personal data when the personal data is no longer necessary for the purposes for which it was collected, or when, among other things, your personal data have been unlawfully processed.
* Complaints: If you believe that your data protection rights may have been breached, you have the right to lodge a complaint with the applicable supervisory authority, or to seek a remedy through the courts.
You may, at any time, exercise any of the above rights, by contacting [hello@rated.network](mailto:hello@rated.network).
### Right to withdraw consent
If you have provided your consent to the collection, processing and transfer of your personal data, you have the right to fully or partly withdraw your consent. Once we have received notification that you have withdrawn your consent, we will no longer process your information for the purpose(s) to which you originally consented unless there is another legal ground for the processing.
To opt-out of receiving our marketing communications t please follow the opt-out links on any marketing message sent to you or contact [hello@rated.network](mailto:hello@rated.network). Opting out of receiving marketing communications will not affect the processing of personal data for the provision of our services.
### How long we keep your personal data
We will only retain your personal data for as long as necessary to fulfil the purposes we collected it for, including for the purposes of satisfying any legal, accounting, or reporting requirements and, where required for Rated Labs to assert or defend against legal claims, until the end of the relevant retention period or until the claims in question have been settled. If you want to learn more about our specific retention periods for your personal data established in our retention policy you may contact us at [hello@rated.network](mailto:hello@rated.network). Upon expiry of the applicable retention period we will securely destroy your personal data in accordance with applicable laws and regulations.
### Changes to our Privacy Notice
We reserve the right to update and change this Notice from time to time in order to reflect any changes to the way in which we process your personal data or changing legal requirements. Any changes we may make to our Notice in the future will be posted on this page and, where appropriate, notified to you by email. Please check back frequently to see any updates or changes to our Notice.
### Contact Details
Questions, comments and requests regarding this Notice are welcomed and should be addressed to [hello@rated.network](mailto:hello@rated.network), or send a letter to Rated Labs Limited, 12 New Fetter Lane, London EC4A 1JP.
# API Terms of Service
Source: https://docs.rated.network/legal/terms/api-terms-of-service
Date of last update: `Feb 13, 2024`
These Terms of Service are effective for all Rated API customers from **13 February 2024** onwards. Previous version of the ‘API Terms of Service’ can be found at the [end](#document-history) of this page.
**RATED'S API USE IS SUBJECT TO THE FOLLOWING TERMS AND CONDITIONS. PLEASE READ THESE TERMS AND CONDITIONS CAREFULLY.**
**BY ACCESSING OR USING OUR API SERVICES, YOU AGREE TO BE BOUND BY THESE TERMS AND CONDITIONS AND ALL TERMS INCORPORATED BY REFERENCE, WHICH CONSTITUTE PART OF RATED'S API TERMS OF SERVICE.**
These Terms of Service and any terms expressly incorporated herein ("Terms") apply to your access and use of our API (Application Program Interface) Services, associated software, API Data, API Tools, and any information or content therein (collectively, "API Services" or "Services"). These services are provided by Rated Labs Ltd and its affiliates (referred to herein as "Rated," "Company," "we," "our," or "us"). Your use of our API Services is contingent upon your acceptance of and compliance with these Terms.
We reserve the right to revise, update, amend, or modify these Terms at any time. We will post the updated Terms on our websites. We will also email you via the email address supplied as part of the sign-up process to notify you of material changes to these Terms. We encourage you to review these Terms periodically to ensure you are aware of any changes. By continuing to use the API Services after these changes take effect, you agree to be bound by the revised Terms.
### **1. DEFINITIONS**
**"Customer," "you,"** and **"your"** means the business customer entity named in the order form for the API Service.
**"Customer Users"** means the Customer employees and contractors who use the API Service;
**"Subscription"** means either the Free tier, Starter tier, Build tier, or Growth tier subscription for using the API Service (commercial details of which are set out on the Rated website) which the Customer signs up to and which are governed by these Terms. For details on the features and limits of each tier, please see [Plans - api-docs.rated.network](https://api-docs.rated.network/pricing/plans)
**"API Call"** means a single request made by a Customer User to the Rated API to retrieve, send or manipulate data. Each API Call costs one or more Compute Units and is subject to the feature limits and restrictions set out in your Subscription plan and this Agreement.
**"API Key"** means the credentials Rated provides to the Customer, enabling the Customer and Customer Users to use and interact with the API.
**"API Data"** means all data published or made available through the API, along with any related metadata;
**"API Limits"** means the usage and feature restrictions, and maximum number of Compute Units (limit) set out in the Subscription plan tier the Customer signs up for.
**“Compute Units”** are the metric reflecting the computational resources utilised by each API request (for more information on this metric please see: [Compute Units](/rated-api/pricing/compute-units))
**"Confidential Information"** shall mean any non-public information disclosed by either party ("Disclosing Party") to the other party ("Receiving Party"), either directly or indirectly, in writing, orally, or by inspection of tangible objects (including, without limitation, software, API keys, documentation, business plans, data, scientific formulas, proprietary algorithms, prototypes, samples, plans, and customer lists), which is designated as "Confidential," "Proprietary," or some similar designation, or learned by the Receiving Party under circumstances in which such information would reasonably be understood to be confidential. For the avoidance of doubt, Confidential Information shall not include any information that:
1. is or becomes generally available to the public without breach of any obligation owed to the Disclosing Party.
2. was known to the Receiving Party before its disclosure by the Disclosing Party without breach of any obligation owed to the Disclosing Party.
3. is received from a third party without breach of any obligation owed to the Disclosing Party.
4. was independently developed by the Receiving Party without use or reference to the Disclosing Party's Confidential Information.
**"Terms"** means these terms and conditions.
### 2. ELIGIBILITY FOR BUSINESS USERS ONLY
Our API Services are made available to business customers on a Subscription basis. You should not sign up to, use or pay for these services if you act as an individual consumer.
By signing up for a Subscription to use our API Services, the individual confirms that they are a Customer representative and that the Customer authorises them to act on its behalf and bind it to the terms of a Subscription and these Terms.
### 3. GRANT OF LICENCE & USE OF API
When the Customer signs up for a Subscription to use the API Service, they can subscribe to different tiers (currently either Free, Starter, Build or Growth). You must ensure that the applicable tier is suitable for your intended use.
We provide you only with a limited licence to use our API Data under these Terms based on your Subscription tier. Please also take the time to review and understand the prohibited activities set out in clause 14.
In consideration of you and each of your Customer Users adhering to the terms of your Subscription, these Terms and payment of all Fees under your Subscription plan tier, we will grant the Customer a limited, non-exclusive, non-assignable, non-transferable licence, for the duration of a Subscription, for the Customer's Users to access and use the API Services via the API Key and solely for the Customer to:
* develop, test, and support any software application, website, service, or product intended for software integration with the Customer's applications;
* making API Calls in compliance with the API Limits and features set out in their Subscription plan;
* to display, view, print, download, cache and copy the API Data received from the API for your own internal business use purposes only (but with no rights to use the API Data in any commercially released or third party use scenario or outside of your own business).
However, no licences or permissions are granted by Rated under any Subscription tier for you to resell, license or paywall the API Data as a separate product. In the event of any disagreement between you and Rated whether your use of the API Data is a core offering in your application, our decision will be final.
You are responsible for ensuring that the Customer Users are aware of and comply with the obligations set out in these Terms.
**Reservation of rights:**
All intellectual property rights in the API Services are owned by or licensed to Rated. These works are safeguarded by copyright laws and treaties across the globe. All such rights are expressly reserved.
You acknowledge that all API Data accessed via the relevant API Services and all intellectual property rights existing in such content are the property of Rated. You are not granted any rights to use any of our intellectual property rights (including rights in the relevant API Services or API Data), except as expressly stipulated in these Terms.
No other rights, titles, interests, ownerships, or properties of any kind shall be transferred to you due to your use of the content. To avoid doubt, should you create any inventions incorporating our API Data, this will not transfer any ownership rights, titles or interests in the API Data to you, even though you are the legal owner of such an invention.
Please note that the creation of white-labelled applications is subject to separate explicit written permission from Rated and contingent upon entering an applicable subscription model and paying the corresponding licence fees to Rated. Please get in touch with us at [hello@rated.network](emailto:hello@rated.network) for further information.
### 4. ACCOUNT REGISTRATION
To access the API Services, you must create an online Customer account ("Account") with Rated. We may require additional verification before we allow you to open an Account, including necessary due diligence checks.
When creating an Account, you must:
* generate a strong and unique password;
* provide accurate, complete, and current information about the business customer;
* promptly update your Account information whenever necessary if there are any changes to the information you provide us;
It is your responsibility to maintain the security of your Account by safeguarding your Account password and limiting access to your Account within your organisation.
You must promptly notify us if you discover or suspect any security breaches related to your Account.
Rated will assign your Customer profile with a unique account identifier, which you must retain to access your Account.
Customer Admins may set up and grant individual Customer Users access to the Customer's Rated portal and to use the API Service through the Customer's API Key.
### 5. API KEY AND API CALLS
All usage of the API Service is subject to API Limits and the features of your Subscription plan.
To use the API Service, the Customer must obtain an API Key through the account registration.
You must not share the API Key with any third party other than your authorised Customer Users and must keep the API Key and all log-in information secure.
You must use the API Key as the sole means of accessing the API, and we may invalidate the current API key and issue a new one at any time on notice to the Customer.
You must limit your API Calls to the API Limit and features set out in your Subscription Plan. Rated's calculation of the number of API Calls made under your Account will be final unless there is an obvious error or fraud.
If your Account’s use of the API Service exceeds the API Limit or meets the feature limits of the Subscription plan - we may temporarily or permanently limit your use of the API Service and/or we may charge additional fees to reflect the number of API Calls being made – and to revise your future monthly payments to reflect the further use.
### 6. CUSTOMER OBLIGATIONS
You shall:
* ensure that the number of Customer Users does not exceed any limits of users specified by Rated from time to time;
* comply with all applicable laws and regulations concerning its activities under these Terms (and without affecting its obligations).
You are responsible and liable for all uses of the API Service resulting from access provided by you to your Account, directly or indirectly, or whether such access or use is permitted by or in breach of these Terms, including with use with any application or third-party software.
Any act or omission by a Customer User or third party using the Customer's API Key that would constitute a breach of these Terms, if taken by the Customer, will be deemed a breach of these Terms by the Customer.
Without limitation, the Customer is responsible for all acts and omissions of Customer Users concerning their use of the API Service and API Data. This includes being accountable for any usage of our API Services within the Account profile and the costs incurred.
### 7. MONITORING OF USE
We monitor how our API Service is accessed and used, including through analytics code within our API Service.
We also collect basic information about a user as part of the account creation process as set out in our Privacy Policy.
To ensure that our API Service is being used in accordance with our Terms, we track the use of the API Service at a user level.
The data we collect through this monitoring allows us to link the information with a Customer User and the API Service.
### 8. API SUPPORT & API SERVICE AVAILABILITY
You are responsible for reviewing the API Documentation and ensuring you understand how to use the API Service.
Any support provided by Rated will be at our discretion and by way of wikis on the Rated website or through our Discord channel. All help is provided on an 'as is' basis only.
Rated will make the API Service available for use in accordance with the API Documentation; however, Rated may modify the API Service from time to time, and we will provide you with reasonable notice of any significant modifications.
Rated will use its reasonable endeavours to make the API Service available and operational at all times; however, Rated does not guarantee or provide any warranty concerning its availability or performance.
Rated will use its reasonable endeavours to remedy any failure or unavailability of the API Service that may arise.
### 9. PAYMENT TERMS
You agree that we may charge all amounts due and payable for the API Services, including service fees, setup fees, subscription fees, or any other applicable fees, taxes, or charges associated with your Account to your credit card or any other payment mechanism selected by you and approved by us during the Account creation process.
You bear responsibility for any charges related to bank transfers, currency conversion losses, and administrative fees associated with making payments for the API Services. You are also responsible for all tax obligations, including, but not limited to, service tax, withholding tax, goods and services tax (GST), value-added tax (VAT), and any other applicable levies. We shall provide you with an invoice for any GST, VAT or similar taxes where applicable.
The fees for the API Services ("Fees") will be specified in your Rated Account and on our site and are stated exclusive of tax. In the case of any error on our website, we may immediately correct and update any Fees, and you will, at our discretion, be invoiced for the correct Fees.
All Fees must be paid by you in full, without set-off or deduction.
We may change our subscription prices at our discretion, including for API Services previously offered free of charge. We will provide you with prior notice by email to the address used in the Account creation process of any price changes and an opportunity to cancel your Subscription if the price of a subscribed API Service changes. If you do not cancel your Subscription within the notice period, you will be deemed to have accepted the price increase and agree to pay the revised Fees.
### 10. ADDITIONAL CHARGES
Additional charges and terms may apply if you require additional services (such as extended rate limits, additional compute units, dedicated maintenance and support services or others) beyond the scope of the standard API Services as laid out on our website.
### 11. CANCELLING YOUR SUBSCRIPTION
You may cancel your Subscription at any time. If you choose to cancel your Subscription, please note:
(a) payments already made are non-refundable, and we do not provide refunds or credits for partially used API Services and
(b) you will not be billed for additional/renewal subscription terms, but the API Services will continue until the end of the current subscription term, whether or not you choose to use the API Services.
To avoid being charged for the next subscription period, you must cancel your Subscription before the next billing date. If you have subscribed to API Services for a specific term, its termination will only be effective at the end of the then-current term, and you will have access to the paid API Services until the end of your billing period.
To cancel your Subscription, you must use the cancellation feature in your Account via the billing portal on the Rated console.
**All payments made are final and non-refundable.**
Where applicable, the billing portal may indicate an auto-renewal date for subscriptions that will automatically renew after the initial subscription term unless cancelled before the start of the next period.
You are responsible for managing your Subscription and cancelling it before the renewal date. Rated shall not be held liable for any damages, losses, or expenses arising from your failure to cancel your Subscription.
### 12. SUSPENSION OR CANCELLATION OF YOUR ACCOUNT BY RATED
We reserve the right to suspend or immediately cancel your Subscription and use of the API Services if we reasonably believe that your Subscription or use of the API Service may be contrary to these Terms, or fraudulent, illegal or involves any criminal or immoral activity.
The suspension shall be for a period as we, at our discretion, determine necessary to investigate the matter and shall be lifted if we are satisfied that you have not breached these Terms or are not involved in any fraudulent, illegal, criminal or immoral activity. In such an event, you shall not be entitled to any pro-rata refund or hold us liable for any withholding of, delay in, suspension, forfeiture or cancellation of any payments. However, we may grant an extension of time on the contractual term accounting for the suspended periods, assessed on a case-by-case basis.
### 13. DOWNGRADE OF SUBSCRIPTION FOR FAILURE TO MAKE PAYMENT
If you fail to make any payment in accordance with these Terms, we reserve the right (without prejudice to our other rights and remedies) to downgrade your Account to the free tier (as outlined [Plans](/rated-api/pricing/plans)) until you make the due payment in accordance with these Terms.
### 14. PROHIBITED ACTIVITIES
In addition to the limitations of use set out in clause 3 (Grant of Licence), the following limits also apply as set out in clause 14:
When accessing or using the API Services, you agree that you will not, and nor will you permit or authorise any person to use the API Services to violate any law, contract, intellectual property, or other third-party right.
**You are responsible for all conduct under your Account.**
Our performance under these Terms is subject to existing laws and legal processes, and nothing contained in these Terms shall limit our rights to comply with law enforcement or other governmental or legal requests relating to your use of our API Services. You agree not to:
* Duplicate, modify, or replicate our API Data, information, text, audio, video, images, software (including machine images), or other documentation and resources retrieved or made available through our API Service or any related content ("API Content");
* Use our API Content or any other content to develop any software service that directly competes with any of our services;
* Alter any API Content or related content for resale to a third party;
* Sell, trade, rent, loan, lease, licence, or provide our API Content or access to our service for commercial purposes;
* Reverse engineer or decompile any aspect of the API Content or related software;
* Use the API Services in a manner that is malicious, harmful, or detrimental to us or any third party;
* Send automated requests to the API in a manner that exceeds reasonable usage;
* Misrepresent your identity or the nature of your usage of the API Content;
* Use the API Services in connection with any illegal activities, such as hacking, phishing, or spamming;
* Engage in any data mining or data scraping that interferes with our website or affiliated websites;
* Attempt to bypass any security measures we have implemented; and
* Use screen-scrapers, hacks, spiders, robots, viruses, worms, or any other tools to access, attack, or interfere with our API Services or affiliated API Services.
### 15. USAGE OF 'POWERED BY RATED' BADGE
If you are not a licensed user of our API Services but want to incorporate the API Content into your business applications, you must secure explicit written consent from Rated before proceeding.
Following the receipt of such consent, you are required to visibly display the '[Powered by Rated'](https://docs.rated.network/brand-resources/rated-brand-guidelines#powered-by-rated-badge) badge on your application in a clear and easily identifiable manner to users and as a condition of us granting the consent.
Failure to adhere to these requirements, and without limiting our rights and remedies, may result in the immediate suspension, obstruction, restriction, or termination of your access to API Services without any prior notice or liability to you.
### 16. IMPROVEMENTS TO THE API SERVICE
We shall retain a royalty-free, worldwide, transferable, sub-licensable, irrevocable, perpetual licence to use or incorporate any enhancement requests or feedback you provide into the API Services, the site, and the API Content. We are under no obligation to implement any such enhancement requests or feedback.
### 17. DISCLAIMERS
API Content provided by Rated should not be construed as an endorsement or recommendation of any specific blockchain, protocol operating on a blockchain, or node operators. Our API Services and Content are solely intended for general informational purposes. They do not comprise regulated advice or recommendations upon which you should rely. It is your responsibility to ensure that our API Service results fit your intended purpose.
While Rated endeavours to ensure the availability of API Services 24/7, subject to your compliance with the Terms, we offer no representation, warranty, or undertaking that the API Services or API Content will be uninterrupted or error-free. Rated disclaims all liability for any inaccuracies related to the API Services or Content, does not guarantee the completeness of API Services or Content, and makes no assertions regarding the compatibility of API Services or Content with any software, service, system, data, or information.
To the fullest extent permissible by law, Rated bears no liability for any:
* Errors or inaccuracies within the API Services or Content;
* Unauthorised access to or use of our servers;
* Interruption in the transmission of API Services;
* Bugs, viruses, or Trojan horses transmitted to or through the API Services by any third party;
* Errors or omissions in the API Content, or for any loss or damage sustained as a result of using any posted API Content;
* Internet connection failures; and
* Illegal conduct by any third party.
Except as expressly and specifically provided in these Terms:
(a)the Customer assumes sole responsibility for results obtained from the API Service, API Content and the API Data by the Customer and Customer Users, and conclusions drawn from such use.
(b) Rated shall have no liability for any damage caused by errors or omissions in any information, instructions or scripts provided to it by the Customer in connection with the API or any actions taken by Rated at the Customer's direction;
(c)all warranties, representations, conditions and all other terms of any kind whatsoever implied by statute or common law are, to the fullest extent permitted by applicable law, excluded from this agreement;
(d) and the API Service, API Content and the API Data are provided to the Customer on an "as is" basis.
By using our API Service, you agree to assume the risks of utilising internet-based services.
Without limiting our remedies under the law, any violation or suspected violation of the Terms may result in the immediate suspension, restriction, or termination of your access to our API Services without any prior notice or liability to you.
### 18. LIMITATION OF LIABILITY
Except as expressly stated in these Terms:
Rated shall not in any circumstances have any liability for any losses or damages which may be suffered by the Customer (or any person claiming under or through the Customer) or Customer Users, whether the same are suffered directly or indirectly or are immediate or consequential, and whether the same arise in contract, tort (including negligence) or otherwise howsoever, which fall within any of the following categories:
* special damage even if Rated was aware of the circumstances in which such special damage could arise;
* loss of profits;
* loss of anticipated savings;
* loss of business opportunity;
* loss of goodwill;
* loss or corruption of data,
provided that this section shall not prevent claims for loss of or damage to the Customer's tangible property that fall within the liability limits set out below or any other claims for direct financial loss that are not excluded by any of the categories above.
The total liability of Rated, whether in contract, tort (including negligence) or otherwise and whether in connection with this Agreement or any collateral contract, shall in no circumstances exceed a sum equal to the total Fees paid by the Customer during the \[1] month preceding the date on which the claim arose.
### 19. CONFIDENTIALITY & PUBLICITY
Each party agrees to keep confidential all Confidential Information, whether written or oral, that it has received or obtained from the other or may receive or get from the other and shall not use the same without the prior written consent of the disclosing party for any purpose except as expressly permitted under this Agreement. This obligation will not apply to any disclosure required by law or information in the public domain (other than because of a breach of any confidentiality obligation).
Rated shall be entitled to reference the Customer as an API user in Rated's general marketing literature, including on the Rated website and other online platforms. The reference to the Customer for these purposes may include a reference to and use of the Customer's corporate name and any of its trade names and trademarks.
### 20. NON COMPETITION
By accessing and using our API Services and API Content, then to the fullest extent permissible by law, you agree not to use our API Services to develop, create, or offer any software services that directly compete with our offerings, including but not limited to our Explorer and Oracle. This non-competition clause is applicable during your use of our API Services.
### 21. INDEMNITY
Upon utilising our API Services, you agree to indemnify, defend, and hold harmless Rated, its shareholders, directors, officers, employees, representatives, agents, subcontractors, and licensors from and against all third-party claims, damages, costs, expenses, and legal actions, including reasonable attorneys' fees and court costs, that arise out of or result from your misuse of our API Services or your violation of these Terms.
### 22. PRIVACY POLICY
We are committed to protecting your privacy.
Our [Privacy Policy](/privacy/privacy-notice), incorporated herein by reference, governs the collection, processing, storage and transfer of your personal data. By using our API Services, you acknowledge that you have read, understood, and agree to the terms of our Privacy Policy.
Our Privacy Policy also describes your choices regarding our use of your personal data and how you can access, update, and manage this information. We encourage you to periodically review our Privacy Policy to stay informed about our privacy practices.
### 23. EXPORT
Neither party shall export, directly or indirectly, any technical data acquired from the other party under this agreement (or any products, including software, incorporating any such data) in breach of any applicable laws or regulations (**Export Control Laws**), including United States export laws and regulations, to any country for which the government or any agency thereof at the time of export requires an export licence or other governmental approval without first obtaining such licence or approval.
### 24. SEVERABILITY
Should any provision, or part thereof, within these Terms be found to be unlawful, void, or unenforceable, such provision will be considered severable from these Terms and will not affect the validity and enforceability of the remaining provisions. The remainder of the Terms will remain valid and enforceable to the fullest extent permitted by law.
### 25. CONSEQUENCES OF TERMINATION/SUSPENSION
Upon termination or suspension of your Account, the following shall apply:
* You will lose the ability to log into your Account and the Rated console, and all licences previously granted to you under these Terms will be immediately revoked;
* You will be prohibited from registering a new account, whether it be under your name, an alias, or the name of a third party, even if you are acting on that third party's behalf; and
* You must immediately cease all use of the API Services
### 26. ASSIGNMENT
The Customer shall not assign, transfer, or distribute the rights or licences granted under these Terms to any third party.
No provision of these Terms shall be interpreted as bestowing any benefits, rights, remedies, or recourse to any third party whether under the Contracts (**Third Party Rights**) Act 1999 or otherwise.
The Customer's Account with us is non-transferable. All rights to the Customer Account shall cease upon termination of these Terms or closure of your Account.
### 27. ENTIRE AGREEMENT
These Terms constitute the entire agreement between you and us and shall remain in full force and effect as long as you continue to use our API Services at any level. They supersede any prior understandings or agreements between you and us regarding using our API Services.
### 28. NO PARTNERSHIP OR AGENCY
Nothing in this agreement is intended to or shall be deemed to, establish any partnership or joint venture between any of the parties, constitute any party the agent of another party, or authorise any party to make or enter into any commitments for or on behalf of any other party.
### 29. OTHER IMPORTANT INFORMATION
Should we fail to insist on the performance of any of your obligations under these Terms or delay in exercising our rights against you, this does not imply that we have waived our rights or that you are exempted from your obligations.
Rated shall not be held accountable for any failure or delay resulting from conditions or occurrences beyond its reasonable control. This includes but is not limited to, governmental actions, acts of terrorism, natural disasters like earthquakes, fires, pandemics, floods or other acts of God, labour conditions, power failures, and disruptions in internet services.
### 30. FORCE MAJEURE
Except for the Customer's obligation to pay the Fees, neither party shall be liable for any failure to perform its obligations under these Terms if their performance is hindered or prevented by any matter beyond their reasonable control (including without limitation because of any loss, interruption, or degradation of any computer network or system or hardware or the internet or any part of it) (a **"Force Majeure Event"**). If a Force Majeure Event continues for more than 30 days, then either party may immediately terminate this Agreement on written notice to the other (provided that the Force Majeure Event is ongoing on the date of that notice).
### 31. DISPUTES AND APPLICABLE LAW
The parties agree to respond promptly to any issues arising from these Terms or relating to the Customer's use of the API Service and to try and resolve any disputes as quickly as possible through each party's key contact.
If a dispute cannot be resolved within seven days of referral to the other party's key contact, then the dispute shall be escalated to a director-level person at each party.
If a director-level person cannot resolve the dispute in 14 days, each party may seek legal remedies.
The dispute resolution process set out above shall not apply when a party seeks immediate remedies for infringement of IPR or breach of confidential information.
These Terms and any contractual or non-contractual claims shall be governed under the laws of England and Wales.
You irrevocably agree that the courts of England and Wales shall have exclusive jurisdiction to settle any dispute or claim arising out of or in connection with these terms of use or their subject matter or formation (including non-contractual disputes or claims) however, Rated reserves the right to bring a Claim against the Customer in the applicable courts of the Customer's principal or registered place of business.
### 32. CONTACT US
The Terms outlined herein are subject to change at our discretion to align with evolving industry standards or best practices. If you have any questions or comments about these Terms or wish to complain, please get in touch with us at [hello@rated.network](http://hello@rated.network).
***
## Document History
API Terms of Service - Nov 30 2023 - Feb 13 2024.pdf
API Terms of Service - Dec 12 2022 to Nov 30 2023.pdf
# Onboarding Terms of Use
Source: https://docs.rated.network/legal/terms/onboarding-terms-of-use
Lite version of ToU for the Pro-tier onboarding
Date of last update: `Apr 17, 2023`
These Terms and Conditions ("Terms") constitute a legally binding agreement between Rated Labs Ltd. ("Rated") and you ("Client") for the provision of Pro Tier Onboarding services on Rated, the leading platform for in-depth analysis and display of validator metrics on Ethereum.
By signing up for the Pro Tier Listing services, the Client agrees to be bound by these Terms and all applicable laws and regulations.
### 1. Information About Us
1.1. The Rated APIs are owned by Rated Labs Limited (“we”, “our” or “us”) or our licensors. We are registered in England and Wales under company number 14036060, with our registered address at 12 New Fetter Lane, London, England, EC4A 1JP, and with VAT number 421887483.
### 2. Changes to These Terms
2.1. We may revise these terms of use at any time (for example, if there is an underlying commercial or legal reason) by amending this page. If you are a consumer who has a Rated Account and is a Registered User (as set out in paragraph 3) then we will provide you with at least thirty (30) days' advance notice of any such changes, unless the change is due to a change in law or for security reasons (in which case we may need to change these terms of use on shorter notice). If you do not wish to continue using your Rated Account after we have made such changes, you can cancel your Rated Account via the site.
2.2. If you do not have a Rated Account, we will not be able to notify you of changes to these terms of use. Accordingly, the terms of use that are live as at the date that you access one of the Rated APIs will apply to that single access.
### 3. Payment and Fees
3.1. The total cost for the Pro Tier Listing services is \$20,000, which will be broken down into two payments:
* An upfront payment of \$10,000 upon accepting the ToU. This payment must be deposited to `0xb34c9675ebe87125021a2be30f5e1456cf31ceec` or `ratedw3b.eth` (in the agreed upon digital asset) within 10 days after accepting the ToU this agreement and the transaction hash must be shared via email to [e@rated.network](mailto:e@rated.network).
* A final payment of \$10,000 after the successful delivery and activation of the Pro Tier Onboarding services. This payment must be deposited to ratedw3b.eth (agreed upon digital asset) within 10 days of Rated notifying the Client of service completion and the transaction hash must be shared via email to [e@rated.network](mailto:e@rated.network).
3.2. Should a part of the payment be done in a native token, the 14-day moving average on the TOKEN/USD pair from Coingecko should be treated as the exchange rate.
### 4. Services
4.1. Upon receipt of the upfront payment, Rated agrees to deliver the following services to the Client:
* Detailed public monitoring and benchmarking on the Rated Network Explorer.
* Drill-downs on effectiveness and performance metrics on both an aggregate and per operator basis.
* 1:1 support on the Rated API, enabling detailed metric tracking with simple calls.
* Maintenance and support for contract structure changes and updates to the active set.
4.2. Rated will notify the Client once the services are live and available for public viewing.
### 5. Governing Law and Dispute Resolution
5.1. The agreement and any dispute or claim arising out of or in connection with it or its subject matter or formation (including non-agreement disputes or claims) shall be governed by and construed in accordance with English law.
5.2. Each Party irrevocably agrees that the courts of England and Wales shall have exclusive jurisdiction to settle any dispute or claim arising out of or in connection with the Agreement or its subject matter or formation (including non-agreement disputes or claims).
### 6. Amendments
6.1. Rated reserves the right to amend these Terms at any time. The Client will be notified of any changes, and continued use of the Pro Tier Listing services constitutes acceptance of the amended Terms.
### 7. Entire Agreement
7.1. These Terms, together with any other documents incorporated by reference, constitute the entire agreement between the parties and supersede all prior and contemporaneous agreements, proposals, or representations, written or oral, concerning its subject matter.
### 8. Signature
8.1. By signing up for the Pro Tier Listing services, both parties acknowledge and agree to the terms and conditions stated in these Terms.
### 9. Contact us
To contact us: Address: 12 New Fetter Lane, London, EC4A 1JP, United Kingdom
Email address: [hello@rated.network](mailto:hello@rated.network)
# Website Terms of Use
Source: https://docs.rated.network/legal/terms/website-terms-of-use
Terms last updated `Dec 12, 2022`
Rated Labs Ltd is a company incorporated in England and Wales (company number 14036060, VAT number 421887483), with its registered address at 12 New Fetter Lane, London, England, EC4A 1JP (“Rated”). Rated owns and operates the website at the following URL [https://rated.network](https://rated.network) (“Website”).
### 1. Understanding these Terms
1.1. These terms of use (these “Terms”) describe how you may access and use the Website. By accessing and using the Website you acknowledge and agree to these Terms. If you do not agree to any of these Terms you must not access and use the Website.
1.2. When certain words and phrases are used in these Terms, they have specific meanings (these are known as “defined terms”). You can identify these defined terms because they start with capital letters (even if they are not at the start of the sentence). Where a defined term is used, it has the meaning given to it in the section of these Terms where it was defined (you can find these meanings by looking at the sentence where the defined term is included in brackets and speech marks).
1.3. In these Terms, when we refer to “we”, “us”, or “our” we mean Rated; and when we refer to “you” or “your” we mean:
1.3.1. you, the person accessing and using the Website; and
1.3.2. where applicable, the business on whose behalf you are acting.
Please note:
1.3.3. if you are acting for purposes that are wholly or mainly outside your trade, business, craft or profession, you are acting as a “consumer”; or
1.3.4. if you are acting for purposes relating to your trade, business, craft, or profession, then you are acting in the course of a business (a “Business User”).
1.4. If you are acting on behalf of your employer or another business when you access and use the Website you represent and warrant that:
1.4.1. you have full legal authority to bind your employer or that business; and
1.4.2. you agree to these Terms on behalf of the employer or business that you represent.
1.5. Please note that we only use your personal information in accordance with our privacy policy (available in [Privacy Notice](/privacy/privacy-notice)).
1.6. Please note that certain functions made available on the Website are governed by additional terms and conditions, including [API Terms of Service](/terms/api-terms-of-service).
### 2. The Website
2.1. The Website is made available free of charge. We do not guarantee that the Website, or any data, records, reports, results, documents, drawings, logos, typographical arrangements, software, text, designs, graphics, photographs, images, and any other output, information, materials or content either available on the Website (or produced by accessing the Website) (“informational content”), will always be available or be uninterrupted. Access to the Website is permitted on a temporary basis. We may suspend, withdraw, discontinue or change all or any part of the Website without notice. We will not be liable to you if for any reason the Website is unavailable at any time or for any period. We may update the Website and/or change the informational content on it at any time.
2.2. You are responsible for making all arrangements necessary for you to have access and use to the Website. You are also responsible for ensuring that all persons who access and use the Website through your internet connection are aware of these Terms and that they comply with them.
2.3. The Website and the informational content on it are provided for general information purposes only. They are not intended to amount to any type of regulated advice or recommendation on which you should rely on.
2.4. Any informational content on the Website is not intended and should not be construed as an endorsement or recommendation of any particular blockchain protocol, any node operating on a blockchain protocol or any node operator.
2.5. Nothing in these Terms shall constitute investment advice, legal advice, financial advice, or any other professional advice. You assume all risks in acting on any informational content. We shall have no responsibility or liability for any financial position, investment or other business decisions or advice, or any calculations arrived at when using or relying on any informational content. Accordingly, you agree that you assume sole responsibility for results obtained from the access and use of the Website and any informational content and for conclusions drawn from such access and use.
2.6. We do not guarantee that use of the Website (including any informational content) will meet your requirements nor that any recommendations will deliver any particular benefits if implemented.
2.7. We do not guarantee the use, or the results of the use, of the informational content in terms of their correctness, accuracy, reliability or otherwise.
### 3. Acceptable Use
#### *General*
3.1. You agree not to:
* 3.1.1. use the Website in any way that breaches these Terms or any applicable local, national or international law or regulation;
* 3.1.2. copy, or otherwise reproduce, or re-sell any part of the Website unless expressly permitted to do so under clause 4.4 ; or
* 3.1.3. do any act or thing that might damage, disrupt or otherwise interfere with the operation of the Website or any equipment, network or software used in operating the Website.
#### *Viruses*
3.2. We do not guarantee that the Website will be totally secure or free from bugs or viruses. You are responsible for configuring your information technology, computer programmes and platform in order to access and use the Website and we recommend that you use your own virus protection software.
3.3. You must not misuse the Website by knowingly introducing viruses, trojans, worms, logic bombs or other material which is malicious or technologically harmful, or is unlawful, harmful, threatening, defamatory, obscene, infringing, harassing or racially or ethnically offensive; facilitates illegal activity; depicts sexually explicit images; or promotes unlawful violence, discrimination based on race, gender, colour, religious belief, sexual orientation, disability or any other illegal activities. You must not attempt to gain unauthorised access and use of the Website, the server on which the Website is stored or any server, computer or database connected to the Website. You must not attack the Website via a denial-of-service attack or a distributed denial-of-service attack. By breaching this provision, you would commit a criminal offence under the Computer Misuse Act 1990. We will report any such breach to the relevant law enforcement authorities and we will co-operate with those authorities by disclosing your identity to them. In the event of such a breach, your right to access and use the Website will cease immediately.
### 4. Intellectual Property
4.1. We are the owner or licensee of all intellectual property rights in the Website and its informational content, including but not limited to, the Rated name and mark. These works are protected by intellectual property laws and treaties around the world. All such rights are reserved.
4.2. You are not granted any right to use, and may not use, any of our intellectual property rights other than as set out in these Terms.
4.3. Except to the extent expressly permitted under clause 4.4 , no part of the Website, including, without limitation, any informational content may be copied, reproduced, republished, uploaded, re-posted, modified, transmitted or distributed or otherwise used in any way for any non-personal, public or commercial purpose without our prior written consent.
4.4. Notwithstanding clause 3.1 above and clause 4.3 subject to your compliance with these Terms (including, for the avoidance of doubt, the remainder of this clause 4.4), you may copy, share, republish, upload, re-post or distribute, the informational content for information and non-commercial purposes only. You are prohibited from manipulating, modifying or in any way changing the informational content in order to copy, share, republish, upload, re-post or distribute it in accordance with this clause 4.4. If you copy, share, republish, upload, re-post or distribute any informational content in accordance with this clause 4.4, you must, at your option, either include a statement alongside such informational content that says “Powered by Rated” or use our “Powered by Rated” widget \[coming soon] and if you do so you should ensure that this statement or widget is placed on such informational content with sufficient prominence to be seen by the intended viewer.. We reserve the right to require the removal of, and for you to cease using, any such informational content at any time and you shall immediately cooperate. The rights granted under this clause 4.4 are non-exclusive, non-transferable, revocable and non-sublicensable. You shall not copy, share, republish, upload, re-post or distribute the informational content in order to build a product or service which replicates, competes with or is substantially similar to the Website or for any purpose not expressly permitted by these Terms.
4.5. You acknowledge and agree that the licence set out in clause 4.4 above does not apply to any data, records, reports, results, documents, drawings, logos, typographical arrangements, software, text, designs, graphics, photographs, images, and any other output, information, materials or content made available by Rated to you via the application programming interfaces (“Rated APIs”) available to you on the Website (“Rated Data”). Use of the Rated Data and Rated API is subject to the terms and conditions set out in the [API Terms of Service](/terms/api-terms-of-service).
4.6. Any communications or materials you send to us through the Website by electronic mail or other means will be treated as non-proprietary and non-confidential. We are free to publish, display, post, distribute, and otherwise use any ideas, suggestions, concepts, designs, know-how and other information contained in such communications or material for any purpose, including, but not limited to, developing, manufacturing, advertising and marketing us and our products.
### 5. Our Liability
5.1. Nothing in these Terms excludes or limits our or your liability for: 5.1.1. death or personal injury caused by our or your negligence;
* 5.1.2. fraud or fraudulent misrepresentation; and
* 5.1.3. any matter in respect of which it would be unlawful for us or you (as applicable) to exclude or restrict our or your (as applicable) liability.
5.2. We assume no responsibility for the content of websites linked to the Website (including links to our commercial sponsors and partners). Such links should not be interpreted as endorsement by us of those linked websites. We will not be liable for any loss or damage that may arise from your use of them.
5.3. The Website may contain inaccuracies or typographical errors. We make no representations about the reliability, availability, timeliness or accuracy of the informational content included on the Website.
5.4. The Website and all informational content is provided "as is" and, to the extent permitted by law, Rated disclaims all conditions, warranties, representations, undertakings, or other terms which might have effect between you and us with respect to the Website and all informational content, whether express or implied.
#### *If you are a Business User*
5.5. If you are acting for purposes relating to your trade, business, craft or profession, then subject to clause 5.1:
5.5.1. in no event shall we be liable to you for: (a) any loss of profits, loss of sales, loss of business, loss of revenue, loss of contracts, business interruption, loss or corruption of data, loss of business opportunity, loss of goodwill, loss of reputation or loss of anticipated savings (whether direct, indirect or consequential), whether arising from tort (including negligence), breach of contract (including liability under any indemnity) or otherwise; or (b) any indirect or consequential loss or damage, whether arising from tort (including negligence), breach of contract (including liability under any indemnity) or otherwise; and
5.5.2. and clause 5.5.1, our total liability to you for any loss or damage arising out of or in connection with these Terms, whether in contract (including liability under any indemnity), tort (including negligence) or otherwise shall be limited to £100.
5.6. You shall indemnify and hold us harmless against any losses, costs, liabilities and expenses suffered or incurred by us and/or our affiliates as a result of any breach of these Terms.
#### *If you are a consumer*
5.7. If you are acting for purposes that are wholly or mainly outside your trade, business, craft, or profession then, save as set out in clause 5.1, the following sub-clauses apply:
5.7.1. nothing in these Terms affects your statutory rights. Advice about your statutory rights is available from your local Citizen’s Advice Bureau or Trading Standards Office;
5.7.2. you agree not to access and use the Website, or any informational content on the Website, for any commercial or business purposes whatsoever and, accordingly, you agree that in no event shall we be liable to you for: any loss of profits, loss of sales, loss of business, loss of business revenue, loss or breach of business contracts, business interruption, loss or corruption of business data, loss of business opportunity, loss of goodwill in a business or commercial enterprise, loss of business reputation or loss of anticipated business savings, of any kind and howsoever arising;
5.7.3. if we fail to comply with these Terms, we are only responsible for loss or damage that you suffer that is a foreseeable result of our breach of these Terms or our negligence. We are not responsible for any loss or damage that is not foreseeable. Loss or damage is foreseeable if it was an obvious consequence of our breach or if it was contemplated by you and us at the time that you accessed or used the Website;
5.7.4. subject to clause 5.7.2, and 5.7.3, our total liability to you for any loss or damage arising out of or in connection with these Terms, whether in contract (including liability under any indemnity), tort, (including negligence) or otherwise shall be limited to £100.
### 6. Suspension and Termination
6.1. If you breach any of these Terms, we may immediately do any or all of the following (without limitation):
6.1.1. temporarily or permanently withdraw your right to use or access the Website;
6.1.2. issue legal proceedings against you for reimbursement of all costs resulting from the breach (including, but not limited to, reasonable administrative and legal costs);
6.1.3. take further legal action against you;
6.1.4. disclose such information to law enforcement authorities as we reasonably feel is necessary to do and/or
6.1.5. require the removal of, and for you to cease using, any informational content (including any informational content you copy, share, republish, upload, re-post or distribute in accordance with clause 4.4) at any time and you shall immediately cooperate.
### 7. Changes to these Terms
We may make changes to these Terms from time to time (if, for example, there is a change in the law that means we need to change these Terms). Please check these Terms regularly to ensure that you understand the Terms that apply at the time you access and use the Website.
### 8. Other important information
8.1. Each of the clauses of these Terms operates separately. If any court or relevant authority decides that any of them are unlawful or unenforceable, the remaining clauses will remain in full force and effect.
8.2. If we fail to insist that you perform any of your obligations under these Terms, or if we do not enforce our rights against you, or if we delay in doing so, that will not mean that we have waived our rights against you and will not mean that you do not have to comply with these obligations. If we do waive a default by you, we will only do so in writing, and that will not mean that we will automatically waive any later default by you.
8.3. Rated will not be liable for any failure or delay resulting from any condition or occurrence beyond its reasonable control, including but not limited to, governmental action or acts of terrorism, earthquake, fire, pandemic, flood, or other acts of God, labour conditions, power failures, and internet disturbances.
8.4. If you are a consumer who is resident in the European Union and you wish to have more information on online dispute resolution, please follow this link to the website of the European Commission: [http://ec.europa.eu/consumers/odr/](http://ec.europa.eu/consumers/odr/). This link is provided as required by Regulation (EU) No 524/2013 of the European Parliament and of the Council, for information purposes only. We are not obliged to participate in online dispute resolution.
### 9. Governing law and jurisdiction
9.1. These Terms are governed by the laws of England and Wales. This means that your access to and use of the Website, and any dispute or claim arising out of or in connection therewith (including non-contractual disputes or claims), will be governed by English law.
9.2. If you are a Business User, you and we irrevocably agree that the courts of England shall have exclusive jurisdiction to settle any dispute or claim (including non-contractual disputes or claims) arising out of or in connection with these Terms or its subject matter or formation.
9.3. If you are a consumer:
9.3.1. you may bring any dispute which may arise under these Terms to – at your discretion – either the competent court of England, or to the competent court of your country of habitual residence if this country of habitual residence is within the UK or is an EU Member State, which courts are – with the exclusion of any other court – competent to settle any of such a dispute. We shall bring any dispute which may arise under these Terms to the competent court of your country of habitual residence if this is within the UK or is an EU Member State, or otherwise the competent court of England.
9.3.2. As a consumer, if you are a resident in the UK or the European Union and we direct this Website to (and/or pursue our commercial or professional activities in relation to the Website in) the country in which you are resident, you will benefit from any mandatory provisions of the law of the country in which you are resident. Nothing in these Terms, including clause 9.1, affects your rights as a consumer to rely on such mandatory provisions of local law.
### 10. Contact us
**Email address:** [support@figment.io](mailto:support@figment.io)