Please see the link below to review the IISS 3.0 Proposal. We look forward to seeing all feedback, thank you!
Please see the link below to review the IISS 3.0 Proposal. We look forward to seeing all feedback, thank you!
No penalty for voters would be Nice .
As a simple icx buyer , i Will always be happy to see work to lower inflation .
Their Is definitly work on the p-rep Side . Its a great start !
Request for more information
Overall I agree with the entire proposal, I have one recommendation to make.
I would like to recommend to take into account the development of a grace period for teams to gather the amount of ICX necessary for the bonds.
I realize that the CPF can be used for up and coming sub P-Reps that because of their work they managed to move up the ranks pretty fast and they can submit a fund proposal to have enough ICX to pay the bond and free the I_Score.
I still believe that a grace period can be positive, for example, it can be done like this.
Instead of the bond being 6% of your current allocated votes, it can be 6% of the votes of the previous month.
If your votes in the previous month are lower than your current votes, the bond is 6% of the previous month (this in the case that you gained votes). If the votes of the previous month are higher than the current month the 6% bond is related to the current month (this in the case of the P-Rep losing votes)
I don’t know how difficult it could be on the technical side, but I believe that It can be a positive change to allow P-Reps to work more comfortable and have less stress about the bond without taking away the positive things about the bond idea which I think is great.
Comments: Burn penalty no longer harming voters is a very positive modification. Bond requirement allowing for aggregation of rewards until met: fair and reasonable. Increased stake by teams: a positive. Strong supporter of the CFP initiative. Governance slash to improve participation: a positive.
Edit: Some additional thoughts were initially written here but have been moved to the open discussion thread.
We love the future of ICON that highly rewards contributions.
Decision: Rejected we support everything besides bond
Comments: There are great thinking and planning behind the whole proposal and it’s going to benefit icon chain a lot in the future but we believe bound part will hurt icon on the long run but since It’s not going to disappear because it’s also the backbone of the penalizing main p-reps structure we will accept the same offer with 3% bond.
Our first comment
Even tho I don’t think bound will not have any meaningful effect on the vote-buying situation and will cause centralization on the long run. The adjustment of the rewards will fix a lot of issues and greatly planned so I am 100% backing these changes
After I run the numbers for the cover bond you need to put 6 months of rewards from what I can see that mostly put out any self-development part preps. It mostly grants right now so I don’t think that’s gonna change a lot of things but for example to become main prep you need to put around 50000 USD as if now. That will centralize stuff and make it impossible for community teams to become main in the future.
Second edit and conclusion
We update our decision to reject since we strongly believe bonding will centralize the chain on the long run all the other changes are very beneficial for the chain so we need compromise we like to accept the proposal with bond rate 3% and point out the issues we see with the bond system.
Since I wrote my first edit the required icx investment aggressively dropped from around 50000 USD to around 25000 USD with 1 icx equal to 0.147 USD. In crypto, price changes a lot. If you are working on crypto you can’t gamble on the price of the coin you are holding. We like to start with the example of a small team which invest their money yesterday morning by the end of the day they planned and invested but their funding becomes 50% less. No one can know how long this will go on for. So normally they need to 6 months to get back the money they invest in but that become a 12 month. Their project needs a grant to be in the schedule under all of these circumstances why would they consider being prep while they can. There is also the part of keeping up with the voters. All of these will just stress the preps on following the price movements consider selling with some price increase so they can be safe etc. small companies self-funded teams can’t take these risk for a long time so in the long run. Strongly backed entities start to fill up all the chain. (as we stated before we need diversity for on-chain governance so some group can’t just start to make changes for their benefits)
The biggest problem
Let’s say all the preps bonded their icx with the update by that time Icon price become 1.3 USD. In best case required icx for becoming a main prep stayed the same which is impossible but for the sake of lowering the number. That’s equal to 250000 USD investment for just bound part considering the marketing and all the stuff they need to pull a vote from mostly inactive voters it can cost up to 400000 USD did they do that probably not because it’s a very risky uncontrollable variable. Their approach will see what they can do with their existing assets and can it be profitable enough to buy tokens to self stake. So in anyway chain gets bigger becoming prep become so unreachable. We create our own cartel with the existing preps we have. Lastly, what can puncture these high limits? Exchanges and other entities like that hold a lot of coin with their self stake.
We like to hear what do you guys think about the point we stated here please share your thoughts.
Approved! Very well thought out!
This is a very well-thought out proposal that outlines all the necessary solutions to existing problems with IISS 2.0 design. We hope these changes will be implemented in code as soon as possible. Big kudos to Scott and ICX Station Team.
Approved. All additions are in line with our Iconproject vision. I am happy to see the foundation keeps on proposing things that do. Tells a lot to me!
Maybe for IISS 4.0:
Number of votes vs number of iconists: i my opinion we should take the relative number of votes vs number of iconists into account. In current IISS, it is better to have 1 iconists voting for you with 1000 votes than it is to have 900 iconists to vote for you with 1 vote.
All in all, great proposal.
It will make a huge positive impact on #ICONProject
Decision: Request for more information
Is it possible to get a PDF of the proposal? Due to travel to a remote area and a low bandwidth I am unable to use the Google docs. From the IISS PDF overview, we generally support the idea. However, I would like to see the full document before making a final conclusion.
Decision: ICONation - Request for more information
Would it be possible for the foundation to be a bit more specific when they mention these changes “may take many months” to develop? I’m looking to identify if we’re talking about 2-3 months, 4-6 months, or 6+ months. We need to have a better understanding of the time frame to make a more accurate forecasting assessment.
Also, is there any consideration regarding adjusting the 6% bond number, or is that set in stone?
Regarding the slashing penalty for not participating in governance proposals: I recall that ICONation essentially missed the opportunity to vote on the 1st proposal that was ever submitted because the proposal had already gained enough votes to pass while we were still discussing internally + with our supporters in the community. By the time we went to vote, since the proposal already received enough support to pass, we were no longer able to participate and cast our vote.
Let’s say there will be a 3 day window to vote on a proposal. If the proposal receives enough support to pass on day 1, will teams that haven’t yet voted still be given the opportunity to participate in the vote on day 2 and 3 to avoid the penalty, or will the voting period conclude once the proposal has passed as it does today?
That’s all I have right now, but if our team comes up with more questions I will be sure to list them.
Approved. Look forward to it.
Thank you for your feedback @espanicon. I would just like to ask you a clarifying question:
Based on the current design, would you vote to “approve” or “reject”? Just wanted to clarify your position. No worries if still undecided. I know you are suggesting a grace period and your suggestion is interesting, but I’m trying to clarify if the current design (expected 6+ months of development time as a period to prepare, to also answer one of @radiofriendly123’s questions) is unacceptable to you and would be a deal breaker.
As for your specific suggestion, it’s my opinion that the development time of this proposal offers such a grace period already. Overall I think the bond requirement design is fairly soft compared to other networks that require a bond. The fact that rewards are waiting for you if/when you are able to post a bond is quite forgiving. Tezos, for example, blocks all rewards towards bakers that can’t post the required bond based on the research I have done and discussions I’ve had in their community.
Hey @Nessaki glad to hear you approve of the proposal. Happy to answer your question. If you don’t mind, would you be able to share which P-Rep team you represent? Also no problem if you are not part of a team. We should have included that in the recommended response format, that’s our bad.
1% Boundary: This is chosen because of the new rewards formula. The formula is just taking the square root of the delegation percentage you have prior to calculating your rewards. This square root only begins to apply above 1%, because if it were applied below 1% it would actually increase rewards for teams below 1%, creating a weird incentive for self-delegated nodes to run as many nodes as possible with as little delegation as possible. You are correct that the current design incentivizes them to stay close to 1%, and the beneficial consequences of this design are outlined in detail in the proposal. Check out the section “CPF Allocation Structure” if you have not done so already for more clear and detailed explanations.
IISS 4.0: I completely agree. What we currently have is essentially a plutocracy rather than a democracy. However IISS 3.0 actually helps mitigate some of the downsides of this, as large token holders are economically incentivized to stay out of governance (this point speaks to your previous question regarding the 1% boundary as well). Having said that, giving 1 person 1 vote on an anonymous blockchain network is difficult. This is something we could potentially do if myID becomes widely adopted and most ICX holders have a myID allowing us to count 1 person as 1 vote. In the current situation, it’s very easy to create multiple accounts to game the system.
Hope that helps and happy to answer more questions if necessary.
It’s not a deal breaker for me so my vote is approve, sorry for not specifying it I just saw that I could use the “request more info” label and used it to make this recommendation.
I understand that the time it will take to implement this would be enough for the current preps to gather the funds necessary for the bond
My recommendation is to take into account the expansion of the network and the possibility for future preps that may rise quickly on the ranks in the future. I think is a solution that gives a little bit of breathing room without actually breaking the idea behind the bond, it will give enough time for the preps to see their growth and evaluate their position.
Hey @radiofriendly123, I can take these questions:
Development Time: From what we have heard and based on current development priorities this is something that would take 6+ months to be finalized. So plenty of time to prepare.
6% Bond Number: Coming to consensus on specifics will always be difficult. I recommend thinking of it this way. If the 6% bond requirement is a deal breaker for you guys, I would respond to this thread with “Reject” then under your comments you could say “We would change our Reject to an Approve if the bond requirement was lowered to 3%” as an example. If it is not a deal breaker and something you are just a bit uncomfortable with, I would recommend switching to “approve” then in your comments section you can voice your opinion.
Governance Slashing: Votes will no longer close upon reaching majority in order to allow all teams to vote.
Self-Delegated Nodes running multiple sub p-reps: This is by design and I don’t think it’s a concern. Also, after doing some quick number crunching using the “whale analysis” model, these teams would make less rewards than they currently do.
Take a look at the “Whale Analysis” spreadsheet to see the actual numbers associated with this, and take a look at the bulleted list under the “CPF Allocation” Section of the proposal for detailed explanations of why this is actually beneficial in our view.
In IISS 2.0 (current design), self-delegated teams/exchanges are actually incentivized to run multiple main p-reps because of the additional reward you get per main P-Rep for producing blocks (B1). We are lucky nobody has decided to do this. This is a dangerous situation, and having passive/exchange teams stay out of block production and stay out of governance by running several sub p-reps is a far more favorable situation. Ask yourself if you would rather see a malicious whale running 2-3 main p-reps or several sub p-reps. Also, we never want to find ourselves in a situation where a few entities have controlling power of the network. We should use economics to ensure this doesn’t happen.
As a side note, any system design that puts any cap at all or any limitation of rewards on an individual node will result in an economic incentive for self-delegated teams to run multiple nodes, whether they are Sub P-rep Nodes or Main P-Rep nodes depends on the design. IISS 3.0 leads to Sub P-Reps.
I agree with that great proposal.
Sorry if this is the wrong place to ask this, but I remember vote decay being one of the posible solutions being disscused to solve voters apathy to revote.
Was this considered at all at some point and rejected? Or not considered at all?
In the case of it being considered and rejected I would like to know the reason why it was rejected (if possible).