[Withdrawn] Change to one vote per account

Hi @janhack

I’ve read in your post about introducing BFT. Does this mean we will have a hybrid or BFT-based DPoS? I was reading these days about the BFT-based PoS Tendermint consensus used for cosmos. I think is definitely worth the read.

I also have my thoughts if this one vote per account will have the desired effect. I also think most users will just vote the delegates rewarding most. From user experience perspective is nice and cool and it has to be much, much easier than today to vote. Personally I agree with @hirish and @cc001 that most of the voters will just vote the highest rewarding delegate. The balance of voters won’t be the one we are all hoping for. Somehow you can see this today were most just vote for max rewards. So relying on people would be a terrible mistake for a consensus mechanism. It has to be self sustaining and sufficient.
I’m personally thinking about having a larger pool of nodes and only use 101 active. Increasing the number of active nodes too much may decrease the TPS but maybe here some other solutions can be found like supernodes . Anyway randomly selecting forging nodes would be a great idea, maybe also weighted based on different criteria like stacking, availability, rewards sharing, etc. Somehow


With all due respect to HQ and research team, seeing proposal to change number of votes to 1 from 101 and keeping 101 top delegates. Makes me wonder whether LiskHQ creator/creators of the idea, even read the topic from github. It’s the weakest idea from entire github thread, but the easiest one to implement, one change in constants and force drop old nodes.

It will lead to chaos, some delegates from groups will rage quit, and possibly liquidate all their holdings pushing price to bottom. 1 vote per account increases risk of rich addresses voting their own nodes very easily, much lower entry point. It will also force some end users to just split funds to few different accounts if they decide they want to support more than 1 delegates, if not it will just make people vote for delegates sharing 90-100% rewards, which is also pointless, in that case it’s better to follow Ethereum way and move to POS, but this isn’t great route either.

Much better idea, with similar positive effect but less/no negative consequences is to simply split vote weight between voted delegates, as a voter there is problem to keep up with all the delegates and keep up with work and news they do (if any :slight_smile:) Splitting vote weight proportionally among voted delegates, allows voter to actually choose the number of delegates, they are comfortable to keep close look at, otherwise, most people vote full 101 and do nothing with verification whether they do some work or not and if shared percentage is accurate - in result, most delegates do nothing and defend themselves by saying that running node is enough effort.

Lisk DPOS can and could actually work fairly well in scenario when there is SDK out, however, no one would have thought that here in 2019 there is still no sdk. This pathological situation created sharing, which is really bad, and essentially pointless, these days it translates well to how politicians bribe citizens with all the “financial benefits / free money from government in any form” which are actually eventually paid by working people to the leeches, just to keep ruling party in power. 1 vote per account will just increase speed of this degradation.

How Lisk DPOS can be actually and significantly improved?
SDK, SDK and once again SDK. Most people are stupid and cannot think of anything else than SHORT TERM GAIN. Regular voter, who can vote for one delegate only, will just browse delegates find someones who shares something close to 95-100% and they are good to go, they won’t care any more than this. Thing is to place incentives in the right place, this is how proof of work works so well economically, it puts incentives in right place.

Who is/should be ideal delegate?
Group of people / team / company / foundation / talented developer working on some blockchain project based on Lisk. Most people won’t vote for such delegate unless they can make money, directly, short sightly, substantially. Such delegate, should share % of tokens in their project, proportionally to received vote weight on Lisk network. This gives huge incentive for voters to seek good delegates/projects to vote for, instead of voting for the ones sharing the most. This is actually very close to proof of work, but not the mathematical proof of work, but proof of development work. LiskHQ should at least verbally approve only this model and disapprove sharing and admit that this is consequence missing part of Lisk called SDK. Without SDK, We will never see how it would work correctly.

As delegate, whoever says that running Lisk node is such hard work and that it’s enough, they don’t need to do anything, it’s so hard, they need to keep network secured and that’s enough, should feel ashamed.

However, there are some things to improve in Lisk DPOS

  1. Proportionally split vote weight between votes you make, no vote cap. there will be rational vote cap based on individual abilities to track voted delegates.
  2. Slightly increase rewards for higher positions in Lisk network with the extension of top forging positions, 50-100 more forging slots would be much better, it has some drawback, but with SDK out this could be really beneficial for development of Lisk ecosystem. Perhaps creating rewards group, just for indicative reasons:
    Group 1 - (delegates rank 1-33) - 40% of reward
    Group 2 - (delegates rank 34-66) - 25% of reward
    Group 3 - (delegates rank 66-100) - 20% of reward
    Group 4 - (delegates rank 101-130) - 10% of reward
    Group 5 - (delegates rank 131-150) - 5% of reward (perhaps, not by value of block, but by chance of forging block/getting the forging slot)
    (Total inflation remains the same, % above indicative)
  3. Creating delegate punish mechanism, along with solution number 2, there might be some risk of downtime from delegates from lowest rank / group which does not have good enough incentive to maintain best productivity, even though they should have enough incentive to get to higher rank, it would be good to have mechanism to ban them permanently from network, lower rank - easier to get banned as delegate. Possibility to unban as transaction with very high fee, depending on rank.
    4.(rather optional) Project funding, similar to the one from Dash Masternode network, reducing reward to delegates by for example, 10%, reserving to the the proposals coming to the network. People and/or delegates could vote for best proposals, some sort of event/one time job for lisk ecosystem thing.

This can, increase a bit processing times in Lisk network, but economically and in matter of decentralisation in can be very beneficial. It will solve many problems, as well problem with NO COMPETITION between top delegates whatsoever. Some delegates who fought for top101 did a lot of work, but after getting there, do nothing, reward groups in top forging nodes will solve that as well.

Really, idea with one vote per account is disappointing, really bare minimum of thought. As delegate and member of Lisk community I don’t even have words to say how disappointing it is.

If someone feels like assembling this into fancy looking academic document, publishing it and submitting this as official LIP, feel free to use these ideas, MIT license on these :slight_smile: I don’t need to be included there, I don’t care, if anyone wants to discuss it on lisk.chat feel free as well. I might assemble it into LIP later, currently I don’t have enough time to write it in academic style, nor I like to do it, but really, it isn’t necessary, essentially it’s all here.

Either Lisk goes the right path or the easy path.

I believe that I have logically, and mathematically, proven that the 1 vote per account system will destroy any competition or chances among standby delegates.

By having the number of votes equal to the number of active delegates, the DPoS system creates an inherent opportunity cost for voting for a standby delegate. (Currently the opportunity cost can be directly measured in the form of reward sharing)

To easily understand this concept, let us assume a voter only has 100 votes and that the reward sharing from each delegate is the average delegate sharing amount. This is because the opportunity cost is even greater for unvoting a high sharing delegate or pool vs a low sharing one and we want to keep the math simple.

If a voter has each of these 100 votes for active forging delegates then they receive 100% of their value from the system. If the voter wishes to signal for a non-active delegate, then they will lose a % of their reward proportional to the number of standby delegates voted for. This is the opportunity cost.

That means that voting for 1 standby delegate will have an opportunity cost of 1%. Voting for 50 standby delegates would then cause an opportunity cost of 50% to the voter.

In the case of a 1 vote per account system, if a voting account wishes to give their full support to a standby delegate, they will have a 100% opportunity cost for supporting a standby delegate.

Ark will be a primary example of a chain that has one vote per account. With 51 forging positions we will take a look at the cliff between the active delegate position 51 and the standby positions below it:

51 has 1.12% approval at 1,424,327 votes
52 has 0.43% approval at 554,126
53 has 0.27% approval at 339,799
54 has 0.21 approval at 266,893
55 has 0.14% approval at 176,409
56 has 0.10% approval at 133,229

As we can see, the cliff in a one vote per account system is a difference of around 61.6%. It merely takes 5 positions in into the standby delegates to have an approval rating an order of magnitude lower than the lowest active position. Only 10 positions later, the approval rating drops another order of magnitude and into non-existence.

LIP11 claims to increase competition among the delegates by reducing the votes per account to 1. Based on the logic above, the cost of voting for 1 standby delegate will increase from 1% currently to 100% in the proposed system. This is an increase in the cost by 2 orders of magnitude with a maximized opportunity cost of 100%. The evidence suggests that this will cause competition and fairness among standby delegates to be nonexistent.

I think this issue needs to be addressed.

1 Like

Well, I urge every mainnet forging delegate and standby delegates from rank 102 to 303 to signal attitude to this idea on the blockchain, here is the interface and instructions.

Data on blockchain, interface open source.

1 Like

I am an active delegate, and one of the few who voted in favor of the proposal.

In short, BFT would not be in compliance with the 101 votes per account. There is a lot of theoretical groundwork underlying this, where for instance implementations can be found at Cosmos and Polkadot. Voting is not the same as staking. With staking the issues brought forward by some here are counteracted by a bonding period, a high inflation rate that forces token holders to stake, and slashing which forces token holders to select trustworthy delegates/validators or get punished. Voting that is used for EOS and originates from Bitshares (inventor of dPoS) has marginally low block rewards so that validators cannot amass block rewards over time. In that sense, Lisk was flawed from the very beginning and not really dPoS. Furthermore, with a view to long time acceptance and competitiveness of the Lisk platform the costs for users need to be low. As much it is likely that platforms need to have much more than the current 101 validators for being recognized as decentralized. Cosmos e.g. will have up to 300 and Polkadot 1000+ validators. Some platforms like Dfinity and Ethereum 2.0 will have even more. All in all, with BFT being implemented for Lisk the 101 delegates with 101 votes per each account is without merits, and fundamental changes are necessary.

I’m not sure I’m following why one is incompatible with the other. But I do agree that DFINITY and ETH 2.0 seem to have the right approach. DPoS with 1 vote !== POS. I would like to see a full POS implementation with nearly infinite network participants like DFINITY.

The multiple votes and the fixed rewards per spot is what brings in the cartels and group effects. BFT is a method for reaching consensus based on the condition that a certain majority of components/delegates does not fail. It is questionable that with the cartels and group pressure on delegates (which is actually enormous in Lisk) there is currently unaffected consensus coming from a majority of “non-failing” delegates, and one that represents real delegation from stakes/voters. With a view to producing correct state transitions for blocks it might not be critical, but for governance it appears bad, as the cartels act primarily as preservers of their own benefits. Thereby, a system that has inherent group building/collusion tendency is not really a basis for BFT.

What if you just:

Eliminate the ability for delegate accounts to vote.

Make the voting process anonymous - kind of like an election, only major difference being the delegates can be un-elected at any time by the masses.

That is not realistically possible as delegates can have various anonymous LSK addresses they control. Cosmos intends to not give block rewards to delegates in the staking token but in a utility token (transaction fees etc.), however this would require sufficient network adaption in order that the utility token has value.

Anonymous voting is also not easily possible, and undermines transparency of blockchains. The advantage/effect it would have won’t be worth it.

1 Like

Maybe a hybrid consensus would be an interesting solution for Lisk. There are some PoW/PoS systems that have additional PoW in case PoS fails or becomes too weak. Lisk could do a dPoS/PoS, where every holding above a certain threshold of LSK can run its own masternode for getting stake rewards on own address, and the dPoS nodes are basically for reliability of the system with a view to PoS weaknesses.

Dear @Matthew_Alexander,

thanks for your detailed analysis with regards to the opportunity cost of voting for standby delegates. I will try to respond to the points you mentioned in your two last comments.

I agree with your general analysis: If you only consider the “Change to one vote per account” LIP, then the opportunity cost for voting for a standby delegate are all shared rewards (as long as the standby delegate is not yet active). That is also why we have the “Incentivise standby delegates” objective on the roadmap. Iker is currently drafting a LIP for this objective and the basic idea is that standby delegates would also be able to forge in certain slots and therefore share rewards. In particular, this means that standby delegates can already share rewards and only voting for a standby delegate does not mean that you do not receive any rewards.

Moreover, you claim in your analysis that voting for 1 standby delegate only has an opportunity cost of around 1 % percent. But in practice this is not true. For instance, if you do not vote for one member of the Elite Group, you already lose all rewards from 54 delegates, so the opportunity cost is much higher.

Another aspect to consider is how long you likely forfeit the block rewards. In the proposed voting system only accounts with a total balance of around 560,000 LSK need to change their votes for a standby delegate to become active. This can happen much quicker than accounts with a total balance of 29,000,000 LSK changing their voting preference in the current system.

An entity controlling 6-7 delegate slots has basically the following options:

  • Normally forge blocks in their time slot and receive rewards.
  • Not forge (lose rewards, be eventually banned according to “Punish protocol violations by delegates” roadmap objective)
  • Maliciously double forge/send invalid blocks (lose deposit due to punishment as defined according to “Punish protocol violations by delegates” roadmap objective)
  • Send invalid transactions or do DoS on nodes/delegates (anybody - not only delegates - can do this, but the nodes would be banned soon as defined in LIP 0004 )

In any case, the effects on the network are limited and the maliciously entity either contributes or loses a substantial amount of money. Even if accounts or exchanges get hacked, the attacker wants to make money so would either sell immediately or use the tokens in a profitable way.

The general question here is: Do we think it is desirable or necessary (for security) that the majority of accounts in terms of stake approves (via the current approval voting) that somebody is allowed to forge blocks? I think for security this is not necessary as shown by many proof-of-work and proof-of-stake blockchains in pratical use. I further think it is not desirable that the majority needs to approve that a 5 % minority in terms of stake (this can be many different individuals) runs 5 delegate nodes, for instance.

I believe the evolution of the token distribution is mostly influenced by the block rewards and transaction fees. I don’t think reward sharing should be enforced by the protocol (enforcing a higher percentage of reward sharing that you suggest is equivalent to a lower inflation if everybody votes).


Hi @Ionut,

thanks for your comment. See my response below:

I think what is confusing is that the term “consensus” is used rather inconsistently in the blockchain space. I would distinguish the following two parts:

  1. Who can propose/forge blocks or participate in the consensus?
    The block proposers are typically selected using either proof-of-work (hash computations) or proof-of stake (randomized selection proportional to stake) or DPoS (voting).

  2. How do the consensus participants agree on one blockchain?
    This is what I would call a consensus algorithm. This can be the longest-chain rule (Bitcoin), Casper, Tendermint or the proposed BFT consensus LIP.

So the “Change to one vote per account” LIP only proposes to change part 1, i.e., how block proposers are selected. This can be combined with different solutions for part 2, i.e., Casper, Tendermint or the proposed Lisk-BFT consensus algorithm. I hope this answers your question.

I agree that most people in the current voting system as well as in the proposed voting system will vote to maximize their personal profit (although there are some idealistic people taking other factors into account). Economically, this is the rational behaviour and this should therefore be assumed when analysing a voting system. Assuming only this behaviour in the current voting system would mean that everybody only votes for active delegates and a change of delegates almost never occurs due to a huge number of voter representing 29,000,000 LSK that would need to change their preferences (the deviations in practice are largely due to the rules of the voting pools). For the proposed voting system, also everybody would vote for active delegates, but already a rather small group (560,000 LSK) can organize themselves to get one delegate into place.


Dear @thepool,

thanks for suggesting an alternative proposal. It would be great if it is concretely specified as a LIP (it is not necessary to have such a long motivation and rationale section as in the “Change to one vote per account” LIP, but the specifications need to be precisely stated). I guess it would be best to then open a separate topic to further discuss it there.

You can further find my response below.

This was already suggested by @cc001 and is also discussed in point 8) of the summary of my post above. Note that this change is equivalent to changing to one vote per account if you ignore the usability aspect for users to manage multiple accounts. In particular, almost the whole analysis for the “Change to one vote per account” LIP also hold for your proposal. For instance, we also would have proportional representation (a group owning x % of stake can basically decide about x % of the delegate slots) and, in particular, 560,000 LSK would be enough for a group/whale to vote itself into a delegate position.

Comparing to the “Change to one vote per account” LIP, the advantage of your proposal is the usability if users want to vote for multiple delegates. The disadvantage, on the other hand, is that in your proposal the voting system and code is more complex, in particular, processing vote transactions and determining the active delegate set is more complex and less efficient. Otherwise, the main properties of both proposals are the same.

I think the suggested difference in rewards would be unfair (all active delegates have the same amount of work in running a computer and forging blocks) and lead to several cliffs within the delegate ranks. For instance, a delegate on rank 33 would receive almost twice the amount of rewards as a delegate on rank 34. This would likely mean that the delegate on rank 33 receives a lot more votes (as it can share more rewards), than the delegate on rank 34 and can also accumulate a lot more tokens over time, which manifests this difference even further.

This is a good idea. But as it is a separate objective on the roadmap, it would be best to address this topic in a separate LIP/discussion.

As already mentioned above, I would personally be happy to see a proposal for a democratic, transparent and fair way to support community initiatives (Santerr proposed the creation of a DAO). I would also separate this topic from the voting system and address it in a different LIP/discussion.


Dear @carolina_delegate,

thanks for your thoughts and comments, see my response below:

This is a very good point. If the BFT consensus algorithm tolerates up to 33 Byzantine (malicious) delegates, then we would like the property that these represent approximately 33 % of the voters and not only one voting pool due to collusion. Therefore, it is important that a voting system that does not incentivize collusion.

Actually, as part of the roadmap objective “Incentivise standby delegates” we are exploring to go into this direction. This is still work in progress, but the basic idea is that standby delegates can forge proportional to vote weight (not stake) in a few slots.



Thanks for reply.

Well, that changes a lot. I see no point in shaking entire network to first make change “one vote per account” and then patch it with different changes. Such big consensus change which will shake all forging delegates, it should be made as one LIP with all changes affecting forging positions. If not, incentive for standby delegates should come first.

Agreed, it might be bit more complex, but most people will support it unlike one vote per account. As I mentioned, it’s reasonable that voter should have ability and convenience to support and verify/track as many delegates is capable to with account weight being split proportionally.

I don’t agree. Running delegate account is not just running a computer and forging blocks. Good delegate is working on ecosystem, creating tools and doing other social/promotion work, maybe little sharing now too. In future - developing apps and sharing tokens in new apps to the Lisk voters.
Only running computer and forging blocks - is just being bad delegate, not to say, shitty delegate.

Right now, once you get in top 101, there is literally no incentive to do anything and I have seen that many times for people who made it into top 101. Their efforts stopped as soon they got in. However system is also flawed, as there is not much to do without SDK. Literally everything has been made, there is no more tools to develop. So hard to blame them too.


Hi all,

The general feeling in the community is that Lightcurve and LiskHQ will push the update forcefully.

As expressed in other channels, the general feeling and perception is that Lightcurve will forcefully impose their “Change to one vote per account” “proposal”. Besides the already expressed potential dramatic consequences (exchanges owning most of the forging spots, +90% shares, discouragement of support of the ecosystem, yada yada…). This would put in serious discussion the LIP process per se and the whole centralization of the project. LIP stands for Lisk Improvement Proposal, please reflect on the word proposal. Proposal means something you discuss and then you agree. If Lightcurve GmbH decides to force such update, this would be yet another huge blow that Lisk takes in terms of centralization.

I’d recommend to take further inspiration on the BIP process, where the LIP process take inspiration, works:

Given that the majority of the network does not agree with the change (thanks @thepool for organizing the survey here: https://thepool.io/api/info/lips_approval/ ) and looking through this thread, only 2 voice supports the idea. Can we consider this proposal rejected and move ahead with a newer iteration, perhaps getting away from the mentality of making an easy change just for the marketing purpose?

We all agree that Lisk consensus algorithm can be improved. What I do not agree is that a quick change gets implemented in order to create some marketing.

I would like to share the following thinking in order to analyze the situation by taking some steps back. What is the role of a delegate?

Let’s take a step back and see what is the role of a forging delegate. The main task of a delegate is to make sure that the Lisk network runs smoothly and safely by keeping their infrastructure secure and an uptime as close as possible to an 100% in order to not slow down the block approval process. For this reason, the delegate that does this operation gets rewarded with LSK. It would be nice (even if not written anywhere) that this amount of LSK gets reinvested in resources for the Lisk Ecosystem in order to increase the adoption/value of it. Now let’s look at the current situation. Is the network running smoothly? Yes. As I guess most of us remember, Lisk went through some issues with the network stability multiple times in the past, one in particular was due to a malformed transaction (referring in particular about the 2nd of June bug, recap here https://www.reddit.com/r/Lisk/comments/8o033l/lisk_blockchain_temporarily_halts_due_to_an/) that halted the blockchain for some hours. Panic hours, but everybody ready to solve the situation. The network started to validate blocks immediately after the hotfix has been deployed and the whole network recovered in matters of hours. Therefore the base task of a delegate I would say is covered.

Getting back on the reinvesting into the ecosystem point. Funds are being reinvested in the ecosystem. We could take as example the two Lisk startup incubators from Elite group in China and Japan; or perhaps the Lisk Center in Utrecht from GDT; or the operating Lisk based exchange EliteX, with plans to become a DEX down the road; Or perhaps the countless sponsored and organized meetups. Furthermore is worth keeping in consideration the opportunities that the forging rewards created under the form of bounties in order to incentivize community members to stay in the Lisk community.

The follow up question on this point could be, are this fund reinvested in an adequate way? Maybe yes, maybe not, but for sure this actually created an ecosystem of contributions back to the community that were not designed by the protocol itself. But perhaps this a topic for another day.

According to the previous points I believe the delegates are doing a good job. Is it the consensus algorithm perfect? No and perhaps never will be and for sure the status quo can be improved, but the fact that the network runs smoothly, this gives us the possibility to work together in order to create better a consensus algorithm, instead of rushing the change because Lisk didn’t manage to handle bad press from competitor projects (spoiler alert, there are much worst projects with DPoS algos doing fine). Perhaps switching priorities on the roadmap allows the project to find and work on more elaborated and adequate improvements to the consensus algorithm (perhaps even considering on creating voting anonymity).

Please do not push such changes to create some marketing. Don’t apply a patch that can create more harm than good with the risk of destroying the ecosystem built. The reason why there is so much focus on the DPoS and seems to be priority #1 for the rest of the world is because people have nothing else to focus on Lisk besides the 101 forging positions, this created a lot of bad taste in the mouth of people that did not succeed, allowing competitors and trolls to exploit the situation in order to create bad press.

Nevertheless, forcefully pushing the “One vote per account” rule, brings up some conspiracy theories that have not been expressed in this post yet. One of the conspiracy leads to think that Lightcurve will forcefully impose this change for their own personal interest, given that the team holds 15,3m, which would be enough to self sustain ~30 forging positions assuming the 500k initial entry gap, but even one single account in forging position from Lisk Foundation/ Lightcurve GmbH would destroy completely the credibility of the project.

I hope nobody gets offended by my thoughts.

1 Like

@janhack Any comment on my last message, or any update on the LIP11?

Hi carbonara,

thanks for sharing your thoughts on the LIPs process and governance. I agree that it would be nice
to have a governance system that is part of the protocol where not only delegates, but every account holder can vote on protocol changes or other topics related to Lisk. Something like this could also be proposed as part of the LIP process.

The purpose of this thread is to discuss the advantages and disadvantages of the “Change to one vote per account” LIP, not the decision making process around LIPs. The community review and input is valuable for us and we take it seriously. This is one of the main reasons for establishing the LIP process and this forum. We will soon publish more LIPs which tackle the different roadmap objectives in the “Delegated Proof of Stake” roadmap phase. These will give a more complete picture of the things that we are trying to achieve in that roadmap phase. So stay tuned for some exciting new proposals to discuss.

Furthermore, we would also be happy if the community finalizes some of the proposals that they brought forward and they open a pull request on the lips GitHub repository.


Just a reminder for any ideas and LIP drafts regarding the “Delegated Proof of Stake” roadmap phase suggested here. It would be great if you could finalize your LIP and open a PR on https://github.com/LiskHQ/lips until the end of September to ensure that it is fully considered by the Lisk foundation. The research team will also publish 3 more LIPs for the “Delegated Proof of Stake” roadmap phase before then. So stay tuned for some exciting new proposals to discuss here.

I created a PR for this LIP with status Withdrawn as we published a proposal for a different voting system today.

1 Like