It has been brought to my attention that Moonbeam and Moonriver could use the services of an identity registrar.
After some dicussions with the team, I have been asked if I could bring the services of Registrar #1 to the Moonbeam and Moonriver chains.
I’d be happy to make 2 onchain proposals in order to add Registrar #1 to the list of available registrars for for both Moonriver and Moonbeam.
My proposal is to follow a similar strategy than what is deployed on Polkadot and Kusama.
To trigger the process as a start, I would kindly ask applicants to send the address of their account(s) to one of the emails below:
The registrars for both Monnbeam and Moonriver will be located at index = 1 with addresses communicated later in this thread (and part of the onchain proposal).
Registrar #1 is the only registrar present on Polkadot, Kusama and Westend. It has also been deployed on Moonbase. You can learn more about Registrar #1here.
Yes, the operation of the registrar has a cost and a fee will be set.
The fee is set onchain and will be modified from time to time (I don’t track daily though…) to keep the price inline with the costs.
There is usually quite some confusion about the fee topic since a few fees are involved and behave different. Let me sum up below.
Every transaction requires the user to pay a fee. This is usually well understood.
Setting an identity requires the user to lock some funds. This is not a fee but the amount is no longer transferrable. The locked amount depend on the chain and remains locked as long as the identity remains set. If a user clears the identity, the funds are returned.
The amount is set onchain. The registrar fee is provided when the user requests a judgement.
The fee is provided in PLANKS (so it usually looks like a number with many many 0).
There is no risk for the user to make a mistake since:
if the users provides exaclty the fee, everything works as expected
if the user provides less than the required fee, the tx will fail
if the user provides more than the fee, the chain provides the change and the registrar ONLY ever get the exact fee, no matter what the user provided
The registrar fee is locked during the verifaction process. Once a judgement is set (whatever the judgement), the fee is unlocked and transferred to the registrar.
an estimate of what you expect to charge for the registrar fee at service launch if approved for Moonriver and Moonbeam?
With the price fluctuations atm, I careful not to mention any price but my plan is to set fee similar to what is on Kusama and Polkadot.
what inputs will be required and you’ll support by those requesting a judgement and
This will be 100% like on Kusama and Polkadot and as mentioned in the links above.
So in short, I enforce at least one comm. channel but encourage for 2+.
Those comm. channels will be challenged and the applicants will have limited time (3days total) and attempts (3x) to complete the challenges designed to confirm they own the comm. channels.
if you will be providing known-good judgements?
This is, as on Kusama and Polkadot, not the plan for now.
Hey @turrizt - the docs are a horrible source for registrar fees as the registrar can change them at any time and won’t go refactor the polkadot documentation.
It’s just somebody did write these values down at some point in time, when token values might have been way higher.
For example the 0.65 KSM fee from the docs was set on 2021/06/22 and updated on 2021/09/05 (and many times afterwards to adjust for price fluctuation).
The data I posted is the current on-chain data and was obviously an unintended user error by @chevdor .
I was hoping for him to check back, state fees, fix KSM&DOT fees to change my votings to AYE - voting ends in 13h 50m.
thanks for the clarification, I appreciate it! tbh, I believe that docs should always be updated and display accurate data. therefore, we will strive to ensure that Moonbeam docs are always updated and display accurate data. because this is the very first resource that the community refers to, and not everyone is an advanced user to track this on-chain data . also, I think changing fees should also be discussed in some way. judging by the screenshots you sent, it is obvious that this is a typo, but you noticed it very correctly, it probably needs to be fixed urgently. if it’s not a typo, then who will use it
as @dev0_sik mentioned, any of the docs are bad and only show a price that was correct at a given point of time. I actually tried removing any prices everywhere, but it looks like there are remains. Only what is onchain matters. The fees are adjusted according to the price from time to time and updating all the docs is virtually impossible. Any of the docs should just say “check on chain”.
since the fee (potentially) keep changing, BUT looking onchain can be challenging for some users, the registrar #1 sends an email to users with the information in clear text as they apply. It may not be functional from day one on moonbeam but this is what is in place on Kusama/Polkadot
I would have to double check but by the look of it (I did not count the zeroes), the information fetched onchain by @dev0_siklooks correct for Kusama and Polkadot.
I mentioned that fees on moonbeam/moonriver would be similar, I did not say they would be 100% the same, as a matter of fact, the fees on Polkadot/Kuasama are a little high for my taste atm for reasons out of the scope of this topic. So those fees will go back down
if I would set the prices right now (based on price updates) it would be 165 GMLR and 10 MOVR. I did not want to mention those values because they are linked to the current prices… so as/if price move, those fees will change and may end up being higher or lower
I am not tracking adjusting the fees on a daily basis so the fees are usually set to allow price fluctuations
Once those fees are set, they will show up on chain in planks so with 18 trailing zeroes
I totally understand if people are against the proposal due to the fees and this is totally fine. I am just proposing a service that I think could be helpful and I have gathered by now enough experience to know what it takes to run such a service.
I surely could set a bait price to get in now and change it later at will but I have no intererst in doing that at all.
I would invite anyone against the proposal for “fee reasons” to propose the same service for lower fees and the voters then to go for the cheaper option if they think it is a better option for the chain, this is totally fine with me
thanks for the clarification, I appreciate it! tbh, I believe that docs should always be updated and display accurate data
Ideally yes but this is super time consuming and no doc should be trusted anyway… we have chains to hold those data. The ideal option would be that whatever system is used by the doc could pull the data from the chain and to re-generate the doc daily for instance.
I hope that answers all the open questions, let me know if I missed one.
thank you very much for the clarification! I work a lot with the community, and 99% of users check the data in official docs, therefore, it seems to me that the user should be aware of the amount of fees and could easily find this information. even now, for example, it has led to confusion
Thanks for the further clarification, this helps a lot. I voted ‘yes’ and I think you’ve proven to be able to provide this service and that’s what I am voting on – the market should decide the price.
Personally, I hope you reconsider the pricing (and not as a bait), as there are full in-person government ID verification services that charge less (e.g. TSA Pre-Check for $79) and I don’t see why this Web3 service for verifying social accounts should be more expensive. However, people can decide whether or not they want to use the service and I would only advocate for more competition, certainly not to restrict access to the market from those providing a reliable service.
I see. The UI used to take values in DOTs, it has changed a while back to taking plancks (10 decimals on Polkadot), and it seems to be back to taking DOTs.
So when I set the fee last time on Polkadot, it got granted 10 extra zeros making it the value you saw. You should now be reading 120_000_000_000 plancks = 12 DOTs on Polkadot.