I’m excited to be talking about this on the forum after much discussion and analysis. Let me first mention that a solution for Vote Stagnancy must be researched properly to be implemented in code and we are currently exploring whether or not this can be included in the first release of ICON 2.0. The existing schedule is tight to get all the core features, so this might have to be an update after the completed migration. We’re still talking it over with developers. Of course we hope to include this type of feature in the launch, but launching on time is the highest priority.
Having said that, we have done extensive research into the originally proposed Vote Spreading solution. We had found an architecture that could work, but after further discussion we realized that this solution unfortunately leads to a significant incentive to Sybil Attack our network.
Example Sybil Attack: Imagine there are 1,000,000 stagnant votes. This means that each P-Rep in the top 100 would receive 10,000 votes from spreading. This would create a race to deploy as many P-Reps as possible into the top 100. If Bob were able to get 10 of his own anonymous P-Reps into the top 100, Bob would receive 100,000 votes across all his nodes. This is a bad scenario, we don’t want to pay people extra money to deploy as many nodes as possible. Ideally, each node is operated by a different entity in order to prevent a network takeover and single points of failure (if Bob is operating so many nodes and his nodes go down, it could hurt the network).
Now for our most recent discussion - Vote Decay. Take a look at the below solution and let us know your feedback.
Goal: Lower the impact of stagnant votes on P-Rep rewards distribution and governance power distribution. Rewards will be allocated toward nodes whose voters have voted recently and toward voters that have voted recently
Solution: For an individual user account, after 60 days without sending a setDelegation transaction (voting), the ICON Network begins to lower their delegation amount. Since these accounts will have their delegation amount lowered, it will directly lead to higher rewards for people that vote actively and higher rewards for P-Reps with more active voters.
Architecture:
Each user account can be in one of two states
notDecay - not decaying
inDecay - decaying
notDecay state parameters
block(Height) - lastSetDelegate(blockHeight) <= 2,592,000 (this means the voter has sent a setDelegation transaction within the last 60 days, which is ~2,592,000 blocks)
Calculated at the end of each term and implemented on the next term
inDecay state parameters
block(Height) - lastSetDelegate(blockHeight) > 2,592,000 (this means the voter has NOT sent a setDelegation transaction within the last 60 days, which is ~2,592,000 blocks)
Calculated at the end of each term and implemented on the next term
inDecay Sate
For each user account in the inDecay state, every 43,200 blocks (~1 day, 1 Term), the network will undelegate ICX equivalent to 1% of their staked ICX until delegated ICX = 0.
For example, staked ICX = 10,000, delegated ICX = 9,000. At the end of the next term, delegated ICX = 8,900 (9,000 - 10,000 x 1%)
Apologies if I’ve misunderstood this but wouldn’t this mean votes don’t necessarily need to move, the voters account just needs to stake a bit more every 60 days to avoid decay on all votes?
You have a correct understanding. What this does is incentivize people to either:
1.) Change votes
2.) Remove votes
3.) Add votes
So long as somebody is doing some sort of voting activity within the last 60 days, they will not suffer vote decay. Vote decay targets people who never send any voting related transactions. The setDelegate method is used anytime somebody updates voting preferences, whether that be adding votes, removing votes, or changing votes.
This is definitely one of the biggest “debates” going on right now, so it’s good to see the thread on it. Hopefully we can get some feedback from everyone.
I understand why the vote spreading won’t work, unfortunately, because I think that was probably the the best solution otherwise.
Overall I think vote decay is a good approach too. The only concern I have with that solution is the possible backlash that might come back to ICON from token holders who aren’t in the loop on these kinds of changes. I think if we move forward with this we all will need to make a concerted effort in making the community aware of the changes well before they are deployed. Even then we’ll get plenty of people complaining that a) the network/software/interface etc. is broken or b) that they weren’t aware of this system and missed out on rewards because they slept on ICON for a year and are mad about it etc.
I’m not sure those are reasons NOT to go forward with this since the vote stagnancy problem is generally greater though, but the people who are contributing to the stagnancy issue are also the same people are will be impacted by changes like this.
Unfortunately I don’t have any alternative ideas, but If I think of something I’ll make sure to post it.
Yeah I totally agree with what you’re saying here. I was originally against this idea for that very reason and hoping to do vote spreading instead. However, now that vote spreading appears to be a poor approach (and honestly had many technical difficulties as well), I think the pros outweigh the cons here
Here’s some data (extracted today – 29th or 30th of Oct 2020, depending on where you are) if you’d like to see what impact this might have on specific P-Reps.
These are the data in the last 30 / 60 / 90 days of stagnant votes on ICON Network.
Do we know the percentage of accounts that have voted but don’t vote regularly (if a all) which this solution would target? I can see how this would work if that percentage is high, otherwise I am not sure how effective it would be if most accounts add votes within a 60 day timeframe.
My thinking was that the solution on vote stagnancy would incentivise accounts to spread their votes a more, rather than just bunging their votes to the same top P-Rep they always have done, with little acknowledgment of others. The decay solution wouldn’t incentivise this, or really penalise it so unless the percentage of inactive accounts is high then I’m not sure it would make too much of a difference.
Overall I like the concept and hopefully it will lead to a more active voter base. It may be better that decay hits a baseline figure and stays there (ie. you will decay a maximum of 75% of your wallet holdings and the 25% remaining will sit there and still earn rewards). This way it keeps some security for the network and also creates a strong incentive for voters to actively vote every 60 days. This would mean the whole network wouldn’t slowly decay over time (if many are inactive) and those that just “stake and forget” still get rewards relating to 25% of their wallet holdings.
This is an interesting solution to Vote Stagnancy.
Ourselves were quite worried about the Sybil Attack incentive in the past propositions too.
The overall concept introduced here is interesting, however I believe it gives an extra advantage to exchanges and custodial players vs. pure P-Reps.
Most of P-Reps rely on votes given by a set of voters using decentralized wallet solutions such as Iconex / Ledger / MyIconWallet, while exchanges and custodians hold the custody of the ICX of their clients. Because custodial players hold the funds of their clients, they can automate the setDelegation transaction on behalf of their clients, and offer an automated way to maximize rewards and avoid the funds to decay. ICX community members looking for easy staking solutions might be very tempted to let their tokens sleep on a custodian rather than on their own wallet. Thus, under this model, sleeping token holders get higher rewards going to custodian players. Custodian players may also get more active voters in average than P-Reps, and higher rewards too.
It is my understanding that P-Reps will not be able to offer a similar solution and may fall behind with this model, which might be bad for the ICON community and decentralization.
Is there any solution being thought to mitigate the above points?
How about if we forward the stagnant votes to the CPF or a marketing initiative fund or something similar - something common to all preps the allocation of which could be decided by voting? Alternatively they could just be burned, although Im not sure whether this will not trigger an incorrect avalanche message
About the vote decay - I do not believe that this exact solution would solve anything. The problem is not that the Iconists are not checking their wallets, its that they are not doing basic research and are voting for whatever prep is on top or they have heard something about in their minimal interaction with the chain’s info channels.
I believe that almost all Iconists are re-staking their delegations (and respectively their i_rep rewards) if not once per week, than at least once per month in order to maximize their earn value. The only ones that dont do this are as Edouard mentioned above - certain staking services. These could easily be automated as well and the proposed solution would not only not contribute to the resolution of the problem, but will be completely obsolete
Isn’t the whole point of the vote stagnancy argument about votes sitting in the top p-reps and never moving? This is a good solution for people not voting ever. But people could just restake 1 icx to the same p-reps and we are back where we started, just having added one annoying hurdle.
I’m a fan of instituting this combined with a 50/25/25 maximum on voting. 50% max to one p-rep. 25% max to the second, 25% max to the third. Of course you could vote for as many as you like, however, 50% max from each wallet would go a long way to curb people voting for the top p-rep and never voting again for years.
Also what about a 50% max for p-reps in the top 30? This would definitely spread votes around. I would venture to guess that 90%+ of voters don’t care who they vote for and don’t want to research who they are voting for. They are only voting for rewards. This would atleast spread votes around. Thoughts?
The fear of a burn (which was never implemented) caused a lot of ICONists to worry, potentially scaring away ICX investors.
Again I can’t help but wonder if the solution would be better found through incentive and excitement, rather than forced about through fear of punishment.
Could we hold a Re-Election marketing campaign? We can celebrate being 1 year decentralised.
Every wallet that newly delegates after X date would gets a small bonus to their staking returns (paid out of a bonus wallet/pool).
OFC plan a bunch of other giveaways, but from our side of things the ultimate intention is to get ICONists to make a fresh pick.
While it’s something I don’t see it’s a solution to a problem since the issue was people voting only at the top region without doing research. These people depending their time is restaking monthly weekly etc. even if that’s not the case and they vote and forget they can do that. I don’t see people researching or splitting their vote with this change
Ya i hear you. If thats the case and the ultimate goal of p-reps is to have self staking whales that have no contact with the community, I feel that any solution is only temporary and ultimately pointless. If/when ICX takes off and serious money can be made from being a top p-rep, the top 22 will be all self staking whales.
I don’t think we can have a balanced utopia of perfectly spread votes and self staking whales at the same time.
The balanced utopia of perfectly spread votes never happen. Self staking wales take some part of it either way. Imo aim should be towards self staking wales gaining more power over time or even if it’s voted by community. You can’t avoid it completely you can’t do that for anything. You can make it harder with every step so it becomes an inconvenience to abusers or harder possibility. You can’t be clear of it how much you try totally diluted pos network is always under risk of sybil attack for example. My only issue with this proposal is there is a problem and some produced solution for that problem but the solution is not changing or having any effect to issue.
Love it. I didn’t really agree with the vote spreading. I believe staking and voting on ICON where the token is a governance token should be an ACTIVE thing, not just a bank that gives APR. So this method I agree with a lot more. Reward the active people.
First of all, thank you for the proposal
I am not sure if the solution will give the desired results. As it is already mentioned, one can easily delegate part of the rewards, vote and circumvent the system, maybe exchanges will get an upper hand as they will provide services to the voters (also mentioned) etc
For me, the whole voting system should be reviewed from the beginning.
But talking about stagnant votes, a quick thought would be to not reallocate the votes but the rewards? Let’s say there are stagnant votes generating x icx. Assuming an agreed rate (let’s say 90%) allocate the rewards to a pool where they could either a) burn, b) lock long term and use them later (as currently occasionally done - allocate them to preps to support them with projects) c) as NEO has done, create a fund where you can invest in other projects, not directly linked to icon but that could benefit icon etc. Being in icon today, I would burn the rewards, as we don’t generate enough transactions to battle inflation, but would definitely consider other options too.
The latter is also a very big topic that should be thoroughly discussed (limited transactions).
In that way you slash the amount of rewards, people that are away for longer from crypto space and come back find at least something in their wallet etc.
Maybe this system will incentivize people to vote/ re-vote more frequently? If not, at least you get a feeling of a) how much icx are locked/not in exchanges from stagnant delegators and b) you can use the rewards for something that the ecosystem will benefit from.
Hopefully, by discussing, we can find a solution that is best for the ecosystem as a whole.
