[Validator voting change] (Version: 1.12.0)

[xVet]

The XRPL (XRP Ledger) relies on its validators to make critical decisions through a binary voting system, where validators can either "veto" or "agree" to proposed amendments.

This leads to numerous issues, there is no chance to distinct between validators who are actively vetoing an amendment or validators who simply just don't vote, thus not only discourages participation but also removes the ability to give quality signal to the rest of the network about a operators stand towards an amendment.

The result is a slower and poor voting process for all participants, especially for feat amendments that need due diligence from all operators.

New three distinct voting options: "No," "Neutral," and "Yes."

No Vote:

Validators can express strong opposition to a proposed amendment by casting a "No" vote, signalling that they believe the change should not be implemented.

Neutral Vote:

Validators can choose a "Neutral" vote to indicate that they have reservations or concerns about a proposed amendment but are not strongly opposed to it. This vote allows validators to express cautious optimism and encourages further discussion.

Yes Vote:

Validators can continue to cast a "Yes" vote as before, signalling their full support for a proposed amendment.

This expanded voting system offers several advantages:

Increased Transparency:

The introduction of "Neutral" votes allows validators to be more transparent about their stance, also it serves well as a starting point for amendments introduced to new rippled versions. Basically change the default "no" approach to a default "neutral" approach.

Informed Decision-Making:

Developers and the broader XRPL community can better gauge the consensus and sentiment of validators, leading to more informed decisions on protocol changes.

[Island-Ghost]

After listening to various discussions, this seems to be a logical approach. Thank you for suggesting it

[perldude69]

An additional aspect of a three state voting system is participation metrics. A healthy community consists of validator owners that strive to improve the network. Participation in voting could be considered in the metrics when choosing new UNL validators.

[rippleitinnz]

IMO even a third option of neutral is a vote cast on a validators behalf without understanding their influence or understanding of what they may be voting on,

Voting is meant to be democratic and, unless one passes their vote by proxy to somebody else, if allowed, then nobody, including software, should cast any vote on your behalf. If they do, then it is not a voting system.

I have raised this issue over a number of years now. Having a vote cast on your behalf, even if you agree with that vote, shows no participation in the voting process, and should serve against you as being an active, engaged participant of the network proving your willingness to being a trusted validator for inclusion in a validators UNL.

Even a neutral vote is a vote cast. Given there are only two options for amendments - enable or reject - there should only ever be two options available to vote on, and none should come as a default vote.

Given a neutral default vote is still a vote that does not advance an amendment to becoming enabled, there is no way to understand if a validator chooses to simply not change the default neutral vote to reject if that is their wish, given the result is the same. A neutral vote is always equal to reject and never to enable.

The only way to fully understand active participation by any validator, is for them having to actually cast a vote, not have one applied for them by default. It is the only way of knowing.

In essence. no default vote at all, a vote is always required to be cast. If you didn't vote, you abstained, which over time paints a picture of involvement and value to the network as a UNL member

[tequdev]

I think it should be impossible to change from Yes or No to Neutral. Neutral should only be the default value and should not represent the idea of any validator other than unvoted.

[perldude69]

The three states express more than the current 'neutral' or 'approve' state. This would allow the outright rejection of an amendment. For instance:

1. 'yea' votes win and the obligatory time passes -> Amendment is adopted just as it is today.
2. 'neutral' votes 'win' (Neither yea or nay win) -> The amendment remains as it is, and passes to the next version to be voted on in future versions.
3. 'nay' vote wins and the obligatory time passes -> The amendment is rejected, removed and tossed in the waste bin or recycled after going through a new development cycle.

[dangell7]

We should look at the traditional voting process to understand how and why these processes are implemented.

In traditional voting;

1. Window Opens
2. Quorum reached (51%)
3. Votes counted
4. Majority/SuperMajority reached (51%/66%/75%/80%)
5. Amendment Pass or Fail

So if we are to add a neutral then we also need to add a traditional quorum imo. Or that would mean that one person could vote to 100% and pass the amendment.

I think it should be that the neutral vote is abstaining from the voting process and your vote is not counted. None of the votes are counted until the quorum is reached. Once the quorum is reached, then the votes need to be at 80% yay for 2 weeks to pass. You could also make the quorum 80% but I believe the distinction needs to be made. A quorum is not a supermajority. Those terms seem to be conflated in XRPL and that has always bothered me a bit.

[jonaagenilsen]

At some point we could possibly require a validator to be active in the voting process? Maybe voting should be almost as important as upgrading the validator?

Status of UNL right now UNL validators running v1.12.0: 24 (68.6%): 11 with no vote at all UNL validators running v1.11.0: 8 (22.9%]: 6 with no vote at all UNL validators running v1.10.1: 3 (8.6%): 2 with no vote at all

We need a 3rd vote to tell if a given validator has voted or not. We don't know why there are no votes above. Do they say 'no' or are they just not voting? With a 3rd vote, non-UNL validators would have a way of showing they are actively participating. Right now they can only do that by accepting a vote.

After a new amendment has arrived, if no 'yes' or 'no' explicitly being cast, a countdown starts (xx days). When hit, validator gets a mandatory 'not voted' (3rd vote) status and is not counted as part of the 80% requirement. So basicly a voting quorum. Less validators needed for passing or stopping an amendment.

[MarkusTeufelberger]

You mean something like https://github.com/XRPLF/rippled/issues/2689?

[xVet]

You mean something like https://github.com/XRPLF/rippled/issues/2689?

It's really that old huh 😂 But yea, we really need a neutral gear of some sort, i also liked the suggestions of a default null option that once you voted (Yes or No) you can't go back to.

Basically the initial state is null and then it's either yes or no.

[rothexD]

Yes, no vote, no

Quorum: yes vs sum of (no vote + no) votes

Yes and no show your active choice, no vote means no choice made yet, you should not be allowed to remove your vote once it's casted but you may change it

[MarkusTeufelberger]

As long as there are defaults in the code base (for amendments and reserves), it is very likely that people just will stick to them. I don't really see the advantage any more of adding a third "Don't care (yet)" option, especially if it comes with special rules (how would you track that nobody can go back to "don't care/neutral" any more for example? Votes are ephemeral currently...).

I'd rather first see a removal of defaults to force validator operators to always explicitly cast their opinions on the following 3 major topics under their own, private influence:

• UNL
• Amendment votes
• Fee/reserve amounts

If that is implemented I don't see the big value of having a "neutral" option, since it is easy enough to change one's vote at runtime anyways and there is no additional signal to be gained from an abstaining vote.

I am strongly against any extra rules added to the system in regards to "if someone voted X in the past, they are only allowed to vote Y or Z in the future".

I am slightly against narrowing down the pool of active participants even further ("only consider Yes/No votes for quorum") by ignoring "Neutral" votes. The nUNL is already limiting the amount of voters while assuming that everyone who is actively participating online actually also has a vote. I don't think that apathy in the face of decisions is something we should strive for when selecting our UNLs.

[wojake]

To me, this adds more transparency. "neutral" is still considered a "No".

+1

[wojake]

Your thoughts @ximinez? This discussion has been on-going for years on end, more efforts should be put in to the governance model of the XRPL. Streamlining it would lead to a smoother process of enabling amendments.

[ximinez]

Your thoughts @ximinez? This discussion has been on-going for years on end, more efforts should be put in to the governance model of the XRPL. Streamlining it would lead to a smoother process of enabling amendments.

@wojake Since you asked.... I'm mostly staying out of this discussion for now, because I don't think there's any one right answer, and I wanted to hold off before tilting the discussion one way or another. Different people have different priorities, and different opinions about what would be "best" for them, and perhaps for the ecosystem. (That's one reason why most of the last few times I've opened a PR related to amendments, I've called it an "improvement" instead of a "solution".)

That said, I view our current voting model as "yes" vs. "abstain" (despite the fact that the code calls it "no" or "veto"). I tend to think in terms of implementation, and I think the most straightforward way to implement increased vote transparency is to:

1. Add an explicit "no" vote option.
2. Add a "voting against / no vote" field to validations, so those votes can be broadcast and recorded.
3. Change the default vote for all current amendments to an "abstain" (which is basically what DefaultNo does now), but don't remove the default vote functionality entirely - a default yes may still be useful for urgent bug fixes.
4. Not really change the activation functionality, or ledger layouts.
5. Keep the voting functionality in feature the same, so that an operator can not explicitly vote to abstain. If you move away from the default, you pick "yes" or "no".

I don't think it makes sense to store "no"s on the ledger, because the whole point of recording "yes"es is to synchronize activation across all nodes. There's nothing to synchronize with a "no". That's a governance action that needs to take place off ledger: changing code, lobbying validators, or something else.

Disclaimer: These are my personal opinions and thoughts, and don't necessarily reflect the opinions of any other Ripple employees, or Ripple as a whole.

[xVet]

Your thoughts @ximinez? This discussion has been on-going for years on end, more efforts should be put in to the governance model of the XRPL. Streamlining it would lead to a smoother process of enabling amendments.

@wojake Since you asked.... I'm mostly staying out of this discussion for now, because I don't think there's any one right answer, and I wanted to hold off before tilting the discussion one way or another. Different people have different priorities, and different opinions about what would be "best" for them, and perhaps for the ecosystem. (That's one reason why most of the last few times I've opened a PR related to amendments, I've called it an "improvement" instead of a "solution".)

That said, I view our current voting model as "yes" vs. "abstain" (despite the fact that the code calls it "no" or "veto"). I tend to think in terms of implementation, and I think the most straightforward way to implement increased vote transparency is to:

1. Add an explicit "no" vote option.

2. Add a "voting against / no vote" field to validations, so those votes can be broadcast and recorded.

3. Change the default vote for all current amendments to an "abstain" (which is basically what DefaultNo does now), but don't remove the default vote functionality entirely - a default yes may still be useful for urgent bug fixes.

4. Not really change the activation functionality, or ledger layouts.

5. Keep the voting functionality in feature the same, so that an operator can not explicitly vote to abstain. If you move away from the default, you pick "yes" or "no".

I don't think it makes sense to store "no"s on the ledger, because the whole point of recording "yes"es is to synchronize activation across all nodes. There's nothing to synchronize with a "no". That's a governance action that needs to take place off ledger: changing code, lobbying validators, or something else.

Disclaimer: These are my personal opinions and thoughts, and don't necessarily reflect the opinions of any other Ripple employees, or Ripple as a whole.

Appreciate your input a lot Ed 🫂!

I like the way of your suggested implementation 👌

[danielwwf]

The current way is kinda okay as we have a lot of people expressing their stance. I do agree with Vet that a neutral option would help people when they look at stuff. It would definitely help the community.

[Silkjaer]

I believe increased transparency will foster more lobbying and validator pressure. Why is it anyone's business how validators choose to conduct their business? Unless it's an adoption criteria metric by UNL publishers alongside e.g. geography and performance. It's just as valid to be happy about the status quo as it is to vote for new features. Fixes will be default yes eventually and automatically adopted unless manually rejected.

[JoelKatz]

I'm in no way strongly opposed to this idea. But at least to me personally, it seems unnecessary. People can communicate without using the XRPL to do so. It's no easier to change your vote from neutral to no than it is to fire off a tweet saying you actively oppose an amendment and the latter is likely to communicate more information and facilitate replies to try to persuade you.

[rippleitinnz]

Why not just delete the amendment vote mechanism and move it all to Twitter vote?

Seems logical.

[bigcjat]

Why not just delete the amendment vote mechanism and move it all to Twitter vote?

Seems logical.

One step further, lets have nothing at all on ledger, lets just put it all on x