Vote Stagnancy Solutions

[BennyOptions_LL]

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.

[Cali]

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.

[nblaze]

Thanks for the detailed response! I will try to elaborate a bit further to avoid confusion this time.

@BennyOptions_LL

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.

@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

This comment was only referring to this part of your proposal. I only wanted to point out that if we fear a Sybil attack, there are other options, such as instead of spreading votes between all preps, we can open a fund using the gains from them or even burn the excess amounts (that is if we dont go for vote decay). As I said, Im not sure whether its a valid option, I just wanted to throw it out there just in case that it fuels another solution. Vote decay is also a perfectly valid alternative to that.

@BennyOptions_LL

As @TranscranialSol pointed out (if i understand correctly), ~36% of all ICX votes have not sent a setDelegate transaction in the last 60 days.

If you check the data, 48% of these ‘stagnant votes’ belong to:
Icon Foundation: 23%
ICX Station: 7%
NEOPLY: 7%
Symmetry: 7%
Velic: 5%

Which means that this is mostly from the self-staking of those large teams (I highly doubt that the Foundation in example is re-staking their delegations for whatever reason). When you add to that amount the delegations staked by the Foundation, related to Grants, Im sure that you will get at least 60-70% of these ‘stagnant voters’.

Im not sure what the proper solution to that will be. Im sure that whatever we implement, it would be negated by a re-staking software to a very large extent, however I believe that if we decide to and we go in this direction, it should be in a more aggressive way - with a lower period than 2 months and at least weed out the non-active voters this way as much as we can. Whatever we go for, we should definitely rework the staking softwares to show that clearly though as as @Brandon_FBM said, if we dont, we should get ready for an extremely heavy backlash

[stgian]

Hi, thanks for the reply. I am sure a technical solution could be found. In that way you keep the votes intact and play around with the rewards. Another way using again the rewards could be the following. I remember seeing another post for the separation of rewards rate for different stakeholders In ICON 2.0 (preps, investors, relayers etc). Maybe another group can be included ‘inactive voters’. In that group allocate a different % of rewards? You will need to add another indicator to each wallet address With the criteria that will be agreed.

[ICONPLUS]

Hi @BennyOptions_LL; can we include in the above list, claim rewards too, hence an active (Bar Transfers) wallet overall would be enough regardless. to be clear:

1.) Change votes
2.) Remove votes
3.) Add votes
4.) Claim rewards

[ICONPLUS]

Hi @BennyOptions_LL

In addition to my comments above, i agree on the Sybil attack risk; low probability nonetheless a back door for malicious behavior or at least a single point of failure. We cannot allow ourselves to take this risk given what at stake.

The decay option is good; i have suggested above to add to the active criteria “Rewards Claiming” this should indicate the wallet is active beyond pure transactions but the voters are satisfied with their current choices and balance (IE: in the case where no changes required but the wallet does not wish to re-stake more rewards as an example)

Secondly, you picked 60 days for the decay to kick in - how was the 60 days picked? was there a mathematic calculation behind it? If 60 days just seems reasonable, i would recommend to move it to 90 days, this way we can match the decay as a quarterly activity for the Korean financial calendar - Anticipating/hoping we will have many public companies onboard, this can be a quarterly activity matched with their local financial quarters and therefore an easier task to remember.

Finally you mentioned the Rewards will be allocated toward nodes whose voters have voted recently and toward voters that have voted recently, could you please clarify it this means the total amount of the decayed rewards will be shared amongst the active voters/Preps… and if so share more details on the allocation calculation.

Please do let me know if you have any questions.

Regards,
Reda, Team ICONPLUS

[Primo]

As an iconist after reading a lot of interesting stuff around this problem I just wanted to say how I see it and hope it helps:

1)For newcomers to the ecosystem researching and voting for many p reps can be really time consuming
2) So newcomers and APY motivated actors will take the path of least resistance leading to vote stagnancy and vote spreading problems
3)With my limited tech knowledge these are what I could think in the hopes that it helps :

• Setting a minimum number of p reps to vote for to be eligible for staking rewards. This introduce a list and an order for p reps and this minimum number can be set at 10 to begin and increased or decreased via governance vote.

-In combination with this there would not be the choice to choose the percentage of icx allocation for each p rep but it will be set in stone in two modes.
The "equal mode"where all of your icx votes are equally shared to the 10 p reps in this case. (it will be shared equally to all the p reps you selected on your list)
The gradual mode where it will be shared with a higher percentage to the first p rep and diminish until the last p rep and this is where the list order matters.

To add to that a minimum of p reps from the list must be changed to new p reps over the course of 60 days.This number can start at 5 and will be set in stone only changeable via governance vote.
At the end of those 60 days if a voter has not renewed the minimum 5 preps from its total list he will enter an unvoting phase

To sum it up the process will be like:

1. stake
   2)Establish the order of your p rep list and pass the minimum number of p reps to vote for
   3)Choose equal or gradual voting distribution
   4)renew the minimum number of p reps required in your list list at least once each 60 days or you get into an unvoting state and you stop getting rewards.

Of course in theory this method can generate many problems :
-Bad actors trying to move wallets to vote for same p reps but the unstaking period can mitigate that as they will take a loss from the actual 7 days + 2 days when restaking.

• An other problem is the migration to a solution that entails the loss of staking rewards and how it will impact uninformed actors.
  This can be done via a migration system by putting the system in place but not enacting on the loss of staking reward yet all this while having an awareness campaign and monitoring the voters participation to the new system.

-If i am not wrong the POS security will still be upheld because voting and stacking is separated on the icon blockchain so only voting % will go down if voters do not renew their p preps list with the minimum required in the time given.

-Self staking actors will see their selfstaked icx diminish so the gradual method could be:
1 on the list =60%
The rest on the list will get votes in a gradual distribution according to their order on the list.
A higher voting power allocated to the first spot.

-Icon foundation delegation with precise numbering of icx might not be possible anymore.
But the CPF will help alleviate this problem.

-A problem might arise with liquid staking forms of ICX due to the unvoting state but I still can’t wrap my head around it and am not too sure about this one.

[BennyOptions_LL]

@Cali

Just going to have to agree to disagree here haha. Sybil Attacks are important to prevent, at the very least to limit central points of failure of the network and at the very worst to prevent a network takeover. I want to make sure you know that anybody can make a proposal to vote on, so if you feel strongly about your solution of 50/25/25 we can certainly vote on it.

You seem to want a system that does not help “massive self-staking non-contributing p-reps”, but this system you are proposing strongly benefits those teams. Self-voted teams will just split their self-stake across 3 of their own nodes, while a community voted team will likely lose a lot of votes. This strongly benefits whales that can afford to run 3 nodes, while everybody else will be stuck abiding by the policy. Also, this could definitely lead us down the same path as EOS where large holders agree to vote for each other. 1 EOS = 1 vote for 30 teams, what you are proposing is similar where it would be 1 ICX = 0.5 votes for 1 team and 0.25 votes for two teams.

@stgian

Interesting suggestion about creating a bucket for inactive voters vs active voters in IISS 3.1. The problem here is that it’s an all or nothing solution, where you are either active or inactive. But something worth considering. Would likely be an easier to implement solution vs constant calculations

@ICONPLUS

The original proposal included 1-3, but I am against including 4. I don’t believe the action of claiming rewards and sending to Binance, as an example, should be classified as being an active voter. Only voting should get you active voter status, not simply claiming rewards.

60 days was picked to be ~half a year before somebody faces full decay. It leads to 160 days of time before you are completely decayed. Decay starts after 60 days, where it’s just 1% per day after that. @nblaze on the other hand wanted faster decay, so taking both into consideration maybe 60 days is a happy medium.

Here is an example to illustrate your question about reward distribution to recent voters. With IISS 3.1, there is a fixed amount of rewards for P-Reps and a fixed amount of rewards for voters.

My rewards = (my votes / total votes) x voter reward pool. So as people stop voting because they are getting decayed, “total votes” goes down while “my votes” stays the same if I am an active voter.

Imagine this scenario:

Bob the Voter: Voted with 100k ICX
Alice the P-Rep: Received 200k ICX of votes
Voter Reward Pool = 1M ICX
P-Rep Reward Pool = 2M ICX
Total Network Votes = 5M ICX

Bob’s rewards = (Bob’s votes / total votes) x Voter Rewards = (100,000 / 5M) x 1M = 20,000 ICX per year

Alice’s rewards = (Alice’s votes received / total votes) x P-Rep rewards = (200,000 / 5M) x 2M = 80,000 ICX per year

Now, let’s say tons of vote decay starts happening and total votes on the network goes down to 4M (dropped by 1M), but Bob is an active voter and Alice’s supporters are all super active so they don’t suffer from decay at all.

Bob’s rewards = (Bob’s votes / total votes) x Voter Rewards = (100,000 / 4M) x 1M = 25,000 ICX per year

Alice’s rewards = (Alice’s votes received / total votes) x P-Rep rewards = (200,000 / 4M) x 2M = 100,000 ICX per year

Maybe this looks confusing, but it’s all quite simple. Rewards are based on your percentage of votes. If your votes stay the same (because you are active) while the total votes is going down (from people getting decayed), your percentage of rewards goes up. If you are still confused please DM me.

@Primo

Thanks for the input. Overall I’d say your suggestion is similar to what Cali has been suggesting, though I believe it suffers from the same issue of Sybil attacks and cartelization. If you force wallets to vote for 10 P-Reps, it’s inevitable that we see either of these scenarios (or both):

1.) Large ICX holders / exchanges form cartels to vote for each other. You would get 10 large holders all voting for each other. This happened in practice to EOS. 1 EOS token gives you 1 vote for 30 different teams, this is similar to your proposed 1 ICX = 0.1 vote for 1 team, so I would expect something similar to happen to ICON if we go this route.

2.) One large ICX holder can deploy 10 P-Reps and uses his ICX to vote for each of them.

[BennyOptions_LL]

@stgian @nblaze

I have been thinking about the general suggestion of reallocating rewards rather than removing votes. But I want to ask you both what your goal is and how you would like to define an “inactive voter” and/or “stangant votes”. Please keep in mind as you think that we don’t want many different conditions as it makes the network too complex.

Burning rewards of inactive voters could be interesting from an inflation standpoint, but I don’t think it addresses the issue of teams that have a bunch of stagnant votes. I had thought people wanted a solution for top teams that have lots of votes that are essentially just “stuck” there because nobody is re-voting. Obviously my solution does not address self-staked teams, but my original proposal would start removing votes from teams that have not received new votes in however long (original proposal was 60 days + 100 days of decaying). Your proposals, however, would keep votes on those teams, so it would not effect P-Rep rankings at all.

So I guess I’d like to take a step back and ask you guys, what do you want to accomplish?

[BennyOptions_LL]

@Geo_Dude @Brandon_FBM @NorskKiwi @Emre @Cali @nblaze @mj-reliantnode @thelionshire @Edouard_POS_Bakerzn @Paddy @TranscranialSol @ICON_Buddy @Icon4Education @stgian
I’d also like to present these questions to everybody, and please try to keep in mind that the answers to these questions need to be expressed in something on-chain:

What is it you want to accomplish?
i.e. lowering inflation, impacting ranking/rewards/votes received of p-reps, impacting rewards of voters, etc…

How would you define an inactive/stangant vote?
i.e. doesn’t send a vote transaction, doesn’t claim rewards, doesn’t send any transactions, etc. etc.

Based on your answer to the above question, what time frame should we consider inactive/stagnant and how long should it take to decay (or some other solution)
i.e. 60 days of no action + 100 days of decay, 90 days of no action + 60 days of decay, etc. etc.

Based on discussions so far, some ideas I think are realistic to add to the original proposal are:

• Not doing a full decay, only up to x%
• Burning rewards of voters instead of reallocating (P-Reps won’t be realistic but I can explain in private if anybody cares)
• Could also scrap this entire thing and start again, hence my above questions. Seems that it’s a bit contentious and not clear if it will accomplish the goal we want

[TranscranialSol]

Thank you for doing this. We often get sidetracked and may miss the point of the proposal.

.

What is it you want to accomplish?
In my opinion, we want to solve vote stagnancy problem because

1. votes are unfairly distributed (subjective)
2. improve decentralisation

I feel that lowering inflation or change in the rewards of the voters could be the artifacts of the solutions we want, and are not the priority for this thread.

It is difficult to address (1: votes are unfairly distributed) since it’s a subjective matter. Who is to say (P-Rep A) deserves more than (P-Rep B)? But the problem is, people are more likely to vote for Top P-Reps, especially for new comers.

Below is Top 10 P-Reps voted by New Voters each week since the beginning (there are more but truncated).

‘week’ column represents how many times they were in top 10.
‘prep_ranking’ column represents median ranking of the P-Rep.

From the data, it’s clear that new voters tend to vote for Top P-Preps.
When more self-staking P-Rep whales come online, will the top spots be replaced by them, because more voters will just vote for the top P-Reps?

This point then becomes more of ‘voter apathy’.

So then (2: improve decentralisation) seems like a more viable area to target, but is subjected to Sybil attack in some way.

.

How would you define an inactive/stangant vote?
It should be when they do not send a vote transaction. I don’t think claiming rewards should be considered as active.

.

Based on your answer to the above question, what time frame should we consider inactive/stagnant and how long should it take to decay (or some other solution)

I feel that 60 days (or 90) is good, with a little aggressive decay of another 60 days.

.

* Not doing a full decay, only up to x%
Not doing a full decay seems reasonable, but this means the outcome of the vote decay may not be impactful.

* Burning rewards of voters instead of reallocating (P-Reps won’t be realistic but I can explain in private if anybody cares)
This seems better in terms of being fair and no need for complex system of re-distributing somehow.

.

It’s a tricky problem with many interlinking parts, but discussion is very much needed sooner than later.

[Brandon_FBM]

What is it you want to accomplish?
Personally I think providing a carrot (or stick) to address vote stagnation should be the key focus here and I think a decay (or burn) are a good way to address this.

Secondary to that I think reigning in inflation and/or making sure it is used wisely are other big issues, but largely beyond the scope of this discussion with the exception of the proposal for burning inactive vote rewards rather then a decay.

The top heavy votes right now I think are probably, at some level, an issue too, but I also feel that providing a protocol level incentive to vote may help address this to some degree. Unfortunately any approaches to making it more “objectively” fair at a protocol level that I’ve thought on either introduce too much complexity or expose ICON to attack vectors we want to avoid.

How would you define an inactive/stagnant vote?
A stagnant account would be an account that has not participated in a voting action within a defined time frame. Claiming rewards, sending transactions or even staking (without vote) should not count toward this.

Based on your answer to the above question, what time frame should we consider inactive/stagnant and how long should it take to decay (or some other solution)

I think 60 days seems fair. I think a 100 day decay also works, especially given how many in the community are going to come back after a year and complain already.

I do think that burning “inactive” votes would likely be better. But i’m on the fence, because if we effectively unstake inactive votes, then rewards will proportionally grow for P-Rep teams in general (this coming from a lower ranked P-Rep with 60% of votes “inactive”). Leaning more towards a burn though, to help combat inflation.

[nblaze]

I personally believe that it is very hard to separate the main issues that we are facing and to provide a solution to only one of the problems as essentially they are quite interconnected. I think that the vote decentralization is very closely intertwined to voter apathy and vote stagnancy. A ton of voters are simply apathetic, they do 0 research and choose the prep names that they have been exposed to only because that is a requirement to get their rewards. Once they have done that, it takes a miracle to make them to switch their votes and that is why we have teams that have been inactive since decentralization that are still occupying top spots

I also dont believe that those voters dont re-claim their rewards, I believe that they dont bother to switch because their rewards are not affected if they do and that is all that they care about. Re-claiming and voting (for the same team) provides cumulative rewards though, so Im quite sure that almost all voters do this. I think that the majority of the ‘stagnant votes’ that we are currently tracking belong to large entities (the Icon Foundation included and being very large part of that) and Im not sure that this is an issue that we might need to try to resolve.

That being said, Im not sure that I have a suggestion for a solution to the current problems that is not complex or does not create extra issues. We could easily implement a ‘I dont care’ vote that sends the rewards to all preps or to a separate fund; we could implement a decay for wallets (or % of them) that were not switched to another prep in a while; set levels of rewards depending on the amount of preps that you have voted for (with % of your wallet as a threshold) or even set up a decaying vote reward system, tracking separately the amount of time (and vote %) that you have left your votes for on every individual prep that you have voted for in the past year and lowering your rewards gradually for continuing to vote for each of them, etc etc - the solutions are endless, however I think that most that I can think of involve either danger of sybil attack, cartelization or making the system too complex.

[Icon4Education]

Hi Scott,

First, I would like to say thank you for the constant work and dedication on so many things related to ICON. You have been instrumental for ICON and I don’t know if you get thanked enough for that.

Second, In regard to a better voting situation, we need to take a step back and look at how great the current system has worked. We have had multiple P-Reps rise the ranks over the last year. I think your ideas on vote stagnation make sense but this may solve on it’s own over time. Maybe time and energy should be focused on collaboration with current P-Rep skillsets heading into ICON 2.0. Let’s dive into this deeper with skill sets the Foundation can incorporate:

Some that come to my mind:

ICX Station- Works 24/7 for the public chain creating use cases
ICONation- Contributes to ICON in many impressive ways (outreach, develops, reddit organizers).
Ubik- I believe Russ could greatly impact ICON at future blockchain project conferences around the world. Maybe the Foundation should reach out to him and his team to see if he would be interested in representing ICON in this way.
Rhizome- Foundation should utilize their expertise in knowledge of Node and blockchain technology. They also are very talented in writing articles related to ICON.
ICON Hyperconnect- Great outreach for ICON for Korea and the world (Rose the Ranks)
Mineable- Best video maker in the Crypto business (Rose the Ranks)
ICON DAO- Best outreach in Korea and education in Asia (Rose the Ranks)
ReliantNode- Talented programmer and developer (Rose the Ranks)
ICONPLUS- Impressive work ethic, incredible outreach for ICON through their many team members (Rose the Ranks)
IBriz- They put their head down and develop for ICON (Rose the Ranks)
ICONVIET- Great development team
Block42- Transparency and development
Parrot9- Design (Rose the Ranks)
ICON Pinas- “Positive attitude and adoption marketing” (Rose the Ranks)
Sharpn- Great development team
Blockmove- Incredible development team

I will stop here but there are many, many more quality P-Rep teams not mentioned above and their work for ICON is impressive!

As we move quickly to ICON 2.0 a lot of current P-Reps will become long-term voters for various reasons (Full Node Cost, Risk of Burn, etc). We need to move forward with a focus on the Foundation reaching out to ICON 2.0 Active P-Reps to utilize their skill sets. A perfect example of teamwork between teams is the project “Balanced.” We are starting to see more examples of the Foundation doing this, and that is awesome!

Third, Our Team’s Thoughts Moving Forward:

IMO, moving forward the (1.) Foundation should continue to HEAVILY PRIORITIZE use cases of $ICX within its growing network in Korea as they have already started to do. The Foundation knows the unlimited value of our public chain and I believe will do everything they can to incorporate the public chain when possible. (2.) Utilize ICON 2.0 Full Node Running P-Reps skill sets and increase transparency, positivity, and teamwork between teams and the Foundation. Affirm P-Reps contributions, especially when made outside of the grant process (This is very important). 3.) Everyone likes the contribution proposal system and we should see great progress in this area. (4.) Work on ways to decrease inflation, vote stagnation.

We believe ICON has been a true success so far. Over the last 2 years, many projects have fallen to oblivion but ICON has been consistent on delivering its vision. We look forward to the future of this project.

[mj-reliantnode]

It would be ideal for ICX holders to keep up-to date and delegate their votes every 60 days, but this is unrealistic.

We’d have concerns if we start to penalize ICX holders if they don’t delegate their votes every 60 days.

A large number of users won’t understand or want to comply with this requirement and we will leave them with a negative experience of dealing with ICON governance.

We think lowering the reward a P-Rep gets as a result of their own voters getting vote decay is a positive.

Ideally after 60 days without any new delegations a voters delegated votes slowly decay away from the P-Reps and towards the CPF.

After talking to Benny this is challenging to implement technically, so we are still considering the exact solution, but this is our thoughts on the current situation.

[stgian]

@BennyOptions_LL

Glad to share my view. Although not affiliated in any case with ICON, neither am I a prep, I am an invested stakeholder who wants to see the project achieve its true potential and become what it was built for. I am happy this panel gives the opportunity to people like me to raise their thoughts/constructive criticism & be taken into consideration. There are different issues that, in my point of view, need to be addressed*, but let’s stick to the topic in hand, stagnant votes.

Related to that, I think the general voting process and allocation of votes needs an overhaul. I raised this many months back when the initial discussions started for Icon.More rules need to be implemented and the core logic of voting to change. Although it might be cumbersome to do so, at some point in time, we potentially need to deal with it to structure an effective governance tool.

There are at least two issues with the stagnant votes, a) the fact that these are stagnant to specific preps, thus potentially not rewarding quality preps, who can better contribute to the ecosystem and b) that people do not actively participate in governance since the general model incentivizes people to stake and forget.

For me, the main challenge is to ‘attract participation’ through a model where people will have to come back regularly and participate in the governance. Will this ever be ideal? Most probably not, but it can improve from the current setup.

By adjusting the rewards:

• You accomplish less inflation, especially at a time where the usability of the ICON blockchain is still to be proven. As mentioned in previous message, suggestion is for now to burn these rewards vs reallocating them to other prepsand in the future once the ecosystem is mature enough, to potentially use these rewards (i/o burning them) as an additional governance fund to support start-ups/projects etc.

• At any point, you have an analysis of the amount of stagnant votes, as you know how many rewards are flowing to the new category, burned/in the fund etc, thus you know you need to take additional action to improve the governance.

• You create more active participation, as I am sure the majority do not want to lose on potential rewards.

• You avoid having people that want to exploit the high rewards ICON offers, without contributing anything.

The above alone is not solving fully the issue of adjusting the votes to different preps, as most people would come back, stake the earned rewards periodically and leave without adjusting the vote allocation. As complimentary action I would consider a step where participants will need to adjust, let’s say arbitrarily, 20% or any other % of their votes to different preps than the ones on their list, unless their vote spreading is satisfactory (maybe > 22?). Is this something that can be implemented?

To be honest, something like that should be applicable for everyone, even the preps. In order for a system to succeed there needs to be trust amongst each other and having the same goals in mind, thus preps should also be supportive of other preps they deem worthy of part of their votes. There are more implications there, such as the bond they need to keepetc, but maybe something to consider. Then questions arise as how often will participants need to adjust-reallocate? This brings us to the next point, timeframe.

What is a reasonable timeframe for votes to be considered as stagnant? Difficult question. Is there a market standard or are we creating the standard? Then let’s think about how active we want the governance participation to be. Are you happy with a year timeframe? I wouldn’t. Are you happy with monthly? Might be a bit aggressive. I think 60-75 days gives a good balance between asking too much and too little, but this is definitely something that can be discussed and refined accordingly.

*Following up on the above and to finalise, I think you need to initiate a discussion of transactions in ICON vs rewards as the weight leans disproportionately towards high rewards with limited transactions in the ecosystem today. Increasing the fees will definitely help towards the right direction, but the gap is still very big. I mentioned above an overhaul of the voting system. In my mind this would include various KPI’s on which a prep is evaluated, including the desired mix of preps in top 22 (marketing/developer/block producer etc) as well as KPI’s for the number of transactions, the projects being worked on etc etc, putting different weights on each KPI, based on the significance. Also, allocation of votes based on several rules (not been able to vote for 1 prep only etc).

[Cali]

I agree with what @nblaze wrote. Any changes would create new problems that would need to be solved, creating a mousewheel scenario. With large self-staking/non-contributing holders being the future, p-reps are going to turn into simply large holders getting extra rewards for being rich, while developers won’t bother running a node and simply apply for grants. I think it’s sad as I believe that this is not how the p-rep program was initially envisioned, but it’s quickly heading that way.

[BennyOptions_LL]

Based on current feedback and a lack of clear consensus on a specific direction my current plan is to try to solve the problem using UI/UX changes to ICONex and the Tracker after the Contribution Proposal System comes out. The problem I am trying to solve with this, to be specific, is voter awareness/education.

As you can see in the images above, adding these two metrics should hopefully push more voters toward teams that are actively engaged in managing the CPS and sponsoring projects. Neither of these metrics are game-able, especially the Sponsored Projects column.

Maybe I am wrong here, but to me it sounds like the primary concern is that people are unhappy with how people are choosing to vote. Voters are not well-researched (understandably so) and are sometimes making uneducated decisions when it comes to allocating votes. I’m hoping the changes to the UI/UX will lead to at least basic levels of research to see who is contributing to governance. This also provides an incentive to actively manage the CPS.

After looking more at the data, stagnant votes are not actually as big an issue as we thought imo. Ubik capital, for example, only had ~3.5M stagnant votes (stagnant for 60+ days) last I checked, which would only drop them from rank 5 to rank 7 even if all 3.5M votes were decayed. ICX Station, as another example, had 4.4M stagnant votes over the same period. This would drop ICX Station to rank 3 instead of rank 2. Not a huge impact.

To me, it doesn’t seem worth it to dramatically shake things up for voters (our primary user base) and do a ton of R&D just to see small changes in voter behavior / p-rep rewards at best. But I’m open to being convinced (especially if @TranscranialSol finds more convincing numbers) and open to other proposals if anybody wants to put together something specific.

Thank you everybody for the feedback and constructive discussion. To reiterate, happy to continue the discussion and offer feedback on any new proposals, but for the time being I want to try this UI/UX change + promoting the change to the community once the CPS launches.

[TranscranialSol]

I think at this stage, UI/UX improvement would be a good start. Perhaps if top 5 P-Reps have more than 50% of the total votes (currently ~31%), then this could be re-visited. Hopefully UI/UX change and other promotions will help mitigate vote concentration to the top P-Reps.

[Emre]

@BennyOptions_LL
Good idea but how we the sponsored projects part got edited. Is it in control of the foundation? I really prefer sharing what we doing and spending with the foundation over the prep projects system which is not a good system.