Currently, validators on the Casper Network can set their validator fee to 0%. While this may appear attractive to delegators, it creates unhealthy competition that undermines validator sustainability. Running validator machines requires significant costs, and validator fees are the only source of income for operators. With fees at 0%, validators are forced to spend without earning, threatening the stability and security of the network.
To address this, I propose that the Casper codebase be updated to support a minimum validator fee parameter.
Problem
Inflation distribution: Around 8% of new CSPR is distributed annually through staking rewards.
Validator rewards: Delegators earn from inflation, while validators rely on a self-set commission fee (the validator fee) as their only income.
0% fee competition: Because validators can set their fee to 0%, delegators naturally prefer them. This creates a race-to-the-bottom dynamic that leaves validators without revenue.
Sustainability risk: If validators cannot cover costs, they will leave the network, reducing decentralization and security.
Proposed Change
Introduce a chain-level minimum fee parameter in the Casper protocol.
Validators will not be able to set their fee below this minimum.
This ensures all validators have at least a baseline income stream.
Phase approach:
Step 1 (this proposal): Implement the code logic for a minimum validator fee, making it possible to enforce such a rule.
Step 2 (future governance proposal): Decide the actual minimum percentage (e.g., 2%, 5%, etc.) through community discussion and vote.
Benefits
Protects validator sustainability.
Ensures fair competition (delegators still have choice, but not at the expense of validator survival).
Strengthens network decentralization and long-term security.
Next Steps
Approve implementation of the minimum fee parameter in the Casper blockchain code.
After the feature is merged, open a new proposal to decide the exact minimum fee value.
There could be the following reasons to run a 0% node - neither financial nor legal advice nor fact checked:
Tax-related
Regulation/Market manipulation
Religious/ideological reasons (in for the tech, enough hopium for a brighter future aka marketing for later)
Cross financing with other institutions/exchanges/partners/projects to gain a market share/grow a brand
Starting a new node with minimal effort and marketing, the 0% speaks for itself and attracts delegators
Running limited 0% campaigns easily at any time as long as wanted (attract new delegators, compensation for downtime…)
I see the marketing part being the biggest limitation affecting every node operator and a minimum rate would benefit existing node operators only to secure their slot and only because they were here first. It would therefore make it harder for new node operators to get some delegators.
Important side note:
I think this proposal is a very small issue compared to the whole situation of the network and how the CA with their new board and structure are operating.
There are two factors that need discussion and agreement.
1 - Implementing this so that in steady state operation. Changes to make this function for all new validators and calls to end points.
2 - The next piece is migration. For those that are under this new limit, would the rate be automatically adjusted at upgrade and rewrite these bid records?
if wanted real fast, we could look into a 2.0.5 with it hardcoded
if wanted as a chainspec setting, v2.2
presumably it should still be possible to have a reservation delegation rate as low as 0
side notes:
reservation logic should be checked to see if it is allowed to reserve a slot for a delegator that you already have…presumably validators that self delegate would want to set up a reservation with a lower than min delegation rate for their self-delegations
So in the light of the dev team’s comment and the comments above, this seems okay/reasonable to me:
It will be a chainspec setting
It doesn’t impact/limit the reservation delegation rate
It doesn’t work retroactively, i.e. there is no migration needed, and the new limit only applies to new calls to add-bid
As a validator, I think we should have this feature, but I’m not sure if it should be enabled or when or with which minimum value yet. We will have more time to further discuss the details among the validators and with our delegator communities.
I see your point, but enforcing the fee on existing bids requires a migration, which complicates the implementation. I think it would be wise to keep it simple.
@gokaysatir Please let me know if you spot any issues. Planning to put the immutable doc on IPFS in the morning (EU morning, Sep 18), then mint the voting tokens.
