[Feat]: Decide the deployer and ownership model for Name Service on mainnet

[sphamjoli]

Component

Other

Priority

P0

Summary

The Name Service contracts need a defined deployer and owner before mainnet. The deploy is already deterministic and reproducible, so the addresses do not depend on who runs it, but nothing yet fixes who holds the deploying key, the proxy upgrade authority, and ownership of the protocol registry. If a single entity deploys and administers the upgradeable contracts, that entity is a central point of failure: compromising it compromises every username and every app that resolves through the Name Service. The decision is whether the Name Service is system-level infrastructure or an application with a named deployer, and who then holds each privileged role.

Proposal

• Decide the model: system-level infrastructure (deployed and governed as runtime-adjacent state) versus application-level (a named entity deploys and administers). This choice drives everything below.
• Deployer: name who runs the mainnet deployment and holds the deploying key. The deploy is deterministic, so the risk is control of the key, not the resulting addresses.
• Upgrade authority: assign the owner of every UUPS proxy. Recommendation is that governance holds upgrade authority rather than a deployer account or a single team multisig.
• Registry ownership: whoever owns the protocol registry can re-point any contract address, so its owner must be at least as trusted as the upgrade authority.
• Role separation: keep privileged actions (upgrade, registry writes) separate from day-to-day operations, so a compromised operator that can only reserve names (see [Feat]: Short-run governance track and operator management for reservations #205) can neither upgrade nor re-point contracts.
• Trust assumptions: list every privileged role, who holds it, and the blast radius if each is compromised.

Acceptance criteria

• A written decision on whether the Name Service is system-level or application-level infrastructure.
• A named holder for the mainnet deploying key, with the deployment runbook recorded.
• Upgrade authority assigned for every UUPS proxy, with governance as the default.
• Protocol registry ownership assigned to a party at least as trusted as the upgrade authority.
• Every privileged role enumerated with its compromise blast radius.
• The operator role ([Feat]: Short-run governance track and operator management for reservations #205) confirmed as separate from upgrade and registry authority.

[re-gius]

Must address before mainnet launch - P0 confirmed from my side

[re-gius]

This is also related to #202 (reserve names for claimants pre-launch) and #233 (whitelisting)

[re-gius]

This is not our responsibility since deployment should be managed by the Polkadot Community Foundation. Moreover, governance can upgrade any proxy and so, effectively, any functionality of DotNS.

Closing this and removing it from our milestone - remaining scope is in the new P2 issue #250