Networks marketed as always available have stopped producing blocks on multiple occasions, and the causes reveal genuine design trade-offs.
Resource exhaustion
Transaction volume exceeding what validators could process.
Which produced halts requiring coordinated restart.
Bot activity around high-demand events was the trigger in several cases.
Consensus implementation bugs
Validators disagreeing about state due to a code defect.
Which stops finality and requires patching before resumption.
Networks with a single dominant client implementation are more exposed to this.
The restart problem
Resuming requires coordination among validators about which state to continue from.
Which is a social process conducted through communication channels.
The existence of that process is itself informative about how decentralised a network actually is.
Fee market design
Networks with very low fees have less economic protection against spam.
Which is a deliberate trade for accessibility.
Local fee markets and priority mechanisms were introduced in response.
Validator requirements
High hardware requirements enable throughput and reduce the number of participants.
Which concentrates who can restart a network after a halt.
Published validator counts and requirements allow this to be assessed.
Finality mechanisms
Networks with explicit finality can stall rather than fork when validators disagree.
Which prioritises safety over liveness.
Networks without it continue producing blocks and can reorganise instead.
Communication during incidents
Status pages, validator coordination channels and post-incident reports.
Which vary substantially in quality between networks.
Published post-mortems are the useful artefact.
The general point
Every network chooses between safety and liveness under adverse conditions, and outages are that choice becoming visible.
Duration and impact
Outages have ranged from hours to more than a day.
Which affected applications, exchanges and users depending on the network.
Liquidations and time-sensitive operations were disrupted in several cases.
Client software patches
Resumption typically required a patched client distributed to validators.
Which is a coordinated software deployment under time pressure.
Testing under those conditions is necessarily limited.
Prevention measures
Fee market redesign, transaction admission controls and stake-weighted quality of service.
Which have reduced outage frequency on affected networks.
Published incident reports document what was changed after each.
Comparison across networks
Some major networks have never halted; others have halted repeatedly.
Which correlates with design choices about throughput and validator requirements.
Uptime is a checkable historical fact rather than a claim.
The user perspective
Funds are not at risk during a halt, and access to them is, which matters for anything time-sensitive.
Validator coordination channels
Restart decisions are made through communication among operators.
Which is a social process with identifiable participants.
The existence and composition of those channels is informative about a network's actual decentralisation.
Exchange responses
Venues suspend deposits and withdrawals during halts.
Which protects them and leaves users unable to move funds.
Suspension notices are published and are the practical signal for users.
Application-level effects
Protocols depending on price updates or liquidations are exposed during halts.
Which has produced knock-on losses.
Designs accounting for chain unavailability handle this better.
Improvement over time
Affected networks have reduced outage frequency substantially through specific changes.
Which is documented in their published incident reports.
How to assess a network
Historical uptime, validator count, client diversity and published incident handling.
The trade-off stated plainly
High throughput requires capable validators; capable validators are fewer; fewer validators means restart decisions are made by a small identifiable group.
Networks that have never halted generally made the opposite choice and accepted lower capacity for it.
Neither is wrong, and marketing rarely presents it as a choice at all.
What to check about a network
Historical uptime, validator count, hardware requirements, client diversity and published incident reports.
All of which are public.
Marketing about reliability is considerably less informative than an incident history.
Why it matters to users
During a halt, funds are safe and inaccessible, which is fine unless something time-sensitive is happening.
Liquidations, expiring options and arbitrage positions all care about the difference, and several users have discovered that during outages.
Transparency during incidents
Status pages, validator communications and published post-mortems.
Which vary substantially in quality and speed.
Networks publishing detailed technical post-mortems generally improved faster afterwards.
Design responses that worked
Fee market changes, transaction admission controls and stake-weighted prioritisation.
Which reduced recurrence measurably on affected networks.
A closing note
A network that has never halted has made a choice about capacity to achieve that, and a network that halts occasionally has made the opposite choice.
Presenting either as simply better than the other misses that both are positions on the same trade-off.
What to check
Historical uptime, validator count, client diversity and how past incidents were handled and reported.
All public, all more informative than reliability claims in documentation.
An incident history with detailed post-mortems is a better signal than a perfect record with no explanation of how it was achieved.
Transparency about failure is generally the better indicator of engineering seriousness.