Polkadot Staking Experience: Representing the Stash and Controller Account
This product is a work in progress, designed to communicate ideas, generate feedback, and define a solid foundation for application-side Polkadot.
Opinionated vs Unopinionated Dapps
The question of how opinionated a decentralised app should be plagues front end developers in an effort to find the right balance between usability and maintaining decentralised sources of data.
The question of how opinionated the Polkadot Staking Experience should be will be a recurring theme throughout its development as we attempt to shape the app in the most ideal way for the Polkadot community.
Two primary considerations have already made themselves known at this stage of development:
- How do we find the balance of using node-derived data and third-party services? The approach we are taking has been described in my previous piece and can be summarised as the following: Node data drives the app, whereas third-party services complement it.
- How do we represent the idea of Stash and Controller accounts — and should the paradigm of having two separate accounts be assumed or enforced by the app?
This second question is the focus of this piece.
Recap: How Accounts Are Imported
Most Dapp dashboards (Terra’s Anchor and Nexus Protocol, Solana’s Marinade Finance, Lido, and so on) all require users to connect to a wallet, with one active account at any given time.
Upon connecting a wallet, the dashboard populates its content based on the active account’s activity. This is the simplest approach of Dapp account integration.
Polkadot JS Apps takes the opposite approach of importing (and even creating) accounts, by providing multi-account management features and not assuming anything about their roles.
Polkadot JS Apps does not assume which accounts are Stashes and which are Controllers — and nor would this be the correct approach given that staking is only one of many functions of the app. It is up to the user to decide what an account is and what they want to do with them.
Concretely, Polkadot JS Apps is un-opinionated, whereas the previously mentioned dashboards are opinionated — assuming the connected account is there for a particular purpose.
With Polkadot Staking Experience, we should be aiming for the expressiveness of being un-opinionated, but enforce certain paradigms where they make sense, to guide the user, decrease the learning curve, and ultimately make for an easy-to-use Dapp.
Representing the Stash and Controller
When it comes to enforcing a Stash and Controller account, the app is currently acting as opinionated: both accounts need to exist to fully interact with the dashboard.
At the same time, singular accounts that have been configured to be both Stash and Controller outside of Staking Experience are also supported — and the Controller can indeed be updated to a separate account if the user opts to do so.
We therefore have a somewhat-opinionated representation of accounts and their roles.
The Stash and Controller are prominently represented in the header of the Dapp:
When we switch accounts however, we are switching the Stash, and not the Controller. When we do so, the controller is derived from the stash account’s on-chain state.
Making it obvious that we switch the Stash account will be paramount to minimising ambiguity of the Dapp.
Of course, an account may not be staking yet, in which case a Controller will not be set. The app realises this and simply states the Controller is not yet set:
There is also another scenario to consider— that of the Controller not being amongst the connected accounts.
This scenario would not happen by solely using this app, but could happen when accounts have been configured for staking outside of the App, using external wallets, etc.
We have to account for this scenario too. Staking Experience does this by explicitly stating that the Controller account is not amongst the connected accounts (currently via the Polkadot JS extension).
It then gives the user the choice to change the Controller account (an extrinsic that is signed by the Stash account):
The Advantages of Being Opinionated
To sum up this piece, it is worthwhile to point out the advantages of taking this opinionated approach — which hopefully are evident by the way we have enforced the Stash / Controller paradigm.
An opinionated Dapp, when designed well, can:
- Lessen the ambiguity of how it should be used, guiding the user with the ideas it has explicitly presented
- Make the app easier to understand, with less user-facing decisions
- Streamline help content, now structured around concrete usage patterns.
For interested non-Parity parties: Please contact me for any constructive feedback or ideas to improve the ideas discussed in this piece. @rossbulat on Twitter is my preferred public communication channel.
