This lines up almost exactly with MRC-13 (Validator Metadata Registry), which I have a reference implementation and conformance harness for. Worth connecting the two before they diverge.
The core is identical: a per-subject, verbatim key-value store where writes are authorized by proof-of-control, every write emits a MetadataUpdated event, and consumers read it without standing up a second identity system. MRC-13’s subject is a validator (keyed by validator id, written by the validator’s authority); MRC-14 generalizes the subject to any account and adds a (topic, index) axis. A validator is really just an account attesting under a “validator” topic, so MRC-13 reads like a specialization of what you’re describing.
Two things from having shipped MRC-13 that might help:
-
Interface and naming alignment. MRC-13 settled on
getMetadata/getName/hasMetadata/MetadataUpdated. If MRC-14 keeps the read surface close (getMetadata/hasMetadata/metadataId, same event shape), one SDK and one conformance suite can cover both registries instead of two. I already have a behavioral conformance harness for MRC-13 (read, simulate, and write checks: return shape, event decoding, non-authority rejection, unknown-subject handling); extending it to MRC-14’s(account, topic, index)keying is small, and I am happy to contribute that. -
The observed-versus-declared boundary. The draft is right that the registry grades no claim and values should be weighed against off-chain evidence. That consumer-side verification is the interesting part in practice: for validators we already cross-check declared metadata against observed network reality (provider, ASN, region) in MonadPulse and with ProofLine. The same declared-versus-observed pattern applies to MRC-14’s key-management topics (MPC/TSS/TEE/operator), and it is worth stating in Security Considerations that consumers should treat entries as attestations rather than proofs and pair them with independent evidence where the stakes warrant it.
Keen to help move this forward and to align MRC-13 with it so we do not end up with two overlapping registries.