Reduce Governance Concentration via VP Cap, Joining Stake and Admission Guard

[0xBorsty]

This proposal reduces the risk that a small number of validators operated by a single entity can accumulate enough voting power to block protocol upgrades, without introducing any protocol-managed or dynamic validator commission.

It does so by:

1. Lowering the per-validator voting power cap from 10 percent to 5 percent of total voting power (from 1,000 to 500 out of 10,000).
2. Increasing the minimum stake required to join the validator set from 2,000,000 IOTA to 4,000,000 IOTA.
3. Enforcing a stake admission guard that prevents new delegation to an active validator once it is already at the voting power cap (in the normal capped regime), until it falls below the cap again.

These changes directly target voting power concentration, raise the economic and operational cost of multi-validator setups intended to gain governance blocking power, and dampen the "zero commission race" by making large validators capacity-constrained once capped, while keeping validator commission fully operator-controlled and contractually predictable.

Motivation

Problem Statement

Protocol upgrades and other high-impact decisions are gated by validator voting power. While the current system includes a per-validator voting power cap, entities can still accumulate meaningful governance influence by operating multiple validators.

The primary governance risk is not that individual validators can exceed the cap, but that a small number of validators controlled by a single entity can jointly reach a blocking threshold for protocol changes. This is particularly relevant for protocol upgrades, where an entity holding a blocking share can prevent activation of new versions and thereby exert disproportionate influence on network evolution.

A commission-based mechanism is an indirect lever for this problem. It introduces economic and reputational side effects while not addressing multi-validator concentration structurally. If the objective is to limit governance power concentration and reduce blocking risk, the most direct approach is to adjust voting power mechanics and entry costs, and to enforce stake flow constraints once a validator is already capped.

Why Not Dynamic Commission

Protocol-managed commission changes are high-risk for adoption and operations because:

• Commission is often used as a stable commercial parameter for delegators and partners.
• Automatic commission changes at epoch boundaries can be perceived as operator-driven fee changes, creating reputational damage.
• Delegators and integrators lose predictability, which undermines long-term planning and can prevent certain institutional or enterprise-style staking relationships.
• The mechanism creates negative externalities where stake flows by some delegators change the effective economics for all delegators in the same pool.
• A voting-power-linked minimum commission introduces feedback loops that incentivize constant re-delegation: as validators approach high voting power, fees increase, delegators exit, fees drop, and delegators re-enter. This produces churn and oscillation rather than stable, long-term stake allocation.
• If staking becomes fee-volatile and requires continuous optimization, a non-trivial segment of users will opt out rather than accept uncertainty plus potentially higher enforced commissions, reducing overall staking participation.

For these reasons, governance concentration and stake concentration should be addressed directly through voting power rules and stake admission rules rather than through dynamic commission.

Goals

• Reduce the likelihood that a small number of validators controlled by a single entity can block protocol upgrades.
• Preserve commission as an explicit validator operator choice and keep it predictable for delegators.
• Increase the marginal cost of operating additional validator instances for governance influence.
• Maintain transparent, deterministic, and easily explainable rules.
• Enforce a stake admission guard that stops further stake growth for validators already capped on voting power (in the normal capped regime), encouraging stake redistribution without fee volatility.

Non-Goals

• Preventing multi-validator operation entirely.
• Introducing identity-based or subjective "entity" enforcement.
• Changing the staking reward distribution model or validator commission mechanics.
• Introducing new scoring or reputation systems.

Background and Current Parameters (Reference)

This section documents the current relevant implementation in the provided codebase.

Voting Power

• Total voting power is constant at 10,000.
• Per-validator voting power is capped at 1,000 (10 percent).

Source:
crates/iota-framework/packages/iota-system/sources/voting_power.move
const TOTAL_VOTING_POWER: u64 = 10_000;
const MAX_VOTING_POWER: u64 = 1_000;

The voting power implementation includes a feasibility rule to ensure the total voting power can be assigned even when the validator count is small. The effective cap becomes:
threshold = min(TOTAL_VOTING_POWER, max(MAX_VOTING_POWER, ceil(TOTAL_VOTING_POWER / committee_size)))

This behavior is preserved by this proposal.

Validator Set Size

• Maximum number of active validators: 150

Source:
crates/iota-types/src/governance.rs
pub const MAX_VALIDATOR_COUNT: u64 = 150;

Minimum Stake to Join

• Minimum stake required to become an active validator: 2,000,000 IOTA

Source:
crates/iota-types/src/governance.rs
pub const MIN_VALIDATOR_JOINING_STAKE_NANOS: u64 = 2_000_000 * NANOS_PER_IOTA;

The on-chain parameter is referenced via system parameters when a candidate requests activation:
crates/iota-framework/packages/iota-system/sources/iota_system_state_inner.move
self.validators.request_add_validator(self.parameters.min_validator_joining_stake, ctx);

Protocol Upgrade Activation Threshold

Protocol upgrades are governed by stake-weighted approval thresholds derived from BFT constraints and configured buffers. In the current codebase, this is expressed as "2f + 1 + buffer stake" logic, where the buffer is configured via ProtocolConfig::buffer_stake_for_protocol_upgrade_bps and can result in activation requirements beyond a simple two-thirds majority.

Source pointers:

• crates/iota-core/src/authority.rs (comments in set_override_protocol_upgrade_buffer_stake)
• crates/iota-protocol-config/src/lib.rs (network snapshots contain defaults)

This proposal is designed to reduce the feasibility of upgrade blocking by a small number of validators under common threshold configurations.

Specification

1. Lower Per-Validator Voting Power Cap to 5 Percent

Change the constant:

• MAX_VOTING_POWER from 1_000 to 500.

Normative behavior:

• Total voting power remains fixed at TOTAL_VOTING_POWER = 10_000.
• The per-validator voting power cap is MAX_VOTING_POWER = 500 when the committee size makes this feasible.
• The existing feasibility rule remains unchanged, meaning the effective cap can be increased above 500 if required to allocate the full 10,000 total voting power when the validator count is very small.

2. Increase Minimum Validator Joining Stake to 4,000,000 IOTA

Change:

• MIN_VALIDATOR_JOINING_STAKE_NANOS from 2_000_000 * NANOS_PER_IOTA to 4_000_000 * NANOS_PER_IOTA.

Normative behavior:

• This threshold applies to validator candidates joining or re-joining the active set after the upgrade.
• Existing active validators MUST NOT be forcibly removed solely for being below the new joining threshold. The intent is to raise the entry cost for additional validator instances without disrupting current long-tail participation.

3. Stake Admission Guard for Validators at the Voting Power Cap

Goal:

• Provide a buffer mechanism that prevents a validator from continuing to accumulate additional stake while it is already capped on voting power in the current epoch (in the normal capped regime).
• Reduce the payoff of "zero commission" stake-attraction strategies by making large validators capacity-constrained once they are capped and forcing incremental stake to flow to non-capped validators.

Normative behavior:

• A stake delegation request to an active validator MUST be rejected if, in the current epoch, the validator's voting_power equals the effective voting power cap used by the protocol for the current committee size, and the system is in the normal capped regime where effective_cap == MAX_VOTING_POWER.
• The guard applies to new stake additions only. It MUST NOT prevent stake withdrawals, unstakes, or re-delegations away from a validator.
• It is acceptable that a validator can reach the cap due to pending stake that becomes effective at an epoch boundary. Once capped in the new epoch, the validator cannot accept additional stake until it falls below the cap again.

Feasibility rule interaction:

• The guard MUST use the same effective cap logic as voting_power::set_voting_power, including the committee-size feasibility adjustment.
• To avoid pathological behavior in very small committees where the feasibility rule raises the effective cap, implementations MUST only enforce the guard when effective_cap == MAX_VOTING_POWER (that is, when the system is in the normal capped regime). When effective_cap > MAX_VOTING_POWER, delegations MUST remain allowed.

Error semantics:

• Rejection SHOULD abort with a dedicated error code such as EValidatorAtVotingPowerCap so wallets and SDKs can surface an understandable message (for example, "Validator closed to new stake while at voting power cap").

Rationale

Why 5 Percent Voting Power Cap

Lowering the per-validator voting power cap reduces the governance influence a single validator can hold and increases the number of validators required for any entity to reach governance blocking thresholds.

In practical terms:

• Under a 10 percent cap, entities can reach meaningful blocking power with a small number of validator instances.
• Under a 5 percent cap, an entity must operate more validator instances to reach the same aggregate voting power, increasing operational complexity, capital commitment, and public visibility.

This is a direct mitigation of governance concentration risk without changing commission.

Why Raise Joining Stake to 4,000,000 IOTA

Lowering the voting power cap can increase the incentive to operate multiple validators. Raising the minimum joining stake increases the marginal cost of each additional validator instance.

A moderate increase from 2M to 4M IOTA:

• meaningfully increases Sybil and multi-validator cost,
• avoids excluding a non-trivial set of existing smaller validators,
• preserves decentralization by keeping long-tail participation viable while still raising the barrier to multi-instance governance accumulation.

Why the Stake Admission Guard Helps

Even with a voting power cap, delegators can continue to add stake to already capped validators. That does not increase voting power in the current epoch, but it can still amplify stake concentration, increase the likelihood that the validator remains capped in future epochs, and make it harder for stake to redistribute organically.

The stake admission guard acts as a deterministic capacity constraint:

• Once a validator is capped, it cannot keep growing further until it drops below the cap.
• New stake is forced to flow to non-capped validators, which improves distribution without fee volatility or subjective enforcement.
• This structurally dampens the "zero commission race": a low-fee validator can no longer attract unlimited stake indefinitely, because it becomes "full" once capped and incremental stake must route elsewhere.

Why This Is Preferable to Dynamic Commission

Dynamic commission is an indirect mechanism for a governance concentration problem. It introduces economic unpredictability, reputational failure modes, and contractual infeasibility for delegators and operators, while not structurally preventing multi-validator concentration strategies.
More importantly, a voting-power-linked minimum commission is likely to destabilize delegator behavior:

• It incentivizes continuous re-delegation to avoid fee spikes, creating churn and oscillations around epoch boundaries.
• It shifts staking from a predictable, passive activity into a continuously re-optimized strategy.
• It risks reducing staking participation if users are unwilling to accept fee volatility and potentially higher enforced commissions.

Voting power rules, entry costs, and a stake admission guard directly address concentration with fewer collateral side effects, and they preserve commission as an operator-controlled parameter.

Backward Compatibility and Migration

Voting Power Cap Change

• The voting power cap change takes effect at the epoch boundary after the framework upgrade that updates MAX_VOTING_POWER.
• Voting power is recomputed each epoch, so the new cap is naturally applied at epoch transition.
• No validator or delegator action is required.

Minimum Joining Stake Change

• Applies to new validator candidates and to re-activation or re-joining flows after the upgrade, depending on how the current on-chain parameter is used in lifecycle transitions.
• Existing active validators MUST NOT be removed solely due to being below 4,000,000 IOTA. This proposal is intended to raise the cost of new entries and additional instances rather than to evict current participants.

Implementation note:

• SystemParametersV1.min_validator_joining_stake is stored on-chain. The upgrade MUST ensure the stored value is updated to match the new constant, either through an explicit migration or by introducing an override mechanism with proper access control.

Stake Admission Guard

• The guard takes effect at the epoch boundary after the framework upgrade that introduces it.
• Wallets and explorers SHOULD be updated to surface capped validators as "closed to new stake" to reduce user confusion and failed transactions.
• Documentation MUST be updated because the system would no longer allow unlimited new stake to any validator at any time.

Security Considerations

• Reduces risk of protocol upgrade blocking by small validator counts controlled by a single entity.
• Increases economic cost of multi-validator strategies via higher joining stake.
• Stake admission guard reduces the ability of already capped validators to further accumulate stake, mitigating concentration dynamics (including low-fee stake attraction) without commission changes.
• Does not eliminate identity-based concentration; sufficiently capitalized entities can still run many validators. This is a deliberate trade-off to avoid subjective identity enforcement.
• The feasibility cap adjustment for very small committees remains unchanged, because a too-small committee is itself a critical decentralization failure scenario and requires keeping the system operable.

Economic Considerations

• Delegators receive clearer, more predictable commission semantics, since commission remains operator-controlled.
• Larger validators are prevented from translating stake dominance into governance dominance beyond 5 percent per validator.
• Stake admission guard forces incremental stake to redistribute once large validators are capped, dampening "race to zero commission" dynamics by limiting the ability of any single low-fee validator to scale indefinitely.
• Avoids making staking churn-heavy: delegators should not need to constantly re-delegate to preserve expected economics.

Reference Implementation

Voting Power Cap

File:

• crates/iota-framework/packages/iota-system/sources/voting_power.move

Change:

• const MAX_VOTING_POWER: u64 = 1_000;
  to
• const MAX_VOTING_POWER: u64 = 500;

Tests to update:

• crates/iota-framework/packages/iota-system/tests/voting_power_tests.move
  • Update expectations where the effective cap is applied under feasible committee sizes.

Documentation to update:

• docs/content/operator/validator-node/validator-tokenomics.mdx
• Update the described cap from 10 percent (1,000) to 5 percent (500), and explain feasibility behavior.

Minimum Joining Stake

File:

• crates/iota-types/src/governance.rs

Change:

• pub const MIN_VALIDATOR_JOINING_STAKE_NANOS: u64 = 2_000_000 * NANOS_PER_IOTA;
  to
• pub const MIN_VALIDATOR_JOINING_STAKE_NANOS: u64 = 4_000_000 * NANOS_PER_IOTA;

Documentation to update:

• docs/content/operator/validator-node/overview.mdx
  • Update "2 million IOTA" to "4 million IOTA".

On-chain parameter migration:

• Update SystemParametersV1.min_validator_joining_stake during the framework upgrade so that request_add_validator enforces the new threshold.
• The migration approach should be explicit and auditable, minimizing risk of accidental validator set disruption.

Stake Admission Guard

Files:

• crates/iota-framework/packages/iota-system/sources/validator_set.move
• crates/iota-framework/packages/iota-system/sources/voting_power.move
• Potentially crates/iota-framework/packages/iota-system/sources/iota_system_state_inner.move (only if needed for wiring, usually not required if enforced in validator_set)

Recommended approach:

1. Add a public helper in voting_power.move to expose the effective cap for a given committee size, using the same formula used internally for set_voting_power.

   Example signature:

   public fun effective_voting_power_cap(committee_size: u64): u64

2. In validator_set.move, inside ValidatorSetV2.request_add_stake, add a guard:

   • Determine committee size.
   • Compute effective cap via voting_power::effective_voting_power_cap(committee_size).
   • If effective_cap == MAX_VOTING_POWER and validator.voting_power() == effective_cap, abort with EValidatorAtVotingPowerCap.

3. Add or update Move unit tests to cover:

   • Delegation succeeds when validator is below cap.
   • Delegation aborts when validator is at cap (normal capped regime).
   • Delegation remains allowed in small-committee cases where effective cap is raised above configured MAX_VOTING_POWER.

Documentation updates:

• Update tokenomics or staking docs to clarify that delegations to capped validators can be rejected until the validator drops below the cap.

Alternatives Considered

1. Dynamic minimum commission based on voting power
   • Rejected due to contractual risk, reputational and UX issues, negative externalities among delegators, delegation churn around epoch boundaries, and bypass routes such as off-chain rebates.
2. Identity-based entity caps
   • Rejected due to unverifiable identity, governance subjectivity, and difficult enforcement.
3. Only raising joining stake
   • Insufficient, because it does not address the "small number of validators can reach blocking power" problem if the per-validator voting power cap remains at 10 percent.
4. Only reducing voting power cap
   • Helps, but may increase incentives for multi-validator operation. A higher joining stake complements the cap by raising the marginal cost per additional validator instance.
5. No stake admission guard (cap only)
   • Rejected because delegators could continue to concentrate stake on already capped validators, sustaining the "zero commission race" incentive and making organic redistribution harder across epochs.

Unresolved Questions

• Confirm the most appropriate migration mechanism for SystemParametersV1.min_validator_joining_stake in the framework upgrade process.
• Confirm network-specific defaults for protocol upgrade buffer thresholds and evaluate whether additional parameters should be adjusted in the same upgrade for consistency. This IIP does not require changes beyond voting power cap, joining stake, and stake admission guard.
• Define wallet and explorer requirements for surfacing "closed to new stake while capped" validators to minimize failed transactions and user confusion.
• Finalize the error code naming and user-facing message conventions for EValidatorAtVotingPowerCap across SDKs and wallets.

Conclusion

Lowering the per-validator voting power cap from 10 percent to 5 percent, increasing the minimum validator joining stake from 2,000,000 to 4,000,000 IOTA, and enforcing a stake admission guard is a direct, transparent method to reduce governance concentration and upgrade blocking risk.

It avoids destabilizing validator economics by keeping commission fully operator-controlled and predictable, while raising the operational and economic cost of multi-validator strategies used to accumulate governance influence. The stake admission guard further reduces concentration by preventing already capped validators from continuing to accumulate stake, forcing incremental stake to redistribute and structurally dampening the "zero commission race" without introducing fee volatility or re-delegation churn.

[dlt-green]

We anticipated a proposal along these lines. However, we strongly oppose both further lowering the cap and raising the entry barrier. These changes would impede support for new validators and directly disrupt the existing reward structure. In our view, this would drive established professional validators out of the IOTA ecosystem while making it significantly harder for newcomers to enter.

We will not engage further on this matter until all blocks imposed on us (main profile and some long-standing IOTA OGs and also blocking on other validators) in the "IOTA Deutsch" X group (formerly "TangleTalk") and its Telegram channel have been lifted and messages are not censored there anymore. Such actions run entirely counter to the collaborative spirit of a decentralized network and amount to an attempt to manipulate public perception within these circles.

WE AS DLT.GREEN DO NOT SUPPORT THIS IIP

[0xBorsty]

Such a reaction was certainly to be expected. It's amazing how you can now reconcile my profile with "Iota Deutsch." X https://x.com/Borsty_1?s=20 You can't get anywhere with demands. Get me permission from all administrators in "Iota Deutsch" and I will be very happy to discuss what has been clarified internally. Such information is kept secret. I can't wait to talk about it. Be careful, it may prove better that this information does not come to the outside world because the result does not correspond to one's own perception. Since they won't be any more answers, I wish them a nice Sunday!

[tokenlabsx]

TokenLabs formally registers its STRONG OPPOSITION to this proposal (IIP-31)

Upon technical review, we conclude that the proposed mechanisms would undermine the network's decentralized nature by protecting incumbents and erecting artificial barriers against new entrants.

1. Artificial Barriers to Entry (The 4M IOTA Threshold)
Increasing the minimum stake to 4,000,000 IOTA is an exclusionary measure that directly harms the ecosystem's diversity.

• Effect: It effectively blocks the "long tail" of community validators and independent developers from securing the network, reserving the validator set exclusively for well-capitalized entities.

• Centralization Risk: High entry barriers historically lead to oligopolies, not decentralization.

2. Ineffectiveness of the 5% Cap & Sybil Risks
Reducing the cap to 5% without addressing the underlying economic incentives (fees) is functionally ineffective against large capital holders.

• The Sybil Vector: Large entities will simply fragment their stake across more nodes to bypass the limit. This increases ledger bloat without distributing actual power.

• The Paradox: It is striking that this proposal—which claims to combat centralization—comes from an entity that currently controls >10% of the Voting Power across multiple nodes with near-0% fees.

• Observation: This proposal would not stop such entities; it would merely force them to spin up a third node, while the 4M requirement ensures no smaller competitors can rise to challenge them.

3. Governance & Transparency Standards
We strongly second @dlt-green concerns regarding the integrity of the debate. TokenLabs has also been blocked from social media channels managed by the proponent simply for engaging in technical governance discussions.

• Principle: Genuine governance requires an open forum where dissenting technical arguments are debated, not silenced.

Conclusion:
IIP-31 appears designed to consolidate the position of existing large operators while closing the door on the community.

We advise the community to reject this and focus on finalizing IIP-29. We must address the root cause—the unsustainable fee structure—rather than manipulating entry requirements to exclude competition.

[0xBorsty]

Then let's continue with the false perception here. https://x.com/Borsty_1 is my profile, what I do with it is absolutely my personal and private matter. I ask that this be taken into account. I have been doing talks around Iota for years, there is no payment, on the contrary, I had a lot of costs that I will never see again. That's the way it is with a hobby. One more thing, I don't even have Iota Token. To the 4 million tokens, The IF had something in mind when they set the amount of the tokens. The price is crucial here; since the launch of Rebased, the price has fallen very sharply. This is about getting closer to that value. The 5% is there to make it more difficult for companies to influence decisions. I didn't even know I was a validator.

[salimaseelenwolf]

🧵 IIP 31 on IOTA

✅ Pros
• Targets the real risk of governance blocking via multi validator control
• 5 percent cap plus stake admission guard tackles concentration without dynamic fees
• More predictable staking, less churn, cleaner UX

⚠️ Cons
• 4M minimum stake can slow validator growth right when speed matters
• The admission guard only really kicks in once the committee is large enough
• Sybil is not removed, only made pricier, plus slot capture incentives can rise

🎯 My take
Direction is right
But the 4M threshold should be phased in so the current country level adoption momentum is not slowed
Countries indirectly demand more validators, not fewer

[tokenlabsx]

@salimaseelenwolf Thank you for this balanced analysis.

I believe you have correctly identified the critical flaws that make this proposal (IIP-31) counter-productive in your "Cons" section.

1. On Sybil Resistance (The 5% Cap) As you rightly noted: "Sybil is not eliminated, only becomes more expensive." We have already observed on-chain that large entities have no issue splitting their stake across multiple nodes to bypass limits.

The Reality: Lowering the cap to 5% without addressing the economic root cause (zero fees) essentially incentivizes ledger bloat. It forces large incumbents to spin up more redundant nodes to hide their total control, while honest operators are restricted. It creates "Security Theater" rather than actual security.

2. On the 4M IOTA Barrier vs. Growth You mentioned that the 4M threshold "can slow down validator growth just when speed matters." We fully agree.

Whales vs. Community: Increasing the requirement from 2M to 4M is trivial for a whale (or an entity managing >10M IOTA), but it is a massive barrier for the "long tail" of community validators and startups that actually decentralized the network.

The Price Factor: We must also consider adoption. As the network grows and the token price potentially rises, a fixed 4,000,000 IOTA requirement becomes an exponentially higher financial wall in dollar terms. We should not be building higher walls if we want to invite global adoption.

Conclusion A proposal that guarantees slower growth (by raising barriers) but offers bypassable security (Sybil attacks remain possible) is not a solution.

The Solution: We agree with the need to reduce concentration, but the path is IIP-29. We need to incentivize capital to naturally flow from saturated nodes to smaller ones via economic mechanics, rather than trying to force it with rigid barriers that only hurt new entrants.

[0xBorsty]

A little tip, currently there are maybe three validators to be provided with 500K, which is absurdly easy when you want everything to run on iota since we're talking about it here. The value of the 4 million token will be adjusted anyway if the price increases sharply. This change is not a big expense in the protocol and why not first pass in one direction and then in the other direction again if time requires it. Example, when I heard about ADAPT in September, I also thought the price was going up. Didn't happen and I have to take the current price and that wasn't what could possibly happen at some point. To sell capital naturally? The sentence also overrides the last mechanics of validators who can still decide for themselves. In this publishing house the validator forces are forced and the people who will be their token delegates are not happy about it, they were made with them.

[cyberphysic4l]

IOTA Foundation Research IIP Assessments

In recent weeks, two IOTA Improvement Proposals (IIPs), including this one, have been made by community members, each taking a different approach to solve the same problem of excessive voting power concentration in a small number of actors. We have impartially assessed each IIP and arrived at an IOTA Foundation position on each.

Proposal 1: Dynamic Minimum Commission

The first proposal introduces a dynamic minimum commission for validators exactly equal to their voting power with the goal of preventing large validators from setting excessively low commission and outcompeting smaller validators for attracting delegators. Setting a minimum price for a service in this way is known as price floor regulation and is a well established practice used to prevent monopolisation in many industries. It acknowledges that the larger a single supplier (validator) becomes, the more efficient they become and they can drive down their price, ultimately cutting all smaller actors out of the market unless regulated. Although efficiency and low prices (commission) is positive for customers (delegators), monopolisation can lead to complete elimination of competition and much worse outcomes. In DLTs, this is even more serious because centralisation of validator power is also detrimental to the security and integrity of the entire system, not just to the delegator market.

The figure below illustrates the proposed minimum commission function alongside several level curves showing the annual amount of IOTA earned through commission for different voting power and commission percentages.

One of the primary concerns with the proposed commission function is that it incentivises large validator operator's to simply split their stake over multiple validators to avail of lower commissions. However, there is a limit to how many times they can reasonably split their stake because each new validator comes with additional costs and a minimum stake. The level curves in the figure illustrate the fact that smaller validators must set significantly higher commissions than their large counterparts to cover these fixed costs or be profitable.

Stake Redistribution

The original IIP includes some static analysis of the new commissions for validators, but this does not take into account the resulting stake redistribution due to operators diving their stake over additional validators and delegators moving their stake in response to the new commissions. Here, we provide a brief analysis of the potential impact of these behaviours. This analysis contains important assumptions that do not perfectly reflect reality.

At the time of writing, roughly 27% of voting power lies with 15 validators with commission less than or equal to 2%. The bar plot in the figure below shows the commission of each validator, with low commission validators shown in red. The height of the bars is the commission and the width of the bars is the voting power of the validator.

Let us assume that the stake delegated to these low-commission validators is highly elastic, meaning that it will gradually move to the validator offering the lowest commission. Assuming all other stake in the system is inelastic, no operators split their stake and no other validators enter the market, we would expect the equilibrium distribution of the stake on these validators to be as shown in the figure below under the proposed minimum commission proposal.

The reason we expect to arrive at this equilibrium is that the smaller validators will be able to set lower commission to attract more delegators, and they will take the delegations from larger low-commission validators who have higher commission due to the new minimum commission rule.

When we remove some of the unrealistic assumptions, we begin to get closer to the true expected behaviour. For example, we must assume that operators will split their stake across multiple validators and that new low-commission validators will enter and leave the market in response to these changes. In this case, we will instead expect a similar equilibrium, but at a different level of voting power and commission due to the variable number of low-commission validators on the market. Accurately predicting the true equilibrium point of these low-commission validators is impossible, but observing that such an equilibrium should exist is sufficient for this analysis.

Small Validators Entering the Market

One of the goals of the proposal is to allow small new validators joining the system to attract more delegators when they are getting established. We expect this to be possible to a limited extent. We expect the system to tend towards having a cohort of low-commission validators that attract all the delegations of the more elastic delegators. These low-commission validators will be operating at a commission that is barely profitable, and will likely contain many validators run by the same large operators who can operate at lower costs due to the efficiency of running multiple instances. When a new validator enters the market, they will be able to set their commission lower, initially making a loss to attract delegators. They will be able to grow to the size of this cohort of low-commission validators where they may be able to make some profit, but not expected to be able to grow beyond this size by attracting delegators looking for low commission.

Alternative Minimum Commission Functions

The current proposal utilizes a linear relationship between voting power and minimum commission. While this is effective at penalizing centralization, it may be considered overly restrictive for large validators. A linear function may be too restrictive in the case of larger validators as it effectively negates the economic benefits of scale. This removes the freedom for large, efficient operators to lower their prices to compete.

Alternative functions could still enforce a rising price floor as voting power increases, but the rate of increase could diminish for larger validators. Examples include the piecewise linear function proposed in this comment, or a sublinear functions (e.g. square root). These alternative would act as a compromise: it is "fairer" to large operators by allowing them to retain some competitive pricing flexibility, but it applies less aggressive economic pressure to split or reduce stake. These functions would result in a weaker driver for decentralization compared to the strict linear model, but may be enough for healthy decentralisation.

Summary

Pros

• Easy, low-complexity implementation.
• Low number of existing validators impacted immediately.
• Makes it impossible to operate a near-zero commission validator profitably.
• Creates a barrier to large operators running low-commission validator services.
• Allows small validators to operate with competitively low commission while they become established.

Cons

• We still expect a low-commission validator market to exist with commission less than 2%, where the existing operators and some new operators run one or more validators.
• We expect it to remain very difficult for small validators to operate profitable based on the premise of attracting delegators through low commissions under this proposal.
• The incentive for large low-commission operators to split into multiple validators is a major inconvenience to these operators. A solution that does not encourage splitting would be preferable.
• Large actors will still be able to set lower commissions than if we used a simple fixed minimum commission of 5% (see appendix below).
• The unpredictability of commission and the need for delegators to constantly re-delegate is not good for user experience.

Proposal 2: VP Cap, Joining Stake and Admission Guard (this proposal)

This second proposal introduces the following changes:

• Reduction of voting power cap from 10% to 5%.
• Raising the minimum joining stake from 2M to 4M IOTA.
• Introducing an `admission guard' for validators to prevent delegation above the 5% level.

This second proposal does not include a dynamic element, so the resulting analysis is more streamlined.

The first component -- a reduction of the voting power cap to 5% -- has the impact of encouraging large operators to split into multiple validators when they reach this threshold. However, the threshold is still high enough that an operator can control a unhealthy level of stake with a relatively small number of validators.

The second measure attempts to address this concern by making it prohibitively expensive to create additional validators, but this also has the impact of making it prohibitively expensive for any other small actors to join as validators.

The third measure aims to protect delegators in the event of delegating to validators whose voting power goes over the cap, ensuring the rewards of other delegators do not become diluted.

Summary

Pros

• Easy, low-complexity implementation for the first two measures.
• Low number of existing validators impacted immediately.
• Creates additional barriers to single validators growing their voting power.
• More directly enforces splitting of excessively large validators.

Cons

• The third component of admission guard has relatively high implementation complexity and exact effect is unclear.
• Does not address the race to zero commission with large validators easily outcompeting small actors.
• Makes it more difficult for small actors to join the validator set due to increased joining amount.
• Although more direct an effect, it does not create any economic incentive to actually move stake away from large actors, only encourages splitting of stake.

IOTA Foundation Research Position

IOTA Foundation Research supports proceeding with the Dynamic Minimum Commission proposal to observe its impact on network behavior. We are in favour of promoting healthy decentralisation of validator power in the interest of network health, and we do not anticipate any aspects of the proposal to increase centralisation.

As highlighted in the proposal, only a small number of validators will be immediately impacted. These actors have the option to operate multiple validators if they wish to continue offering low commissions. Observing the delegation dynamics after implementing the proposal will give us further insights and allow us to investigate the potential benefits of alternative commission functions as discussed above. Given the complexity of these economic dynamics and the uncertainty of the actual impacts, we intend to treat the optimization of this function as a priority for future research rather than proposing a definite alternative at this stage. If we observe that the identified cons significantly impacts delegators' user experience or if stake remains overly concentrated, we will consider transitioning to an alternative minimum commission function, or a fixed minimum commission (e.g., 5%), which may offer a better long-term outcome.

Regarding the second proposal of VP Cap, Joining Stake and Admission Guard, IOTA Foundation considers that it provides insufficient economic incentives to have any real impact on the voting and governance power of large actors. There is also insufficient evidence to promote the need for an increase in the minimum joining stake which will deter new small validators from joining the set. We also deem the complexity of the third measure to outweigh its practical benefits.

Appendix: Fixed Minimum Commission

An alternative solution discussed above that is worth discussing further is to set a fixed minimum commission of 5% for all validators, regardless of voting power. As mentioned in the original IIP, this has been used in other networks already, and its dynamics are simpler to analyse because it creates no incentive for operators to split their stake among several validators. "Low-commission" validators will have a fixed minimum of 5%, preventing a race to zero commission and unsustainable economics for small validators. Although it does not present an opportunity for small validators to offer even lower commission than their large counterparts, it allows them to be an equally viable alternative while still having the potential to make some profit and operate sustainably.

Summary

Pros

• Easy, low-complexity implementation.
• Already tested and verified in other networks.
• Makes it impossible to operate a near-zero commission validator.
• Good UX with predictable commission and less need for delegators to re-delegate.
• Allows small validators to offer equally low commission to large validators while also operating sustainably.

Cons

• Impacts the commission of a larger number of validators immediately.
• Only removes incentive to move delegation to large low-commission actors, does not actively incentivise moving delegation away from them.