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

DAO Extension #530

Merged
merged 420 commits into from
May 18, 2020
Merged

DAO Extension #530

merged 420 commits into from
May 18, 2020

Conversation

aguycalled
Copy link
Member

@aguycalled aguycalled commented Jun 14, 2019

This PR includes a serie of Deployment Proposals as described in https://www.reddit.com/r/NavCoin/comments/bs4pvn/proposal_for_the_extension_of_the_community_fund/:

  • Adds support for abstaining in the votings. (Version Bit 19) - includes functional test

  • Enables voting state cache, reducing the amount of votes which need to be broadcasted down to 1 per address. (Version Bit 22) - does not include specific functional test, but old fund tests pass having this deployment activated

  • Enables DAO consultations. (Version Bit 23) - includes functional test

  • Enables modification of consensus parameters through DAO consultations. (Version Bit 25) - includes functional test

  • Enables voting delegation and voting from light wallets. (Version bit 27) - includes functional test

  • Allows fund proposals to have a different address for signing the payment requests and for receiving the payment. This allows to use arbitrary scripts as payment addresses, like multisig addresses. When the payment address differs from the owner address, the first will be specified using the p parameter on the JSON object embedded on the strDZeel property of the transaction.

  • Includes UI to manage the new DAO features.

Abstention votes

Abstention votes will be added to the yes and no votes from proposals and payment requests to calculate the minimum quorum.

Consultations can also have abstentions.

New op codes and voting

Op codes

Name
OP_ABSTAIN 0xc7
OP_REMOVE 0xc8
OP_DAO 0xc9
OP_ANSWER 0xca
OP_CONSULTATION 0xcb

Voting

The following assumes the deployment of the voting state cache has been accepted in the network.

Proposal and payment request voting

Script Description
OP_RETURN OP_CFUND OP_PROP OP_YES HASH Inserts a yes vote for the proposal HASH in the state cache
OP_RETURN OP_CFUND OP_PROP OP_NO HASH Inserts a no vote for the proposal HASH in the state cache
OP_RETURN OP_CFUND OP_PROP OP_ABSTAIN HASH Inserts an abstention vote for the proposal HASH in the state cache
OP_RETURN OP_CFUND OP_PROP OP_REMOVE HASH Remove the vote stored for the proposal HASH in the state cache
OP_RETURN OP_CFUND OP_PREQ OP_YES HASH Inserts a yes vote for the payment request HASH in the state cache
OP_RETURN OP_CFUND OP_PREQ OP_NO HASH Inserts a no vote for the payment request HASH in the state cache
OP_RETURN OP_CFUND OP_PREQ OP_ABSTAIN HASH Inserts an abstention vote for the payment request HASH in the state cache
OP_RETURN OP_CFUND OP_PREQ OP_REMOVE HASH Remove the vote stored for the payment request HASH in the state cache

Consultation support and voting

Script Description
OP_RETURN OP_DAO OP_YES HASH Insert a support vote for the range consultation or answer HASH in the state cache
OP_RETURN OP_DAO OP_REMOVE HASH Remove the support stored for the range consultation or answer HASH in the state cache
OP_RETURN OP_CONSULTATION OP_ANSWER HASH Inserts a yes vote for the consultation answer HASH
OP_RETURN OP_CONSULTATION OP_ANSWER HASH VALUE Inserts a vote with value VALUE for the range consultation HASH
OP_RETURN OP_CONSULTATION OP_ABSTAIN HASH Inserts an abstention vote for the range consultation or answer HASH in the state cache
OP_RETURN OP_CONSULTATION OP_REMOVE HASH Remove the vote stored for the range consultation or answer HASH in the store cache

Vote from light wallets

Wallets can now create a new type of Cold Staking address where the voting rights are delegated to a third address.

Syntax:
getcoldstakingaddress staking address spending address voting address

Coins sent to this new type of address will be sent to the following script:

<VOTING PUBKEY HASH> OP_DROP
OP_COINSTAKE OP_IF
    OP_DUP OP_HASH160 <STAKING PUBKEY HASH> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
    OP_DUP OP_HASH160 <SPENDING PUBKEY HASH> OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

The blocks where the coin stake transaction spends one output of this new class, will use the votes stored in the state for the voting key.

Light wallets will be able to modify the voting state by submitting to the network a transaction with the following requirements:

  • The version of the transaction is 8.
  • The first input spends a P2PKH output from the voting address.
  • It contributes to the fund a minimum amount of CONSENSUS_PARAMS_DAO_VOTE_LIGHT_MIN_FEE=0.1NAV
  • Some of its outputs has voting scripts as described in the previous sections.

Consultations

Consultations are permission-less open questions submitted to the network.

Once consultations are created they must gather a minimal support (defined by consensus parameter CONSENSUS_PARAM_CONSULTATION_MIN_SUPPORT=1.5% for range consultations and by CONSENSUS_PARAM_CONSULTATION_ANSWER_MIN_SUPPORT=1.5% for the rest of consultations) in a minimum of 2 answers if a normal consultation or 1 answer if the consultation is about a consensus parameter. Range consultations do not have this requirement. Instead, range consultations must receive support themselves.

In order to give enough time to a large number of stakers to add new answers to consultations, a consultation will never pass until the cycle defined by CONSENSUS_PARAM_CONSULTATION_MIN_CYCLES=2 is over. Consultations will be in a looking for support phase for a maximum of CONSENSUS_PARAM_CONSULTATION_MAX_SUPPORT_CYCLES=4 cycles, and the voting phase will last a fixed amount of CONSENSUS_PARAM_CONSULTATION_MAX_VOTING_CYCLES=4 cycles. An exception will be consultations about consensus parameters, which could end earlier whenever one of the answers have a minimum of 75% affirmative votes at the end of a voting cycle. Between the looking for support and voting phases, there will exist a reflection phase with a lenght of CONSENSUS_PARAM_CONSULTATION_REFLECTION_LENGTH=1 cycle.

Consultations are created through the creation of a transaction with version 6, pay at least a fee of CONSENSUS_PARAM_CONSULTATION_MIN_FEE=100NAV and a JSON object in the strDZeel parameter with the following structure:

{ "v": version bits of the consultation,
 "q": question of the consultation,
 "m": if the consultation version indicates this is a range consultation, sets the lower bound of the range,
 "n": if the consultation version indicates this is a range consultation, sets the higher bound of the range, otherwise, sets the maximum amount of answers a staker can vote in the same block for a consultation,
 "a": an array of strings containing candidates to answers
}

The version bits are:

Bit Dec Desc Comment
0 1 Base
1 2 Answer is numeric and a range between m and n
2 4 Stakers can propose more answers Allows a to be empty, otherwise it must have 2 elements
3 8 Consultation is about a consensus parameter m is used to refer to the id of the consensus parameter, n must be 1 and a can be empty.

Consultations are identified by the hash of the transaction where it was created.

Stakers can submit during the looking for support phase proposals for different answers for every consultation which is set up as such through the creation of a transaction with version 7 and a JSON object in the strDZeel parameter with the following structure:

{
 "v": version bits of the answer, in this implementation only version 1 exists,
 "h": the hash of the parent consultation,
 "a": the proposed answer
}

Answers are identified by the hash of the concatenation of the transaction hash where it was created and the string of the answer.

answer.hash = Hash(tx.hash || strDZeel.a)

New RPC commands

createconsultation

Creates a DAO consultation

Syntax:
createconsultation Question max of simultaneous answers
createconsultation Question lower bound higher bound range bool
Create a normal consultation
createconsultation "Should we all dance together?" 1
Create a range consultation
createconsultation "What will be NavCoin price in USD at the end of the year?" 1 5 true

proposeanswer

Creates a proposal for a consultation answer.

Syntax:
proposeanswer hash answer
Propose an answer
proposeanswer d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f "Yes"

support

Signals support for a specific answer or consultation.

Syntax:
support hash bool
Support an answer
support d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f true
support d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f false

consultationvote

Sets the vote for a range consultation or answer.

Syntax:
consultationvote hash yes|value|abs|remove (value)
Vote yes for an answer
consultationvote d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f yes
Vote a value for a range consultation
consultationvote d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f value 10000
Vote abstain for a consultation
consultationvote d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f abs
Remove a vote
consultationvote d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f remove

consultationvotelist

Shows the list of votes for consultations

Syntax:
consultationvotelist

supportlist

Shows the list of support votes.

Syntax:
supportlist

getconsultation

Shows details of a consultation

Syntax:
getconsultation hash
getconsultation d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f

listconsultations

Shows the list of consultations. Possible filters: not_enough_answers, waiting_for_support, reflection, voting and finished

Syntax:
listconsultations filters
listconsultations waiting_for_support finished

getconsultationanswer

Shows details of a consultation

Syntax:
getconsultationanswer hash
getconsultationanswer d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f

getconsensusparameters

Shows a detailed list of the consensus parameters which can be defined by the DAO.

Syntax:
getconsensusparameters

proposeconsensuschange

Creates a proposal to change the value of one of the consensus parameters.

Syntax:
proposeconsensuschange parameter id value
proposeconsensuschange 10 10000

Consensus parameters

Id Name  Desc  Type Default value
0 CONSENSUS_PARAM_VOTING_CYCLE_LENGTH Length in blocks of a voting cycle NUMBER 20160
1 CONSENSUS_PARAM_CONSULTATION_MIN_SUPPORT Minimum of support needed for starting a consultation PERCENT 150
2 CONSENSUS_PARAM_CONSULTATION_MIN_CYCLES Earliest cycle when a consultation can get in confirmation phase NUMBER 2
3 CONSENSUS_PARAM_CONSULTATION_MAX_VOTING_CYCLES Length in cycles for consultation votings NUMBER 4
4 CONSENSUS_PARAM_CONSULTATION_MAX_SUPPORT_CYCLES Maximum of voting cycles for a consultation to gain support NUMBER 4
5 CONSENSUS_PARAM_CONSULTATION_REFLECTION_LENGTH Length in cycles for the reflection phase of consultations NUMBER 1
6 CONSENSUS_PARAM_CONSULTATION_MIN_FEE Minimum fee to submit a consultation NAV 1000000000
7 CONSENSUS_PARAM_CONSULTATION_ANSWER_MIN_SUPPORT Minimum of support needed for a consultation answer proposal PERCENT 150
8 CONSENSUS_PARAM_CONSULTATION_ANSWER_MIN_FEE Minimum fee to submit a consultation answer proposal NAV 5000000000
9 CONSENSUS_PARAM_PROPOSAL_MIN_QUORUM Minimum of quorum for fund proposal votings PERCENT 5000
10 CONSENSUS_PARAM_PROPOSAL_MIN_ACCEPT Minimum of positive votes for a fund proposal to be accepted PERCENT 7000
11 CONSENSUS_PARAM_PROPOSAL_MIN_REJECT Minimum of negative votes for a fund proposal to be rejected PERCENT 7000
12 CONSENSUS_PARAM_PROPOSAL_MIN_FEE Minimum fee to submit a fund proposal NAV 5000000000
13 CONSENSUS_PARAM_PROPOSAL_MAX_VOTING_CYCLES Maximum of voting cycles for fund proposal votings NUMBER 6
14 CONSENSUS_PARAM_PAYMENT_REQUEST_MIN_QUORUM Minimum of quorum for payment request votings PERCENT 5000
15 CONSENSUS_PARAM_PAYMENT_REQUEST_MIN_ACCEPT Minimum of positive votes for a payment request to be accepted PERCENT 7000
16 CONSENSUS_PARAM_PAYMENT_REQUEST_MIN_REJECT Minimum of negative votes for a payment request to be rejected PERCENT 7000
17 CONSENSUS_PARAM_PAYMENT_REQUEST_MIN_FEE Minimum fee to submit a payment request NAV 0
18 CONSENSUS_PARAM_PAYMENT_REQUEST_MAX_VOTING_CYCLES Maximum of voting cycles for fund proposal votings NUMBER 8
19 CONSENSUS_PARAM_FUND_SPREAD_ACCUMULATION Frequency of the fund accumulation transaction NUMBER 500
20 CONSENSUS_PARAM_FUND_PERCENT_PER_BLOCK Percentage of generated NAV going to the Fund PERCENT 2000
21 CONSENSUS_PARAM_GENERATION_PER_BLOCK Amount of NAV generated per block NAV 250000000
22 CONSENSUS_PARAM_NAVNS_FEE Yearly fee for registering a name in NavNS NAV 10000000000
23 CONSENSUS_PARAMS_DAO_VOTE_LIGHT_MIN_FEE Minimum fee as a fund contribution to submit a DAO vote using a light wallet NAV 10000000

Type of parameters

  • NUMBER. This is a normal numeric parameter.
  • PERCENT. This is percentage and is expressed in cents. 0,5% is written 50. 90% is written 9000.
  • NAV. This is a NAV amount and is expressed in Navoshis. 1 NAV has 100000000 Navoshis.
  • BOOL. This is a boolean and can only be 0 or 1.

@mxaddict
Copy link
Contributor

@aguycalled I tried a gitian and cross compile build of this branch and I ran into a similar issue that I did with my #557 branch.

I've since solved the issue (Making modifications to how the qt.mk is built)

You might wanna take a look at how I did it to get this branch to build in gitian and in travis-ci.

@mxaddict
Copy link
Contributor

More specifically I think the changes are in this commit: 194ef50

@mxaddict
Copy link
Contributor

Same error as the one in travis-ci OSX build

@mxaddict
Copy link
Contributor

@aguycalled I've pushed a commit to this branch which fixes the gitian and cross compile build for qt

@mxaddict
Copy link
Contributor

Fixed a failing test

@mxaddict
Copy link
Contributor

mxaddict commented Jul 25, 2019

@aguycalled Am getting this error on boot of a node with existing datadir

Screenshot from 2019-07-25 10-52-33

EDIT: Also tried with a bootstrap, and got same error

@mxaddict
Copy link
Contributor

@aguycalled Am getting this error on boot of a node with existing datadir

Screenshot from 2019-07-25 10-52-33

EDIT: Also tried with a bootstrap, and got same error

This seems to be resolved in the latest test I did with the PR

@chasingkirkjufell
Copy link
Contributor

This is the first round of report.

  1. Is there a max amount of answer? Tried up to 22 and still going. The display of the answered should probably be ordered.
    image

  2. Not that important but if one propose a question, maybe just default support it? Same as when creating a consultation with answer options.

  3. Current test field does not support typing of other languages I think(tested Chinese), but copy and pasting works.

  4. the RPC command "createconsultation "question" "max of simultaneous answers" does not describe how to also put the answers when creating a consultation.

  5. After a consultation finishes, the view result initially displayed the results view, but then after 1 or more block cycles, results cannot be viewed.
    image

  6. Waiting for support for range consultation does not show any support votes. I understand there is no answer to vote on but might still be helpful to show support count
    image

  7. When changing consensus parameter, waiting for support phase will mess up the look. Wrapping test should fix this easily.
    image

  8. Maybe consider adding a counter for current block cycle? like 182/20000
    image

  9. Same block and blockhash so didn't fork but displayed different count. The node displaying 2/2 votes doesn't seem to get the votes from the other node.
    image

They seem to be in different block cycle, one is one block cycle behind than the other. The lagging node is the node that created the consultation, this consultation had two options but three choices.
Still working on trying to replicate it to nail down what happened.
image
And below is from the nodes that are in the same network but didn't vote at all. Notice voting cycle is different on one of them.
image

@aguycalled
Copy link
Member Author

  1. there's no max. amount of answers. i'll commit a patch to adjust the fee based on the number of answers.
  2. good idea. the wallet should at least suggest it.
  3. do you mean some specific text field?
  4. i'll create a new rpc command createconsultationwithanswers
  5. will review
  6. will review
  7. will add wrapping
  8. yup
  9. will have a look

nice review!

@chasingkirkjufell
Copy link
Contributor

  1. just realized it's because i was forwarding the window into a different machine and used a language not installed by the original machine so please ignore this point.

@chasingkirkjufell
Copy link
Contributor

chasingkirkjufell commented Oct 4, 2019

  1. fired up 6 nodes connected to each other. clean start. only using one node to stake and to create consultation.

the one node staking:
First generated 900 blocks to activate all the forks.
Waited for 120 blocks to ensure consensus parameters didn't change automatically
Created a consultation called"2nd test 10/4" with two answers "1st answer" "2nd answer" not allowing other to suggest answers and only allowing 1 vote.
checked in every now and then to ensure network parameter staying the same and they did
right after consultation finished voting this happened.

image

no proposal was submitted but it changed on itself

@aguycalled
Copy link
Member Author

did you vote for the consultation?

@chasingkirkjufell
Copy link
Contributor

after creating the consultation, voters vote for the answers and once answers found support, the consultation will enter another around of waiting for support. Is it the intended behavior? if so, what support is it waiting for since answers already were supported?

{
"version": 1,
"hash": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"blockhash": "d0a653f4de20af43b8239f276fa665c2b2761a2755c93be2dc31aed5abd5666c",
"question": "2nd test 10/4",
"support": 0,
"answers": [
{
"version": 1,
"string": "2nd answer",
"support": 20,
"votes": 0,
"status": "found support, waiting for end of voting period",
"state": 0,
"parent": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"hash": "8a702d9fae8c398e4180827edfafcce779b470f2f2d4bf34ff2d2cebf3bf16e8"
},
{
"version": 1,
"string": "1st answer",
"support": 20,
"votes": 0,
"status": "found support, waiting for end of voting period",
"state": 0,
"parent": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"hash": "66b8a954166c6bf7c801318d0541bbf34797270e072662f1a78736210a5df948"
}
],
"min": 0,
"max": 1,
"votingCycle": 0,
"status": "waiting for support",
"state": 0,
"stateChangedOnBlock": "0000000000000000000000000000000000000000000000000000000000000000"
}
Fri Oct 4 18:40:23 UTC 2019
{
"version": 1,
"hash": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"blockhash": "d0a653f4de20af43b8239f276fa665c2b2761a2755c93be2dc31aed5abd5666c",
"question": "2nd test 10/4",
"support": 0,
"answers": [
{
"version": 1,
"string": "2nd answer",
"support": 1,
"votes": 0,
"status": "found support",
"state": 1,
"parent": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"hash": "8a702d9fae8c398e4180827edfafcce779b470f2f2d4bf34ff2d2cebf3bf16e8"
},
{
"version": 1,
"string": "1st answer",
"support": 1,
"votes": 0,
"status": "found support",
"state": 1,
"parent": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"hash": "66b8a954166c6bf7c801318d0541bbf34797270e072662f1a78736210a5df948"
}
],
"min": 0,
"max": 1,
"votingCycle": 1,
"status": "waiting for support",
"state": 0,
"stateChangedOnBlock": "0000000000000000000000000000000000000000000000000000000000000000"
}
Fri Oct 4 18:41:23 UTC 2019

@chasingkirkjufell
Copy link
Contributor

did you vote for the consultation?

i did

@aguycalled
Copy link
Member Author

In order to give enough time to a large number of stakers to add new answers to consultations, a consultation will never pass to reflection phase until the cycle defined by CONSENSUS_PARAM_CONSULTATION_MIN_CYCLES=2 is over.

@aguycalled
Copy link
Member Author

Paid 11,500NAV from dev bounty to NL9jPW75P4kNMdvQmFBpYVkZ3sABQtXfYY
minor ux (300) + minor ux (300) + minor ux (300) + minor ux (300) + minor ux (300) + consensus (5000) + consensus (5000)
5993262f1201206a1649a58f4a019849760ee62577840997683f433eb8846ec4

@chasingkirkjufell
Copy link
Contributor

  1. (suggestion) might be helpful to let the user know how many characters are allowed in proposals and answers during the creation window. Would be even better if it's a countdown. Like somewhere in that area.
    image

@chasingkirkjufell
Copy link
Contributor

fail to compile locally
coins.cpp: In member function ‘boost::unordered::unordered_map<uint256, CPaymentRequest, SaltedTxidHasher>::const_iterator CStateViewCache::FetchPaymentRequest(const uint256&) const’: coins.cpp:157:34: error: could not convert ‘((const CStateViewCache*)this)->CStateViewCache::cacheProposals.std::map<uint256, CProposal>::end()’ from ‘std::map<uint256, CProposal>::iterator’ {aka ‘std::_Rb_tree_iterator<std::pair<const uint256, CProposal> >’} to ‘boost::unordered::unordered_map<uint256, CPaymentRequest, SaltedTxidHasher>::const_iterator’ {aka ‘boost::unordered::iterator_detail::c_iterator<boost::unordered::detail::ptr_node<std::pair<const uint256, CPaymentRequest> > >’} return cacheProposals.end(); ~~~~~~~~~~~~~~~~~~^~ CXX libnavcoin_common_a-keystore.o make[2]: *** [Makefile:6132: libnavcoin_common_a-coins.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory '/home/-/navcoin-core/src' make[1]: *** [Makefile:10465: all-recursive] Error 1 make[1]: Leaving directory '/home/-/navcoin-core/src' make: *** [Makefile:706: all-recursive] Error 1

@chasingkirkjufell
Copy link
Contributor

  1. (suggestion) I think a better way of showing support is maybe dividing the current support or vote count by the current block cycle height. Say if there are 3 answers and they got 10 5 2 supports repectively on 20th blocks in a 30 blocks block cycle, the support pie will show 50% support 10% support and 4% support for answers 1, 2, and 3. Same for the range consultation since now it showed the whole block cycle block count as the denominator.
    image

  2. (just an observation of inconsistency, either is fine)Right click on consultation in qt wallet and click view votes, only range consultation updates voting whenever "view votes" is click, option based consultation will only update after clicking other tabs like "fund proposals" and then click back to "consultations"

  3. getconsultation returns different sorting sometimes
    image

  4. I think support counting should be stopped and stored at the end of support phase? Right now support is still being reset on voting phase sometimes (I think it's reset if the answer is voted on, meaning it counts both support and votes all over again. If the answer is not voted on, support count stays the same as when it passed support phase)

  5. Unchecking the boxes does not remove voting power, it actually results in voting on both answers not only for multiple answer questions, but also breaking the rule and voting on both when only 1 answer is allowed.
    image

  6. Why would it be 0? Wouldn't it be either 30/30 or 1/30 for block cycle of 30 blocks?
    image

  7. Also, the cycle progress percentage does not update the denominator if the consensus parameter is changed.

  8. (suggestion) Maybe not so many decimals?
    image

  9. "Range consultation" vote count still accumulating after it's finished. It's not reset for each cycle just keeps adding up(the only staking and voting node).

  10. "Option consultation" resets voting count and voted again after it's finished in qt wallet (the only staking and voting node).

  11. (working on replicating it) nodes are seeing different vote counts after "range consultation" is finished.

@chasingkirkjufell
Copy link
Contributor

chasingkirkjufell commented Oct 8, 2019

for point 13, i 'd like to change to suggest to display % still but it'll stop increasing once it reaches the requirement % to be supported (1.5%) to prevent influencing voters decisions from having differnet amount of supports. Just an idea though.

by the way voting list still not sorted
image

@navbuilder
Copy link

A new build of dcf494b has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

@navbuilder
Copy link

A new build of 2c72313 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

@navbuilder
Copy link

A new build of 89d3f56 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

@navbuilder
Copy link

A new build of 73a5003 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

@navbuilder
Copy link

A new build of 482939a has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

@navbuilder
Copy link

A new build of 35ce8c7 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

@navbuilder
Copy link

A new build of 0332bc5 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

@navbuilder
Copy link

A new build of 72cf43e has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

@navbuilder
Copy link

A new build of 8ae0039 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

@aguycalled aguycalled merged commit 7fd0713 into navcoin:master May 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
NavCoin Core
In Progress
Development

Successfully merging this pull request may close these issues.

None yet

5 participants