
When Validators Won't Update
Posted on Monday, 21 July 2025Suggest An EditTable of Contents
- When Validators Won’t Update: Or, how Polkadot learned to stop worrying and love the economic incentive
- The Beautiful Lie We Tell Ourselves
- The Day the Music Stopped
- From Shame to Economics
- The New Deal
- The Dual-Layer Cake
- The 33% Solution
- The Nominator Wake-Up Call
- Beyond Slashing: Rewarding Performance
- The Economics of Attention
- Client Diversity as Risk Management
- What We’ve Learned
- The Magic of Aligned Incentives
- Looking Forward
When Validators Won’t Update: Or, how Polkadot learned to stop worrying and love the economic incentive
There’s something deeply human about the way blockchain networks fail. We build these elaborate cryptographic systems, Byzantine fault-tolerant consensus mechanisms, and mathematically provable security models – and then watch them grind to a halt because Bob hasn’t updated his software in six months.
This is a story about Polkadot, economic incentives, and what happens when you realize that the biggest threat to your network isn’t a sophisticated adversary, but simple human laziness.
The Beautiful Lie We Tell Ourselves
When we design distributed systems, we make certain assumptions about the participants. We assume validators will:
- Keep their software updated
- Actually verify the blocks they’re supposed to check
- Participate constructively in the network
These assumptions feel reasonable. After all, validators are earning rewards. They have skin in the game. Surely they’ll do the bare minimum required to keep earning those rewards?
As it turns out, no. Not really.
The dirty secret of proof-of-stake networks is that once you’re in the validator set, the path of least resistance is to do as little as possible. Run ancient client versions. Rubber-stamp approvals without checking. Collect rewards. Why bother with the hassle of updates when the network seems to run fine without them?
The Day the Music Stopped
In May 2025, this theoretical vulnerability became very real. For 23 hours, Kusama – Polkadot’s canary network – couldn’t finalize blocks. Not because of an attack. Not because of a bug. But because 40+ validators were running client versions from months ago.
Here’s what happened: These outdated nodes encountered a new candidate receipt format (RFC-103) that their ancient clients couldn’t understand. So they did what confused validators do – they disputed the blocks. All of them. The dispute avalanche brought finality to a grinding halt.
Imagine building a fault-tolerant system that can handle up to 33% of validators being actively
malicious, only to watch it fail because 10% of validators couldn’t be bothered to run apt-get update
.
From Shame to Economics
The evolution of Polkadot’s approach to this problem reveals something fundamental about human nature and system design.
In the beginning, there was “chilling” – a quaint mechanism where slashed validators would voluntarily step down from the next election cycle. The network essentially expected bad actors to feel ashamed and remove themselves. There was also Im-Online, a heartbeat system where validators would ping the network to prove they were alive.
These mechanisms shared a common philosophy: they assumed validators would behave responsibly either out of shame or through gentle nudges. It’s the blockchain equivalent of expecting people to return their shopping carts because it’s the right thing to do.
Spoiler: they don’t.
So Polkadot did what any system dealing with humans eventually must do – it gave up on shame and embraced cold, hard economics.
The New Deal
The solution is elegant in its brutality:
pub enum DisputeOffenceKind {
ForInvalidBacked, // 100% stake slash - you proposed garbage
ForInvalidApproved, // 2% stake slash - you approved garbage
AgainstValid, // Era ban - you disputed good blocks
}
That 2% for approval violations is the key innovation. It’s small enough that honest mistakes won’t
destroy you, but large enough to hurt. With validators typically staking around
Suddenly, that $200/month server upgrade looks pretty reasonable.
The Dual-Layer Cake
But wait, there’s more. The system now implements two distinct layers of punishment:
Onchain disabling is the economic layer – triggered by slashable offenses, lasting entire eras, preventing you from all the fun validator activities like block production and backing.
Offchain disabling is the behavioral layer – a shorter timeout triggered just by losing disputes. It’s like being put in the penalty box for a few hours to think about what you’ve done.
This dual system recognizes that not all misbehavior is equal. Sometimes you need a sledgehammer (economic penalties), sometimes you just need a timeout.
The 33% Solution
Here’s where it gets philosophically interesting. The disabling limit increased from 17% to 33% – exactly the Byzantine fault tolerance threshold. The network is essentially saying: “We can handle up to one-third of you being terrible. But no more.”
When more than 33% of validators misbehave, the system doesn’t panic and force a new era like it used to. Instead, it keeps only the worst offenders disabled. This creates a fascinating dynamic – a competition to be the “least bad” among the misbehaving validators.
It’s like being graded on a curve, but for Byzantine behavior.
The Nominator Wake-Up Call
For years, nominators have been the sleepy capital allocators of the Polkadot ecosystem. Set your nominations once, forget forever, collect your ~14% APY. What could be simpler?
Well, that free lunch just got a price tag.
When your validator gets slashed 2% for being lazy, you get slashed too. If you’re nominating with
100,000 DOT and your validator messes up, you lose
This creates a beautiful market dynamic. Nominators start caring about client versions. Validators who don’t update lose stake. Natural selection, but for blockchain participants.
Beyond Slashing: Rewarding Performance
The approval slashes represent just one side of Polkadot’s economic evolution. While slashes punish bad behavior, Jeff Burdges from Web3 Foundation has proposed RFC119 to fundamentally restructure validator rewards to incentivize good performance.
The proposal would shift reward distribution from the current flat model to one based on actual work performed:
- 70-75% for parachain security (approval checking, backing)
- 15-20% for relay chain operations (block production)
- 5-10% for availability distribution
- 5% for finality tasks
This creates a double-sided economic pressure: validators lose money for being lazy (slashes) and make more money for being active (performance rewards). The combination should drive professional validator operations while pushing out the passive participants who’ve been riding on network effects.
However, both slashing and performance rewards introduce geographic centralization risks. Validators in regions with poor connectivity to European hubs may find themselves unable to compete regardless of their operational competence – a consideration Web3 Foundation’s Decentralized Nodes Program will need to address.
The Economics of Attention
The beauty of this system is that it prices attention correctly. Previously, validator maintenance was an externalized cost – lazy validators imposed risks on the entire network while capturing the same rewards as diligent ones.
Now the cost of inattention falls directly on those who choose not to pay attention. Market forces can finally work their magic:
- Attentive validators retain more stake over time
- Lazy validators gradually lose nominations
- The most professional operations grow their influence
- The network becomes more reliable without central planning
Client Diversity as Risk Management
Here’s an unexpected consequence: with real economic penalties, running the same client as everyone else becomes a correlated risk. If a bug causes mass slashing, you want to be on a different implementation.
The system accidentally created an economic incentive for client diversity. Sometimes the best solutions are the ones you don’t design.
What We’ve Learned
There’s a pattern here that extends beyond blockchain. When you’re designing systems that depend on human behavior, you have two choices:
- Hope people will do the right thing
- Make it expensive to do the wrong thing
Polkadot started with option 1. They had reputation systems, voluntary withdrawal, gentle nudges. It was idealistic and beautiful and completely ineffective.
Now they’ve embraced option 2. No more assuming validators will update out of duty or pride. No more hoping nominators will pay attention. Just cold, hard economic reality: participate properly or pay the price.
The Magic of Aligned Incentives
What makes this solution elegant isn’t the slash percentages or the dual-layer system. It’s that it aligns everyone’s incentives with the network’s needs.
Validators want to keep their stake. So they update their clients. Nominators want to keep their stake. So they monitor their validators. The network wants active, updated participants. So it gets them.
No central authority needed. No governance votes begging people to update. Just economics doing what economics does best – modifying behavior at scale.
Looking Forward
The approval slashes update represents a philosophical maturation in blockchain thinking. We started with the belief that decentralized systems could run on goodwill and shared purpose. We’re learning that while those things matter, they’re not enough.
In the end, sustainable systems need sustainable incentives. And in the realm of blockchain, sustainable incentives are denominated in tokens.
Welcome to the new Polkadot: where laziness has a price tag, and that price is exactly high enough to make you care.
The state transition from reputation to economics isn’t just about fixing a technical problem. It’s about acknowledging a fundamental truth: in systems where anyone can participate, you can’t rely on everyone being competent, diligent, or even well-intentioned. You can only rely on everyone responding to incentives.
And maybe that’s enough.