It is everyone's expectation for the community to welcome new Registrar candidacies aiming to decentralize the role as much as possible. Given the last discussions regarding this type of proposals, we expect those who want to become Registrars to explain their intentions and plans beforehand, and once the proposal is in the queue ask the community to second it to move forward to the referenda queue.
Make sure to be active on all channels and talk to your council members and the community in general about your proposal. To do this, share this information on the Kusama Direction Channel and on any of the forums available for the Community.
In order to keep candidacies organised and to make sure the community has full information, we encourage all candidates to follow these recommendations:
Registrars should be known: some kind of identity linked to the address should be available for the community to communicate with the proposer, and at least two communication channels should be in place in the on-chain identity for a registrar to show availability.
Registrars should publish what the requirements are for the judgement levels available and what the registrar fee is.
Specifics on infrastructure used (in particular backend architecture and any custom code) should be published and kept up to date. The candidate should explain the code and design on the proposal, if any. **There should always be room for differentiation: ** innovation is always welcomed, but remember a price-sensitive strategy can also be attractive to the community. A Registrar should know what differentiates their approach from others.
The Registrar's design should deliver efficiently.
It is essential for a Registrar to respond fast in the eventuality of a blacklist event if needed: for this, efficient communication is important to the role.
Check the Kusama Wiki page to learn more about how to become a registrar and how to set an identity.