On collective membership in council.

4yrs ago
10 Comments

rel: https://kusama.polkassembly.io/post/28

Here's a scalable way to get more direct representation on council for the community based on only the existing multisig functionality available on Kusama.

Creating a collective councilor today

A core feature of the multisig pallet is that onchain it appears to be indistinguishable from any other account (other than the fact that controlling a multisig is done purely through utility pallet extrinsics) - this means that:

  • any role that an account can participate in can be performed by a multisig account as well.
  • an account can be proved to be a multisig account to an offchain observer
  • "internal" activity in the multisig is public onchain and can provide accountability to the greater community.

Presumably, one could:

  • Create a multisig with the desired membership+thresholds, (fees)
  • Send it's address KSM for identity, and extrinsic fees, (10locked+fees KSM)
  • Set onchain identity information, this may require using custom fields to point at the members of the multisig.
  • Signal candidacy in Council - each participant of the multisig votes (ideally exclusively) for the multisig, the multisig votes for themselves. Hopefully this is enough votes to get into the runners-up list. (locks)
  • Post multisig details in a public forum, and announce collective candidacy. This can be verified by using (threshold, membership) data to recreate your multisig address.

From then on, any activity of this collective concilmember will require the declared threshold of it's members to agree in order to execute.

Considerations

Multisigs in the utility pallet do not have dynamic membership, for better or worse. This means you can trust that the membership of the collective you've voted for will remain consistent, but also means that you need to create a new multisig and apply for candidacy if you do need to change the membership of the multisig for any reason.

In addition, multisigs are not limited to any type of behavior, so members need to be collectively vigilant of a part of the multisig colluding to add a malicious backdoor via recovery - for example.

Also, depending on the chosen threshold of the multisig, it may be less agile than a single individual councilor (there are also scenarios with lower thresholds where it may be more agile)

Up
Comments
No comments here