1b) What is this parameter used for? Is it the same for all nodes?/ip4/3.87.28.170/tcp/40333/p2p/12D3KooWGHtULvhdKMZtzigSK1438uWXPj9rBQHVzTaKMWv1WRXp
2a) I noticed that operators will need to wipe and sync their node from the genesis block, since they need to sync both consensus and domain chains… Is there an option to start syncing the operator node before the start of Stake Wars?
2b) Is it recommended to keep an operator’s farmer offline during the time that the consensus+domain chains are resyncing?
2c) Is it required that the Operator node is fully synced before creating an operator key?target/production/subspace-node key generate --scheme sr25519
3a) Will there be an option to set nominationTax in decimal format? e.g. 2.5% or are the options limited to using whole numbers?
3b) Will there be an option to change nominationTax on an active operator? Will operators have to deregister/reregister or re-recruit their nominators if they want to change nominationTax?
I’m afraid neither (also --skylordafk parameters doesn’t exist, obviously). Both are partially correct (and /tmp doesn’t exist on Windows), official docs should have correct instructions though.
It is a bootstrap node, in this case for Nova domain because it is not stored anywhere else right now IIRC.
You can do it right now, it is just not possible to sync consensus chain first and enable operator later, you need to enable operator (do not have to stake though) from the beginning, we will fix it in the future.
If you have enough CPU feel free to do that.
No, the key can be generated any time, but you should only register after you are synced, see Stake Wars Rules of Engagement
At the moment this is not possible and the Call expects a number instead of decimal but there is not reason not introduce such a change and will introduce this change in the near future.
At the moment there is no option to change the nomination tax once registered. While we can introduce such change, we have consider potential concerns from Nominators perspective. I’ll start a discussion on this to gather more feedback from the team
I think the decimal may be helpful for operators to experiment with taxes. From 0%-1% for example, but I don’t think it’s absolutely necessary at the start.
This is probably a good thing, so that nominators don’t stake expecting a low tax that gets adjusted to a high tax without their knowledge. But I could see it being beneficial for operators to change the tax while registered to adapt for changing circumstances. i.e. Starting with a high tax and adjusting lower to attract more nominators, or starting low to bootstrap and increasing the tax to support higher costs or upgrades.
But deregister then re-register makes a lot of sense so that nominators stay informed. Thanks for the consideration Ved.
Can be anywhere and actually there is a default location in domain’s node folder if you don’t specify it explicitly. This is something that can be improved in our docs (directory will be created after domain has started, it will exist by the time you end syncing, which is what you are supposed to wait before registering anyway).
This is a potentially interesting behavior. Deregistering would be more disruptive since nominators will stop getting rewards until they re-nominate a different (effectively) operator.
The approach I’m thinking of is this.
Operators don’t need to deregister if and when they want to change operator config, runtime could just clear up all the nominators. So operators can continue to produce the bundles and nominators interested to join operator with new config can re-nominate again.