Changes to ICON Economic Policy (IISS 4)


IISS 4 is a series of upcoming network proposals, originally introduced by Lydia Labs, intended to improve our network in the following ways:

  • More Decentralization: Increasing the number of people who produce blocks. This makes our network stronger and less likely to fail or be attacked.
  • Better Rewards: Ensuring validators (the people who help secure our network) and their supporters are rewarded only when they’re actively contributing to the network’s security.
  • Stronger Penalties: Adding new penalties to discourage any harmful actions and to keep our network safe and secure.


The most important event for validators and community members is the IISS4R0 network proposal. If this passes, validators will need to set their commission rates. Community members may want to change who they are delegating to based on the newly set commission rates.

For more information, see the up-to-date schedule here. Note that IISS4 changes are currently live on testnet and the schedule is subject to change if bugs are found during testing.


With ICON Incentive Scoring System (IISS) 3.0 and 3.1, we set out to create a more collaborative environment that aligns the network’s interests with those of its participants. The introduction of bond requirements, slashing penalties, and the contribution proposal system were key steps toward achieving this goal.

Several months ago, Lydia Labs put out a temperature check on their proposal to change the ICON monetary policy to improve the decentralization and sustainability of the ICON network. This proposal was approved by all of the validators who voted, which was 20 out of 25 of them. Now, we are in the final stages of the development of the policy changes. For more information about when the changes will be rolled out, please see the timeline.


IISS 4.0 includes changes to the number of validators involved in block production. By adjusting the number of validators to distribute block production more evenly across the network, more entities will be given the opportunity to participate in block production while maintaining a fast block time.

These changes are a step towards a more decentralized and robust blockchain ecosystem, ensuring that no single entity has disproportionate control or influence over the network.

  • Total number of validators per block to increase from 25 to 28.
  • Number of fixed validators to decrease from 22 to 19.
  • Number of rotating validators to increase from 3 to 9.


IISS 4.0 includes changes to the financial incentives of validators to better align with their role in securing the network. Validators receive rewards from block production and can charge commissions to voters, while the remaining tokens are distributed back to voters.

However, jailed validators or those without the required bond receive no rewards, and neither do their voters (more on that in the Penalties section below).

These changes help motivate validators to maintain a secure and reliable network, while also giving voters a clear reason to support validators that actively contribute to network security.

Inflation Allocations (%)

Parameter IISS 3 IISS 4 Notes
ivoter 77 N/A ivoter is merged to iprep in IISS 4 because prep sets commission and the rest of their allocation goes to their delegates
iprep 13 85
iwage N/A 5 iwage is newly added. For more information on iwage, see the Minimum Wage section below.
icps 10 10
irelay 0 0


Previously, voters’ ICX reward came from the ivoter parameter of inflation allocation. With IISS 4.0, voters’ ICX reward comes from the iprep parameter. PReps set how much of the iprep allocation they take for themselves, or their commission, and give the rest to their delegates.

Minimum Wage

Eligible validators can receive a minimum wage to help ensure their operations are profitable or at least close to break-even.

  • Eligibility: The top 100 validators that are not jailed with at least 10,000 ICX bonded are eligible for minimum wage. If there are fewer than 100 eligible validators, the minimum wage will be distributed among those eligible. Minimum bond is set by on-chain governance and part of the upcoming network proposals is to set it to 10,000 ICX.

Note that the total inflation rate, the percentage of inflation allocated for minimum wage, and the maximum number of eligible validators are variables that can be adjusted through on-chain governance processes.


We’re introducing some new penalties to keep validators accountable. These include penalties for missing blocks, repeated validation failures, double signing, and ignoring network proposals. We want to maintain a healthy environment where everyone plays by the rules to uphold the network’s best interests.

  • Penalized validators will be “jailed,” or removed from consensus until they signal readiness with an unjail transaction and validate a block on their next turn.
  • Rewards that a jailed validator would have received are instead burned.
  • A jailed validator’s position is replaced by a sub-validator with the highest power.
  • Validators who are disqualified via the P-Rep Disqualification Proposal will have their bond slashed by 100%.
  • Validators who sign two votes at the same block height and round will be jailed and have their bond slashed by 10%.
  • Validators who do not vote on a network proposal will have their bond slashed by 0.01%.
  • Validators who miss 660 consecutive blocks within a term will be jailed.
  • Validators who miss 660 consecutive blocks 3 times over the span of 30 participating terms will have their bond slashed by 0.01%.

The proposal to activate these penalties will be proposed 3 months after the Revision is set to IISS4R1, which is tentatively May 15, 2024.



" * A quorum(hover over for definition of quorum) of validators will be able to permanently ban a validator. Permanently banned validators will have their bond slashed by 100%."

This was never brought up or discussed in any of the previous posts. I personally will not be approving this proposal if this is included in the changes. This allows for REALLY bad politics to happen. I understand why this would be something that people would think is a good idea, but in reality this is a very very bad idea and will be driven by politics more than actual valid reasons.

Hey Geo_Dude, the P-Rep Disqualification Proposal already exists. The penalty looks like this:

  • Trigger: A quorum of validators votes in favor of disqualifying a validator via “P-Rep Disqualification Proposal”
    • Quorum: ⅔ of validators and ⅔ of total powers of validators
  • Consequence
    • Disqualified: the disqualified validator cannot be a validator forever.
    • Slashing 100% of validator’s bond
    • No reward forever for the validator and voters who have delegated their powers to it.

The slashing was announced in IISS 3.1 but most public facing archives got deleted. I’ll see if I can dig it up, but it was also in this forum post about it here IISS 3 | P-Reps penalty mechanisms and bond management

In any case, I think you bring up good points and if there is consensus in this forum about removing it, we can adjust accordingly.

I’ve searched all of the current chain code and there is a disqualification for Prep, but the 100% slashing was never added.

Consider this the public discussion then:

I was fine with the disqualification method in IISS 2.0 because it could be used to ban Preps that were just sucking up free rewards without participating in governance or even having an active node. This was an issue in IISS 2.0 for sure and into 3.0 I believe this issue persisted until 3.1? I’m not super confident in that regard, but at some point if you didn’t have bond and a working Prep node you would not collect rewards anymore. This was a solution to the stagnant prep node problem.

Honestly at this point I believe the ability for preps to create a network proposal to ban other preps should be removed entirely from the code. There are plenty of chain security measures in place now and with 4.0 that will punish malicious and stagnant behavior. This chain should not turn into a courtroom of peers judging each other and other political BS.

If a Prep can act maliciously against the chain then that’s a bigger issue with the chain and it’s coding that should be considered a MAJOR bug that should be remedied ASAP and should be handled with emergency network proposals. Not just allowing any prep to put up a proposal to ban another and burn their bond for any reason.

UPDATE: Thanks to Cyrus he found the post where it was mentioned but I believe glossed over because of all the other slashing issues (as you can read in the thread) and then never brought up in any future 3.1 posts (nor was the slashing mechanism for this particular disqualification ever implemented in 3.1). Here is the post it was mentioned in first and last: IISS 3 | P-Reps penalty mechanisms and bond management

I still believe this mechanism should be discussed further to see if it’s even relevant any more to the state of the chain.

We have to agree with @Geo_Dude on this one.

We stand against forcibly excluding validator and taking their funds - especially without legal basis behind it.

Disqualification based on the voting is a step away from decentralization.

Code should be the law.

1 Like

Overall I have no strong opinion. The feature of a P-rep DQ proposal is already on main net, but the penalty is not.

I’m fine setting the penalty to 0 for being DQed, can always be adjusted if folks feel otherwise, whether that be during the follow-on proposal or another time. I doubt this will ever be an issue anyway. Being removed from the network is penalty enough.

1 Like

What does it mean? **Validators sign two votes at the same block height** Can this happen automatically by code? Or does it mean double signing the blocks at same height with the same key from 2 different servers? 10% slash looks too much if the code can do it due to sw glitch?

Regarding P-Rep Disqualification Proposal will have their bond slashed by 100% , do you have more information about what could be causes for such proposals? Any example? It looks terrible!

1 Like

It means double signing the blocks at the same height with the same key from 2 different servers.

Such proposals are when a quroum of validators determine that a p-rep has been a bad actor and want to remove them from participation in securing the network. An example would be if a criminal or hacker becomes a p-rep. It is a corner case that is unlikely to ever occur, and can be considered sort of as a last line of defense for the network.