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.