Validator Metadata Registry

MRCs
1

What this MRC is proposing

A draft MRC for a permissionless on-chain registry of validator metadata. Each validator’s authority address — as already known to the staking precompile — can publish a record containing their name, website, description, logo, socials, and a forward-compatible JSON extension blob, keyed to the validatorId.

The problem it solves

The staking precompile knows what consensus needs — validator IDs, authority addresses, stake, commission — but nothing humans can read. Today every wallet, explorer, dashboard, and delegation tool solves this independently: maintain your own metadata.json file, scrape socials, ask validators directly. The result is fragmented naming across the ecosystem and a quiet concentration of “who gets to label validator N” in whoever happens to be curating the list a user is looking at.

A registry contract where validators publish their own metadata is the obvious fix. No protocol change needed — it’s a pure application-layer addition. The value of the standard is that wallets, explorers, governance UIs, and indexers can all read from a single shape.

The interface

The MRC defines IValidatorMetadata:

- A Metadata struct with name, website, description, logo, socials, additionalInfo.

- setMetadata (write the whole record) and updateMetadataField (update one field).

- A MetadataUpdated event on every write.

- Read methods for the stored record plus convenience getters.

socials and additionalInfo are stored as JSON-by-convention strings: the registry doesn’t parse or validate them, so writers and consumers carry the schema. socials is suggested as a JSON object keyed by lowercase platform identifier ("x", "telegram", …) so the spec doesn’t bake in today’s platforms; additionalInfo is open-schema for downstream MRCs to layer structured extensions on top.

A few design choices worth highlighting

Authority address as the baseline writer, not the sole writer: The validator’s authority address must be accepted; implementations may extend the writer set — delegated keys, multisigs, governance contracts — under their own rules. Forcing teams to touch the staking key just to update a logo URL is the kind of friction that pushes people back to off-chain curation, which is the worst of both worlds.

No canonical implementation, no curator: The MRC defines the interface; integrators and validators pick which conformant deployment(s) to use. The authors will deploy a reference implementation for their own use, but the MRC does not anoint it, and neither Monad Foundation nor any affiliate acts as a curator of validator metadata.

JSON, not custom encodings: Off-chain consumers in this space already speak JSON. Pinning a serialized struct or a binary format would force everyone through extra plumbing for marginal gain, and would lock the schema in ways that prevent forward-compatible extensions.

Immutable contract, no upgrade path: Future MRCs that change the storage layout or interface deploy at new addresses. The standard does not promise a stable address over time; integrators track which deployments they consider current themselves.

Read the full draft

Comments, critiques, and integration questions welcome in this thread.

7 Likes
2

Supportive — I sit on both sides of this: a validator (testnet id 267) currently published via the off-chain validator-info repo, and the operator of MonadPulse, a third-party indexer that reads names from it today. A single on-chain shape I write myself removes the “who labels validator N” fragmentation directly.

One addition worth considering for additionalInfo: a conventional key for self-declared infrastructure (hosting provider / ASN / region). Today infra concentration is only visible by scraping gossip and mapping IPs to ASNs by hand; a validator-declared field would give explorers and delegation tools a first-class place to surface provider diversity. Open-schema in additionalInfo keeps it optional and forward-compatible.

Happy to integrate the reference deployment into MonadPulse once it’s live.

1 Like
3

We support this direction. From a validator operator perspective, this solves a very real problem: validator identity is currently fragmented across explorers, wallets, dashboards, and privately maintained lists. That creates inconsistent names/logos, stale links, and unnecessary dependence on whoever curates a given frontend.

Having validator-controlled metadata anchored to the same authority model used by staking feels like the right baseline. It keeps the registry permissionless, makes the source of the update auditable, and gives integrators a simple common shape to read from.

A few points I’d like to highlight:

First, I strongly agree that the authority address should be the required baseline writer, but not necessarily the only writer. In practice, teams should not have to touch their core staking authority key just to update a logo, website, or social link. Delegated metadata managers, multisigs, or governance-controlled update flows are important for real validator operations.

Second, the JSON fields for socials and additionalInfo are a pragmatic choice. Wallets, explorers, and indexers already know how to consume JSON, and keeping those fields open-ended makes the standard future-proof without forcing a new registry every time the ecosystem wants to add a new metadata field.

The one area I think needs careful coordination is deployment discovery. If the MRC intentionally does not define a canonical contract address, that is good from a neutrality point of view, but integrators still need a reliable way to know which deployment(s) the ecosystem currently treats as active. Otherwise we may partially recreate the same fragmentation problem at the registry-address level. This does not need to be a Foundation-curated list, but some lightweight discovery convention or well-known registry-of-registries pattern would probably help wallets and explorers converge.

I would also encourage clear consumer-side guidance: all metadata should be treated as self-attested and untrusted. UIs should sanitize strings, validate URL schemes, avoid blindly loading arbitrary remote images, and show validatorId / authority address somewhere accessible so copied names or logos do not become a phishing vector.

Overall, this is a good application-layer standard. It does not require protocol changes, it respects validator self-sovereignty, and it gives wallets/explorers/indexers a shared interface instead of pushing everyone into private metadata files. POSTHUMAN would be happy to support this kind of standard.

1 Like
4

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.

1 Like
5

Great idea. I’ve spent a lot of time in different blockchain explorers lately and this was a problem everywhere. More than 50% of validators didn’t even have a description or name.

At the same time, some profiles were filled out really well, which reflects the exact issue you’re talking about.

The only thing that concerns me is that pfps will stay offchain. Let’s make our own monad validator punks.

6

@ColinkaMalinka the declared-vs-observed cross-check is the right framing — a self-declared field only stays honest if something measures drift against it, and that’s what makes it worth standardizing instead of being another unaudited string. I produce the same observed side in MonadPulse (provider / ASN inferred from live peer endpoints), so happy to help define the convention alongside ProofLine.

A concrete minimal shape for the additionalInfo key, all fields optional:

“infrastructure”: { “provider”: “ovh”, “asn”: 16276, “region”: “ap-southeast” }

That’s enough for explorers to surface provider diversity and for either of our dashboards to flag declared-vs-observed mismatches, while staying open-schema. If the authors would rather keep additionalInfo fully freeform and layer this in a follow-on MRC, that works equally well.

7

If multiple registries contain different metadata for the same validator, how should integrators resolve conflicts? Is the expectation that the ecosystem converges on a small number of trusted deployments over time?

8

From the integrator seat (MonadPulse): I’d anchor trust on the authority address from the staking precompile, not on any single registry — “who wrote it” matters more than “which registry,” which turns most conflicts into a recency question rather than a trust one. For objective fields like the infrastructure one above, the observed gossip data is a natural tiebreaker: the record matching what the network actually shows wins.

The convergence/discovery half — which deployments count as current — is the real open one, and that’s for the authors. +1 that some lightweight discovery convention would stop this recreating the fragmentation at the registry-address level.

9

We agree and fully support this direction. A validator-controlled metadata registry would reduce fragmentation across explorers, wallets, and dashboards, while giving operators a simple and transparent way to keep their information accurate and up to date.

10

+1 to @ShadowOfTime1 on anchoring trust on the authority address rather than any single registry, that turns most conflicts into a recency question.

for the objective fields (infrastructure especially), observed network data is a clean deterministic tiebreaker: when records disagree, the one matching what the network actually shows wins. we already produce that observed side for the full active set (asn/provider/region inferred from live peer endpoints, 200/200 in our current snapshot), so it can serve as the reference for resolving those conflicts, not just for flagging drift.

on discovery, the spec deliberately leaves deployment choice to integrators with no canonical curator, which is the right call. a lightweight, non-curated discovery convention (the registry-of-registries idea raised above) would stop fragmentation reappearing at the registry-address level without recreating a curator. authority-address trust plus observed-as-tiebreaker for objective fields covers most of the practical cases meanwhile.