Currently in the Lisk protocol delegates receive rewards for forging blocks. Recall that the set of active delegates is determined based on the total number of votes (self votes and votes from voters). The current protocol does not provide any kind of rewards to the voters.
We note that there is an off-chain communication between voters and delegates so that part of the block rewards are shared with voters (see, e.g., here). However this is a rather informal framework and there is no guarantee that the rewards will be received. Moreover it requires knowing and using external services and tools.
Taking this into account, the research team is investigating possibilities for an on-chain reward sharing mechanism as announced at AmpliFire 2021. Our current idea is basically that each delegate will set a commission percentage (e.g., 10%) which will be attributed to them and the rest of the rewards (90% in case of a 10% commission) will be shared to all voters according to their stake. Adding such a feature is expected to have the following results:
For voters: The voters (i) will have an easy-to-access interface to decide on the delegates to vote based on their share percentage and (ii) will be guaranteed by the protocol to receive rewards. Therefore this is expected to increase the total staked amounts and consequently the security of the network.
For delegates: It will simplify their tasks, since there will be no need to perform external communication.
Let us know what you think or if you have further ideas on the topic. We look forward to exchanging ideas with you.
It is good idea.
Will be a delay time when delegate change % of share ? I mean when delegate change share this will change after a certain period of time.
What this will work ? By transaction ?
Yes, definitely! I believe most of the delegates and voters would agree on the idea as it was brought up many times in the past. I guess, more interesting are the details which we don’t know yet, for example, how often can a delegate change the commission or how are the rewards distributed technically… through minting, claiming from a staking pool? etc.
This was discussed in the past years in the community and one of the main concerns was that the project could change its financial perception (security etc.) in certain jurisdictions (US) and therefore scare away platforms such exchanges or involve further bureaucracy. Not really an expert, so haven’t really dug into the topic.
Regardless of that, I can see some very important advantages in implementing rewards sharing at the protocol level. It brings transparency, trust and further simplicity into the consensus.
The only disadvantage that I can see, is that the node operators would become even more lazy.
I wouldn’t like to have big delays. They bring more complexity. I think keeping things easy should be the key. Perhaps a little delay (perhaps 24h) would make sense to prevent sudden fee changes but further than that, I think the consensus gets an unnecessary level of complexity
I think it should be possible to edit the fees, therefore a new kind of transaction? I was also thinking how the sharing could be theoretically be implemented. Making a coinbase TX (like standard TX) at the forging time, could “spam” the network (each block potentially hundreds of TXs). A way could be that the rewards are virtually transferred to the voter to a secondary balance which can be claimed at a later time with a claim TX.
E.g. voter A votes for X, X forges 100 blocks which it entitled A to 10 LSK reward. Then A would have a balance of 10 unclaimed LSK, which can be claimed now or at a later stage.
Thank you all for your responses! We are happy to realize that the idea of introducing a reward sharing mechanism is well-received!
I will try to answer the questions posed here, although many of those are still under research.
This is something that we thought about, but this will increase protocol complexity (as @carbonara mentioned) and it seems that it would not change a lot the final rewards received by a voter.
For example, if a commission doubles from 10% to 20%, means that the share decreases from 90% to 80%, meaning 8/9 of rewards are still sent to voters and only 1/9th of them is missed. Then, even if we delay the change for a week (which would be strict anyways), the total loss in the yearly revenue of a voter would be (1/9)*(1/52) which is roughly 0.2%.
So it seems that even if such a rule is applied, the effect on the rewards is limited and therefore does not seem to worth adding extra protocol increase.
Those questions are still under consideration. Perhaps there is no problem in allowing the delegate to decrease their commission at any time, but there should be limitations in increasing the commission (not so often).
As for distributing the rewards, we figured out a way to do this efficiently, which will be presented once the research is finished and the specifications drafted. At short, whenever a user wants to claim rewards, there is an efficient way to calculate their reward for each vote and send it to them. So, as @carbonara guessed, we need a claim transaction and there is no need to calculate all voters’ rewards at the time a new block is added .
Looking forward to further feedback and discussion on this topic!
I wonder how often the delegate will be able to change the share. What happen when delegate will change share everyday ? It will be easy to calculate reward ? And where this token/rewards will be visible ? Maybe on delegate accout ? something like „reward to claim” ?
Thanks @gkoumout for shedding some light on your approach .
When the new DPoS was introduced back in 2021, there was a discussion among delegates if they should include/exclude selfvote from their voteweight when calculating rewards. Essentially, if they should pay rewards to themselves, what’s your take on that?
Thanks again for your replies! Your questions are getting into deeper details which have not been determined yet, but let me try to give some replies:
Yes, there should be no problem on calculating the reward. Of course the main point is not to calculate rewards for every block, for every voter; but if you want let’s say to calculate your rewards at the end of each day, we can do this efficiently, even if delegate changes commission many times during the day (which will not be allowed anyways…).
I think that once the reward sharing is on-chain, it will not matter at all, it’s just two different ways of saying the same thing. IMO, it is simpler to include the selfvotes when calculating rewards; that means a 10% commission and 10% of self-votes means that the delegate gets 10% for the commission and the 10% of the remaining 90% of rewards, i.e., 9% for a total of 19% of the total rewards. This way a voter will care only about the total votes in order to calculate their rewards and not how many of them are due to self-votes. Therefore the interface becomes cleaner.
For UI/UX-related questions such as how rewards will be visible, we will try to provide this information as soon as we have more details on our final solution.
.