Vote Stagnancy Solutions

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.

1 Like

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.

3 Likes

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

2 Likes

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.

https://raw.githubusercontent.com/Transcranial-Solutions/ICONProject/master/data_analysis/04_vote_stagnancy/results_2020_10_30/vote_stagnancy_all.csv

More detailed ones below:

30 days
https://raw.githubusercontent.com/Transcranial-Solutions/ICONProject/master/data_analysis/04_vote_stagnancy/results_2020_10_30/vote_stagnancy_30_days.csv

60 days
https://raw.githubusercontent.com/Transcranial-Solutions/ICONProject/master/data_analysis/04_vote_stagnancy/results_2020_10_30/vote_stagnancy_60_days.csv

90 days
https://raw.githubusercontent.com/Transcranial-Solutions/ICONProject/master/data_analysis/04_vote_stagnancy/results_2020_10_30/vote_stagnancy_90_days.csv

1 Like

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.

It’s a difficult one.

In the last 60 days, around 36% of total votes (~114M out of ~318M) were stagnant / inactive.

Also, we have submitted 2 grant proposals targeting active voters to some extent, but it’s a community effort rather than a protocol change.

Please see below:

1 Like

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.

2 Likes

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?

4 Likes

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

Thank you for starting this thread benny!

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.

This doesn’t work Cali because we want large investors to buy large amounts of ICX and stake to themselves. Take NEOPLY for example.

What we need to do is to find a way to activate the stagnant community vote.

Looks like a very solid solution.

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.

2 Likes

First of all, thank you for the proposal :slight_smile:
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.

1 Like

Everybody - thank you for the commentary. This is a difficult problem to solve and I appreciate all the suggestions.

@ICON_Buddy

I like this idea and ideally we can incorporate it if technology permits.

@Edouard_Stakin

You’re certainly correct here, but in reality, any kind of reward for active voters (and nodes with active voters) or punishment for inactive voters (and nodes with inactive voters) will ultimately end up favoring those that have control over their ICX (whether that be investment in ICX or custody of ICX). The ICON community has been asking for a solution to inactive voters for a while, but maybe it hasn’t clicked with most people that whales and exchanges will be the most “active voters” out there, and any solution to stagnant votes helps self-delegated teams.

In theory, any P-Rep could come up with a Smart Contract that auto-delegates for their voters to circumvent this system, which is a valid concern, but at least any P-Rep would be able to do it rather than just exchanges. IMO people that would utilize a system like this are people who would already be relatively active though, so I still think my proposal is a step in the right direction.

@nblaze

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

I’m not sure what you mean by your suggestion here, if you can edit it and elaborate that would be helpful. This proposal is to slowly undelegate votes of anybody that has not voted in the last 60 days, nothing is getting reallocated anywhere which is why I am confused.

I believe you are conflating two different problems. This is more about vote stagnancy, while your commentary is more about how to pick quality P-Reps and spread votes around. You say that the problem is not that ICONists are not checking their wallets, but that is actually not true. As @TranscranialSol pointed out (if i understand correctly), ~36% of all ICX votes have not sent a setDelegate transaction in the last 60 days. The idea is to slowly lower their delegation amount. This means that people who never check will earn less rewards, which by design leads to more rewards for people that do check. This also means P-Reps that are supported by people that never check will slowly lose votes. When one P-Rep loses votes, all other P-reps earn slightly more income by design, since rewards are based on my votes received / total votes. For a P-Rep with active voters, “my votes received” will stay the same but total votes will go down. Same logic can be applied to voters, since voter rewards will be based on my votes / total votes.

As for vote spreading and voting for good teams, I think this comes from UI/UX improvements to ICONex, not something at the protocol level. The idea would be to get people checking at least once every 60 days while also adding UI/UX improvements to help them pick more active teams. In my opinion we’ll never have something that is not gameable at the protocol level that can accurately assess a “good and active team”.

@Cali

See my point above regarding conflating vote stagnancy and picking good teams / spreading votes. As for your suggestion of 50/25/25 and no more than 50% to teams in the top 30, I had thought of this too but unfortunately this also creates a huge incentive to Sybil Attack and/or start a cartel with two other people.

Sybil Attack Example: Bob launches 3 anonymous nodes and self-delegates his ICX to Bob1, Bob2, and Bob3. If we add the 50% limit to top 30, Bob launches 3 anonymous nodes and self-delegates his ICX to Bob1 (top 30), Bob2 (outside top 30) and Bob3 (outside top 30). And if Bob has so much ICX that he can’t keep Bob2 and Bob3 outside of the top 30, he’ll launch even more anonymous nodes further worsening the Sybil attack.

Cartel Attack Example: Bob talks to Alice and Charlie in Twitter DMs. Bob, Alice and Charlie all agree to vote for each other using the 50/25/25.Note: This is similar to what EOS has and they ran into both Sybil attacks and cartel creation based on conversations I had with some of their community block producers

@NorskKiwi

This suggestion seems more like a promotional idea similar to @TranscranialSol’s Spread your Votes campaign rather than a protocol level solution. For spreading votes around, I actually DO think that the best solution is promotions + better UX, but my proposal is more about vote stagnancy, which are people that don’t vote at least once every 60 days.

@stgian

It’s an interesting suggestion to burn the rewards of stagnant voters, but I think this will add lots of complexity to development. The way ICON rewards work is that a pool of ICX is created for voters every block, let’s say 10 ICX. Then the network calculates per wallet: delegated ICX in Wallet_n / total delegated ICX. So the “redistribution of rewards to active voters” isn’t some sort of active redistribution, it just lowers the percentage of rewards going to inactive wallets and therefore raises the amount going to active wallets. But having said all that I’ll keep this in mind and talk to ICON devs about it.

2 Likes

Hey Benny, thanks for your reply.

Are we focusing too much on a sybil attack? Yes it is a problem that could occur, but maybe the fear of the ‘boogie man’ (sybil attack) is making it difficult to find a true solution? I think a 50% limit inside the top 30 would really make a change to the list. It would push millions of votes outside the top 30, put pressure on those wanting to self stake to buy even more, and hopefully change things for the better. But like I said, I don’t believe we can have a system that encourages massive self-staking non-contributing p-reps AND vote spreading.