Can somebody explain me why a 0% commission validator can earn 47 DOT per day?
1guBaaUmYpYPmsNmooQApqFmpmRHeaipb1CxoncMuiaqXGh
14tcxHSTAiZf7M4vcLfFdGkGJFjfx6zDqds5QVyz2H24hKgG
15tfUt4iQNjMyhZiJGBf4EpETE2KqtW1nfJwbBT1MvWjvcK9
Are validators charging the commission that is displayed, or is there a discrepancy between the shown and actual commission?
Did you forget to check the commission history?
Are you asking why a specific validator charging 0% commission receives rewards themselves? If so, each validator in the network receives approximately the same amount of rewards, this is paid from a part of the inflation. These rewards are divided proportionally to the stake on that validator node, if the validator himself has a selfstake then a proportion of the rewards are paid to him, the rest to his other nominators. The commission is just a percentage of the rewards that the validator gets to keep, it can be 0% or 1% or 3% or 5% or even 100% if the validator decides so. Hope this explains it, otherwise, please let me know if I misunderstood your question.
It looks this validator Mile in changing the commission to 10% before the election and then dropping it back to 0% and tricking users?
Any others doing the same?
Some validators are taking advantage of a UX issue: the most popular staking UI shows the current commission, but what actually matters is the commission recorded for each era. By flipping commission around the era boundary, a validator can look like “0% commission” most of the time while still charging a higher commission in the era that actually matters. You can see this preference-flip pattern in events like this.
Luckily, https://staking.usepapi.app/ isn’t susceptible to this because it displays the actual commission charged per era.
Validators can change their preferences at any time (commission and whether they accept nominations). That’s allowed by protocol, and it’s ultimately on nominators to make sure that they are nominating to validators that are worthy of their nomination.
What a few validators do is change their preferences twice around the era boundary:
Staking.ErasValidatorsPrefsYou can see an example of that “bump then reset” pattern here.
Because the most commonly used staking UI (the one most nominators rely on) shows current commission, not the commission that was actually applied in recent eras. So a validator can appear “0% commission” at a glance, while still capturing commission at the moment that matters.
Nominators using the PAPI staking optimizer won’t fall for this for two reasons:
For example:
In this screenshot you can see an example of one of the validators that you asked about (15tfUt4iQNjMyhZiJGBf4EpETE2KqtW1nfJwbBT1MvWjvcK9). As you can see, our UI displays the actual commission that they charged in each era, not the commission that they currently have. You can also see that this validator is in the position 400 when sorted by APY. Therefore, nominators using the PAPI staking optimizer are not susceptible to fall for this “trick”.
Small UI note: That being said, we realized we can make this even more explicit on the individual validator page, and we’ll likely ship a small improvement shortly.
Lets expose this commission flippers:
Coinstudio - Commission History
Cypher Labs - Commision History
Mile - Commision History
Mile / Bravo - Commision History
Stake Hulk / Alpha - Commision History
StakedTech/ ONE - Commision History
Tesla - Commision History
YellowFin Tuna - Commision History
YellowFin Tuna / Adriatic - Commision History
Sorry for the ping but this is unnaceptable and this flippers should be blacklisted and removed from the ecosystem.
@Birdo @danicuki @Eric-W3F @GabrielJ @kianenigma @Karim @michalis @Nico @OliverTY
I see that it was a completely different question, my bad. Thanks @Megadot for bringing up this issue.
Indeed, this to me is untrustworthy behavior, it’s very disappointing to see fellow validators doing this, so sad this known malicious practice continues to happen.
Exactly, technically it’s the nominator’s responsibility (in their own interest), to select validators that do not act maliciously or with trickery. I hope this post, as well as tools like the PAPI staking dashboard, can help nominators to make better decisions when selecting their validators and can also help validators decide how they want to run their operation.
The more I investigate, the more serious issues I find.
The links posted before are after the AH migration, but here you can see that this flipping has been going on for MONTHS in the Relaychain. 
Cypher Labs - Commission History (relay chain)
Mile - Commission History (relay chain)
Mile / Bravo - Commission History (relay chain)
Tesla - Commission History (relay chain)
YellowFin Tuna - Commission History (relay chain)
YellowFin Tuna / Adriatic - Commission History (relay chain)
Thank you for discovering this, Megadot, and thank you Josep for developing a tool that lets you easily avoid this situation.
We are looking into it now and seeing what the best course of action is.
I have also tweeted about it here to get the word out, as a first step: https://x.com/BillLaboon/status/2008875413917855879
Ping warranted, thanks. I am chatting with the staking team on how to prevent this.
I get why this feels unacceptable, and I agree it makes sense to expose this behavior. I’d even be happy to help build a dashboard that highlights “fishy / questionable” patterns (commission flipping, sudden blocks, reward anomalies, etc.).
That said, we should keep in mind this is a permissionless, decentralized system. Strictly speaking, these validators are not breaking any rules… They’re simply operating within the incentives and mechanics we’ve established. The bigger problem is:
And this “within-the-rules but feels unfair” dynamic isn’t unique to commission flipping. There are other ways to gain an advantage while staying inside what’s allowed, for example:
So I don’t think the right response is “lets blacklist”. The durable fix is to improve the incentives and the tooling, so the playing field is transparent and nominators can make informed decisions.
In this particular case, the most direct fix is for staking apps to show era-effective commission (what was actually applied), not only “current commission”. Unfortunately, the dashboard that has been promoted for years as the “official” staking nomination UI is flawed here (and in other ways). That’s one of the reasons we built the PAPI staking optimizer, which shows commission as used in recent eras and ranks validators based on realized yield.
If you want to see what I’d personally consider a bigger structural issue, go to the validators section of the PAPI staking optimizer and disable the “Filter Blocked” toggle. You’ll see something like this:
Notice how all the highest-APY validators are blocked to “normal” nominators? That’s not a coincidence, it’s a predictable outcome of incentives and how participants choose to operate.
Is that “fair”? Maybe, maybe not. If you ask the ones who are benefiting the most from this, they will certainly tell you that’s completely fair 
. But it is currently part of the game as designed today. If we want to improve outcomes, we should push for:
There is no reason to fix this at the protocol-level, because this can (and should) be addressed on the UI/off-chain layer.
This is a great answer, thanks @josep.
On-chain, we already store 84 eras of historical `real` validator commission (in ErasValidatorPrefs), so frontends could show this to user instead of only showing the current but mutable commission rate.
That said, if there is a strong community demand, we could also consider adding rate-limiting on-chain to how often commission rate can be changed (once per era probably makes sense).
This issue was raised six months ago, and since little progress has been made since then, our previous discussions may remain a valuable reference.
Absolutely. This is basically a UX/tooling problem: frontends should surface the era-effective commission (what was actually applied in recent eras), not just a mutable “current commission”.
More broadly, we should invest in better off-chain tooling so building correct staking UIs is straightforward. One of the goals of the PAPI staking optimizer was exactly to demonstrate how the PAPI Staking SDK can be used to build sound staking interfaces.
I’d strongly recommend not adding on-chain rate limiting here.
Nominators must be educated so that they understand that they are expected to actively maintain their nominations. A rate limit is a stopgap that feels like it solves the issue, but in practice it mostly shifts behavior to the edges:
The clean solution is: better UIs + better education. If nominators can easily see “what this validator actually charged in recent eras” (and how that impacted yield), then this whole class of behavior becomes self-correcting through market dynamics, without complicating the staking pallet.
I’m very much against any solution that reenforces the wrong perception that nominators are not supposed to keep taps on their nominations.
Just slash them
You see, this is a perfect example of people not understanding how Nomination Proof of Stake actually works. For starters most of these validators don’t even have any self-stake, so you will be penalizing the nominators that are already “victims” of the “naughtiness” of those validators. Slashing is a very extreme mechanism that should only be used to guarantee the security of the network. 
@bill_w3f @OliverTY The Polkadot Live app has had validator commission change notifications for years - I recommend the community using this tool to keep an eye on their validator statuses in real time, as well as other real time chain changes on a multitude of state items. It is a useful tool for identifying change patterns of state items.
As far as the Staking Dashboard - we will review and amend the necessary UI if it is warranted. I will say though that our selection algorithms are calculated on a month of validator performance on multiple dimensions, and not only for the currently assigned validator commission.
Whoever nominates must learn to choose carefully the validator to which he entrusts his DOTs, this is the other rule of the NPOS
