Details
As of the Celestia v3 upgrade (block 2993219), the theoretical block time was reduced from 12 seconds to 6 seconds. However, in practice, average block times have decreased from ~10s to ~5s. Accordingly, the SignedBlocksWindow was doubled from 5000 to 10000 to maintain the same ~3h30min effective slashing window.
{
"SignedBlocksWindow": 10000,
"MinSignedPerWindow": 0.75
}
With these parameters, a validator is jailed if they miss 2,500 consecutive blocks (25% of 10,000), which—at 5 seconds per block—equates to roughly 3 hours and 30 minutes.
While this may seem sufficient on paper, our recent experience shows that it is not enough to realistically respond to real-world infrastructure incidents—especially those that occur during nighttime hours.
Case Study: node101 Incident – What we experienced
On December 29, 2024 at 03:58:18 UTC (block 3268199), our validator was jailed due to a server failure. The machine we had rented suddenly entered read-only mode, disabling the validator. Despite having a fully functional monitoring setup, no alert could resolve the underlying hardware issue fast enough—especially since it occurred during nighttime in our region (UTC+3, Turkey).
We immediately changed providers and rebuilt our infrastructure, but the damage was done. A one-time, unpredictable server failure resulted in a jailing penalty that undermined months of continuous, high-quality validator operation.
We’re Not Alone
After discussing with other validators, we discovered that many were jailed around the same time. Some of them include:
And surely others whose experiences we don’t yet know about. These were not cases of negligence, but rather unavoidable technical interruptions—happening during a slashing window too short to reasonably recover from.
Why This Matters
We fully recognize that being jailed is not a light matter—it directly impacts network liveness and the staking rewards of delegators who trust us with their assets. At node101, we treat this responsibility as paramount and always aim to operate with the highest standards of reliability and responsiveness.
However, real-world infrastructure issues can still arise. Hardware failures, kernel panics, or sudden provider-side restrictions are situations no validator is immune to, no matter how robust their monitoring systems are.
The current 3.5-hour jailing window leaves an extremely narrow margin for recovery from such incidents. It’s not about time zones or sleep schedules—at any given moment, somewhere in the world it’s night, and validators operate across all continents. Even the most committed teams can’t ensure human intervention 24/7 without unsustainable operational overhead.
We believe the slashing window should reflect both technical realities and the effort validators already put into proactive monitoring.
Proposal
We propose to double the SignedBlocksWindow from 10000 to 20000. This change increases the effective jailing threshold from ~3h30min to ~7h, calculated as:
20000 × (1 - 0.75) = 5000 blocks
5000 blocks × 5s = 25,000 seconds = ~6.94 hours
{
"SignedBlocksWindow": 20000,
"MinSignedPerWindow": 0.75
}
Uptime Perspective
Let’s put this into an annual reliability context:
- Total hours in a year:
365 days × 24 hours = 8,760 hours - If a validator is down once for 7 hours:
8,760 - 7 = 8,753 hours uptime
(8,753 ÷ 8,760) × 100 ≈ 99.92% uptime - If down twice for 7 hours (14 hours total):
8,760 - 14 = 8,746 hours uptime
(8,746 ÷ 8,760) × 100 ≈ 99.84% uptime
These are extremely high availability levels—comparable to enterprise-grade SLAs—yet still susceptible to jailing under the current 3.5-hour window. That’s the imbalance we aim to address.
This proposal doesn’t weaken slashing—it preserves validator accountability while recognizing real-world ops. It’s a step toward greater fairness and resilience in a globally decentralized network.
Voting
YES — Increase the SignedBlocksWindow to 20000 blocks (~7h window)
NO — Keep the current SignedBlocksWindow at 10000 blocks (~3h30min window)
Authors
- node101 Validator
- P-OPS Team Validator