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.