Pocket Network will soon activate a feature that will allow node runners to specify a different address for node rewards from the address that operates the node. With this, all existing node runners will need to choose whether to convert their node to this new setup, and should not delay making this choice.
Update: We’ve edited this post, and removed the prior reference to a mid-July release date, in order to acknowledge our revised plan to bundle the release of non-custodial staking along with the activation of stake-weighted servicer rewards (PIP-22). This will help to reduce administrative overhead for node runners.
As of mid-August, PIP-22 has now been released along with v0.9.0, and non-custodial staking will be fully activated when the network is upgraded after hitting the node adoption threshold (i.e. around 67% of nodes upgraded to v0.9.0).
How node staking works now
Right now, one Pocket account manages a single node and receives the rewards. For each node there is only one Pocket account associated with it.
So what’s the problem?
Since a server that is running the node needs to have access to the Pocket account (and vice versa), a Pocket wallet needs to be live on the same server (known as a “hot wallet”). This could present a potential security risk if your server gets compromised.
Also, not everyone runs their own servers. Over time, third-party node-hosting services have proliferated, and these node-hosting services are now a common way for node runners to contribute to the Pocket ecosystem without having to stand up one’s own server. While our known node-running services have exhibited a high-level of security and integrity, it still stands that one’s own wallet credentials must be accessible on a server hosted by a third-party. And for some, that’s unacceptable.
Enter non-custodial staking
Because of this, an improvement proposal was raised to add an option to run a node on behalf of another account. This means that for each node there are two relevant accounts/wallets: an operator address and an output address.
The operator address is the account that does the staking, and is the only valid signer for blocks and relays. However, the output address is where reward and staked funds are directed. Both accounts may be responsible for node transactions such as editing the stake, unstaking, and unjailing. Neither address may be altered while the node is staked.
To explain by way of example, this means that when a node is configured to run in non-custodial form, the operator address will stake the required POKT, but while the node is active, all rewards will flow to the output address, not the operator address. And when the node is unstaked (which can be initiated by either account), the staked POKT will be sent to the output account, not back to the operator account.
In this way, the operator account credentials can be live on a server, and administrators can be secure in the knowledge that there is nothing about that node that could be vulnerable to exploitation. If a malicious actor gains command of the operator account, there is no way to gain access to the funds connected to the node. All rewards and stake are funneled to the output account, which is safely stored off the server.
Why is this happening now?
The original proposal, PIP-9 (recall that PIP stands for Pocket Improvement Proposal) was submitted in December 2021, and was put to a vote by the DAO soon after. The proposal passed in February 2022. The feature was built into version 0.8.0 which was released in April 2022. The engineering team opted to ship the feature “unactivated” to allow for the ability to activate the feature once all nodes had upgraded to version 0.8.0.
It’s now been a few months since this version was released, so we’re ready to give our node runners this feature.
When will this feature be activated?
Our plan is to bundle this feature along with the activation of stake-weighted servicer rewards (as voted on in PIP-22).
v0.9.0 has now been released, and includes the changes outlined in PIP-22. This feature will be activated once the network crosses the adoption threshold of about 67% of nodes upgrading to v0.9.0.
What do existing node runners need to do now (Important!)
Before this feature is activated, you need to do two things:
- First, make sure you are using the most up-to-date version of pocket-core. You can always find the latest release on GitHub.
- Second, decide whether you wish to convert your existing node(s) to non-custodial staking, and if so, which account will be your output address.
As an additional task, non-custodial staking is already activated on Pocket testnet, so you can test out these new settings there if you’d like.
What do existing node runners need to do after activation (Important!)
Once this feature is activated, all nodes will be in an unspecified state, technically custodial (as that was the only option) but not explicitly set as such.
Therefore, nodes will be able to explicitly set their desired preference of operation: custodial or non-custodial.
However, nodes will only have a single opportunity to set this change. And any successful node transaction (such as editing stake) will set this for the node.
So we recommend that you run a node transaction as soon as possible to explicitly set your node preference. This way, if you have any automations in place, they won’t accidentally make your choice for you!
But do note that the commands to run node transactions have changed. Please see the documentation for the specific syntax changes.
What’s the risk of doing nothing?
The risk of not doing anything is that you may accidentally lock in custodial staking when running a node transaction, either through automation or just by running a command by default without specifying non-custodial as an option. If this happens, and you later decide that you wish to convert to non-custodial staking, you will need to unstake and restake your node (and remember that it takes 21 days to do this).
I’m thinking of spinning up a new node. Should I wait?
If you’re thinking of spinning up a new node, there is no need to wait for this feature to be activated. You will launch with custodial staking, and using the workflow above, you can easily switch to non-custodial when the feature is activated if you’d like.
What else is changing?
Not specifically related to non-custodial staking, but with this change, the forced unstake burn will be removed. The forced unstake burn is the process by which a node that falls below the minimum staking amount due to jailing and slashing is forcibly unstaked, and the entire staked amount is burned! This was deemed to be too harsh a penalty for node runners, and now, if you fall below the minimum stake, you will be put on a forced unstake, but you will not lose your stake.
There are a few other minor changes that go along with this, so please read the proposal to learn more.
As always, we welcome any and all discussion on our Discord. Aside from that, please see the following: