Skip to main content

​
Overview

​
Summary

This article explains how beaconcha.in assigns human‑readable tags to Ethereum validators. Tags make it easier to understand which validators belong to well‑known entities (e.g., Lido, Rocket Pool), as well as large independent operators (“whales”). It covers data sources, the step‑by‑step tagging pipeline, how often tagging runs, and how conflicts are resolved. Shout‑out: A big thank‑you to Hildobby for maintaining a community dataset of validator/entity mappings used by many in the ecosystem.

​
What is a validator tag?

A validator tag is a short, human-readable label associated with one or more validators. Tags help you:
  • Attribute validator performance to entities via their BeaconScore® benchmark value.
  • Understand decentralization by operator/entity.
  • Identify large clusters of validators controlled by the same address.
Examples include:
  • Coinbase or Binance
  • Lido, Lido Simple DVT, or Lido CSM (Lido modules)
  • Rocket Pool (Rocket Pool validators)
  • Whale_0x1234ab (an independent cluster labeled by address prefix)

​
High‑level pipeline

At a high level, the tagging module:
  1. Imports community tags from the Hildobby dataset
  2. Queries on‑chain contracts to detect Lido validators (Curated v1 and v2, Simple DVT, Community Staking)
  3. Queries ether.fi’s on‑chain contracts to detect ether.fi validators
  4. Queries on‑chain contracts to detect Rocket Pool validators
  5. For any remaining untagged validators, clusters by withdrawal address and assigns whale tags if the cluster balance reaches 320 ETH
  6. For any remaining untagged validators, clusters by deposit (funding) address and assigns whale tags if the cluster balance reaches 320 ETH
  7. Applies operator self-reports
  8. Applies manual overrides
The pipeline runs automatically once a day.

​
Step‑by‑step details

1) Community tags via Hildobby
  • Source: Hildobby’s public validator/entity dataset (community maintained).
  • Matching: The dataset contains mappings of validator indices or pubkeys to known entities. We import those tags directly.
  • Why first? Community‑maintained mappings often include entities that are not easily inferred from on‑chain structures.
  • Note: We retain Hildobby’s naming semantics and apply them as the baseline when no higher‑certainty on‑chain inference is available.
2) Lido validators from on‑chain contracts We identify validators belonging to Lido by reading their on‑chain registry data. This includes:
  • Lido Curated Module v1
  • Lido Curated Module v2
  • Lido SimpleDVT Module
  • Lido Community Staking Module
Implementation outline:
  • Enumerate the validator set exposed by each module’s contracts
  • Read Curated Module v2 operator names from its on-chain MetaRegistry
  • Map each validator pubkey to the appropriate tag: Lido, Lido Simple DVT, or Lido CSM
  • Prefer these determinations over community tags when a contract says a validator belongs to Lido
Rationale: On‑chain state is authoritative for Lido’s modules and provides the highest‑certainty attribution. 3) ether.fi validators from on‑chain contracts We detect ether.fi validators by reading the validator registrations of ether.fi’s own staking contracts. Implementation outline:
  • Read the validator registration events of ether.fi’s staking contracts
  • Look up each validator’s node operator and its name in ether.fi’s official operator list
  • Tag those validators as ether.fi, with the node operator as the sub-entity, replacing the ether.fi tags from the community dataset
4) Rocket Pool validators from on‑chain contracts We detect Rocket Pool validators by reading the relevant Rocket Pool contracts that register or imply validator ownership (e.g., minipools and their validator keys/addresses). Implementation outline:
  • Enumerate active and historical minipools
  • Retrieve associated validator pubkeys
  • Tag those validators as Rocket Pool, with the node address as the sub-entity
Rationale: Like Lido, Rocket Pool’s on‑chain structures allow for accurate, direct inference of validator membership. 5) Whale tagging by withdrawal address (>= 320 ETH) For remaining untagged validators, we infer likely common control by clustering validators sharing the same withdrawal credentials/address.
  • Cluster key: withdrawal address
  • Cluster size metric: sum of the current balances of the validators in the cluster
  • Threshold: >= 320 ETH (equivalent to at least 10 validators at 32 ETH each)
  • Tag format: Whale_0x1234ab, where 1234ab are the first six hex characters of the withdrawal address in lowercase, for readability
Operators often consolidate withdrawals to a single address, making it a strong signal of common ownership/control. 6) Whale tagging by deposit (funding) address (>= 320 ETH) For any still‑untagged validators, we cluster by the funding address that sent the deposit transaction(s).
  • Cluster key: deposit/funding (from) address of the validator’s first deposit
  • Cluster size metric: sum of the current balances of the validators funded by that address, where validators with 0x00 credentials count as 0 ETH
  • Threshold: >= 320 ETH
  • Tag format: Whale_0x1234ab
Large operators often fund many deposits from a single address, even if they diversify withdrawal addresses. 7) Operator self-reports Some staking operators report to beaconcha.in which validators they run. For every entity that has self-reported, its report replaces the tags the earlier steps assigned to that entity:
  • Each reported validator is tagged with the entity (and the sub-entity given in the report), even if an earlier step tagged it differently
  • Validators that earlier steps attributed to the entity, but that are not in its report, lose that tag
8) Manual overrides As the last step, beaconcha.in applies manual overrides. An override sets a validator’s entity and sub-entity, or removes its tag, and takes precedence over every other step.

​
Tag priority and conflict resolution

When a validator qualifies for multiple tags, we follow this precedence (from highest to lowest priority):
  1. Manual overrides
  2. Operator self-reports
  3. On‑chain entity detection (Lido modules, ether.fi, Rocket Pool)
  4. Community dataset (Hildobby)
  5. Inferred whale clustering by withdrawal address
  6. Inferred whale clustering by deposit address
Each step overrides the tags of the steps before it, except the two whale steps, which only tag validators that are still untagged.

​
Schedule and freshness

The tagging system runs on a fixed UTC schedule:
  • Daily at 10:00 UTC: Full tagging pipeline (all steps) runs in order, followed by a precompute job that updates the entity data dashboards.
  • Hourly (other than 10:00): Precompute only. This ensures UI remains fast and consistent even between daily runs.

​
Examples

  • A validator included in either version of Lido’s Curated module contracts will be tagged Lido, with its node operator recorded as the sub-entity.
  • An independent operator running 15 validators with the same withdrawal address will be tagged Whale_0xabcdef, where abcdef are the first six hex characters of their withdrawal address.
  • A cluster of 8 validators with 32 ETH each, funded from address 0xF..., will not get a whale tag because the balance threshold (>= 320 ETH) is not met.

​
How to request a correction

If you believe a tag is incorrect:
  • Open an issue in the beaconcha.in support channel and include validator indices or pubkeys, plus the correct attribution if known.
  • For on‑chain attributions (Lido/Rocket Pool), please provide the relevant contract references or transaction links.
Corrections propagate after the next daily run.

​
Frequently asked questions

  • Why does a whale tag use a short address prefix?
    • For readability in the UI. The underlying full address is retained for accuracy.
  • Will small operators get whale tags?
    • No. Only clusters with a total balance of at least 320 ETH (>= 320 ETH) qualify.
  • When are tags assigned for new validators?
    • Tags refresh daily with new data and may evolve if on‑chain ownership changes or the community dataset is updated.
  • Does tagging affect rewards or protocol behavior?
    • No. Tagging is a UI attribution feature only; it does not interact with consensus or execution layer incentives.

​
Contact

If you have questions or suggestions about validator tagging, please reach out via our support channel.