Enhancing decentralization by design, by choosing PRs through weighted STV

I’m pretty new to this and I’m not a programmer, so I hope this makes sense. I’m wondering if there may be a way to build on Nano’s unique consensus mechanism to enhance decentralization by design. That is, it could be possible to reduce the risks of a >50% attack by slightly changing the way that Principal Representatives are chosen.


The suggestion below is based on the following assumptions:

  1. Nano account holders should be free to delegate their voting weight to any representative node without restriction.
  2. Delegation decisions should be given as much effect as possible (e.g. minimizing ineffective or “wasted” delegations when delegating to a sub-0.1% node which then makes no contribution to consensus until it reaches 0.1% of delegations).
  3. There should be no incentive to try to game the system by strategic delegation of voting weight.

The Single Transferable Vote

The single transferable vote (“STV”, aka “ranked choice voting”) is an electoral system that maximizes the effectiveness of votes cast in elections by minimizing wasted votes, and produces results that reflect the shades of opinion in the voting population rather than “winner takes all”. This is kind of analogous to decentralization. It is used in various forms for political elections in Ireland, Australia, New Zealand, Malta and I believe in a range of local elections in some parts of the US.

The most sophisticated form of STV is to count using Meek’s Method, which uses a specially designed algorithm, see Algorithm Supplement: Single Transferable Vote by Meek's Method

To quote that paper, the basics of STV are:

  1. Voting by order of preference of candidates, the first choice being marked 1, the second 2, and so on, on the ballot papers.

  2. A quota for election, calculated from the number of votes and the number of seats to be filled.

  3. A first counting by first preferences only, and the election of any candidate who equals or exceeds the quota.

  4. Redistribution of surplus votes (above the quota) for any candidate, in accordance with the voters' further preferences, and election of any who now reach the quota.

  5. When no further redistribution of surpluses is possible, the exclusion of the candidate who then has the fewest votes, and redistribution of those papers.

  6. Further counting, election, redistribution of surpluses and exclusion as necessary, until all seats are filled.

The result is a sort of proportional representation without requiring party lists.

How could this be adapted to choosing Nano Principal Representatives?

Political elections are really a special case which assume:

  • every voter is to be equal when choosing a representative (one person, one vote), and
  • every elected member is to have equal voting weight in the decision making body (one seat, one vote).

The result of this is that for political elections, there is a single quota for election determined by the pre-determined number of seats to be filled.

For an ecosystem like Nano, these two assumptions don’t necessarily need to be retained, since:

  • an account holder’s delegation weight should be proportional to the amount of Nano in the account
  • not every Principal Representative has to have equal voting weight in determining consensus, it’s just that no Principal Representative (or small group of Principal Representatives) should control more than 50% of the delegated voting weight and there should also not be so many Principal Representatives that network performance suffers.

So instead of a single quota to elect a set number of equal Principal Representatives, a “weighted” STV in the Nano ecosystem could have two quotas:

  1. a minimum quota of delegated voting weight to become a Principal Representative, e.g. 0.1% of Nano in voting accounts, below which any delegated voting weight could be redistributed to the account holder’s next viable preference if a representative node has no chance of becoming a Principal Representative, and
  2. a maximum quota of delegated voting weight (e.g. 4% of Nano in voting accounts) above which any surplus delegated voting weight should be redistributed to the account holder next representative node still in the running.

For any Principal Representative holding delegated voting power in the band between the two minimum and maximum quotas (0.1% and 4% in this examples), there would be no need to redistribute votes.

By setting an upper limit, e.g. 4% of voting power, a lower limit on the number of Principal Representatives could be ensured, in this case 25 (or to put it another way, a minimum Nakamoto coefficient of 13).

By setting a lower limit, e.g. 0.1% of voting power as now, an upper limit on the number of Principal Representatives could be ensured, i.e. 1,000.

These quotas could be set at whatever level works optimally for Nano’s consensus mechanism, assuming that too low a minimum quota for election could affect network performance and too high a maximum quota increases the risks of a >50% attack.

Simple quotas could probably be used for these upper and lower limits in the Nano ecosystem. Where electing a set number of representatives with equal voice in the decision making body (as in political elections) a special quota is used to minimise vote wastage, but in this proposal any additional delegation to a PR will not be ‘wasted’ but will increase their voting weight within the band between the lower and upper quota.

By using a weighted STV system:

  • account holders would retain complete freedom to choose their preferred representative nodes (in order of preference)
  • an account holder’s expression of a lower preference could never harm the chances of one of their higher ranked preference nodes from becoming a Principal Representative
  • account holders would be more incentivized to vote for new and small nodes as their first preference, knowing that until such time as the node reaches the minimum quota, their voting power will be delegated to their next highest ranked viable preference, and
  • those who delegate to popular Principal Representatives will know that if the Principal Representative exceeds the maximum quota of delegated voting power, the surplus part of their voting weight will be redistributed to other nodes according to the account holder’s own choice.

Possible challenges

There are a few possible challenges that would need to be mitigated (that I can think of).

First is account holder apathy. If most people don’t bother making a conscious choice about choosing even one Principal Representative, then expecting people to list more than one might be unrealistic. But as now, wallet developers could assign a list of default preferred representative nodes to accounts on creation, drawing on some of the community node ranking services to select more reliable nodes, as opposed to a single representative node. These could even be randomized by the wallet developers (favouring reputable nodes) to spread votes across a range of nodes for those account holders who choose not to choose their own preferred nodes.

The second is the computational power required to calculate who the Principal Representatives are at any one time. I’m not an expert about such things, but may be computationally fairly intensive for nodes to recount the votes every time someone publishes a change block. This could be exacerbated if someone spammed the network continually with change blocks. This risk might be mitigated by:

  • only requiring nodes to recount the vote periodically (e.g. every ten minutes)—if I understand correctly, it wouldn’t really matter if nodes weren’t perfectly synchronized since any differences likely to arise about who the Principal Representatives are at any one time are unlikely to be significant if the period between counts were short enough
  • setting the minimum and maximum quotas such that the delegation preferences of the vast majority of accounts end up with nodes within the band between the quotas (and will therefore simply count towards the first preference with no redistribution), and
  • (if necessary) setting a minimum account balance for delegation preferences to be counted, to avoid dust accounts being used to slow down the counts—they are inherently less likely to have a significant impact on the outcome of any count. If this is too draconian, I’m sure it would be possible to calculate mathematically what the minimal voting value for any count should be, such that all the remaining ‘dust accounts’ couldn’t possibly change the result. But I don’t have the math skills necessary to develop the formula.

The third is, the current two week rolling median to determine online voting weight would probably not work with weighted STV. But with the guaranteed greater decentralization, weighted STV may “smooth” out large fluctuations in other ways. I'm least sure about this point.

Finally, listing multiple preferred Representative Nodes per account would increase the amount of data being sent around and stored in change blocks. This could be mitigated to some extent by setting an upper limit on the number of preferences. In STV political elections, I think it is rare for votes to count beyond the fourth preference.

It would still be theoretically possible for a person to run multiple nodes and gain a majority of the delegated voting power, but it would potentially be more difficult to do so across, say, 13 nodes all of which have 4% voting weight, than 1 node that ends up with 51% voting weight.

I don’t know if this is at all viable in practice, but I thought I’d put it out there.

“He passed a series of observation monitors…One of them showed some horrible green scaly reptilian figure ranting and raving about the Single Transferable Vote system. It was hard to tell whether he was for or against it, but he clearly felt very strongly about it. Ford turned the sound down.” —Douglas Adams, So Long and Thanks for All the Fish

Practically speaking I don't see a way this can be efficiently implemented. You already pointed out one issue: this would have a non-trivial impact on the amount of data being sent around, which would directly lower network CPS.

The main issue is every account delegating to a PR could make a different STV ranking decision. Rather than doing a single number lookup as we do right now, it would need to do a calculation about every account that delegates to a rep, thousands, possibly millions, of calculations every time weights need to be adjusted.

That second issue in my mind makes it a no-go.


I suspected that might be the answer. Thanks for taking the time to consider it.


Stripping this idea way way back, would there be value in simply setting a maximum online voting weight for any given Principal Representative? This would be similar to the current approach of setting a minimum online voting weight of 0.1%.

If there were a maximum online vote weight of 4%, for example, any delegations in excess of 4% would not be counted, reducing the amount of delegated Nano required for other Representative Nodes to reach 0.1%. Wallet designers might also be encouraged to (optionally) build in a warning for those accounts delegating to a Principal Representative over the maximum online voting weight to encourage people to consider delegating to another Representative Node.

4% is just an arbitrary number -- there may be more rigorous ways to calculate an optimal maximum online vote weight that encourages decentralization while also making good use of those willing to invest in setting up a high-quality and reliable node.