Joystream / Joystream/joystream
Idea: Partial Council Member randomness
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 1.4k
- Forks
- 116
- PR merge metrics
- No merged PRs in 30d
Description
Currently, the council is elected purely on the amount of tokens staked by a candidate combined with the tokens voters stake to support the candidate. This allows for potential situations where the council members either are highly repetitive and the same voices hold substantial control over the direction of the platform, or worse that someone manages to take over the entire council permanently (unlikely, but it is still technically possible)
One idea that could work to provide some balance against this is allowing a set percentage (it could be set as low as 10-15%) of elected council members be randomly elected from those who have announced their candidacy and are also above some certain threshold of total stake (the threshold would exclude those that just stake the absolute minimum to announce their candidacy and therefore limit it to candidates that at least have some level of support from the community).
These "random" applicants would not override those that are successfully voted in via stake, but rather be an extension. For example, if 16 council members are elected, it would add 15% (2) candidates who are chosen from a pool of applicants who have a combined stake above 1.3m JOY.
There are probably many negatives to an approach like this, but it may provide some form of safeguard against the council having semi-permanent members for all of eternity.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files, tests, or entry points. First review the council election and candidacy implementation, then determine how stake thresholds, candidate pools, random selection, and council size would be specified and tested; done would require an agreed design and corresponding implementation scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- blockchain, rust
- Domain
- blockchain
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100