Frequency voting is an interesting idea but likely quite complex to institute in practice. If simplicity in the protocol is our ultimate goal to ensure reliable performance and security, there is a much easier solution, and that is simply removing the 40 NSR minting reward.

The network right now offers minting incentives to two groups of users: those who care primarily about financial rewards (“Incentive A”), and those who care about influencing the network through voting (“Incentive B”). The majority of shareholders will gather utility from both of those outcomes, but will always prefer one or the other if receiving a reward required only one response.

We currently offer data feed functionality to limit the damage caused by minters who only care about Incentive A. It allows those minters to collect their financial reward without influencing the network through apathetic voting.

We don’t currently offer any functionality to limit the damage caused by minters who only care about Incentive B, because there is no damage possible. They are guaranteed a 40 NSR reward by default when they mint and vote.

I would argue that because a second incentive (Incentive B) exists on the Nu network that is very, very likely powerful enough to incentivize a secure number of minters to participate, that Incentive A is unneeded. I would even argue that the presence of financial minting rewards encourages centralization in voting.

To illustrate this, I have a simple example. Let’s pretend the network has ten minters, four of whom primarily mint because of Incentive A, and six of whom primarily mint because of Incentive B. For simplicity’s sake, each group would stop minting if their primary incentive no longer existed. All minters have an equal amount of 1,000,000 NSR.

MINTER - MOTIVATION

M1 - Incentive A

M2 - Incentive A

M3 - Incentive A

M4 - Incentive A

M5 - Incentive B

M6 - Incentive B

M7 - Incentive B

M8 - Incentive B

M9 - Incentive B

M10 - Incentive B

Because Incentive A minters only mint because of financial rewards, let’s pretend that {M1-M3} are using Cybnate’s data feed service, and M4 is using Cryptog’s data feed service. The data feed providers are likely Incentive B types who value voting participation, and so M5 is Cybnate herself and M6 is Cryptog himself. {M7-M10} vote according to their own beliefs as Incentive B minters.

That means that there are 10,000,000 NSR minting/voting, with only 6 unique voting patterns:

M1 - Votes Cybnate

M2 - Votes Cybnate

M3 - Votes Cybnate

M4 - Votes Cryptog

M5 - Votes Cybnate

M6 - Votes Cryptog

M7 - Votes Independent 1

M8 - Votes Independent 2

M9 - Votes Independent 3

M10 - Votes Independent 4

If we set the minting reward to 0 NSR, {M1-M4} will elect not to mint. In that scenario, only 6,000,000 NSR would be minting and voting, but there would still be 6 independent voting patterns. In this case no data feed is given disproportionate centralized influence simply because it captures the apathetic Incentive A user vote. In terms of voting robustness and decentralization, the important number is not the total number of NSR minting – as long as some minimum threshold of minters exists, as I think it would for Incentive B – but the total number of independent voting patterns per NSR.

So, setting the mint reward to 0 NSR feels less centralized to me because of this. Data feeds partially exist out of necessity because we don’t want apathetic voters to cripple the network. Removing the mint reward solves that problem and prevents the data feed centralization in votes from occurring. While it wouldn’t influence market cap, a 0 NSR reward would also increase the share price of NSR if the supply was static or declining too.

I hope most minters realize by now that the mint “reward” is nothing more than an inflationary penalty on non-minters, so removing the minting reward should be less controversial on the Nu network because another incentive to mint exists.

I’m interested in feedback on this. It solves the issues that frequency voting attempts to remedy, while reducing voting centralization and requiring no additional protocol complexity.