Staking Controller Deprecation Plan + Staking UI Leads Comms

[ross]

Summary

As proxy account implementation is currently a big focus for staking dashboard, I wanted to push the controller deprecation agenda and make progress in such a way that is leading us to the removal of the feature.

PR #14039 (WIP) has been opened to put a cap on new unique controllers. It changes 2 calls:

• set_controller: Removes the controller argument, and changes the logic to always set the controller to a staker’s stash account.
• bond: Removes the controller argument, and also changes the logic to always set controller to the stash.

Making these 2 changes will ensure that new controller accounts moving forward will always be the same as the stash, and gives UIs the ability to offer a migration prompt for existing stakers to set their controller acount to their stash, via the updated set_controller.

Stakeholders

Apps & Extensions (not exhaustive):

Todo: insert Github repo links.

• Staking dashboard (Ross)
• Ledger Live staking.
• Nova Wallet staking.
• Polkawallet staking.
• PolkaGate extension.
• Talisman & Subwallet extension staking.
• Fearless wallet staking (coming soon).
• Polkadot JS Apps Staking section.

Platforms:

• Revolut.

If there are staking UIs that are not on the above list, please post them and they will be added. This will be useful for future major staking updates, breaking changes or otherwise.

App Lead Communication

These changes are breaking changes on the UI side, and so prior to these changes taking place, we need to let UIs know of the upcoming changes. This communication is something that I can contribute to, and if we are lucky comms gurus like @Birdo.

I propose the following comms:

• Post a Github issue on each project’s repo notifying them of PR #14039.
  • Also post an optional invitation to Element channel where we can also post updates.
• Post an update on each issue once PR #14039 is merged.
• Post an update when we know the date of the runtime upgrade, and again 24 hours before the runtime upgrade.
• Post upgrade, myself and other volunteers can test each UI to ensure they still have a working staking UI.

Rationale

beyond ED, controllers are essentially free proxies, whereby users are adding storage to the chain, indefinitely, without a deposit. This is not how most of the Polkadot features work - proxies, proposals, voting, tips, nfts, fast unstake - all requiring reserves or deposits.

Staking proxies solve this, not only abstracting over staking in place of controllers, but for the entire chain. Last time we ran the numbers, less than 10% of all stakers have a separate controller account to their stash - this lends credence to a notion that controllers are either a failed feature, or a niche feature, that only a minority of users wish to use.

For those users, proxies will be the better and more flexible option as they go beyond the staking pallet (fast unstake, nomination pools are all a part of the staking system that stakers will also interact with).

The deprecation of controller accounts is not a new idea - @kianenigma posted about it 3 years ago. So if we want to accelerate the adoption of proxies - something staking dashboard is pushing quite aggressively now - then controller accounts need to be resolved (removed).

While 20 DOT for an initial proxy deposit is not a trivial amount, the amount can be changed via governance. But for this to happen, proxies need interest and adoption - something that we as staking UI leads can push forward.

I want to stress also that using a separate controller account is something that the wikis and JS Apps prompt users to do, very directly. Even so, 90% of stakers still use the same stash address as their controller. This further suggests that controllers are niche / unwanted. Again, proxies offer the added security that controllers do, and do it better as they can span multi-pallet, and have the deposit mechanism at play.

From a UX standpoint, it also does not make sense to pollute our UIs with unwanted / unused features. In this case, there is a huge win in onboarding, whereby users do not need to learn this “stash” and “controller” abstraction. It will simply be either nominate directly or join a pool, with proxies added to the mix for advanced / security conscious users

Current Controller Deprecation Efforts on Staking Dashboard

Drawing down the unique controller accounts will take an unpredictable amount of time.

Staking dashboard from 1.0.7, beyond proxy account support, will provide a prompt to unique controllers that will give one-click access to updating it to the stash account:

[shawntabrizi]

@ross

Controllers are essentially free proxies, whereby users are adding storage to the chain, indefinitely, without a deposit.

To be a little pedantic, I am not sure I entirely agree with this statement. Controller accounts need at least an existential deposit to function, which is basically the same as a storage deposit.

But yeah, this transition from Controller / Stash to using the basic proxy primitives will simplify the Staking code, and also make finding and acting on Staking proxies more consistent. This is a great step forward.

[ross]

@shawntabrizi

To be a little pedantic, I am not sure I entirely agree with this statement. Controller accounts need at least an existential deposit to function, which is basically the same as a storage deposit.

* Quickly puts a "beyond ED, " disclaimer in the text *

Very true, set_controller fails if the candidate does not have ED.

[gpestana]

I think this is a good direction and the roadmap looks solid to me!

Last time we ran the numbers, less than 10% of all stakers have a separate controller account to their stash - this lends credence to a notion that controllers are either a failed feature, or a niche feature, that only a minority of users wish to use.

Hopefully this won’t be the case in the future when proxies are fully supported in the different staking UIs, but perhaps wide usage of proxy accounts needs a push (in general, not only in the context of staking).

[ross]

I think this is a good direction and the roadmap looks solid to me!

Hopefully this won’t be the case in the future when proxies are fully supported in the different staking UIs, but perhaps wide usage of proxy accounts needs a push (in general, not only in the context of staking).

Thanks @gpestana! I think in terms of the latter comment, if proxies do not get widespread use, at least they are siloed in their own pallet and do not interfere with other initiatives. I don’t think proxies will be a poster child of Polkadot, but they do offer awesome utility when it comes to security. Multisigs and being able to proxy a hardware wallet address are unique use cases that we offer that will solve some real problems for people.

When we come to deploying the staking parachain, I imagine all UIs will need to switch their endpoints from the relay chain to the parachain endpoint. So what we can do is treat this initiative as a “dry run” (although it is not so dry), and maintain our list and communication channels of UI leads so the parachain migration can go more smoothly. We’ll be able to apply all our learnings & infrastructure built here to the real breakage of switching to the parachain.

[PolkaGate]

Although we believe that a controller account may become redundant with the availability of proxy accounts, we do not recommend removing the setController function from the blockchain. Instead, we suggest that UI developers offer a simplified mode for average users that hides the controller option during the bonding process. Advanced users can still access the full capacity of the blockchain if they choose, and any changes to the chain should remain backward compatible.

[Birdo]

Late reply on my end (must check the forum more!)
I’ve worded up most of the WALLET teams and will ping some of the others that I have contact with

[filippoweb3]

hey @ross I totally agree with this. I would also add that controller accounts are redundant as staking proxies cover everything a controller does plus you can bond more funds (and change controller, not very relevant in this context ).

I see that having a controller or proxy for most of the users is impractical, especially for ledger users as they do not need passwords and they can just sign with the device. Now that the dashboard supports natively Ledger with no extension (and metadata updates needed, etc) this probably eases users’ experience.

Curious to see what happens when the dashboard will allow the use of proxies but in my opinion it might not change much the situation.

[piffle-rack]

@ross

While 20 DOT for an initial proxy deposit is not a trivial amount, the amount can be changed via governance. But for this to happen, proxies need interest and adoption - something that we as staking UI leads can push forward.

I would support such a change. I have been trying to write some “How to keep your DOT secure” guidance and was very surprised to see that it costs more to create a proxy or multisig than it does to buy a hardware wallet. (OK, it is a deposit that you can recover eventually when you stop using the address, but it is still an upfront cost you have to pay to create your secure setup.)

[ross]

Staking dashboard 1.0.7 will be deployed later today. It contains basic support for proxy accounts - I will share the UI here after responses to latest posts.

Following up with feedback:

@PolkaGate Although we believe that a controller account may become redundant with the availability of proxy accounts, we do not recommend removing the setController function from the blockchain.

So setController will not be removed in the near future. I estimate it will be Q1-Q2 next year that it would completely be removed, once the migration away from controller has been completed already.

we suggest that UI developers offer a simplified mode for average users that hides the controller option during the bonding process.

Absolutely spot on, this ideally should be done now. Staking dashboard over the last few months has slowly drawn down controller support. It firstly removed controller configuration from the nominator setup flow, then iteratively removed or decreased the screen estate of controller UI. Now it is at a stage where only the controller account stat is showing on the nominate page.

Even though controller UI is being removed, the dashboard will still support signing txs as the controller (that is essential for bonding, managing nominations, etc) until we completely migrate to everything being signed to the stash. This again is months away.

A controller deprecation prompt in other staking UIs will be super helpful to help draw down unique controllers. This is of course at the UI developer discretion, & not compulsory.

@Birdo I’ve worded up most of the WALLET teams

Awesome! Syncing offline.

@filippoweb3 I would also add that controller accounts are redundant as staking proxies cover everything a controller does plus you can bond more funds (and change controller, not very relevant in this context ).

Exactly, it is essentially removing duplicated logic on chain, in favour of a more robust solution. I agree that proxy will be impractical for many users, and the knowledge barrier it presents will mean that users won’t naturally jump onto them as soon as they start using Polkadot.

Proxies do present an interesting use case for Ledger users who do not wish to use the Ledger device itself - they could register a proxy for the Ledger account & have that proxy live in another wallet or web extension to sign tsx on the Ledger account’s behalf. This is indeed a more advanced use case, & most users will likely be happy simply using the direct Ledger support to sign txs with the device itself. If it’s locked away in a safe somewhere though, proxies come to the rescue.

Curious to see what happens when the dashboard will allow the use of proxies but in my opinion it might not change much the situation.

Basic proxy support is here pending a final feature of allowing the declaration of delegates (so the delegator need not be imported) will be introduced in the next update.

Staking Dashboard 1.0.7 Proxy Account Support

Proxy accounts are sub-categorised under the delegator on the account selection screen. UI has been introduced to represent proxies, such as the double Identicon, and the left arrow pointing to the proxy type:

Crucially, proxy accounts also need to be able to be selected as a standalone account, not just as a proxy to another account. The above screenshot demonstrates this, whereby Ross 1 is in a pool and acts as an Any proxy to Ross Nominator. UIs need to give users access to both.

Ledger Drawback: Note that Ross 1 is a Ledger imported account - Ledger accounts can also act as proxies, but we are awaiting nesting support for a range of calls before we can enable proxy signing directly from Ledger. Dashboard will fall back to the delegator account when signing transactions, if a Ledger-imported proxy account is currently active.

On the Overview page, the active proxy account is displayed under the active account (the delegator), and an additional badge is present in the page header when a proxy is active:

Crucial in understanding proxies: The active account remains the delegator (or proxied) account. The proxy is just the signer, that signs tsx on behalf of the active account / delegator / proxied account / the account that registered the proxy.

When it comes to signing & submitting extrinsics, the dashboard will now display the active proxy account as the signer by default, and will fall back to the active account if the proxy does not support the call in question (or if a Ledger proxy account is currently active, until the required nesting support is rolled out). The signer is displayed alongside the tx submission button and estimated fees:

Note the “Signed by Proxy” badge. This sign badge now persists for every transaction, & displays who is signing the tx in question.

With these updates in place, UIs can now refer to the staking dashboard to guide or aid in their own proxy account integrations. Detailed implementation notes will be published after the next update, which will bring better proxy support to the dashboard.

[ross]

Substrate Controller Deprecation PR Now Merged

PR Merged: https://github.com/paritytech/substrate/pull/14039

The bond and set_controller call signatures have now changed in the Substrate codebase, and will take effect in a future runtime upgrade (version and date is yet to be determined).

• set_controller(controller) will become set_controller()
• bond(controller, value, payee) will become bond(value, payee).

The following announcement has been posted as issues on known staking UI repos:

---

Polkadot and Kusama nominator controller accounts are being deprecated

Polkadot and Kusama nominator controller accounts are being deprecated

This is an issue to notify the maintainers of this repo that nominator controller accounts are being deprecated on Polkadot and Kusama, in favour of proxy accounts. In an upcoming runtime upgrade (version and date is yet to be determined), 2 call signatures of the staking pallet will change. These are breaking changes for UIs, so UIs will need to update their codebases when the changes come into effect.

Call Changes

The staking.bond and staking.setController call signatures have now changed in the Substrate codebase PR here, and will take effect in a future runtime upgrade.

• set_controller(controller) will become set_controller(). This call will simply set the controller account to the caller’s stash account, if it is not already.
• bond(controller, value, payee) will become bond(value, payee). This call will now set the caller as the controller account (same as the stash).

UIs can prepare now by adding a controller deprecation message, and allow stakers to change their controller accounts back to their stash using the existing staking.setController(controller) call. The Polkadot staking dashboard recently deployed this functionality and may be useful as reference code.

Next Steps

• A follow-up message will be made when we know when these changes will be on Westend, giving UIs time to test any needed changes.
• Follow-up messages will be made here when we know the runtime version and date of the change on Polkadot and Kusama.

Other Resources

• Polkadot Forum Discussion: Staking Controller Deprecation Plan + Staking UI Leads Comms

[ross]

Westend now reflects the changes of bond and set_controller.

• set_controller(controller) has become set_controller(). This call simply sets the controller account to the caller’s stash account, if it is not already.
• bond(controller, value, payee) has become bond(value, payee). This call now sets the caller as the controller account (same as the stash).

UIs can now test any necessary changes on Westend leading up to the mainnet releases.

We can assume that the next Polkadot and Kusama releases will reflect these changes, and that it will be at least 4-6 weeks before they are deployed on the networks.

[AntonTheDay7]

Hey everyone!
@ross we are planning to adapt to these changes in upcoming Nova Wallet v6.4 update.
After observing changes in the Substrate code & on Polkadot Staking Dashboard, there are couple of questions raised:

1. Should we follow Polkadot Staking Dashboard and advice people to remove their Controller accounts while in fact they are still working and such advice can be considered as downgrade in terms of security for a user?
2. Staking Proxies are not a part of Nova Wallet yet, as well as I see that on Staking Dashboard it only removes the controller, not replacing it to the Staking Proxy for a user — I would assume that’s because of required deposit for Proxy?
3. What is exact timeline for a let’s say receiving Kusama update for removing Controller account functionality, aka hard deadline for people to de-activate their Stash-Controller setup?

And to emphasize — Controller account was always considered as “advanced” feature in Nova, that’s why we have removed it from the default staking flow & user can setup it only after they have established Staking. We don’t have any data how much of Nova users are using Controller accounts, and in fact we often observed the case that they initiated Stash-Controller setup unconsciously due to Polkadot JS UI, and later on were wondering why e.g. after importing only Stash account to Nova they are asked to import Controller account and what is Controller account at all (clearly an indicator that user was not understanding what they were doing back then in Polkadot JS UI).

I’m also personally all in for migrating to Proxies since it’s one of the upcoming features to Nova.

[ross]

Hi Anton, that is great that Nova Wallet are on board with these changes. Controller deprecation prompts in UIs with the ability to assign the stash as controller would be very helpful to expedite the transition. Of course this is not a compulsory requirement, but it would be helpful.

We expect that the winding down of unique stash controller pairs will take a number of months. I envisage that it will be at least early next year when we will be in a position to assume the remaining unique pairs would be dead or inactive accounts, and thereafter an OpenGov proposal can be opened to update those remaining accounts to the same stash & controller. It will be only after this that we can start removing runtime logic pertaining to the controller account.

Giving users free proxies has been a past discussion point, but such an effort requires a large, expensive migration. On top of this, such a small % of users use controller accounts, it is questionable if users actually want a proxy account - and if they were given one, there are no end-user UIs currently available to manage them, and only Wiki pages to refer to for guidance on the feature. So such a move IMO is unrealistic / unviable & is something we are not ready to offer.

[Denjiro]

Hi everyone, I am currently staking with two Polkadot addresses that are on my Ledger, and I receive my rewards on a hot wallet via Nova. I find this setup very convenient. Before that I had to use my Ledger and transfer my rewards to my hot wallet. I would like to continue to receive my rewards directly on my hot wallet, will this still be possible?

[ross]

Absolutely, it is possible to set your hot wallet address as your reward destination. In staking dashboard this is under “Payout Destination” on the Nominate page.

[Denjiro]

Yep thanks i did it in staking dashboard . What i would like to know is if i can continue to get my rewards on my hot wallet ? It is actually very useful for me and i would not like this to change honestly

[ross]

Excellent. Yes indeed, you are able to receive rewards to any account of your choosing.

[Denjiro]

Even after Staking Controller Deprecation update ?

[ross]

Yes. Payee destination logic is not changing.

With that said, we do have a payee destination of “Controller”, but I imagine a migration will deprecate this in favour of the “Account” option with the controller address as its value. From a user perspective though, nothing will change.