# Validator Metadata Registry **URL:** \ **Category:** MRCs\ **Created:** [June 16, 2026, 5:53pm UTC](https://forum.monad.xyz/t/validator-metadata-registry/497 "2026-06-16T17:53:39Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![ColinkaMalinka](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/colinkamalinka/32/380_2.png) [@ColinkaMalinka](https://forum.monad.xyz/u/ColinkaMalinka)\ **Post date:** [June 16, 2026, 10:44pm UTC](https://forum.monad.xyz/t/validator-metadata-registry/497/4 "2026-06-16T22:44:38Z")
Supportive, and this sits close to what we work on. We run ProofLine, a Japan testnet full-node, and publish a geo and ASN concentration map of the active set. We build it by scraping peer endpoints from gossip, mapping IPs to ASNs, and aggregating by provider, so the “who labels validator N” fragmentation shows up on the infrastructure side too, not just naming. That points to one field worth considering for `additionalInfo`: a conventional key for self-declared infrastructure (hosting provider / ASN / region). It is useful on its own, and its value grows when it can be cross-checked against what the network actually observes. We already produce that observed side (provider and ASN inferred from live peer endpoints), so a declared field would let explorers and delegation tools surface drift between what an operator states and what is measured: stale entries, accidental mislabels, or a node that quietly moved hosts. That makes the field more self-correcting rather than another value nobody audits. On our end we would read the registry as a consumer. Our dashboard currently infers operator identity and provider externally, and a canonical on-chain record to join against would replace a good chunk of that guesswork. Keeping it open-schema in `additionalInfo` keeps the convention optional and forward-compatible. If there is appetite for the infra-field convention, we can bring our observed-side data to help define it. --- _[View the full topic](https://forum.monad.xyz/t/validator-metadata-registry/497)._