[Poll Proposal] Determining consensus on recent and future multi-choice numerical poll outcomes

[grctest]

Abstract

Gridcoin has had a robust voting mechanism for several years now, with recent hardening and poll requirements definition is has become a trustworthy method of determining consensus on important Gridcoin matters. There is however a need to establish network/community consensus regarding how we should determine the outcome of multi-option numerical polls, like the recent rewards multiplier poll.

Motivation

The poll 'Determining Consensus On Future Staking And Magnitude Rewards' recently completed with a final Poll Vote-weight of 91,722,179 which represented 42.62% of AV-W, which exceeds the 35% minimum PVW barrier to validate the poll outcome.

The polling results were as follows:

Poll Option	Percent
500%	41.89
2000%	30.16
1000%	8.72
200%	8.09
100% (no Change)	6.52
1500%	3.54
300%	1.07

This poll indicates that a majority of users (93.48 %) want to apply a rewards multiplier to increase both staking and crunching rewards on the Gridcoin network.

The outcome of this poll requires further clarification on how to evaluate the outcome of this poll, whether we should use First Past The Post or Proportional Representation.

If users voted to use First Past The Post (FPTP) the result would be a 500% increase in rewards, based on 41.89% of votes.

And if users voted for Proportional Representation (PR) the result would be a 978.96% increase in rewards, based on 100% of votes.

Given the rebalancing poll passed, we can calculate the impact as follows:
9600 28,750

Type	Daily staking rewards	Daily crunching rewards
Rebalanced	14,650	23,700
FPTP ( *500 % )	73,241 ( ~76.3 GRC/block )	118,508 ( ~1.03 GRC/Mag )
PR ( *978.96 % )	143,401 ( ~149.4 GRC/block )	232,029 ( ~2.02 GRC/Mag )

By creating this follow up poll we will achieve:

• Stronger consensus on the matter of increasing rewards
• Improvements to the polling process

Rational

Missing poll outcome determination methods in requirements/wiki

The Gridcoin voting wiki and previously voted upon poll requirements proposal lacks details on how to determine the outcome of polls:
https://gridcoin.us/wiki/voting.html
#227

There is a combination of historical precedent for both sides of this matter:

• Gridcoin classic to gridcoin research variable polls on cryptocointalk used an average of user votes (unverified - wayback machine missing key forum posts)
• The polls to decide the split of vote weight between balance and magnitude used an averaged of the results from multiple polls: "Magnitude+Balance" Voting weight balance Gridcoin-Research#87 (comment)
• There was a poll on this matter before the AVW requirement and poll hardening, where proportional representation won over first past the post:
  https://www.gridcoinstats.eu/poll/b6671c69f6498decc1f0c9bfb777cb06c29fd1afdc20553f0184ecfe6bd5ae17
  published proposal about polls Erkan-Yilmaz/Gridcoin-tasks#17 (comment)
• A few polls since the hardening of the voting system have opted to use first past the post to decide the voting outcome.

Without clarity/consensus on this matter, assumptions are being made about how to determine polling outcomes based off subjective historical beliefs/standards which are not written down in any guidelines/requirements/wikis.

Voting on this matter doesn't block the next client update

The upcoming mandatory client upgrade is most associated with the "Proposed Rebalancing Of The Reward And Vote Weight Calculations" proposal, which has passed.

The rewards multiplier can be applied at a later without a client upgrade, so whilst voting on the rewards multiplier outcome does delay the substantial increase in rewards it won't impose any delay to the next mandatory client upgrade influenced by the other poll.

It's therefore rational to validate network consensus on these matters since it doesn't block progress whilst ensuring we're all on the same page.

The time till the next mandatory client is live is also months away, so this poll itself doesn't delay the outcomes of the prior polls.

Specifications

Determining voting outcome for future poll requirements/wiki documentation

Depending on the outcome of the proposed polls:

• First Past The Post

  • Define FPTP as the method of determining poll outcomes

• Proportional Representation (Weighted Average):

  • Define PR and the weighted average calculation steps for this poll type in the docs
  • Declare consensus on calculation for converting the result of an existing client poll result
  • Explain the conditions where FPTP would still remain the default (for yes/no/abstain polls).

Documentation requiring an update depending on the poll outcome:
https://gridcoin.us/wiki/voting.html
https://github.com/gridcoin-community/Gridcoin-Site/blob/master/wiki/voting.md

Required blockchain polls

1. How should we determine the final outcome of multi-choice numerical polls?

   Determining consensus on recent and future multi-choice numerical poll outcomes

   • First Past The Post (The highest voted individual poll option wins)

   • Proportional Representation (Calculate a weighted average of all votes to determine the final outcome)

   • Abstain

Voting outcome deciding factor

Since this poll is non-numerical, it'll be decided by first past the post (the highest individual polling option wins).

Discussion

Impacts of both polling outcome methods

Type	Daily staking rewards	Daily crunching rewards
Rebalanced	14,363	23,236
FPTP ( *500 % )	73,241 ( ~76.3 GRC/block )	118,508 ( ~1.03 GRC/Mag )
PR ( *978.96 % )	143,401 ( ~149.4 GRC/block )	232,029 ( ~2.02 GRC/Mag )

First Past The Post (FPTP)

Potential positive impacts

Simplicity & Clarity – FPTP is easy to understand and implement, offering a clear, unambiguous winner with no complex calculations or interpretations needed. This straightforward approach can help reduce confusion and make the voting process more accessible to a wider audience.

More Familiar & Intuitive – As a widely used system, FPTP is familiar to many people, making it easier to adopt and less intimidating for participants. Its widespread use in various elections means that most voters are accustomed to the process, which can increase engagement and participation.

Prevents Outcome Dilution – FPTP tends to consolidate support around the most popular option, ensuring that the decision is made by the largest group of voters. This can result in a clear and decisive choice that reflects the preferences of the majority, avoiding the risk of a fractured outcome.

Encourages Decisiveness – With only one winner, FPTP encourages voters to rally behind a clear choice, leading to a definite result. This decisiveness can be useful in situations where a strong, unified decision is needed to guide further action.

Potential negative impacts

If we are using FPTP to decide the outcome from a multi-variable numerical poll, then we're discarding votes entirely rather than influencing the final outcome with their votes. The current referenced poll with 41% leading would be throwing away 58% of votes, whilst the currently winning singular option has the most vote percent the rest of the vote options outweigh it yet their collective say had no influence.

If you're aware that one option is winning by a large margin, you're aware that voting on poll options with very little support will have no impact, so you'll be forced to vote for another option which has a higher chance of beating the highest current poll option.

For example if you wanted to vote 10x or 15x but the first and second place options are 5x and 20x you may have to vote 20x to have a higher than 5x outcome despite originally wanting a more moderate reward rate.

Similarly, if you voted for 1x, 2x or 3x but are seeing 20x starting to beat 5x, you'll be under pressure to vote 5x, higher than what you wanted to vote just in order to beat out the 20x vote.

These are forms of tactical voting you're pushed into participating in so that your vote has more than an abstaining influence.

If your FPTP based poll has many polling options then multiple rounds of polling may be required, as the winning option may be a very small percentage due to the large quantity of poll options spreading results around.

Proportional Representation (PR)

Potential positive impacts

Proportional Representation ensures that all votes contribute to the final outcome rather than being discarded. This results in decisions that better reflect the collective preferences of the community.

While some level of tactical voting can still occur, PR significantly reduces the need for voters to abandon their true preference in favour of a more "winnable" option. This makes voting more honest and fair.

FPTP can lead to highly skewed results where a single, divisive option wins with a plurality of votes while most voters preferred a more moderate option. PR helps smooth out extreme swings by factoring in all votes.

In scenarios where the vote involves a range of numerical options, PR prevents vote-splitting and ensures the final outcome reflects the weighted preferences of the entire electorate rather than just the largest voting bloc.

Potential negative impacts

PR requires clearer poll structuring to ensure that all outcome options are meaningful and do not introduce ambiguity or unintended consequences. More effort is required in defining options and ensuring they align with governance expectations.

Proportional Representation isn't free from users participating in tactical voting, for example with the referenced rewards poll if you wanted the 5x option to win, with PR the current outcome would be approximately 9.6x so you'd need to vote for a lower option than 5x to drag down the outcome closer to 5x. Likewise if you wanted 10x or 15x to win you may have to tactically vote 20x to offset the 1x (no change) voters.

Unlike FPTP, where a single winner is clear, PR-based results require additional interpretation (e.g., weighted averages). This may confuse users, especially if they expect a simple outcome.

Use FPTP but require multiple rounds of polling until one poll option has 51% votes

There is a limit of 20 polling options within the poll creation wizard for multiple-choice questions, if the referenced poll had used 20 poll options it's likely that the distribution of cast ballots would be spread more thin.

If ballots are spread thin then the percentage to win could significantly shrink, for example in the above referenced poll 500% got ~42% vote weight, had there been 20 poll options it may have been for example only 20%, and so the argument that 80% of ballots should be counted over just 20% would be far stronger.

If a poll includes 20 poll options, then perhaps there should be 2 polls - the first to weed out the less popular polling options, then a second poll with the top x results from the first poll could be used. With such a polling practice in place, a single user voting for a 100000x increase with a tiny balance wouldn't massively skew polling results, as these outlier poll options would be filtered out by a first round of polling.

How might First Past The Post affect voting participation?

It's possible that users could be disheartened that their vote was discarded in favour of an overall minority percentage poll option winning over all other options; in effect voting anything other than the winning option is arguably a wasted vote, which could drive voter apathy in the future. This is a well observed IRL voting behaviour, when people feel their vote has no impact they tend to disregard future political polls (e.g. tens of millions of democrats chose not to vote in 2024 despite spending ~$1.5B campaigning - voters lost are not easily regained).

If voting participation lowers enough the impact could be that AVW targets are tougher to meet in the future. Polls can however easily be recreated with longer durations to try again to reach the AVW target (delaying the proposal), or like in the past the AVW could be lowered through a future poll proposal (as has been done before).

Users may recast their ballots to help the 2nd (closest to 1st) poll option to win over the first place poll option if they decide they want their ballot to count instead of having no impact if currently cast against a far-losing poll option - this is likely a one-off recast ballot within a poll if they choose to participate in tactical voting.

How might Proportional Representation (Weighted averages) affect voting participation?

It's likely that users are to cast their ballot multiple times over the course of a poll, to tactically vote as opposed to a one-off recast ballot under FPTP. A greater quantity of cast ballots would contribute additional fees to network key stakeholders.

It's possible that users who thought FPTP would be used could be dismayed by the outcome being different than the top voted poll option, however this could drive them to increase their participation in the poll proposal/discussion system in the future and increase the quantity of higher quality polls in the future. With regards to the referenced rewards poll future changes to the rewards multiplier would not require a mandatory client upgrade and so would face fewer hurdles between proposal and implementation - these changes should not be considered set in stone unlike the network properties of Bitcoin for example.

Which historical polls have had multiple numeric options?

For reference the poll which led to this draft proposal:

Title	URL
Determining Consensus On Future Staking And Magnitude Rewards	link

The following polls are the new version, their stats can easily be tracked:

Title	URL
Treasury And Mandatory Sidestaking Structure Poll	link
Grc To Create A Poll	link
Mrc-fee Treasury Split Poll	link

The following polls are an older version, manual TXID parsing is required to parse the outcomes:

Title	URL
Boinc Workshop Reimbursement Poll - Outreach	link
Cbr/research Rewards Rate	link
Constant Block Reward (cbr) Proposal And Poll	link
Meta Poll : What Is The Minimum Vote Weight That Should Be Required For Mandate Behind A Poll To Be Valid?	link
Poll Mechanism : Should There Be A Minimum Vote Weight Required For Foundation Polls?	link
Vote On Grc Mumble Hangout Reward Distibution And Payment	link

The following polls used an average of the results to determine a fairer outcome to all participants:

Title	URL
Vote Weight Rebalancing Cruncher Poll	link
Vote Weight Rebalancing Investor Poll	link

Summary for stakeholders

Existing Gridcoin Users

You won't need to remember Gridcoin's 10+ years of history in order to decide how to evaluate poll outcomes.

Additional poll requirements documentation will improve your future proposed poll quality.

This proposal is a proposal for rules documentation definitions/changes, depending on the outcome a leisure client update could be in scope (likely both GUI and CLI) in the future.

You may need to change how you vote on multi-option numerical polls in the future, depending on the outcome of the proposed poll.

New Gridcoin Users

You won't need to look far back (10+ years) into Gridcoin's history in order to determine what the outcome of a poll will be.

Exchanges & Services

Voting stats websites may need to calculate weighted averages to show the final result, however this is primarily a documentation change proposal.

See Also

#19 (comment)
https://steemit.com/gridcoin/@erkan/gridcoin-poll-how-should-we-interpret-the-outcome-of-a-poll-vote-until-march-29
https://www.mixcloud.com/gridcoin_hangouts/ (several hangouts remain during the first FPTP/PR poll duration - numbers 25, 26 & 27)

[barton2526]

I really do not think the conjecture on price and voting is adding anything to this proposal. You are neglecting to mention that almost the entire crypto market had huge gains in 2017. There are far too many variables to say the CBR poll affected the coin's price.

[grctest]

It's included as a side discussion, it's not highlighted as part of the primary motivation/rationale for the proposal; price action is mentioned in the other proposal's discussion section too (comparison to doge).

I'd be interested to hear counter arguments as to why having your votes discarded under FPTP does not degrade your perceived value of GRC if your vote doesn't influence final outcomes. I find plenty of people IRL have completely given up on politics because they feel their vote has no impact, so I wouldn't say it's a non-factor, just not the complete picture.

If individuals feel disheartened by their vote not having a say, that could have an impact on their decision to hold GRC. People buy/sell emotionally all the time, it might not be wise but that's what hedge funds have preyed on for decades now.

If the whole crypto market increasing was the cause, then why have similar rises not occurred in previous and current cycles of BTC reaching new all time high prices? With BTC hitting $100k we aught to try and sus out what has been holding GRC back, no matter how small/insignificant it may be perceived as being.

Whilst I may have neglected to include that, it's currently a draft and we're discussing it in the comments here, all inputs will be reflected in the final version prior to any poll being created, I welcome all input on this proposal as a whole.

---

Added some extra info in that segment to reflect your input @barton2526

[GRC-Sparrow]

First, the whole section on “Was there a direct influence on the market cap based on indicated PR/FPTP usage in GRC's voting system?” is irrelevant so I will not be engaging with it. Including it “as a side discussion” is unnecessary and, to piggyback off what barton2526 said, it ignores external market factors, mandatory code changes, and how the community has evolved over time.

With that said.

Weighted voting can be gamified by the poll creators and the voters. This creates a serious problem. If we take the answers:

100 * (W 0.05) = 5
500 * (W 0.40) = 200
1000 * (W 0.10) =100
1500 * (W 0.15) = 225
2000 * (W 0.30) = 600

We get a weighted result of 1130 which is higher than what 55% of the users wanted.

If we change the answers ever so slightly, we change the outcome

200 * (W 0.05) = 10
500 * (W 0.40) = 200
1000 * (W 0.10) =100
2000 * (W 0.15) = 300
2500 * (W 0.30) = 750

Weighted result = 1360

OR

100 * (W 0.05) = 5
200 * (W 0.40) = 80
300 * (W 0.10) = 30
400 * (W 0.15) = 60
500 * (W 0.30) = 150

Weighted answer 325

To the average voter these may all seem like very reasonable options on a well-crafted and reasoned poll, but this gives a lot of power to the person generating the poll; It creates a situation where the answers themselves can be carefully crafted to generate a desired outcome. This also creates a situation where people may try to swing their vote wildly, by choosing an extreme position, to balance out the final answer. In the end, no one wins. A system with unnecessary complexity is created that generates confusing results and alienates its users.

One answer of -100 or 5000 could have wildly swung the outcome in either direction.

Weighting the answers also invalidates the current poll as the option "100% (no Change)" was designated to be “the same” as an Abstain vote; Weighting those answers changes how the math works. If there would have been an Abstain and 100% vote it also would have altered the numbers.

jringo, using First Past the Poll in their example, explained this very well on Discord so I’ll quote them here:

Let's say:
The "no change" is considered the "abstain" option
There must be: 1,000,000 vote weight for a poll to be validated.
There is 450,000 vote weight on the option for 1000%.
There is 350,000 vote weight on the option for no change.

This means:
There is 800,000 vote weight so far.
Option for 1000% increase is winning.

Now:
Someone wants to ensure the poll is validated.

So:
They put 200,000 vote weight on "no change"

This means:
There is 1,000,000+ total vote weight, poll is validated
450,000 on option for 1000%
550,000 vote on option for "no change"
"No change" wins, even though the validating party did not want to sway the vote in any way.

That same logic has even greater consequences when one considers that Abstain means: to choose not to vote. By choosing anything in the second poll a person is altering the weighted answer’s outcome, not just putting their support toward validating the poll. That disincentivizes people to vote in the second poll. Words have meaning and if this is how the vote is going to be interpreted then I would argue the poll is invalid, and cannot be used in a set of polls, Per what was written on the official website when the polls where created: https://gridcoin.us/wiki/voting

Especially since a vote, once cast, cannot be retracted.

Ranked voting fixes all this, making it so all users can vote with their heart first and then move on to what their preference would be if their choice was eliminated.

If we take the first example again:

100 * (0.05)
500 * (0.40)
1000 * (0.10)
1500 * (0.15)
2000 * (0.30)

500* is winning but doesn’t have over 50% consensus. In this scenario 100% has the lowest winning percentage so they would be eliminated from the results allowing for their second choice to kick in. Even with that 500 still can’t have a consensus, so the next lowest after second choices were accounted for would kick in… And on and on until a consensus that would make the majority content is found.

That’s not the voting system currently in place. The reality is, only two votes matter.

1. The Developers maintaining the project
2. The User who adopt their code changes.

While polls are nice, one of the reasons I didn't speak earlier during development debates on github is I felt unqualified to speak on the forum. The polls are a great way for the developers to get feedback from the community about proposed changes. I’m not, nor do I have the skills to be, a project maintainer. Recent events, specifically this situation, is starting to change my point of view on that matter; So here I am.

I can say that discussions about this, and the polls that brought about this situation, have been destructive in my trust in Gridcoin and the projects direction. Previously I would vote in most polls just because “I could” and thought it was a fantastic idea to support the process even if I didn’t necessarily agree with what was presented.

Moving forward I’m less likely to vote for any poll unless I agree with what is being proposed, can validate the motives of the person creating the poll, can validate how the results of the poll will be processed, and can confirm the major contributors to the project are on board with the proposed changes. Trust is everything and stirring the pot like this, so close to the polls closing, does nothing but erode trust in the project and the system it's designed to support.

Unfortunately, this situation says to me “a small, vocal, minority didn’t get the desired outcome they wanted so they are trying to alter how the results will be interpreted after the fact.” I have many more thoughts, but, as I am late to speak out on GitHub and Reddit, have truncated it to this specific discussion thread.

[grctest]

First, the whole section on “Was there a direct influence on the market cap based on indicated PR/FPTP usage in GRC's voting system?” is irrelevant so I will not be engaging with it. Including it “as a side discussion” is unnecessary and, to piggyback off what barton2526 said, it ignores external market factors, mandatory code changes, and how the community has evolved over time.

I can appreciate your sentiment, people should base their decisions primarily from the motivation, rationale and specifications sections, the discussion section includes both positive and negative aspects, you're welcome to not engage with the negative aspects of first past the post, however without engaging further on these matters the content may not improve to address the points you raise.

I wouldn't say it ignores these factors, given that it was updated after barton's comment to reflect his comments, however you agree that CBR mandatory change which used FPTP was a contributing factor?

Weighted voting can be gamified by the poll creators and the voters. This creates a serious problem. [...] One answer of -100 or 5000 could have wildly swung the outcome in either direction.

I'd expect bad quality poll options to be called out and rejected in the poll discussion phase. It's a good thing that -100 nor 5000 weren't included poll options then, because they'd have been absurd poll options to use.

Lowering the rewards was not in scope of the referenced poll, and 25x+ was highlighted as excessive so the poll was limited to reasonable ranges.

This also creates a situation where people may try to swing their vote wildly, by choosing an extreme position, to balance out the final answer. In the end, no one wins.

Both first past the post and proportional representation have their own tactical voting which can occur throughout the polling period, as mentioned in the rationale section. Continuous voting is a good thing, it means people are both using the blockchain and spending fees which go to good causes. I don't see tactical voting as a 'nobody wins' situation.

A system with unnecessary complexity is created that generates confusing results and alienates its users

I'd argue that FPTP similarly alienates users, especially when 59% of votes are discarded, taking only 41% of votes into account for an important matter.

That same logic has even greater consequences when one considers that Abstain means

The topic of abstaining should be reserved for the other issue as it's out of scope here.

If there would have been an Abstain and 100% vote it also would have altered the numbers.

Doubtful, abstaining in the other poll is only at 1.66% so the impact would be quite small.

That same logic has even greater consequences when one considers that Abstain means: to choose not to vote.

They already had the perfectly valid option to choose not to vote - abstaining in the process, as the poll didn't require 1.66% to reach the minimum AVW in the end.

Especially since a vote, once cast, cannot be retracted.

You can vote again, overwriting your previous cast ballots, as many times as you want.

Ranked voting fixes all this, making it so all users can vote with their heart first and then move on to what their preference would be if their choice was eliminated.

This is mentioned within the discussions section if you want to do the math on the overhead this would introduce.

Fees would need to increase for voting, and a considerable amount of change would be necessary both in wallet and in external services to support ranked voting.

That’s not the voting system currently in place. The reality is, only two votes matter: The Developers maintaining the project & The User who adopt their code changes.

With this sentiment why are you upset at all about anything relating to the voting system? You would prefer to revert to a benevelent dictator project structuring rules when the times get mildly disruptive?

I can say that discussions about this, and the polls that brought about this situation, have been destructive in my trust in Gridcoin and the projects direction.

Sorry to hear that, however with 93% of voters voting in support of the rebalancing poll, and 94.5% of voters voting in support of raising the rewards (regardless of how much), your sentiment does not seem to be shared by everyone else.

I'd remind you that Gridcoin is a trustless system, with no roadmap and no warranty of any kind, user discretion is advised.

Moving forward I’m less likely to vote for any poll unless I agree with what is being proposed, can validate the motives of the person creating the poll, can validate how the results of the poll will be processed, and can confirm the major contributors to the project are on board with the proposed changes.

Excellent, proposals are open to such participation and engagement, the last proposal was open for discussion for 72 days to accommodate such actions by network stakeholders.

Blindly voting is inadvisable, it's why rewarding voters would be inappropriate - because people would vote without doing their basic due diligence.

If you choose to elaborate on these matters within the scope of this thread, their points will be included in the draft proposal after a period of time.

Trust is everything and stirring the pot like this, so close to the polls closing, does nothing but erode trust in the project and the system it's designed to support.

The discussion regarding rewards polling is in the other thread: #268

I'd say though that you shouldn't be letting the actions of one user on the blockchain change your beliefs in the blockchain itself, however remember this is a trustless system by design (trust is literally nothing), further Gridcoin is massively separated from BOINC, what happens in/to GRC does not reflect on BOINC itself (by design).

Unfortunately, this situation says to me “a small, vocal, minority didn’t get the desired outcome they wanted so they are trying to alter how the results will be interpreted after the fact.”

So you believe there's nothing that can be changed nor improved upon within the voting guidelines, and that there's no need to define standardized methods of determining polling outcomes, where none exist before? That past polling on this exact matter was right to be discarded?

You are free to believe what you want, but that doesn't mean it's reality - the desired outcome was for a rebalancing and a rewards increase and both seem to be happening, pretty sure it seems like the desired outcome from both proposals have in fact been achieved :)

If you feel upset by the outcome of polling then future changes to the rewards will not require a mandatory client upgrade, thus there would be fewer roadblocks between you and achieving what you want, if you can follow the polling guidelines, make a good proposal and net sufficient AVW.

In the mean time, this poll means there will be a buffer between the mandatory and rewards increase, so we'll see what effect both proposals have in the end, and we'll have achieved consensus on this matter to boot.

[jamescowens]

A few comments on this discussion so far:

1. We DO need to clarify the interpretation of poll results.
2. The mode of poll results should be specified in the poll write-up so as to prevent confusion. We should create a poll that cements this requirement in the poll standards.
3. We do not have the resources to implement ranked choice at this time
4. Any new poll discussion meant to qualify a poll should clearly state how the poll results will be interpreted
5. For the specific poll that resulted in this discussion, namely "Determining consensus on future staking and magnitude rewards", we need to do a follow-on poll to get the community to opine on how the results are to be interpreted. This poll should have an abstain option.
6. The change in Gridcoin market cap and the interpretation of polling cannot be linked via causation. Any correlation is by chance, as there were many underlying changes in the market conditions.

[grctest]

What about a middle-ground option of if a single vote option gets 51+% of participant vote weight that it uses first past the post to determine the outcome, otherwise it would be determined by an average weighting?

If there's many poll options then perhaps a second round of polling between the top results with the 51% vote option otherwise proportional represented weighted averages are calculated?

Gridcoin core has a limit of 20 poll options, it may be less likely that a 51% vote weight is achieved from a 20 poll option poll versus a second round of top 5 voted poll options from the first poll.

This upcoming poll is likely to also have a different vote weight distribution, the magnitude vote weight increase is quite substantial.

[GRC-Sparrow]

It would be reasonable for people who have been around for a few mandatory updates to assume that the current poll for determining the reward increase would be FPTP based on similar issues polled within the last 5 years; for example MRC distribution:

https://www.reddit.com/r/gridcoin/comments/t0jx57/mrcfee_treasury_split_poll/
#250

To bring up weighting the results of the current poll, towards the end of the process, after the decision to make tandem polls were made, is where the controversy lives. Just like having values in the poll that where “out of scope” and “absurd” should be called out, so should changing the meaning of the vote towards the end of the polls closing; That should be called out and rejected by the community.

We shouldn’t be turning the Gridcoin polling system into an E-Bay style auction where people gamify, and automate, decisions at the last moment to manipulate the outcome.

Polling should be simple, inclusive, actions used by the dev team to guide their decision-making process and form a consensus around changes.

Clarifying how future poll results will be interpreted is fine. Needing to use a follow-up poll to determine the meaning of the current poll should invalidate it altogether.

---

I don’t see a middle ground in this situation between a re-poll or using FPTP. There were two polls to show flexibility to the system. That flexibility was abused to try and manipulate the poll result.

---

Since anyone can technically make a poll if they have enough GRC in their wallet, May I also recommend that the community clarify that for all future Protocol Development & Governance polls to be considered valid they must come from the foundation address or by a developer found on the https://github.com/orgs/gridcoin-community/people at time of polling?

[grctest]

Needing to use a follow-up poll to determine the meaning of the current poll should invalidate it altogether.

Interesting ideas, do consider throwing together your own protocol proposal on this matter to be voted upon if you feel this way.

If anyone talks about making a poll following up on any other poll topic, you believe the prior poll should be invalidated? Does that apply to all? Because in that case multiple past polls would be invalidated by the two recent polls as they alter the outcome of both then?

IMO having another poll on the final outcome is beneficial, we get to test out the new vote weight system and can push back rewards boosts away from the mandatory which has its own large changes, whilst concluding on what final result people want from the prior poll which failed to achieve a 51%+ polling option.

That should be called out and rejected by the community.

I appreciate your input, best of luck creating a poll proposal on this matter. At the moment there are no such poll requirements/rules which cover such actions, there's effectively no polling rules aside from the poll listing requirements, nor any established code of conduct.

I don’t see a middle ground in this situation between a re-poll or using FPTP.

OK, so you don't want the suggested combined FPTP+PR option idea to be included, just FPTP vs PR? Understood.

There were two polls to show flexibility to the system.

There were two polls because one had scope of the rebalancing, the other had scope of rewards increase size solely.

Both passed AVW and participants voted in support of both (implementation and raising rates) overwhelmingly.

May I also recommend that the community clarify that for all future Protocol Development & Governance polls to be considered valid they must come from the foundation address or by a developer found on the https://github.com/orgs/gridcoin-community/people at time of polling?

Interesting, however you do realize my account is in that developer list too?

Since your account is not in the list, would you not feel being excluded by such a difficult barrier to entry? Commenting in issues (and in discord) doesn't count towards being included in the list, you'd likely need to work on one/several Gridcoin GitHub projects for a few months to be included & list inclusion isn't an automated matter neither. There's only 35 people on the list so far.

It'd probably be easier to increase the min grc to create a poll to 1 million+ GRC instead in the wallet, versus users trying to work to join the org.

[GRC-Sparrow]

Whether or not https://github.com/grctest was in the organization list found here: https://github.com/orgs/gridcoin-community/people or not was not why I made the suggestion. If we are making changes to how the community understands https://gridcoin.us/wiki/voting.html then we should add the requirement that only those capable of making changes, understands what is required in altering the code, and is currently recognized as a primary contributor to the project, should be able to make valid polls in regard to all future Protocol Development & Governance items. It should be clearly written in the documentation so no one 5 days, or 5 years, from now can try to "force" changes and cause a rift in the community.

And You're right; technically all fees, not already based on a percentage, should go up by the percentage of reward increase to account for the added inflation. If 500% ends up winning, then currently the minimum balance to create a poll should increase from 100K to 500K. The cost to create a Poll is 50, so that would increase to 250.

With the Added inflation rate, unless demand and circulation drastically increase, there will be a lot more people able to earn 100K of GRC or purchase 100K of GRC in a short period of time. At the moment it looks like there are only (508?) wallets that can generate a poll. I'd imagine that would increase quickly year over year, so raising the threshold is warranted.

[grctest]

The AVW poll validation requirement creates a substantial barrier for proposed changes which could cause a rift, eg if nobody votes on the matter it's not binding to begin with, so absurd polls created by spammers can be ignored and will by default be invalid.

Nobody can force through any change from the outcome of polling, say for example someone with no coding experience proposes a change back to POW (or another heavy core code change), it's simply not going to happen if they lack core developer support, don't have the ability to code themselves nor if they are unable to contribute code to the main gridcoin-research github repository.

I would also remind you of the influence the core contributors have when they vocalize which voting option they support, for example one poll option gained substantial vote support after developer analysis, so polls & poll options which may cause rifts are less likely to pass/validate already.

Mind there's already a 42 day vote period and a higher AVW requirements or protocol poll topics, that's higher than the other categories, there's also no defined time to implementation requirements/expectations in either of the proposals rushing anyone.

[GRC-Sparrow]

The AVW poll validation creates a substantial, but not an impossible, barrier to proposed changes. As more GRC is generated, and the community grows, it's possible for an activist to "stir up the masses" and gather support for changes that go against the direction the developers wish to take the project.

If Gridcoin is looking to clarify https://gridcoin.us/wiki/voting.html then it would make sense to add a cavoite to Protocol Development & Governance Poll Items that they MUST come from a member of the Dev Team to be considered valid, along with passing AVW.

I agree that no one can "force Changes" and it's why I said the following earlier:

The reality is, only two votes matter.

The Developers maintaining the project
The User who adopt their code changes.

People enter the community discord asking questions about Staking, software configurations, and other basic items on a regular basis. Just as having clarity on how poll results will be interpreted is currently an important topic and should be specified in the poll write-up moving forward, it would seem equally important to state that only formally recognized project contributors can suggest major changes to the code or how the project is governed.

As our current predicament has proven, we can't assume situations won't arise that could challenge community norms.

[grctest]

The AVW poll validation creates a substantial, but not an impossible, barrier to proposed changes.

As it's designed to do, an impossible to pass barrier should not be the intention, but rather a validation of consensus within a poll.

As more GRC is generated, and the community grows, it's possible for an activist to "stir up the masses" and gather support for changes that go against the direction the developers wish to take the project.

As more GRC is generated then so too would the AVW minimum barrier grow to accommodate it, proportionally to how much is actively staking.

Heaven forbid someone tries to "stir up the masses", Gridcoin's only dropped from a top 100 place to a 3000+th place mcap with dwindling hive/steem/reddit activity, getting some life back into these online spaces would demonstrate activity to the rest of the world - discord chat is not SEO friendly. There's still ~59% of AVW (and the inactive stake weight) which was untapped in the latest polls, they seem entirely unstirred.

As has been pointed out and we agree upon this - even if AVW is achieved with a poll, if it's impossible or fundamentally lacks support of core development figures then it's not going to materialize - a poll is not legally binding nor should be seen as a direct order which cannot be refused, it's not that serious.

I somewhat disagree with limiting who can create polls in this manner, because then menial additional job tasks would be imposed on devs potentially disrupting development efforts; if a poll is poorly formed/discussed/worded etc and it fails then so be it, similarly if they're proposing the impossible with zero capability/backing then it too can be ignored entirely.

I'd prefer that someone fail and learn from it than feel entirely shut out despite owning GRC or having a magnitude, rather than possibly turning devs away from gridcoin due to DM's from daft poll creators.

---

New gridcoin-task issues can be created for all the new side ideas people have come up with, they're just a bit out of scope for this issue.

I've updated the original post taking input into account & including the outcome of the referenced polls.

[grctest]

Thanks for the input everyone!

Now that 50 days have passed since the start of this thread, I've created the poll on the blockchain: https://gridcoinstats.eu/poll/a798b00dba1cd98149406489ca8d1fa0573404615ca5cb983346f4cdc5b3b321

https://www.reddit.com/r/gridcoin/comments/1j465d1/gridoin_poll_how_should_we_determine_the_final/

https://hive.blog/gridcoin/@nftea.gallery/gridoin-poll-how-should-we-determine-the-final-outcome-of-multi-choice-numerical-polls-first-past-the-post-vs-proportional

[div72]

Nobody can force through any change from the outcome of polling, say for example someone with no coding experience proposes a change back to POW (or another heavy core code change), it's simply not going to happen if they lack core developer support, don't have the ability to code themselves nor if they are unable to contribute code to the main gridcoin-research github repository.

As has been pointed out and we agree upon this - even if AVW is achieved with a poll, if it's impossible or fundamentally lacks support of core development figures then it's not going to materialize - a poll is not legally binding nor should be seen as a direct order which cannot be refused, it's not that serious.

Yes, voting on the blockchain should be no more than public opinion polling. To manage the project in this way, every person would need to be more involved in making and implementing decisions. When all real participatory elements are rudimentary and most people do nothing further than clicking a button, the results of such poll can never be legitimate.

I think more democratic and effective management can be achieved by creating a formal foundation with open membership, a la Codeberg or Social.Coop. Within an organization, its members will be not atomized individuals, which can be manipulated by whoever runs the polls, but a true community with regular discussions, defined bylaws, some form of commitment (financial at least), generally more informed and willing to participate.

• @CyberTailor via IRC

---

@grctest @CyberTailor seems to not be able to comment, have you fatfingered the block button perchance?