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.

[menglong]

This post was flagged by the community and is temporarily hidden.

[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