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%)
- 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.