Introducing Delegated Voting: Enhancing Governance on Moonriver and Moonbeam

Hey @Lordglmr ,
There will be a dashboard that will display delegate’s info. More info coming soon.

2 Likes

Hi Iyn, how and when the selection for delegators happens?

delegated voting on Moonriver and Moonbeam is being implemented through the Karma DAO tool, which provides a user-friendly delegation dashboard. not sure about the ETA, but it will definitely be announced when it’s ready, so stay tuned…

2 Likes

Hey @Lordglmr ,
The delegation dashboard is currently being tested internally.
We will reach out to several community members sometime next week so they can test the dashboard and provide feedback.
There won’t be a specific process for selection of delegates. Anyone can become a Community Delegate following certain steps which we’ll share in the coming weeks.

3 Likes

Hi Lina.

I very much enjoy providing feedback to UI, I did so for the polkadot.js and Astar. If you redesign it, let me know. I enjoy thinking about the implications of UI on governance and resource allocation (treasury spending). I think this should be of the utmost importance before users come.

Some quick notes on the current setup and pain points I experienced.

-Limited display space to consume delegates.
Solution 1 : Remove ‘Tracks’ e.g. Root, red, gov and grants from delegate homepage ‘profile tiles’. Why? Everyone elects ‘all’ anyway.

    Profile Tile on delegate homepage

• Replace tracks with “Bio". Limit to 160 characters. (i) Tooltip: “About & Currently working”. Why? LinkedIn provides 65 characters for work. Additional 95 characters plenty.
• Instead of adding a “Currently working field” encourage the use of hyperlinks with top users already e.g. SIK to train/encourage users.
• Add GitHub repo icon link
• Add LinkedIn icon link
• Change “score” to “rating”.

  Overview statement hierarchy

→ Add separate input fields with visible character counts remaining to force the user to condense + create value e.g. statements on tiles starting with “hello everyone” are not useful.
• ‘Bio’ (160 characters)
• ‘Currently working on’ (add link)
• ‘Skill & Specs’ on offer (300 characters)
• “Contributions to date” (300 characters) (i) Tooltip: Moonbeam & other ecosystems
• “Why delegate vote to me” (300 characters)
• Change “interests” to “skills” and place above tracks. (Nobody cares what you are ‘interested in’…they care about ‘skills’ as to allocate resources more efficiently.

  User Biasing Controls

a) Populate the top 250 delegates and shuffle results. Consider the Bayesian formula used by IMDb to populate the top 250. For example:

weighted rating (WR) = (v ÷ (v+m)) × R + (m ÷ (v+m)) × C where: R = average for the movie (mean) = (Rating) v = number of votes for the movie = (votes) m = minimum votes required to be listed in the Top 250 (currently 25000)

b) Add a dedicated column or row for rising stars. e.g. slider that can hit arrows left and right encourages equal opportunity. Very useful hiring feature on Fiverr to identify talented hardworking individuals fast.

c) Profile tiles on the homepage should remove the row “delegated tokens, voting weight, on-chain votes, total delegators” etc. to increase real estate for more profiles. Why? User eyes directed to “delegated tokens” in terms of visual hierarchy → encourages vote dumping and centralizes voting.

Average Tokens per delegator and number of delegators would be a better metric

It may sound silly but a talk of note w/ regards to balancing game design for Pillars of Eternity could be applied to Moonbeam. This includes stat and weight adjustments based on a reversion to a base level or in Moonbeam’s case could be used in a similar manner except the modifier is based on the global average of tokens per delegator and number of delegators, and the skills each delgator has been scored or endorsed. Not fleshed out…but if you watch this you will get what I mean. Fantastic talk.

  Periodical reset of delegation, and/or by time per user delegation or delegate

Overall I think the delegate system needs to consider periodical reset of votes, and/or delegation tapering, so votes have less weight over time to encourage the reallocation of votes for the sake of effective treasury spending. My observation with the Astar Staking system was that dAPP staking when it unlocked due to maintenance, made me reconsider who I staked with. Staking Rewards were given to ghost projects no longer operational for a prolonged period. The same will be true for votes and treasury spending when delegates agglomerate and begin to game the system.

Hope this finds you well. Cheers, Steve

1 Like

Hi @steve_martin ,
Sorry it took me so long to respond!

Your feedback is very specific and i like that! Thank you!
Though I didn’t get to which UI you are referring to - is it the Dapp or the Karma Dashboard?

If you are referring to the Dapp here, the tracks are not exclusively for the delegates but the proposals as well and they are quite useful to sort out types of referenda.
If you are referring to the Karma dashboard, the tracks again show what types of tracks the Delegate chose. And it doesn’t take up much space.

I agree with you here - adding a GitHub might be a good idea. Though when we designed the dashboard, we assumed not everyone would be a GitHub user so we added an option to add any link. And in some cases people do add their GitHub link.

This is something we can look into closer.
I’ll tag @mmurthy here from Karma team who built and now maintains the dashboard :raised_hands: Mahesh, maybe you have something to add here.

1 Like

Thanks for the reply.

I was referring to the Karma Dashboard. Yes, they are useful for sorting, but for the reasons I have outlined, there is not much point in displaying them as delegates are proving to select all, therefore the information conveyed provides low value to the profile tile which token holders use to decide who they should vote for.

@mmurthy I would be interested to hear your thoughts concerning my suggestions.

1 Like

Thanks for these suggestions! Super insightful.

In theory, delegates shouldn’t be choosing all tracks I guess? That was our initial hypothesis and the design for it. I think there are other ways to display tracks. Your point is valid though, it is too cluttered because of that.

Regarding User biasing control: I agree with this if there were lots of delegates and tokenholders were having difficulty choosing them. If there are only a handful of delegates who are active, it’s not a problem I believe. But we will consider a randomization technique like you proposed in the future.

Thanks for all the other UI feedback, we will evaluate and update them where it makes sense.

1 Like

No worries. Happy to give feedback anytime. Very much looking forward to seeing what you do with the next iteration even if it doesn’t include any of my suggestions.

2 Likes