Roles in Nomination Pools

Tech Talk
1

Context
We recently launched Nomination Pools which enables any Polkadot user (even with low amounts of $DOT) to become nominator via these bonded pools and earn staking rewards. All nomination pools have the following roles today - Depositor, Nominator, State Toggler and Root. You can read more about them here.

We are now looking into adding commissions for pool operators as an incentive to manage a pool. This will also require us to add another role Manager (still looking for suggestions for a better name) which can set/modify commission rate.

Since it is infeasible to keep adding roles every time we add a new functionality to nomination pools, we wanted to open a discussion with the community about their thoughts and ideas on how to go about this.

Dumping my general thoughts

  • We do want to add multiple roles for mutually exclusive functions since it can be useful in what we call as signalling. For example, if a pool wants to signal the commission rate will never change, they can kill the Root and the Manager account to effectively lose the ability to change it forever.
  • Saying that, we should always look into combining similar functions in a common role (thinking futuristically if we have to) to keep the roles to a manageable number.

Changes to the roles we are proposing

  • Add a new role Manager that is responsible for setting commission rates (and possibly other configuration parameters in future)
  • Rename State-Toggler role to be called Bouncer which is much more concise (and sounds cooler). :slight_smile:
3 Likes
2

Random thought that isn’t maybe really helping you with your overall question. I would recommend to change Role to some bitflags. This could significantly reduce the state size when most of the roles are being done by the same account. The state would be something like:

struct Operator<AccountId> {
    account: AccountId,
    roles: Roles,
}

#[pallet::storage]
type Operators<T: Config> = StorageValue<_, Vec<Operator<T::AcountId>>>

This would also make it relative easy to add new roles, as you would only need to add a new bit.

2 Likes
3

Will it be user friendly for all these roles for an end user? Like I think we are only thinking for people who are already on Dotsama eco. The feature has a lot of options which can confuse and intimidate and end user. My thoughts

4

Will it be user friendly for all these roles for an end user? Like I think we are only thinking for people who are already on Dotsama eco. The feature has a lot of options which can confuse and intimidate and end user. My thoughts

For users that are not interested, these roles can easily be abstracted away.

My main interest in having roles is, as @ankan pointed out, the ability to freeze some of them by removing them. Basically, with the current setup, the instance your remove your root role, your freeze the current setup. So you can configure roles as nominator to be a smart contract, a DAO, and such, and destroy roles like commission, signaling that you never intend to raise your commission.

2 Likes
5

related PR: Allow pool operators `bond_extra` by Doordashcon · Pull Request #12608 · paritytech/substrate · GitHub

1 Like
6

I’m wondering Dotsama/Substrate aren’t embarked on the same journey that yielded Open Policy Agent (e.g. OPA/Gatekeeper):

Or whatever is considered best-in-breed (Oso, Kyverno, etc.).

Is there no prior art to be leveraged?

7

@bkchr thank you so much sharing the detial so helpful for me.