Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create route for council decision - CouncilResponse(card) #12

Closed
patrickwieth opened this issue Dec 24, 2018 · 5 comments · Fixed by #55
Closed

create route for council decision - CouncilResponse(card) #12

patrickwieth opened this issue Dec 24, 2018 · 5 comments · Fixed by #55
Assignees

Comments

@patrickwieth
Copy link
Member

Card drafts need feedback from the council members to enter trial phase. This route is for submitting feedback.

@patrickwieth
Copy link
Member Author

Every council member of a certain council can give their decision on the card.
This means feedback is:
result: approve / deny / revision
notes: string given as info to creator (in case of revision notes must be at least 100 chars)

For making a council decision you must pay a collateral in credits.

the route must implement a commit reveal scheme, so that the other members of the council cannot see the actual votes before voting themselves.

@patrickwieth
Copy link
Member Author

https://docs.starport.com/guide/scavenge/02-game.html
here is a commit reveal scheme explained

in our case it is a bit more complicated, because there are only 5 council members and they only have 3 voting options, so this means there are only 15 possible options to guess what the source of the hash is and then it is very easy to brute force. Therefore we use something like a salt, so when you commit you add a random value to the input of the hash and on reveal you also reveal the random value.

@patrickwieth
Copy link
Member Author

patrickwieth commented Feb 6, 2022

when there are 5 commits in the council, the state of the council should go to something like "reveal phase"
in this phase the users reveal the information of their commits and then a council handler is called afterwards:

if majority voted deny then

  • all approve voters lose their collateral and it is distributed to the deny or revision voters
  • the council ends
  • the card state transitions from draft (we change prototype status to draft) to banned

if majority voted revision then

  • the council is paused until the card creator has uploaded a revisioned version, then commit reveal starts again but there is no
  • revision option anymore (if someone sends tx with revision this is deny then)

if majority voted approve then

  • all collateral is moved to a trial treasury (or stays in there if a treasury is used from the beginning)
  • the card state transitions from draft to trial

@patrickwieth
Copy link
Member Author

I think it makes sense to make the revision vote visible, so only approve or deny are hidden, because it makes sense to inform the other council members that you want a revision
the idea is that sometimes there are small and easy revisions, where some council members would be like "ah well, I approve this card" and others suggest a good revision and the approvers would agree and like the revision but then it is too late. The other way around might also exist, most voters think "nah this card is obviously unfair" but somone offers an easy fix to make the card fair...
I think with revision being public it is possible for the council to give good feedback with a higher likelihood

@lxgr-linux lxgr-linux linked a pull request Feb 26, 2022 that will close this issue
2 tasks
@patrickwieth
Copy link
Member Author

The lifecycle of a council:

  1. A card (prototype) is pushed into a new council. This is done to change the card status from draft to trial.
  2. A council is filled with 5 members. The members are selected at random from all players who have enlisted for council participation. The creator and artist of the card in the council are excluded here. Players can only be enlisted if they are not already in a council. If there are not enough players enlisted so the members cannot be filled to 5, then the council is opened after enough have enlisted and are filled in over time. Enlisting for a council has a time limit, if it is reached, the player drops from a council that has not started (does not drop from a started council).
  3. The council starts once there are 5 members in there. Now everyone can see the card and make a decision.
  4. The first decision is made by all 5 council members as "approve", "reject" or "revision". Only the revision decision can be seen by the others once it is made, the rest becomes visible if the round is completed. The revision decision comes with a note that must be written by the one who does revision. Minimum of 30 characters must be written as note.
  5. The first round is completed when all 5 votes are given. If the majority voted approve, the card moves to the trial phase. If the majority voted revision or reject, there is a second round if there is at least 1 revision vote. If there are 0 revision votes, the card is directly discarded.
  6. In case of a second round the creator has the chance to adjust the card in the card creator as usual and submit it for the 2nd time.
  7. In the second voting round the option "revision" is no longer available. The council has to decide if the card is now ultimately approved or rejected. Majority decides here.

The lifecycle above does not describe cash flow. This comes now: To participate in the council every member has to put down a collateral first. The collateral can be changed via governance proposal and is initially 50 credits. The creator of the cards has to put 10 times the collateral as a fee for the council. All of these credits go to this council's treasury.
Council treasury payout:

  • if the card is rejected, every rejecter gets 2*collateral back from the treasury. Rest goes to public pool.
  • if the card is approved, 5*collateral goes to the cards voting pool, the rest of the payout is delayed to the end of the trial.
  • if the trial is a success, 2*collateral go to the card approvers, rest goes to public pool
  • if the trial is a failure, 3*collateral go to the rejecters, rest goes to public pool

check out this for params:
https://docs.google.com/spreadsheets/d/1n5liFKUI-ktCX8OCFKWFPaPIvDdKnc2v-iF375xCJI8/edit#gid=0

@patrickwieth patrickwieth mentioned this issue Dec 18, 2022
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants