Skip to main content

Inferring Polkadot validator operators through nominator identity convergence

· 9 min read
Ross Bulat
Full Stack Engineer

Measuring Polkadot at the operator level is harder than counting validators. One operator can run several validators, while a validator that appears independent may simply lack an explicit super-identity relationship connecting it to the rest of its operation.

Nominations provide another source of public evidence. When every account nominating an operator-unresolved validator belongs to the same registrar-attested identity graph, that convergence can be used to associate the validator with the operator behind the graph.

I call this method Nominator Identity Convergence. It is a deterministic, snapshot-based heuristic for finding probable operator associations that are not expressed directly by the validator account itself.

The problem

Polkadot's People Chain supports on-chain identities, registrar judgements and super/sub-identity relationships. The Identity pallet defines sub-accounts as having equivalent ownership, which gives an explicit basis for grouping accounts beneath a shared super-identity.

That structure is useful but incomplete from an operator-analysis perspective. A registered validator may:

  • have no identity;
  • have a standalone identity but no super-identity;
  • use an account separate from the operator's publicly identified nominating accounts; or
  • be operated alongside other validators without expressing that relationship through the validator's own identity.

I refer to these accounts as operator-unresolved validators. This avoids prematurely describing them as independent or solo validators before the available evidence has been tested.

The method asks:

Does the complete nominator set of an operator-unresolved validator resolve to one registrar-attested operator identity component?

If it does, the validator is recorded as operator-associated with that component. The method does not claim to prove legal ownership or control.

Methodology

Require registrar-attested identities

An on-chain identity can be self-declared. That is not sufficient for automatic operator attribution.

Nominator Identity Convergence only uses identity details backed by a current registrar judgement of Reasonable or KnownGood. People Chain registrars review identities and issue judgements about their accuracy; the People Chain documentation distinguishes Reasonable identities from the more formally certified KnownGood classification.

This requirement changes the status of the evidence. X and email fields are no longer accepted merely because an account published them. They must belong to an identity that an external registrar has assessed at one of the two accepted levels.

Identities whose usable judgement is only unknown, fee-paid, out-of-date, low-quality or erroneous are excluded from automatic matching. An excluded identity can remain visible in the data, but it cannot establish or merge an operator component.

Three kinds of graph edge

The resulting graph preserves three kinds of relationship instead of flattening them into an unexplained cluster.

EdgeMeaningEvidence type
Super identity ↔ sub-identityThe Identity pallet explicitly links the accountsExplicit
Identity root ↔ identity rootRegistrar-attested X or full-email fields match exactly after normalisationInferred identity equivalence
Operator component → validatorEvery nominator of the validator resolves to that componentInferred operator association

Each relationship carries a different evidentiary meaning. A super/sub relationship is an on-chain ownership declaration. An exact contact-field match is evidence that two separately rooted identity graphs represent the same operator. Unanimous nominator convergence is then evidence that a validator is associated with that operator.

Each inferred association retains the path that produced it. For example:

Validator V
→ nominated by N1, N2 and N3
→ N1 is a sub-identity of Root A
→ N2 is a sub-identity of Root A
→ N3 is Root A
→ Root A has an accepted registrar judgement
→ V is operator-associated with A

A contact-field merge remains distinguishable:

Validator W
→ nominated by N4 and N5
→ N4 resolves to Root B
→ N5 resolves to Root C
→ B and C have the same normalised, registrar-attested X identity
→ B and C form one inferred operator component
→ W is operator-associated with that component

Start with a reproducible snapshot

No historical persistence check is required. Nominator Identity Convergence describes the state visible at a particular point in time.

Staking and identity state reside on different system chains, so the reproducible input is a coordinated pair of finalized blocks rather than one block number. The Asset Hub block supplies the registered validators and nomination preferences. The People Chain block supplies identities, registrar judgements and super/sub relationships.

The same alignment rule used for validator retainment and compound rates can be reused here:

  1. Select the canonical Asset Hub block for the snapshot.
  2. Read its timestamp and block hash.
  3. Select the latest indexed People Chain block at or before that time.
  4. Store both block numbers and hashes with the result.

This prevents the identity view from running ahead of the staking view and makes every inferred association reproducible.

Build operator identity components first

The identity graph should be calculated before testing any validator. Building it once avoids repeated queries and prevents the classification order from affecting the result.

First, create explicit components from People Chain state:

for every super/sub relationship:
union(super, sub)

Super relationships are followed to their ultimate root and all descendants are expanded. An account is counted once even if it is encountered from both directions.

Next, consider contact-field equivalence between otherwise separate roots. Both identities must have an accepted registrar judgement. X handles and emails are compared only after normalisation:

  • trim whitespace;
  • compare X handles without a leading @, URL wrapper or case difference;
  • compare complete email addresses rather than email domains; and
  • ignore missing, empty or unusable field values.

An exact normalised match creates an inferred component edge:

for each accepted normalised X value:
union(identity roots with that X)

for each accepted normalised full email:
union(identity roots with that email)

The field responsible for each union is retained as provenance. A shared email domain such as example.com is not enough: it can indicate a common organisation without establishing that two identities represent the same operator.

Invert the nomination graph

The staking Nominators map stores each nominator's validator preferences. It is therefore indexed in the opposite direction from the question being asked. The snapshot process inverts those preferences once:

validator_nominators: Validator → Set<Nominator>

for each (nominator, targets) in Staking.Nominators:
for each validator in targets:
validator_nominators[validator].insert(nominator)

This method asks who has publicly chosen to nominate a validator. The staking storage documentation describes Nominators as the mapping from a nominator stash to the validators it wishes to support.

Nomination pool stash accounts are keyless bonded accounts, so identities cannot be assigned to them. Although these accounts appear as nominators, they cannot resolve to an operator component. If a nomination pool stash account nominates a validator, that validator therefore cannot satisfy the convergence rule.

The convergence rule

For an operator-unresolved validator v, let:

  • N(v) be the complete, non-empty set of accounts nominating v; and
  • C(n) be the accepted operator identity component of nominator n, or unresolved if the nominator has no eligible identity or is a nomination pool stash account.

The validator is associated with component O only when:

|N(v)| >= 1

and

for every n in N(v): C(n) = O

Every nominator must resolve. The strict outcomes are:

Nominator evidenceOutcome
Every nominator resolves to component AAssociate the validator with A
Resolved nominators point to components A and BConflicting; leave unresolved
Some resolve to A but at least one is unidentified or ineligibleIncomplete; leave unresolved
No nominators target the validatorInsufficient evidence; leave unresolved

The original single-nominator observation is simply the smallest valid case. Multiple nominators strengthen the structural pattern when all of them independently resolve to the same operator component.

Expanding the operator's validator set

Once the components and inverted nomination index exist, the same rule is applied to every operator-unresolved validator.

Operator A
├── explicit validator A1
├── explicit validator A2
├── inferred validator V
└── inferred validator W

V and W may be nominated by different accounts. What matters is that the complete nominator set of each validator resolves exclusively to Operator A's component.

The algorithm builds the identity components before evaluating validators. A disjoint-set or union-find structure resolves all transitive identity relationships first, allowing each nominator to be mapped to a component in near-constant time. After the snapshot indexes are built, processing is roughly linear in the number of identity relationships and nomination edges.

An inferred association is recorded as a result but is not added to the identity graph or used to infer further associations. This prevents one uncertain association from cascading into further identity merges.

Preserve an evidence record

Every result should explain itself. A suitable record contains:

validator: <AccountId>
inferred_operator_component: <ComponentId>
classification: operator_associated

snapshot:
asset_hub_block: <number and hash>
people_chain_block: <number and hash>

nominators:
total: 3
resolved: 3
unresolved: 0
conflicting_components: 0

evidence:
- ALL_NOMINATORS_ONE_COMPONENT
- ACCEPTED_REGISTRAR_JUDGEMENT
- SUPER_IDENTITY
- X_MATCH

The exact evidence list will vary. A validator associated through a shared super-identity should remain distinguishable from one whose nominators converge through matching registrar-verified social or contact fields.

This provenance makes the method auditable and allows accuracy to be analysed by inference path.

Limitations

Registrar attestation strengthens the identity evidence, but it does not validate the nomination-to-operator inference itself. An operator can nominate an independently operated validator, and a third party can nominate a validator without its permission.

The strict unanimity rule is deliberately conservative. An unrelated or unidentified nominator prevents an association, which reduces coverage but protects against silently discarding contradictory evidence. Conversely, a validator nominated exclusively by one operator's accounts can still be misclassified if those accounts are supporting an external validator rather than one they operate.

The result is also snapshot-specific. Nominations, identities, judgements and super/sub relationships can change after the recorded blocks. Running the same method later may legitimately produce a different association.

These limitations are why operator-associated is the appropriate conclusion. The method identifies a strong public pattern; it does not produce cryptographic proof of beneficial ownership.

Conclusion

Nominator Identity Convergence turns an informal observation into a reproducible graph-resolution method:

Registrar-attested identities
+
explicit super/sub relationships
+
exact registrar-attested contact-field matches

operator identity components
+
snapshot nomination preferences

unanimous nominator convergence

inferred validator–operator associations

The method is intentionally narrow. It assigns an operator association only when every nominator is eligible, every identity resolves and the complete set converges on one component. Conflicting and incomplete cases remain unresolved.

That restraint makes the output suitable for operator-level decentralisation research, validator retainment analysis and nomination tooling. It extends the publicly visible operator graph while keeping every inferred relationship inspectable, reproducible and clearly separated from explicit on-chain identity links.