Operators Guide Questions

I’m going through the Operators guide, preparing for Stake Wars next week.

I have a few questions that I’m looking for clarification on:

1) Which is the correct command to start syncing a new Operator node?
Is it the one provided in the Windows dropdown?

./subspace-node-windows-x86_64-skylake-gemini-3g-2023-nov-16.exe ` 
--chain gemini-3g ` 
--bootnodes /ip4/ ` 
--name your_node_name ` 
--base-path your_path_to_node_data ` 
-- ` 
--domain-id your_domain_id ` 
--chain gemini-3g ` 
--operator ` 
--keystore-path /tmp/keystore

Or the command shown in the image below the dropdown?

./subspace-node-windows-x86_64-skylake-gemini-3g-2023-nov-16.exe `
--chain gemini-3g `
--rpc-external `
--node-key 0000000000000000000001 `
-- `
--domain-id 3 `
--chain gemini-3g `
--operator `
--keystore-path /tmp/keystore `

1b) What is this parameter used for? Is it the same for all nodes? /ip4/

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

Not sure, @ved?

Not sure, that would be interesting if someone increases tax after nominators have joined already, @ved should be able to clarify.

@Emilios @Jim-Subspace I think there is an opportunity to improve documentation based on these questions.

1 Like

Good idea, will have and think about how to reflect that in the docs. Thanks!

1 Like

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

Of course. I edited the original post to reflect the commands that are shown in the docs.

I noticed this was included in the command for all three OS. I assume I could put the keystore anywhere, so this isn’t so important.

I should have waited just a few hours to make this post :joy: Thank you for your help @nazar-pc.

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.