Staking Controller Deprecation Plan + Staking UI Leads Comms

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

:rocket: 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 :slight_smile: ).

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 :slight_smile: 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.

1 Like