IISS 3.0 Proposal

Request for more information

Governance Slashing

  1. The governance slashing is proposed from the bond amount. Not having the bond amount by any team just prevents the team from claiming I-Score(or let me know if there are any other). What would happen if some P-Reps get slashing but have no bond?

  2. As we have seen with current mechanism for slashing, it is hardly possible to get slashing for any P-Rep and its voters by going below 85% productivity. With the proposed governance slashing, the proposed penalties will hardly affect any P-Rep if they apply scripts to avoid the penalty. So how does the penalties try to avoid the negligence of P-Reps? As the P-Reps are expected to act accordingly with these penalties to avoid slashing, they can simply do basic tasks just to avoid slashing.


Decision : Approve

Comments : Sorry for the delay in our vote. While we do approve of the proposal in general, there are a few areas we’d love to see some iteration, especially after reading some of the great feedback from the other teams. Overall, we support the direction, understand the reason for the changes, and are looking forward to continued discussions that could lead to some adjustments prior to implementation.


Team Name: DSNC

Decision: “Request for more information”


Regarding “Bond Requirement” - Could you please specify more in details what exactly is this 6% bond requirement? Is this 6% that should be our (P-Rep) self-voting/investing own ICXs from the total of the delegation of the votes we received? Also, where we (P-Reps) should “posting the full 6% bond”? Do we only need to show how many are our own ICXs as a stake we are holding? It is not clear where we need to keep or send this 6% bond requirement fund.

Regarding “Contribution Proposal Fund” – It is a very interesting proposal, which will cut one of the main benefits and the purpose to be the Main P-Rep, as it will remove the block production reward (B1) from all Main P-Reps and allocate those funds to CPF.

  • Does all block production reward (B1) will be cut from Main P-Reps and allocated to CFP or just a percentage of all B1 received?
  • Does this proposal encourage one entity to have multiple Sub P-Reps?
1 Like

Decision: Approve


if the foundation thinks this will improve DPoC, I am all for it.

some argue this complicate things - and yes we want things to be simple (that is, contribute to the project = get rewards). but sometimes getting there requires tweaking the system.

some say buying ICX is already a contribution and could be “skin in the game”. I have to respectfully disagree. some just buy in a bull market and then sell it later. i believe we want long term builders who will be loyal to this project to the end. sounds unreasonable, but that’s the behavior we should reward because that’s how we win. havent we learned enough from the ICO mania?

rewarding “contributions” is a difficult task as most dapp projects are a shot in the dark - we won’t know what the world needs until the world truly needs it. we will get there through repeated trial and error (or “tinkering” as Nassim Taleb puts it) - this is why DPoC is superior to DPoS (where the whales just park their money and dont do anything)

DPoC is hyper-evolution




weBloc Asia is supporting the IISS 3.0 Proposal in general except the quite heavy “6% of delegation received” minimum bond requirement. In order to meet the requirement, the team would need to run the node without claiming I-rep incentives more than several months. For a team concentrating all resources into dApp service development, the 6% figure would be quite a burden. I’d love to suggest mitigation on the minimum bond requirements.

But we do agree with the direction and the goal of the suggestions stipulated on the IISS 3.0 - creating healthy and strong ecosystem with various tools such as CFP initiative.


The IIS 3.0 proposal comes with some good ideas. As we mentioned in the call we would like to add the following:

  • Identities that don’t run a node shouldn’t earn rewards. The solution we suggested: set identities that don’t run a node as inactive if the node isn’t up for a certain period of time (x days). These identities can be set again as active with a certain transaction. If one identity goes inactive multiple times, after a certain number of cases (y times) they should get a slash. Monitoring of the P-Reps can be made by using the latest block height of every node.

  • Exchanges can potentially harm the definition of Delegated Proof of Contribution. If they only participate for rewards, we don’t see their added contribution. Even worse, if users won’t have the tokens locked, they do not respect the rules every other P-Rep has.



Decision: Approve

Comments: Our team supports the bond requirement proposal and the possible ‘filtering’ it may cause for P-Reps looking to receive benefits from the network but aren’t committed to being active participants. We are fine with the 6% but also flexible if other teams believe it is too high. Our team is also in support of the CPF. We see the potential of it being a collaborative effort amongst P-Reps.

Overall, while we believe in the current IISS model, there is always room for improvement and we welcome the opportunity to try new approaches if the aim is the betterment of our network.


Decision : Approve

I like the overall changes and the push to mitigate exchanges and non active p reps to involved in governance. I do feel there was some very good points that were brought up by some of the P reps that should be taken into consideration. But over all it’s a good move and not to say there’s not room for more improvement after the next implementation gets agreed upon.


@DSNC I can answer your questions:

Bond Requirement: The details are not yet decided. All this means is that you need to prove to the network that you hold ICX equal to 6% of your delegation. If you have 100k ICX delegated to you, you would need to stake 6k ICX in order to claim i-score. There would be no requirement of who to delegate toward. The plan would be to allow this to be done from a cold-storage wallet - it must be safe and secure.

CPF: As it is currently written, 100% of B1 goes to the CPF.

For your question about one entity having multiple sub p-reps: right now, in IISS 2.0 (the current incentive design), B1 incentivizes teams to have multiple main p-reps. Self-delegated teams should be running multiple main p-reps in order to maximize ROI. Right now I assume they don’t do this for altruistic reasons, but this is not something we should rely on in the long term to keep the network safe. In IISS 3.0, it shifts this incentive to have multiple sub p-reps. Neither are optimal, but multiple sub p-reps is far safer for the network than multiple main p-reps. There should be a cost associated with taking over multiple main p-reps - IISS 2.0 rewards this behavior, while IISS 3.0 punishes this behavior through opportunity cost.


Thanks a lot for answering my questions Scott.

I left with the impression before that officially there is an option which allows one entity to run multiple sub p-reps!
I hope we still do not allow this kind of behaviour or encourage some main P-Reps to move out from mail p-rep and have the option to run multiply sub p-reps as a better option for their investment!?

1 Like

Team: block42

Decision: Approved

Hey, everyone, I’ve just discussed IISS 3.0 with Scott and here is a quick overlook and the explanation why we approve the general direction of the IISS 3.0 that being said we hope to see small changes or adaptions to the proposal

The bond: We generally approve of the bond but we would like to see that the bond requirement should be eased in over a longer period of time to not completely halt the teams of their progress and maybe introduce a gradual increase over time staring with 1% and increasing each month. Also, the possibility of a % bond with a maximum amount was discussed because of the concern of whales delegating for P-reps to stop them from being able to claim the rewards.

CPF: We were on the same page with CPF. We believe that more rewards should go towards actual contribution than just running a node and there is still quite a good incentive for P-reps to run a node and confirm blocks.
Once it would be implemented if being a P-rep would required a lot of extra work of reviewing grant applications we would like to see the rewards for main P-rep to be increased.

Overall we think this is a step in the right direction, we will continue to monitor all the adaptions that are going to be made to the proposal.


Decision: Reject

While the proposed system does have foreseeable benefits, it’s a pretty radical shift from the decentralized nature of democratic voting, with a lot of additional moving parts that could prove to cause more problems than they solve.

Currently, we have a system where anyone has the ability to prove their worth via contributions and earn votes. ICONists are the one’s who have the ultimate say in what’s best for the ecosystem by delegating, and moving their votes (ICX) to the delegates of their choice, as it should be.

The proposed CPF system, on the other hand leans too much on the side of centralization by essentially moving the majority of rewards, and stripping block production rewards from elected block producers to a centralized fund that will be controlled by a few select entities. The top 22 P-Reps.

I think it’s safe to say, being that ICON Foundation holds majority of votes (17% to be exact). More than 10 times of some of the other P-Reps in the Top 22. They alone will have the majority of sway when it comes to approving or rejecting grants. A very centralized system that incentivizes the formation of “cartels”.

Here are some suggestions for adjustments to gain our approval:

CPF: The contribution proposal fund would be an amazing idea if it were to be implemented as a peripheral project funding system.

For example:

  • All P-Reps in the Top 100 would need to contribute a percentage of their rewards to CPF.

  • Reduce the number going to CPF ~20-30% (depending if you’re s Sub P-Rep, Main P-Rep etc.)

  • Block production rewards need to go to block producers. This is important.

That way we would still have an environment that promotes grants without completely neutering the Top 22’s ability to work on their own proposed initiatives and projects i.e Consensus 2020 which was a decentralized group effort by top P-Reps without any assistance from the foundation.

With a little bit of adjustments, I truly believe we can have the best of both worlds.


Decision: Approve

Comment: We believe that Icon Foundation is fully aware of what they are doing since they created the project and they can see full picture of Icon’s future.

With this proposal we take into account suggestions of many Iconists and p-reps who were asking to find some new solutions for i-scoring. That was one of the main topics this year and now we have very smart solution for it. CPF is also great idea because it vastly expands development. With this improvement many developers who are not main p-reps can now contribute more to the ecosystem.


Team: POS Bakerz

Decision: Approve


  • We support this proposal which will bring the ICON blockchain closer to decentralization.
  • We believe that the minimum bond of 6% for P-Reps lowers greatly align the interests of P-Reps and voters, we also like the fact that it lowers the benefit of vote-buying and that P-Reps will not be able to claim their I-Score when the bond requirement is not met. Our view is that this bond requirement should be implemented progressively over a 12 to 18 months time frame.
  • We love the CPF, the way it is finance and the fact that Main P-Reps will have to vote on proposals. This is a unique proposition and strongly brings the network closer to decentralisation.
  • On governance slashing, we appreciate the 3-day window to vote vs. 24 hours, but we think that the 20% slashing penalties are a bit harsh. Maybe an iterative approach would make more sense here. E.g. do we manage to get all P-Reps voting with only a 0.1% penalty? If it is the case, then fine.
  • Stopping additional delegations is important since P-Reps with lower bonds may not want to be over-delegated, and others such as the Foundation are getting too many votes and can’t do anything about it.
  • We agree with the idea that some might want to stay out of governance. Having this possibility will attract some exchanges, which is a plus for ICON. However, we believe that if one chooses to stay out of governance, then he should not get a Main P-Rep status or qualify for Main P-Rep rewards.

Team: ReliantNode


We’d like to explore the viability of:

  • Exchange nodes producing blocks for ICON, while opting out of governance
  • B1 rewards awarded to teams participating in governance

We’d done a full breakdown here - https://medium.com/@ReliantNode/reliantnodes-thoughts-on-iiss-3-0-b631ff5ab12a


Team : ICX Comics
Decision : Approve


Decision : Approved

The bond requirements is a great idea to lower the benefit of vote buying. would it be possible to have more information about the timeframes we have in order to put this in place?

Overall, IISS 3.0 will reward real builders and slow down the progress of inactive p-rep.

About CPF allocation, we thought it can be a better idea if the P-REP with « Greater than 1% Delegation » is replaced by « the P-rep with Greater than 2% Delegation ». It would encourage smaller teams to become more involved in ICON.

Governance Slashing is a good point.
Agree with the timeframe to vote for Network Proposals (3 days)

Awaiting feedback on our views about the CPF (1% --> 2%)


Hey @Sharpn, thank you for the response. Let me address your questions below:

Time Frame of Bond Requirement: As it currently stands, ICON’s roadmap can accommodate changes to IISS sometime end of Q3 maybe Q4 2020. Nothing is set in stone, but nothing would change prior to end of Q3 / early Q4. That’s the earliest anything would be changed on-chain.

Also, given lots of the feedback, we are looking into ways to ease in the bond requirement.

Changing from a 1% threshold to a 2% Threshold: I’ll take this opportunity to describe more logic of the 1%. 1% was picked because of the function being used to calculate this. Since we are taking a square root (or any root for that matter) this would raise rewards if it were below 1 and start tapering the marginal increase of rewards once it breaches 1.

If we did 2%, it would create a very weird situation where you would start losing money once you breach 2%. People would actually be upset if they received more than 2% of delegation. In the current system, by keeping the threshold at 1%, you always earn more money as you earn more votes. Any deviation from 1% would create weird situations like this. I took some screenshots to show the effect of your specific suggestion - notice how in the 2% threshold section, you actually lose 10k ICX per month (profits go down by 25%) by going from 2% delegation to 2.25% delegation. Happy to discuss over TG (@benny_options) and walk you through the models if there is still any confusion. Hope this helped!

Current situation with threshold at 1%:

Suggested threshold of 2%:


Some of the reasons why we support the IISS 3.0 changes:


A good discussion regarding IISS 3.0 and Consensus 2020. A lot of good ideas and clarifications. It’s a must watch for entire ICON community.