iip-dynamic-min-commission

[dlt-green]

This pull request introduces a new IOTA Improvement Proposal (IIP) that outlines a mechanism for dynamically setting a validator's minimum commission rate based on their effective voting power percentage (VP%) per epoch. The goal is to prevent large validators from hoarding stake by leveraging low or zero commissions, thereby promoting decentralization and fairer competition among validators. The proposal is fully backwards compatible and requires only a minor protocol adjustment.

Key highlights of the proposal:

Dynamic Minimum Commission Enforcement:

• Establishes a rule where a validator's minimum commission for each epoch is set to the greater of their publicly set commission or their effective voting power percentage (capped at 10%), using the formula: effective_commission = max(validator_set_commission, VP%).
• The adjustment is applied only for the current epoch's reward calculations; validators' displayed commission settings remain unchanged for future epochs.

Rationale and Impact:

• Provides a proportional incentive for stake distribution, discouraging centralization by making it less attractive for large validators to use low commissions to attract more stake.
• Ensures the maximum enforced minimum commission is bounded at 10% due to the existing protocol cap on voting power.
• The proposal is simple to implement, non-punitive, and has broad community and protocol team support.

Key changes in the new IIP:

Dynamic Commission Enforcement:

• Proposes that at the start of each epoch, a validator's effective commission rate is set to the greater of their set commission or their effective voting power percentage (VP%), with a maximum enforced minimum of 10% due to the existing protocol cap.

Rationale and Motivation:

• Provides detailed reasoning for the change, highlighting issues with current low-commission strategies leading to centralization, and explains how the new rule offers a proportional, non-punitive solution supported by community feedback.

Specification and Compatibility:

• Outlines the minimal protocol change required (a max() check in epoch logic), confirms backwards compatibility, and ensures no hard fork is needed.

Testing and Security:

• Lists test cases to verify correct enforcement in various scenarios, and discusses security considerations, emphasizing that the change does not introduce new attack vectors.